On 01/28/2013 06:31 PM, Bill Nottingham wrote:
Florian Weimer (fwei...@redhat.com) said:
See <http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv>
for code snippets to implement in the change in a
backwards-compatible fashion. Unfortunately, glibc upstream
insistent on renaming before making the symbol official.
I'm a little confused by the 'unfortunately' here - if apps are using a
private symbol, they should expect that they may need to change later.
Precisely because it's in the private namespace, glibc could just have
documented the existing __secure_getenv symbol. It's not that there
aren't any public functions starting with __. But this was rejected by
upstream, and now we have the __secure_getenv compatibility symbol (not
usable for fresh linking), secure_getenv, and __libc_secure_getenv for
internal glibc use (but which is still public for technical reasons).
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
