> From: Phil Knirsch <[EMAIL PROTECTED]>
[SNIP]
> Here now my comments/thoughts on the various items.
> 
> [EMAIL PROTECTED] wrote:
> > Hi, coders.  Working with the Redhat team to incorporate
> > several of their patches into the main code.
[SNIP]
> > #-#-#-#-#-#-#-#
> >                                                                                 
> > net-snmp-5.0.6-libtool.patch  Thanks for adding verbiage from the
> >  bug list on this one. Makes it easier for us to choose.
> >                                                                                 
> 
> That patch is required because of our buildmethod and having rpaths in 
> binaries is a very bad idea securitywise (i could elaborate a little 
> deeper, but trust me on this). You might ignore that patch for upstream, 
> but in our build environment it's really necessary.

I think not having rpaths is probably good from a security viewpoint, but I
wonder if it would create undo hardship for system administrators.

Any SAs willing to comment on NOT having Rpaths set in Net-SNMP binaries ?


[SNIP]
> > #-#-#-#-#-#-#-#
> > net-snmp-5.0.8-readonly.patch
> > This change to netsnmp_wrap_up_request fixing a problem with
> > processing RO vs RW objects (I'm not sure) was applied in a different
> > source location.
> 
> I've reviewed the latest code in snmp_agent.c and can't find a place 
> where you fix this somewhere else. Could you please be a little more 
> specific so i can verify that our patch is obsolete?

I"m sorry to be lame on this. Dave/Robert/Wes would know more about
recent (18 months) read-only MIB object changes.



[SNIP]
> > #-#-#-#-#-#-#-#
> > net-snmp-5.1.1-ipAdEntIfIndex.patch
> > Will adding struct in_ifaddr break compiles on RedHat 7.2 ?
> >                                                                                 
> 
> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119106
> It's not about breaking compiles, it's about a real bug that the IfIndex 
> on Linux sometimes is wrong.

Coders, would this conflict with recent changes made to the main branch ?
If not, I for one would think it appropriate to apply to the 5.1 and main branches.


> 
> > #-#-#-#-#-#-#-#
> > net-snmp-5.1.1-pie.patch
[SNIP]
> 
> [SNIP] it 
> actually stands for Position Independant Executable. Basically the 
> counterpart to -pic but for binaries instead of for libraries. This is 
> required for newer releases for exec-shield to work properly, which is a 
> security feature (makes buffer overflows much harder to exploit).

My ignorance tells me this may have unseen problems for other platforms.

> 
> > #-#-#-#-#-#-#-#
> > net-snmp-5.1.1-quiet-memshared.patch
> >   I would prefer wrapping using DEBUGMSGTL construct. Will Review.
> >                                                                                 
> 
> This was only needed to prevent a message log flood, but i suspect there 
> are tons of other places where one could do that, too, so again more 
> fairly Red Hat specific patch.
> > #-#-#-#-#-#-#-#
> > net-snmp-5.1-bsdcompat.patch
> >   Removing SO_BSDCOMPAT should be done in both places used.
> >   Patch does not address the code in snmpUDPIPv6Domain.c
> 
> Yep, true, patch should fix it in snmpUDPIPv6Domain.c as well. Not a 
> biggie, will do soon.
> 

memshared and bsdcompat were addressed in an improperly applied
patch, since removed. Coders, I would like comments on re-forming the patch.



> > #-#-#-#-#-#-#-#
> > net-snmp-5.1.2-lelf.patch
> >   We will need to make this elf test  "if not Linux"
> 
> Again as you say fairly Linux/Red Hat specific. IIRC the test just 
> produces a wrong/unecessary result on our distro so it was removed.

[SNIP]
> > #-#-#-#-#-#-#-#
> > net-snmp-5.1-64bit.patch
> >   Interesting that some of the changes are HPUX11 specific...
> >   What is the origin of this patch?
> >                                                                                 
> >   Regardless, this may take longer to segue.
> 
> That patch originally came from AMD. They verified that these fixes were 
> needed for their new AMD64 boxes. IIRC this is the 3rd revision of the 
> patch, so it has been around for quite some time now in our rpms.

Coders,  comments, please.


> 
> > #-#-#-#-#-#-#-#
> > net-snmp-5.1-async-getnext.patch
> >   Do you have a test for this Perl module patch ?
> 
> Again a patch from Kaj J. Niemi:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111479
> 
> He didn't provide a test though, but i generally trust his patches and 
> fixes.

Coders, would this have a positive effect if applied ?

[SNIP]
> 
> Thats all the comments so far. As i said, i'll extend two of the patches 
> in the next release we put out and as soon as 5.1.3 is out we can drop 
> an awfull lot of patches, too.
> 
> Read ya, Phil
> 
> -- 
> Philipp Knirsch      | Tel.:  +49-711-96437-470
> Development          | Fax.:  +49-711-96437-111
> Red Hat GmbH         | Email: Phil Knirsch <[EMAIL PROTECTED]>
> Hauptstaetterstr. 58 | Web:   http://www.redhat.de/
> D-70178 Stuttgart
> Motd:  You're only jealous cos the little penguins are talking to me.
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to