Re: linking statically against dietlibc: a blocker?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I suggest the developer-co should deside on this issue collectively wether the use of other library can be allowed or not (other the glibc to link the module) 
the core issue is use of standerds not the optimization...

Regards
Siddharth

----- Original Message ----
From: Enrico Scholz <enrico.scholz@xxxxxxxxxxxxxxxxxxxxxxxxx>
To: fedora-extras-list@xxxxxxxxxx
Sent: Wednesday, October 4, 2006 12:01:04 PM
Subject: Re: linking statically against dietlibc: a blocker?

wtogami@xxxxxxxxxx (Warren Togami) writes:

>> Tickets above are not for "random binaries" but for projects which
>> are designed for dietlibc. Using glibc for them would make binaries
>> larger, slower and increases memory usage without providing a single
>> gain.
>
> You lose the benefit of FORTIFY_SOURCE and address randomization of
> entry points of libc functions, both of which are detriments to
> security.

Please show me, where an argv0 implementation like

----
#include <unistd.h>
int main(int argc, char *argv[])
{
    if (argc<2)
        return 1;
    execvp(argv[1], argv+2);
    return 2;
}
----

can benefit from FORTIFY_SOURCE or address randomization.



Enrico

-- 
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list






-- 
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux