Summary: | dev-libs/openssl-3.0.7-r2 (and earlier 3.0.7) pkg_postinst() interactively waits for passphrases | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | orzel |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 855494, 893446 | ||
Bug Blocks: | |||
Attachments: |
full emerge --info
full emerge log (xz-compressed) |
Description
Duncan
2022-12-18 23:02:44 UTC
OpenSSL 3 is not being stabled. It was only unmasked a few days ago. It won't be stabled for many many months. You may be confusing it with the rekeywording bug to test our more niche arches. Created attachment 843597 [details] full emerge log (xz-compressed) Hmm... the log (which I'm having to compress) doesn't show the prompts that actually appeared on-screen? Only a bit of garbage from the interactivity. But it should be obvious from that and the above where the interactivity happened in the log. Meanwhile, in the mentioned bug comment https://bugs.gentoo.org/333069#c6 canonical encoding and symbolic links are mentioned, tho in 1.0.0 context from 2010 or earlier, and I wasn't having interactivity problems with 1.x, so something else has apparently changed as well, but that does hint that it could be reverse-usrmerge symlink resolution related. (In reply to Sam James from comment #1) > You may be confusing [stabilizing] with the > rekeywording bug to test our more niche arches. Duh, yes. Thanks. Makes a bit more sense now. Hit by this today. My emerge was stalled, doing nothing (no i/o, no cpu) for more than one hour. Hitting "enter" in the konsole gave this: >>> Installing (102 of 845) dev-util/kbuild-0.1.9998.3499-r2::gentoo >>> Installing (103 of 845) sys-apps/sysvinit-3.06-r1::gentoo >>> Installing (104 of 845) dev-libs/openssl-3.0.7-r2::gentoo >>> Jobs: 103 of 845 complete Load avg: 0.16, 0.39, 1.77 Enter pass phrase for dsa-ca.pem: >>> Jobs: 103 of 845 complete Load avg: 0.07, 0.33, 1.68 And at this point, i could confirm (using genlop) the 'installing' of openssl wasn't finished yet. It asked for two things, then kept on going. I enter garbage, so i was worrying about bad pem being installed, but 'equery files' can't find any *.pem or dsa-ca* in the openssl installed files.. ? Does /etc/ssl/certs/ca-dsa.pem exist on your system? I suspect you created it, and encrypted it with a password, which openssl is prompting you for. Maybe there's some way we can force openssl to never prompt for a password. There's no "ca-dsa.pem", but there are those two files: -rw-r--r-- 1 root root 2674 27 lug 2005 /etc/ssl/certs/dsa-pca.pem -rw-r--r-- 1 root root 2264 27 lug 2005 /etc/ssl/certs/dsa-ca.pem The system was actually installed later, in september 2005 (according to genlop -l |head), so i guess those files were from some package installed then. (In reply to Thomas Capricelli from comment #6) If the files don't contain private data, would you mind attaching them to this bug for reference? It would make it easier for me to reproduce the issue. Problem is I have no idea if there's private data in there. I guess not..? Anyway. I can reproduce the problem easily with "emerge -1 openssl". It blocks during install, and hitting enter will ask for a passphrase. I removed the two files (in some backup), and now openssl emerges without blocking. -> this confirm those files are the reason Those files are unknown by portage (qfile /etc/ssl/certs/dsa* -> returns nothing) I checked on 7 other gentoo boxes, and only one also have those files. This other box was installed in october 2009, but the files also are dated from 2005. Moreover they have the very same md5 as on the first box: verdi ~ # md5sum /etc/ssl/certs/dsa* 96ce4a8d7545ccb56c30c746997e2b25 /etc/ssl/certs/dsa-ca.pem d038ef2b4ce2084ef25ef743d0107dbd /etc/ssl/certs/dsa-pca.pem So i stay on my first impression: those files were installed long ago, are no longer needed, and for some reason weren't removed when the package (openssl?) was updated. The files do not exist on my systems, and I therefore have no easy way to reproduce the issue. If I can reproduce the issue, I can create a work around for systems that have this condition. If you are not comfortable attaching the files publicly, please send them to me via email directly. I think I tracked this down as demo/test files that used to ship with old versions of OpenSSL. https://github.com/openssl/openssl/blob/d02b48c63a58ea4367a0e905979f140b7d090f86/apps/dsa-pca.pem https://github.com/openssl/openssl/blob/d02b48c63a58ea4367a0e905979f140b7d090f86/apps/dsa-ca.pem Question, possibly with security implications due to the package: Should /etc/ssl/certs/ be in CONFIG_PROTECT_MASK by default? Because it's not, here, installed in 2004 (so ~ a year older than Thomas C's), and despite not remembering ever messing with certs (except I think I might have manually removed some after one of the headline cert-authority compromises a few years ago) it appears I have a number of orphan cert-symlinks at least, and possibly some orphan certs (the first two I quick-checked after equery belongs reported nothing for them were both symlinks so not absolutely sure there's actual certs), and now I'm worried that removed certs aren't actually being removed due to that dir being under /etc and thus CONFIG_PROTECTed by default. And it seems to me that CONFIG_PROTECT_MASKing it would at least keep the problem from growing and should arguably be the default, tho there's still the question of cleaning up anything orphaned/stale that's already there. (In reply to Duncan from comment #12) > it appears I have a number of orphan [certs and symlinks] Here's a complete list. Looks like all the certs are dated Feb 14 2005, with the symlinks to them dated Dec 18 (2021 of course), which was when I merged openssl-3.0.7-r2 and filed this bug. Given Thomas's same-2005-dates on multiple boxes, including one installed later (2009), I strongly suspect the 2005 dates were touched to that by either openssl or ca-certificates (the two pkgs owning /etc/ssl/certs here) for date-standardization purposes, and thus don't represent real file dates. $ for file in /etc/ssl/certs/*; do equery -q b -e $file >>/dev/null || ls -l $file; done lrwxrwxrwx 1 root root 10 Dec 18 15:14 /etc/ssl/certs/0f11b315.0 -> vsign2.pem lrwxrwxrwx 1 root root 11 Dec 18 15:14 /etc/ssl/certs/2852d829.0 -> factory.pem lrwxrwxrwx 1 root root 11 Dec 18 15:05 /etc/ssl/certs/3f77a2b5.0 -> ca-cert.pem lrwxrwxrwx 1 root root 12 Dec 18 15:14 /etc/ssl/certs/4cffcdf3.0 -> vsigntca.pem lrwxrwxrwx 1 root root 12 Dec 18 15:05 /etc/ssl/certs/5d8fd011.0 -> RegTP-4R.pem lrwxrwxrwx 1 root root 10 Dec 18 15:05 /etc/ssl/certs/60b1d593.0 -> ICE-CA.pem lrwxrwxrwx 1 root root 11 Dec 18 15:14 /etc/ssl/certs/6dcff108.0 -> rsa-cca.pem lrwxrwxrwx 1 root root 9 Dec 18 15:14 /etc/ssl/certs/6dfedfe8.0 -> tjhCA.pem lrwxrwxrwx 1 root root 9 Dec 18 15:14 /etc/ssl/certs/70510009.0 -> timCA.pem lrwxrwxrwx 1 root root 12 Dec 18 15:05 /etc/ssl/certs/c7fccc02.0 -> ICE-root.pem -rw-r--r-- 1 root root 1953 Feb 14 2005 /etc/ssl/certs/ca-cert.pem lrwxrwxrwx 1 root root 10 Dec 18 15:14 /etc/ssl/certs/cbdbd8bc.0 -> dsa-ca.pem lrwxrwxrwx 1 root root 11 Dec 18 15:14 /etc/ssl/certs/de4fa23b.0 -> dsa-pca.pem -rw-r--r-- 1 root root 2264 Feb 14 2005 /etc/ssl/certs/dsa-ca.pem -rw-r--r-- 1 root root 2674 Feb 14 2005 /etc/ssl/certs/dsa-pca.pem lrwxrwxrwx 1 root root 12 Dec 18 15:14 /etc/ssl/certs/e83ef475.0 -> pca-cert.pem lrwxrwxrwx 1 root root 12 Dec 18 15:14 /etc/ssl/certs/ee1d0b94.0 -> nortelCA.pem lrwxrwxrwx 1 root root 12 Dec 18 15:05 /etc/ssl/certs/f4c00f60.0 -> ICE-user.pem -rw-r--r-- 1 root root 859 Feb 14 2005 /etc/ssl/certs/factory.pem -rw-r--r-- 1 root root 2945 Feb 14 2005 /etc/ssl/certs/ICE-CA.pem -rw-r--r-- 1 root root 2314 Feb 14 2005 /etc/ssl/certs/ICE-root.pem -rw-r--r-- 1 root root 3240 Feb 14 2005 /etc/ssl/certs/ICE-user.pem -rw-r--r-- 1 root root 900 Feb 14 2005 /etc/ssl/certs/nortelCA.pem -rw-r--r-- 1 root root 1953 Feb 14 2005 /etc/ssl/certs/pca-cert.pem -rw-r--r-- 1 root root 1201 Feb 14 2005 /etc/ssl/certs/RegTP-4R.pem -rw-r--r-- 1 root root 1017 Feb 14 2005 /etc/ssl/certs/rsa-cca.pem -rw-r--r-- 1 root root 753 Feb 14 2005 /etc/ssl/certs/timCA.pem -rw-r--r-- 1 root root 871 Feb 14 2005 /etc/ssl/certs/tjhCA.pem -rw-r--r-- 1 root root 989 Feb 14 2005 /etc/ssl/certs/vsign2.pem -rw-r--r-- 1 root root 1084 Feb 14 2005 /etc/ssl/certs/vsigntca.pem (In reply to Thomas Capricelli from comment #4) > 'equery files' can't find any > *.pem or dsa-ca* in the openssl installed files.. ? Try ca-certificates (and anything else that equery belongs /etc/ssl/certs/ reports). FWIW, here, several *.pem, but with the non-symlink exceptions in the orphans list above it appears they're all symlinks, either to other symlinks in /etc/ssl/certs/ or to the actual *.crt files (*.pem symlinks to *.crt) in /usr/share/ca-certificates/ (which only ca-certificates owns). (In reply to Duncan from comment #13) > with the symlinks to them dated Dec 18 (2021 of course) Duh, 2022; it's 2023 now! =:^) (In reply to Duncan from comment #12) Modern versions of portage have FEATURES="config-protect-if-modified" enabled by default. That means files in /etc/ssl/certs will only be affected by CONFIG_PROTECT if the sysadmin modifies the files. This means that adding /etc/ssl/certs to CONFIG_PROTECT_MASK is largely pointless today. Ancient versions of Portage did not have the config-protect-if-modified feature, so that's probably how you ended up with orphaned files. We could avoid the password prompt by changing c_rehash to call "openssl -passin file:/dev/null". However, I think we should probably just migrate to "openssl rehash" instead of trying to fix c_rehash. That's covered in bug 855494. (In reply to Duncan from comment #13) > $ for file in /etc/ssl/certs/*; do equery -q b -e $file >>/dev/null || ls -l > $file; done I got the same results as you. > (In reply to Thomas Capricelli from comment #4) > Try ca-certificates (and anything else that equery belongs /etc/ssl/certs/ Actually i had (first) tried with "equery belongs", no package claim them. New versions for bug 893446 will be stabled shortly. |