Re: Proposed F19 Feature: GLIBC 2.17
On 01/28/2013 03:02 AM, Florian Weimer wrote: GLIBC 2.17 was released at the end of 2012; we have been closely tracking the GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as they arise. The __secure_getenv to secure_getenv renaming need to be reflected in a few packages (as of Fedora 18): octave-3.6.3-2.fc18.2.src.rpm This was from octave's use of gnulib. I am told gnulib has since fixed this and newer versions of octave will have this. Thanks for the heads up. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
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
Re: Proposed F19 Feature: GLIBC 2.17
On Tue, Jan 29, 2013 at 10:39:21AM +0100, Florian Weimer wrote: 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). A @@GLIBC_PRIVATE symbol is not public. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
On 01/29/2013 10:47 AM, Jakub Jelinek wrote:
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).
A @@GLIBC_PRIVATE symbol is not public.
nss_hesiod needs secure_getenv, so a non-private symbol is needed. In
any case, I can link against __libc_secure_getenv in Fedora rawhide:
mock-chroot[root@oldenburg tmp]# rpm -q glibc
glibc-2.17-1.fc19.x86_64
mock-chroot[root@oldenburg tmp]# cat t.c
void __libc_secure_getenv();
int main()
{
__libc_secure_getenv();
return 0;
}
mock-chroot[root@oldenburg tmp]# gcc t.c
mock-chroot[root@oldenburg tmp]#
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
On Mon, 2013-01-28 at 11:02 +0100, Florian Weimer wrote: GLIBC 2.17 was released at the end of 2012; we have been closely tracking the GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as they arise. The __secure_getenv to secure_getenv renaming need to be reflected in a few packages (as of Fedora 18): openssl-1.0.1c-7.fc18.src.rpm Fixed already in rawhide. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
GLIBC 2.17 was released at the end of 2012; we have been closely tracking the GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as they arise. The __secure_getenv to secure_getenv renaming need to be reflected in a few packages (as of Fedora 18): source arm-gp2x-linux-glibc-2.3.6-11.fc18.src.rpm cadaver-0.23.3-4.fc18.src.rpm e2fsprogs-1.42.5-1.fc18.src.rpm gcal-3.6.2-3.fc18.src.rpm gettext-0.18.1.1-17.fc18.src.rpm m4-1.4.16-5.fc18.src.rpm octave-3.6.3-2.fc18.2.src.rpm openssl-1.0.1c-7.fc18.src.rpm popt-1.13-12.fc18.src.rpm pspp-0.7.9-2.fc18.src.rpm rpm-4.10.2-1.fc18.src.rpm systemd-197-1.fc18.1.src.rpm util-linux-2.22.1-2.4.fc18.src.rpm wget-1.14-3.fc18.src.rpm Some of these are a bit peculiar, but the e2fsprogs entry is genuine. 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. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
On Mon, 28 Jan 2013 11:02:31 +0100 Florian Weimer fwei...@redhat.com wrote: GLIBC 2.17 was released at the end of 2012; we have been closely tracking the GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as they arise. The __secure_getenv to secure_getenv renaming need to be reflected in a few packages (as of Fedora 18): ...snip... Are there bugs filed on these packages? Might be good to either just fix them all (if a provenpackager is willing), mail all the owners to make the change or file bugs on them with a tracking bug so it's not forgotten. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
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. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: GLIBC 2.17
= Features/GLIBC217 = https://fedoraproject.org/wiki/Features/GLIBC217 Feature owner(s): Jeff Law l...@redhat.com Switch GLIBC in Fedora 19 to GLIBC version 2.17. == Detailed description == GLIBC 2.17 was released at the end of 2012; we have been closely tracking the GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as they arise. The proposed mass-rebuild with GCC 4.8 [1] in February should also shake out any remaining problems with GLIBC's header files. [1] https://fedoraproject.org/wiki/Features/GCC48 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: GLIBC 2.17
= Features/GLIBC217 = https://fedoraproject.org/wiki/Features/GLIBC217 Feature owner(s): Jeff Law l...@redhat.com Switch GLIBC in Fedora 19 to GLIBC version 2.17. == Detailed description == GLIBC 2.17 was released at the end of 2012; we have been closely tracking the GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as they arise. The proposed mass-rebuild with GCC 4.8 in February should also shake out any remaining problems with GLIBC's header files. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
