[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 9 fully signed off packages * 24 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [core] (20 total) == * ca-certificates-20140923-5 (any) 0/2 signoffs * ca-certificates-cacert-20140824-2 (any) 0/2 signoffs * tzdata-2014j-1 (any) 0/2 signoffs * expat-2.1.0-4 (i686) 0/1 signoffs * libassuan-2.1.3-1 (i686) 0/1 signoffs * libgpg-error-1.17-1 (i686) 0/1 signoffs * libksba-1.3.1-1 (i686) 0/1 signoffs * lvm2-2.02.112-1 (i686) 0/1 signoffs * pinentry-0.9.0-1 (i686) 0/1 signoffs * texinfo-5.2-3 (i686) 0/1 signoffs * dhcpcd-6.6.2-1 (x86_64) 1/2 signoffs * expat-2.1.0-4 (x86_64) 0/2 signoffs * gnupg-2.1.0-3 (x86_64) 1/2 signoffs * libassuan-2.1.3-1 (x86_64) 0/2 signoffs * libgpg-error-1.17-1 (x86_64) 0/2 signoffs * libksba-1.3.1-1 (x86_64) 0/2 signoffs * lvm2-2.02.112-1 (x86_64) 0/2 signoffs * pinentry-0.9.0-1 (x86_64) 0/2 signoffs * texinfo-5.2-3 (x86_64) 1/2 signoffs * traceroute-2.0.21-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (4 total) == * nss-3.17.2-2 (i686) 0/1 signoffs * p11-kit-0.22.1-3 (i686) 0/1 signoffs * nss-3.17.2-2 (x86_64) 0/2 signoffs * p11-kit-0.22.1-3 (x86_64) 0/2 signoffs == Completed signoffs (9 total) == * dbus-1.8.10-1 (i686) * dhcpcd-6.6.2-1 (i686) * glib2-2.42.1-1 (i686) * gnupg-2.1.0-3 (i686) * linux-3.17.3-1 (i686) * traceroute-2.0.21-1 (i686) * dbus-1.8.10-1 (x86_64) * glib2-2.42.1-1 (x86_64) * linux-3.17.3-1 (x86_64) == Top five in signoffs in last 24 hours == 1. foutrelis - 8 signoffs 2. andyrtr - 1 signoffs
Re: [arch-dev-public] Rethinking our CA certificate setup
On 26 August 2014 21:15, Jan Alexander Steffens jan.steff...@gmail.com wrote: On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens jan.steff...@gmail.com wrote: Hi guys, I'm currently at FrOSCon with Pierre and an expert from CAcert.org and we're thinking of changes to our certificate setup. The current issues are: - Mozilla NSS uses its own root store and not /etc/ssl/certs - ca-certificates ships outdated Mozilla roots - Shipping additional roots outside ca-certificates is difficult, requiring patching /etc/ca-certificates.conf To solve these issues, we thought of making the following changes: - Attach NSS to p11-kit so it uses our root store (easily done by replacing /usr/lib/libnssckbi.so with a symlink to p11-kit-proxy.so) - Patch the update-ca-certificates script to read /etc/ca-certificates/conf.d instead of /etc/ca-certificates.conf - Split the current Mozilla roots from the NSS package in the ca-certificates format, shipping /etc/ca-certificates/conf.d/mozilla.conf - Create a package shipping the CAcert.org roots in a similar way - Ship the update-ca-certificates script in a ca-certificates-utils package, which the certificate packages depend on - ca-certificates becomes a metapackage depending on the -mozilla and -cacert packages Comments are welcome. Unless we get objections, we're going to start making these changes. Hopefully we can be done today and push the result to [testing]. Greetings, Jan Firefox isn't quite happy yet with the change, see https://bugs.archlinux.org/task/41689: Addons fail to install or update. It seems this is due to Firefox depending on NSS internals - specifically, addons must be signed by certificates validated by the built-in trusted root store, which is matched by name. Fedora was affected as well: https://bugzilla.redhat.com/show_bug.cgi?id=966424 Upstream report, arguing for the check to be removed: https://bugzilla.mozilla.org/show_bug.cgi?id=880269 Now we can: a. Patch p11-kit to rename the store; the easy way. b. Patch Firefox and Thunderbird and SeaMonkey to not require the name to match; the hard way, and the one Fedora chose. c. Revert the change that links NSS to p11-kit; rather not, as it makes it really hard to control the root store. Opinions? Hi Pierre, hi Jan, So the ca-certificates-utils from testing (20140923-5) declares a provides and conflict on ca-certificates-java. Unfortunately jre and jdk packages use a init-jks-keystore script provided by ca-certificates-java but not ca-certificates-utils. This scripts only computes file /etc/ssl/certs/java/cacerts which is actually also computed by update-ca-trust. So I could just make jre and jdk packages depend on ca-certificates-utils and then ca-certificates-java could be dropped: is that the whole plan?
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sun, Nov 16, 2014 at 3:54 PM, Guillaume Alaux guilla...@alaux.net wrote: So the ca-certificates-utils from testing (20140923-5) declares a provides and conflict on ca-certificates-java. Unfortunately jre and jdk packages use a init-jks-keystore script provided by ca-certificates-java but not ca-certificates-utils. This scripts only computes file /etc/ssl/certs/java/cacerts which is actually also computed by update-ca-trust. So I could just make jre and jdk packages depend on ca-certificates-utils and then ca-certificates-java could be dropped: is that the whole plan? Yes. Since p11-kit can construct the Java cert store and update-ca-trust always does so, ca-certificates-java becomes obsolete.
Re: [arch-dev-public] Rethinking our CA certificate setup
On 16 November 2014 16:13, Jan Alexander Steffens jan.steff...@gmail.com wrote: On Sun, Nov 16, 2014 at 3:54 PM, Guillaume Alaux guilla...@alaux.net wrote: So the ca-certificates-utils from testing (20140923-5) declares a provides and conflict on ca-certificates-java. Unfortunately jre and jdk packages use a init-jks-keystore script provided by ca-certificates-java but not ca-certificates-utils. This scripts only computes file /etc/ssl/certs/java/cacerts which is actually also computed by update-ca-trust. So I could just make jre and jdk packages depend on ca-certificates-utils and then ca-certificates-java could be dropped: is that the whole plan? Yes. Since p11-kit can construct the Java cert store and update-ca-trust always does so, ca-certificates-java becomes obsolete. Excellent. I am going to rebuild OpenJDK7 and 8 and will push them to testing then.
