Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#56484 - [imap] creates ssl keys upon build

Attached to Project: Arch Linux
Opened by Santiago Torres (sangy) - Monday, 27 November 2017, 18:45 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 29 November 2017, 14:51 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Pierre Schmitz (Pierre)
Levente Polyak (anthraxx)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

The current PKGBUILD for imap creates secret keys during the build phase[1]. This yields the package unreproducible[2]. The private keys could be deployed as part of an install hook (or manually genearted by the user after installation) to avoid this.

Additional info:
* 2007f-8

Steps to reproduce:

Build the package

[1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/imap#n42
[2] https://tests.reproducible-builds.org/archlinux/extra/imap/imap-2007f-8-x86_64.pkg.tar.xz.html
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Wednesday, 29 November 2017, 14:51 GMT
Reason for closing:  Fixed
Additional comments about closing:  imap 2007f-9
Comment by Levente Polyak (anthraxx) - Monday, 27 November 2017, 20:13 GMT
hm if the private key is used for TLS, then this is not just a reproducible build issue but a security issue if the private key is known.
Comment by Santiago Torres (sangy) - Monday, 27 November 2017, 21:48 GMT
I wasn't sure about what are the exact implications of this key being hardcoded in the beginning, but this is definitely a security issue (adding to this, it's generating a 1k bit RSA key, which is discouraged...). We should definitely move this statement to a post-install hook or have users manually set the certificates up.
Comment by Eli Schwartz (eschwartz) - Monday, 27 November 2017, 21:58 GMT
According to update-ca-trust(8) it seems like the file shouldn't be going there no matter how it is created.
(It should be generated in post_install and installed to /usr/share/ca-certificates/trust-source/anchors/ rather than being hidden in a swarm of extracted symlinks.)

Thanks for confirming the full impact of this.
Comment by kpcyrd (kpcyrd) - Monday, 27 November 2017, 23:06 GMT
I was first concerend that the private key for imapd is published in the package, but after the hint from eschwartz it seems that it's registered as trusted CA and would have impact on everything that does certificate verification if the package is installed. Can somebody else confirm this?
Comment by kpcyrd (kpcyrd) - Tuesday, 28 November 2017, 00:31 GMT
As a follow-up, my assumption was wrong and the location doesn't seem to cause the file to be included in /etc/ssl/certs/ca-certificates.crt, so the cert isn't imported as a CA.
Comment by loqs (loqs) - Tuesday, 28 November 2017, 01:06 GMT
kpcyrd agreed with the current version the following finds no matches in the bundle even after forcing a bundle update.
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -text -noout | grep -i localhost
However the issue appears to have been present since the initial import in 2008 https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/imap&id=59ec9e013eb72ca2dec35dac4bb63e157574f5eb
Does the assumption hold for the previous systems to update-ca-trust?
Would there be any harm in passing the certificates from each published version to mozilla to be blacklisted should it is confirmed private keys were distributed?

Loading...