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