the glibc-2.5-hardened-configure-picdefault.patch patch fails to apply when trying to build glibc with the hardened use-flag / hardened gcc / hardened profile Reproducible: Always Steps to Reproduce: 1. emerge glibc -1 2. 3. Actual Results: >>> Unpacking source... * Checking gcc for __thread support ... [ ok ] * Checking kernel version (2.6.29 >= 2.6.9) ... [ ok ] * Checking linux-headers version (2.6.29 >= 2.6.9) ... [ ok ] >>> Unpacking glibc-2.10.1.tar.bz2 to /var/tmp/portage/sys-libs/glibc-2.10.1/work >>> Unpacking glibc-libidn-2.10.1.tar.bz2 to /var/tmp/portage/sys-libs/glibc-2.10.1/work/glibc-2.10.1 >>> Unpacking glibc-2.10.1-patches-1.tar.bz2 to /var/tmp/portage/sys-libs/glibc-2.10.1/work * Applying Gentoo Glibc Patchset 2.10.1-1 ... * 0030_all_glibc-respect-env-CPPFLAGS.patch ... [ ok ] * 0040_all_glibc-i586-chk.patch ... [ ok ] * 0070_all_glibc-i386-x86_64-revert-clone-cfi.patch ... [ ok ] * 0085_all_glibc-disable-ldconfig.patch ... [ ok ] * 1010_all_glibc-queue-header-updates.patch ... [ ok ] * 1030_all_glibc-manual-no-perl.patch ... [ ok ] * 1040_all_2.3.3-localedef-fix-trampoline.patch ... [ ok ] * 1055_all_glibc-resolv-dynamic.patch ... [ ok ] * 1070_all_glibc-fadvise64_64.patch ... [ ok ] * 1073_all_glibc-ldbl-nexttowardf.patch ... [ ok ] * 1075_all_glibc-section-comments.patch ... [ ok ] * 1080_all_glibc-no-inline-gmon.patch ... [ ok ] * 1085_all_glibc-2.9-check_native-headers.patch ... [ ok ] * 1090_all_glibc-2.3.6-fix-pr631.patch ... [ ok ] * 1095_all_glibc-2.9-assume-pipe2.patch ... [ ok ] * 1100_all_glibc-2.3.3-china.patch ... [ ok ] * 1103_all_glibc-new-valencian-locale.patch ... [ ok ] * 1130_all_glibc-2.4-undefine-__i686.patch ... [ ok ] * 1160_all_glibc-2.8-nscd-one-fork.patch ... [ ok ] * 3000_all_2.3.6-dl_execstack-PaX-support.patch ... [ ok ] * 3010_all_2.3.3_pre20040117-pt_pax.patch ... [ ok ] * 3020_all_glibc-tests-sandbox-libdl-paths.patch ... [ ok ] * 5021_all_2.9-fnmatch.patch ... [ ok ] * 5063_all_glibc-dont-build-timezone.patch ... [ ok ] * 5070_all_glibc-2.7-cross-compile-nptl.patch ... [ ok ] * 6120_all_ppc-glibc-2.9-atomic.patch ... [ ok ] * 6418_all_sh-glibc-2.9-set-fpscr-proto.patch ... [ ok ] * 6645_all_glibc-mips_shn_undef-hack.patch ... [ ok ] * Done with patching * Using GNU config files from /usr/share/gnuconfig * Updating scripts/config.sub [ ok ] * Updating scripts/config.guess [ ok ] * Patching to get working PIE binaries on PIE (hardened) platforms * Applying glibc-2.5-hardened-pie.patch ... [ ok ] * Applying glibc-2.5-hardened-configure-picdefault.patch ... * Failed Patch: glibc-2.5-hardened-configure-picdefault.patch ! * ( /usr/gentoo/portage_old/sys-libs/glibc/files/2.5/glibc-2.5-hardened-configure-picdefault.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-libs/glibc-2.10.1/temp/glibc-2.5-hardened-configure-picdefault.patch-11066.out * * ERROR: sys-libs/glibc-2.10.1 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 3590: Called eblit-run 'src_unpack' * environment, line 1188: Called eblit-run-maybe 'eblit-src_unpack-post' * environment, line 1192: Called eblit-src_unpack-post * environment, line 1200: Called epatch '/usr/gentoo/portage_old/sys-libs/glibc/files/2.5/glibc-2.5-hardened-configure-picdefault.patch' * environment, line 1945: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * The die message: * Failed Patch: glibc-2.5-hardened-configure-picdefault.patch! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/sys-libs:glibc-2.10.1:20090518-111408.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.10.1/temp/environment'. Expected Results: it should have applied cleanly
Created attachment 191646 [details] output of the failed patch
Created attachment 191653 [details, diff] Fixed for glibc 2.10
Created attachment 191654 [details, diff] Fixed for glibc 2.10
emerge --info please.
Created attachment 191673 [details] emerge --info
that did it ! Thanks a lot Magnus =) you guys are FAST ^^ should I set it to "FIXED" or wait for another (gentoo)dev to attend and do it ?
(In reply to comment #6) > that did it ! > > Thanks a lot Magnus =) > > you guys are FAST ^^ > > should I set it to "FIXED" or wait for another (gentoo)dev to attend and do it > ? > yes if get commited.
I tried the patch of Magnus too, but it fails again with: ... * Applying glibc-2.5-hardened-configure-picdefault.patch ... * Failed Patch: glibc-2.5-hardened-configure-picdefault.patch ! * ( /usr/local/portage/sys-libs/glibc/files/2.5/glibc-2.5-hardened-configure-picdefault.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-libs/glibc-2.10.1-r1/temp/glibc-2.5-hardened-configure-picdefault.patch-10059.out in glibc-2.5-hardened-configure-picdefault.patch-10059.out I find: ***** glibc-2.5-hardened-configure-picdefault.patch ***** ========================================================= PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/local/portage/sys-libs/glibc/files/2.5/glibc-2.5-hardened-configure-picdefault.patch ========================================================= patching file configure.in Hunk #1 FAILED at 2145. 1 out of 1 hunk FAILED -- saving rejects to file configure.in.rej patching file configure Hunk #1 FAILED at 7698. 1 out of 1 hunk FAILED -- saving rejects to file configure.rej ========================================================= ,,,
no it doesn't ;) (for me) Juergen, you are sure you changed the lines in the ebuild and added a folder called 2.10 in the files subdirectory with those 2 files in it ? cause it still reads glibc-2.5* but the new patches are called glibc-2.10*
I've make an minimalistic ebuild-package for this patch (thanks to Magnus Granberg!), but it have to much files to post them into bugzilla. You can find ebuild into my overlay via git: git clone git://vcs.niifaq.ru/portage or via ftp wget -r ftp://ftp.niifaq.ru/pub/portage/sys-libs/glibc/ Links above are hosted on homeserver, so it could be inaccessible sometimes, so everybody welcome to rehost it on any more stable resource (such as github or google-code).
I have to state, that upgrading my server to new glibc broke it's system. This message now appears everywhere: relocation error: screen: symbol __guard, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference So, maybe it would be wise to wait untill glibc would be properly patched by hardened team, I suppose this patch issue some kind of another funny hardened joke: it's acting as package.mask =)
Gentoo patchset is missing the ssp-compat.patch that support the older __guard symbols for < gcc 4.1 We have mask glibc 2.10 in the hardened profile.
Created attachment 192348 [details, diff] ssp-compat patch for __guard NOT TESTED This patch is NOT TESTED
@hardened: Please check these patches and apply if fine.
I created an overlay /usr/local/portage/sys-libs/glibc/, copied there glibc-2.10.1.ebuild to glibc-2.10.1-r1.ebuild, created a /usr/local/portage/sys-libs/glibc/files/2.10 directory, put the two patches into that directory: root@mouse:/usr/local/portage/sys-libs/glibc(10)# ll /usr/local/portage/sys-libs/glibc/files/2.10/ total 16 -rw-r--r-- 1 root root 865 May 25 00:23 glibc-2.10-hardened-configure-picdefault.patch -rw-r--r-- 1 root root 8823 May 21 15:26 glibc-2.10-hardened-inittls-nosysenter.patch added two lines after the end of the other patch lines epatch "${FILESDIR}"/2.10/glibc-2.10-hardened-inittls-nosysenter.patch after the other epatch lines: root@mouse:/root(5)# diff -C 3 /usr/local/portage/sys-libs/glibc/glibc-2.10.1-r1.ebuild /usr/local/portage/sys-libs/glibc/glibc-2.10.1.ebuild diff -C 3 /usr/local/portage/sys-libs/glibc/glibc-2.10.1-r1.ebuild /usr/local/portage/sys-libs/glibc/glibc-2.10.1.ebuild *** /usr/local/portage/sys-libs/glibc/glibc-2.10.1-r1.ebuild Mon May 25 02:01:10 2009 --- /usr/local/portage/sys-libs/glibc/glibc-2.10.1.ebuild Mon May 18 06:41:59 2009 *************** *** 186,195 **** cd "${S}" einfo "Patching to get working PIE binaries on PIE (hardened) platforms" gcc-specs-pie && epatch "${FILESDIR}"/2.5/glibc-2.5-hardened-pie.patch ! epatch "${FILESDIR}"/2.5/glibc-2.5-hardened-configure-picdefault.patch ! epatch "${FILESDIR}"/2.7/glibc-2.7-hardened-inittls-nosysenter.patch ! epatch "${FILESDIR}"/2.10/glibc-2.10-hardened-configure-picdefault.patch ! epatch "${FILESDIR}"/2.10/glibc-2.10-hardened-inittls-nosysenter.patch einfo "Installing Hardened Gentoo SSP handler" cp -f "${FILESDIR}"/2.6/glibc-2.6-gentoo-stack_chk_fail.c \ --- 186,193 ---- cd "${S}" einfo "Patching to get working PIE binaries on PIE (hardened) platforms" gcc-specs-pie && epatch "${FILESDIR}"/2.5/glibc-2.5-hardened-pie.patch ! epatch "${FILESDIR}"/2.5/glibc-2.5-hardened-configure-picdefault.patch ! epatch "${FILESDIR}"/2.7/glibc-2.7-hardened-inittls-nosysenter.patch einfo "Installing Hardened Gentoo SSP handler" cp -f "${FILESDIR}"/2.6/glibc-2.6-gentoo-stack_chk_fail.c \ run 'ebuild glibc-2.10.1-r1.ebuild digest' in that directory. And then 'emerge -vD glibc' fails with the described error. Then I commented out the first two patch lines and now I can emerge glibc-2.10.1 on a hardened system. Thanks
Two months fixed and still not in portage? What the hell?
There is still an issue with _guard symbols. Fix was in blacklisting glibc. If you still want to use it, you may add a patch for youself and recompile the whole system to get rid of old symbols. I presume, that there is a lot of work with new glibc and hardened, so I suppose, that unmasking it at begining was an error.
This bug's a serious issue for those who converted their make.profile to hardened from another profile, since it stamps down portage/revdep-rebuild/etc with it always trying to downgrade glibc then stopping itself so that it doesn't break the system. The solution is to simply add: <=sys-libs/glibc-2.9_p20081201-r2 To /etc/portage/package.mask, but that still doesn't fix revdep-rebuild wanting to re-emerge glibc to fix some dependencies.
complaining will get you nowhere in bugzilla. if you want to actually help, test the hardened-ssp-compat patch. i didnt feel like updating it when i bumped glibc to 2.10.
New patches are in main tree. The package.mask for glibc-2.10.1 is to remain in place per gengor. If a user wishses to test and finds a bug please open a new bug report with all avaliable data.
that statement isnt terribly clear. does glibc-2.10.1 now cleanly unpack for hardened users ?
(In reply to comment #21) > that statement isnt terribly clear. does glibc-2.10.1 now cleanly unpack for > hardened users ? > It does for me.
(In reply to comment #21) > that statement isnt terribly clear. does glibc-2.10.1 now cleanly unpack for > hardened users ? > Yes 2.10.1 unpacks fine for hardened now.
thanks for checking
The following lines need to be removed from /var/cvsroot/gentoo-x86/profiles/hardened/linux/package.mask: # Patch fails, mask for now. Bug #270274. >=sys-libs/glibc-2.10 Because as it is now, doing an emerge --sync will still mask 2.10.1: !!! One of the following masked packages is required to complete your request: - sys-libs/glibc-2.10.1 (masked by: package.mask) /usr/portage/profiles/hardened/linux/package.mask: # Patch fails, mask for now. Bug #270274.
(In reply to comment #25) > The following lines need to be removed from > /var/cvsroot/gentoo-x86/profiles/hardened/linux/package.mask: > # Patch fails, mask for now. Bug #270274. > >=sys-libs/glibc-2.10 > > Because as it is now, doing an emerge --sync will still mask 2.10.1: > !!! One of the following masked packages is required to complete your request: > - sys-libs/glibc-2.10.1 (masked by: package.mask) > /usr/portage/profiles/hardened/linux/package.mask: > # Patch fails, mask for now. Bug #270274. > Mask was dropped by SpanKY ~2hours ago (from the time of this writing). Will be gone on your next emerge --sync.
