Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 887073 - dev-libs/openssl-3.0.7-r2 (and earlier 3.0.7) pkg_postinst() interactively waits for passphrases
Summary: dev-libs/openssl-3.0.7-r2 (and earlier 3.0.7) pkg_postinst() interactively wa...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on: 855494 CVE-2022-4203, CVE-2022-4304, CVE-2022-4450, CVE-2023-0215, CVE-2023-0216, CVE-2023-0217, CVE-2023-0286, CVE-2023-0401
Blocks:
  Show dependency tree
 
Reported: 2022-12-18 23:02 UTC by Duncan
Modified: 2023-02-07 23:45 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
full emerge --info (emerge.info.txt,7.55 KB, text/plain)
2022-12-18 23:02 UTC, Duncan
Details
full emerge log (xz-compressed) (dev-libs:openssl-3.0.7-r2:20221218-220218.log.xz,150.38 KB, application/x-xz)
2022-12-18 23:39 UTC, Duncan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan 2022-12-18 23:02:44 UTC
Created attachment 843595 [details]
full emerge --info

Why am I getting this but nobody else seems to (I see the stabilization proceeding apace with no evidence of it...)?

openssl-3.0.7-r2 builds, binpkgs and merges fine (incl unmerge of old version)... until pkg_postinst(), where the c_rehash step stalls, waiting for passphrase input, twice each on two certs (dsa-ca.pem and dsa-pca.pem) for a total of four inputs.  At least one earlier 3.0.7 had a similar issue, but IDR whether I got both -r0 and -r1 or not or which one if only one.

Of course the passphrase prompts stop world updates and the like cold since they don't take input, but since it's already binpkged I can cancel the non-interactive merge and remerge --usepkgonly to get the passphrase prompts (and since this is in pkg_postinst() it is actually already merged).

Further, there's no clue what the passphrases might need to match or otherwise what they actually do (except that they're tied to these two certs, but what are the /certs/ for and what is the real-world significance of those passphrases linked to them, blank or otherwise?), so the easiest thing is to just hit enter four times, but of course blank passphrases presumably have some sort of security implications... but with no further guidance...

>>> Original instance of package unmerged safely.
* Running 'c_rehash /etc/ssl/certs/' to rebuild hashes (bug #333069) ...
Enter pass phrase for dsa-ca.pem:
Enter pass phrase for dsa-ca.pem:
Enter pass phrase for dsa-pca.pem:
Enter pass phrase for dsa-pca.pem:                                                                                                                             [ ok ]
>>> dev-libs/openssl-3.0.7-r2 merged.
>>> Regenerating /etc/ld.so.cache...

* GNU info directory index is up-to-date.

On ~amd64 no-multilib and here's the USE flags (full emerge --info to be attached):

[ebuild   R    ] dev-libs/openssl-3.0.7-r2:0/3::gentoo  USE="asm verify-sig -fips -ktls -rfc3779 -sctp -static-libs -test -tls-compression -vanilla -weak-ssl-ciphers" CPU_FLAGS_X86="(sse2)" 0 KiB

One potentially significant system difference that occasionally triggers symlink-resolution-related bugs (say when a canonically-resolved path is supposed to match a non-canonically-resolved version of the same path):  I'm running "reverse-usrmerge", that is, /usr is a symlink: /usr -> .  so everything normally in /usr is directly under / with the /usr symlink pointing things at it appropriately.  (So /lib64, /bin, /sbin (-> bin), /include, /share ...)

The full emerge log will be attached as well.
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-12-18 23:24:34 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.
Comment 2 Duncan 2022-12-18 23:39:22 UTC
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.
Comment 3 Duncan 2022-12-18 23:52:33 UTC
(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.
Comment 4 Thomas Capricelli 2023-02-02 16:50:47 UTC
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.. ?
Comment 5 Mike Gilbert gentoo-dev 2023-02-02 18:49:13 UTC
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.
Comment 6 Thomas Capricelli 2023-02-02 20:11:39 UTC
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.
Comment 7 Mike Gilbert gentoo-dev 2023-02-02 20:23:06 UTC
(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.
Comment 8 Thomas Capricelli 2023-02-02 20:38:32 UTC
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.
Comment 9 Mike Gilbert gentoo-dev 2023-02-02 20:53:09 UTC
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.
Comment 10 Mike Gilbert gentoo-dev 2023-02-02 20:55:11 UTC
If you are not comfortable attaching the files publicly, please send them to me via email directly.
Comment 11 Mike Gilbert gentoo-dev 2023-02-02 21:49:48 UTC
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
Comment 12 Duncan 2023-02-03 01:27:55 UTC
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.
Comment 13 Duncan 2023-02-03 03:00:37 UTC
(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).
Comment 14 Duncan 2023-02-03 03:35:36 UTC
(In reply to Duncan from comment #13)
> with the symlinks to them dated Dec 18 (2021 of course)

Duh, 2022; it's 2023 now! =:^)
Comment 15 Mike Gilbert gentoo-dev 2023-02-03 03:55:50 UTC
(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.
Comment 16 Mike Gilbert gentoo-dev 2023-02-03 04:03:20 UTC
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.
Comment 17 Thomas Capricelli 2023-02-03 12:10:36 UTC
(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.
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-02-07 23:45:54 UTC
New versions for bug 893446 will be stabled shortly.