Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

Michael scherer misc at zarb.org
Thu May 1 09:44:54 UTC 2014


On Tue, Apr 29, 2014 at 12:08:11PM -0300, Paulo César Pereira de Andrade wrote:
> 2014-04-27 19:02 GMT-03:00 Andrew Price <anprice at redhat.com>:
> > On 24/04/14 15:13, Lennart Poettering wrote:
> >>
> >> We probably should make setjmp()-freeness a requirement for
> >> all code included in Fedora.
> >
> >
> > Would it be worth the effort, and how feasible is it anyway?
> > - Do we have any usage statistics?
> > - How often do we see bugs caused by bad uses of setjmp/longjmp?
> > - Is mitigation instead of blanket removal possible?
> > - How likely is it that /all/ setjmp/longjmp uses can be reasonably
> > replaced?
> > - Is there existing upstream momentum to move away from setjmp/longjmp?
> >
> > (I'm not against the idea but I think it deserves further discussion.)
> 
>   I think setjmp and longjmp should be treated as a warning, and
> replaced with sigsetjmp and siglongjmp, but not a fatal error, if I
> recall correctly, grub has its own setjmp/longjmp implementation.
>   Probably should be a rpmlint warning, like the one of libraries
> that call exit.

Or like the existing check on setuid order, etc.
 
But in order to be useful, we need a detailed reason on why it should 
be a warning, and what the packager should tell upstream. Even if I agree with
Ajax about being able to read source code ( which I do, and which permitted
to find security issues before it hit Fedora ), I also know not everybody
is fluent in programming. So without any page that outline why it is
a warning and that tell when it can be ignored, this will not be added to rpmlint.

-- 
Michael Scherer


More information about the devel mailing list