[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 12 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 5 fully signed off packages * 46 packages missing signoffs * 4 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.) == New packages in [testing] in last 24 hours (12 total) == * cryptsetup-1.6.6-1 (i686) * ppp-2.4.7-1 (i686) * cryptsetup-1.6.6-1 (x86_64) * ppp-2.4.7-1 (x86_64) * fetchmail-6.3.26-2 (i686) * networkmanager-0.9.10.0-4 (i686) * networkmanager-pptp-0.9.10.0-2 (i686) * rp-pppoe-3.11-7 (i686) * fetchmail-6.3.26-2 (x86_64) * networkmanager-0.9.10.0-4 (x86_64) * networkmanager-pptp-0.9.10.0-2 (x86_64) * rp-pppoe-3.11-7 (x86_64) == Incomplete signoffs for [core] (10 total) == * man-pages-3.71-1 (any) 0/2 signoffs * cryptsetup-1.6.6-1 (i686) 0/1 signoffs * dirmngr-1.1.1-3 (i686) 0/1 signoffs * iproute2-3.16.0-1 (i686) 0/1 signoffs * lvm2-2.02.109-2 (i686) 0/1 signoffs * mkinitcpio-nfs-utils-0.3-5 (i686) 0/1 signoffs * ppp-2.4.7-1 (i686) 0/1 signoffs * cryptsetup-1.6.6-1 (x86_64) 1/2 signoffs * mkinitcpio-nfs-utils-0.3-5 (x86_64) 0/2 signoffs * ppp-2.4.7-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (33 total) == * texlive-bibtexextra-2014.34822-1 (any) 0/2 signoffs * texlive-core-2014.34872-1 (any) 0/2 signoffs * texlive-fontsextra-2014.34817-1 (any) 0/2 signoffs * texlive-formatsextra-2014.33826-1 (any) 0/2 signoffs * texlive-games-2014.34491-1 (any) 0/2 signoffs * texlive-genericextra-2014.34393-1 (any) 0/2 signoffs * texlive-htmlxml-2014.34624-1 (any) 0/2 signoffs * texlive-humanities-2014.34877-1 (any) 0/2 signoffs * texlive-langcjk-2014.0-1 (any) 0/2 signoffs * texlive-langcyrillic-2014.34390-1 (any) 0/2 signoffs * texlive-langextra-2014.34660-1 (any) 0/2 signoffs * texlive-langgreek-2014.34857-1 (any) 0/2 signoffs * texlive-latexextra-2014.34865-1 (any) 0/2 signoffs * texlive-music-2014.33826-1 (any) 0/2 signoffs * texlive-pictures-2014.34851-1 (any) 0/2 signoffs * texlive-plainextra-2014.34228-1 (any) 0/2 signoffs * texlive-pstricks-2014.34856-1 (any) 0/2 signoffs * texlive-publishers-2014.34878-1 (any) 0/2 signoffs * texlive-science-2014.34853-1 (any) 0/2 signoffs * fetchmail-6.3.26-2 (i686) 0/1 signoffs * jack-0.124.1-3 (i686) 0/1 signoffs * networkmanager-0.9.10.0-4 (i686) 0/1 signoffs * networkmanager-pptp-0.9.10.0-2 (i686) 0/1 signoffs * rp-pppoe-3.11-7 (i686) 0/1 signoffs * texlive-bin-2014.34260-1 (i686) 0/1 signoffs * upower-0.99.0-3 (i686) 0/1 signoffs * fetchmail-6.3.26-2 (x86_64) 0/2 signoffs * jack-0.124.1-3 (x86_64) 0/2 signoffs * networkmanager-0.9.10.0-4 (x86_64) 0/2 signoffs * networkmanager-pptp-0.9.10.0-2 (x86_64) 0/2 signoffs * rp-pppoe-3.11-7 (x86_64) 0/2 signoffs * texlive-bin-2014.34260-1 (x86_64) 0/2 signoffs * upower-0.99.0-3 (x86_64) 1/2 signoffs == Incomplete signoffs for [unknown] (3 total) == * texlive-langchinese-2014.34415-1 (any) 0/2 signoffs * texlive-langjapanese-2014.34369-1 (any) 0/2 signoffs * texlive-langkorean-2014.34808-1 (any) 0/2 signoffs == Completed signoffs (5 total) == * systemd-216-1 (i686) * dirmngr-1.1.1-3 (x86_64) * iproute2-3.16.0-1 (x86_64) * lvm2-2.02.109-2 (x86_64) * systemd-216-1 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * upower-0.99.0-3 (i686), since 2014-08-05 * upower-0.99.0-3 (x86_64), since 2014-08-05 * iproute2-3.16.0-1 (i686), since 2014-08-05 * iproute2-3.16.0-1 (x86_64), since 2014-08-05 == Top five in signoffs in last 24 hours == 1. thomas - 3 signoffs
[arch-dev-public] Rethinking our CA certificate setup
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
Re: [arch-dev-public] Rethinking our CA certificate setup
[2014-08-24 11:47:56 +0200] Jan Alexander Steffens:
- 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
So we'd have three ca-certificates-* packages?
If this is this only to allow users to remove the bundles (mozilla or
cacert) they do not trust, then couldn't we instead just keep everything
in one package; simply putting the files
/etc/ca-certificates/conf.d/{mozilla,cacert}.conf
in the backup array would allow anyone to override them, so disabling a
bundle would also be super easy...
Other than the fragmentation of packages (my new pet gripe), your plan
sounds great!
Cheers.
--
Gaetan
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens jan.steff...@gmail.com wrote: 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 Agreed, the current situation is far from optimal. On a related note currently replacing the libnssckbi.so lib with any other drop-in replacement could be handled better. I have been symlinking /usr/lib/pkcs11/p11-kit-trust.so to /usr/lib/libnssckbi.so to use the trust policy module [1] for quite some time and the only way to not let pacman screw this setup is to add usr/lib/libnssckbi.so to both NoUpgrade and NoExtract in pacman.conf. [1] http://p11-glue.freedesktop.org/doc/p11-kit/trust-module.html
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sun, Aug 24, 2014 at 12:06 PM, Gaetan Bisson bis...@archlinux.org wrote:
[2014-08-24 11:47:56 +0200] Jan Alexander Steffens:
- 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
So we'd have three ca-certificates-* packages?
If this is this only to allow users to remove the bundles (mozilla or
cacert) they do not trust, then couldn't we instead just keep everything
in one package; simply putting the files
/etc/ca-certificates/conf.d/{mozilla,cacert}.conf
in the backup array would allow anyone to override them, so disabling a
bundle would also be super easy...
Other than the fragmentation of packages (my new pet gripe), your plan
sounds great!
I don't want to stick either update-ca-certificates or the CAcert.org
certificates into the NSS PKGBUILD, so we will have at least two
PKGBUILDs and three packages involved here:
ca-certificates/PKGBUILD:
- sources: Debian ca-certificates, CACert.org certificates
- pkgnames: ca-certificates
nss/PKGBUILD:
- sources: Mozilla NSS
- packages: nss ca-certificates-mozilla
Since Debian and CACert.org aren't really related, I wanted to do
another split. -cacert and -mozilla both provide packages; the rest is
infrastructure. One could conceive of other provider packages. So our
proposed setup is:
ca-certificates/PKGBUILD:
- sources: Debian ca-certificates
- pkgnames: ca-certificates ca-certificates-utils
ca-certificates-cacert/PKGBUILD:
- sources: CACert.org certificates
- pkgnames: ca-certificates-cacert
nss/PKGBUILD:
- sources: Mozilla NSS
- pkgnames: nss ca-certificates-mozilla
The package ca-certificates is empty and just depends on -mozilla and
-cacert to ensure a sane default setup.
The package ca-certificates-utils provides ca-certificates, so a
minimum install with no certificate provider packages is possible.
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sunday, August 24, 2014 11:47:56 Jan Alexander Steffens wrote:
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
A quick search shows that we have more packages shipping their own (maybe
outdated) CA certificates copy in package. Since we are already on the topic
about the inconsistency between nss and ca-certificates, I would like to also
bring these up. I'd think it a good idea to make them use /etc/ssl/certs too.
(Maybe not the ones in examples? Thoughts?)
perl-mozilla-ca ships usr/share/perl5/vendor_perl/Mozilla/CA/cacert.pem
- serves as the reference for some other projects, for example spamassassin,
gnucash, bugzilla, shutter...
- There was a discussion around this package in Debian [1], which resulted in
not adding this package at all.
python{,2}-pip ship usr/lib/python{3.4,2.7}/site-
packages/pip/_vendor/requests/cacert.pem
- We already have a patch for python{,2}-requests to use ca-certificates [2],
but the embedded version in pip didn't use it.
python{,2}-certifi ship usr/lib/python{3.4,2.7}/site-
packages/certifi/cacert.pem
- only affects tornado for now, consider removing the package and patching
tornado?
vagrant ships opt/vagrant/embedded/cacert.pem
- looks like it has an option to use system-wide ca-certificates [3], would we
patch it or simply remove the embedded version?
goagent ships usr/share/goagent/local/cacert.pem
- looks like a simple patching.
And some others I didn't look further into:
- opensips ships etc/opensips/tls/rootCA/cacert.pem
- owncloud ships usr/share/webapps/owncloud/apps/files_external/3rdparty/aws-
sdk-php/Guzzle/Http/Resources/cacert.pem,
usr/share/webapps/owncloud/apps/files_external/3rdparty/google-api-php-
client/src/io/cacerts.pem, ...
- swi-prolog ships
usr/lib/swipl-6.6.5/doc/packages/examples/ssl/etc/demoCA/cacert.pem
- erlang/erlang-nox ship
usr/lib/erlang/lib/ssl-5.3.5/examples/certs/etc/client/cacerts.pem,
usr/lib/erlang/lib/ssl-5.3.5/examples/certs/etc/server/cacerts.pem
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698101
[2]
https://projects.archlinux.org/svntogit/community.git/tree/trunk/certs.patch?h=packages/python-requests
[3]
https://www.digitalocean.com/community/tutorials/how-to-use-digitalocean-as-your-provider-in-vagrant-on-an-ubuntu-12-10-vps
Regards,
Felix Yan
signature.asc
Description: This is a digitally signed message part.
Re: [arch-dev-public] systemd 216 coming soon to testing
On 20/08/2014 20:25, Dave Reisner wrote: For packagers: - systemd-sysusers is now a reasonable thing as it now reads and writes to /etc/shadow and /etc/gshadow. This means that we can simplify the filesystem package immensely, and packages which want to ship their own runtime users can switch to this as well. Note that new IDs are allocated semi-arbitrarily starting from 999 and counting down. Please be aware of the implications of using this if your package ships files owned by the user you're going to create! There's still no way of removing users via sysusers.d, but I think this is fine (Fedora actually never removes users or groups). I'm enthused by this feature and systemd-sysusers can offer a more standard way for managing system users across distro. Nevertheless, It would be nice if we do not fall into the shortcut of not removing users bound to a package when we remove it. That avoid manual removing and I don't see a drawback for doing this. Do you know why they don't implement the same logic (--create, --clean) as systemd-tmpfiles in systemd-sysusers? -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] systemd 216 coming soon to testing
On 24/08/14 04:54 PM, Sébastien Luttringer wrote: On 20/08/2014 20:25, Dave Reisner wrote: For packagers: - systemd-sysusers is now a reasonable thing as it now reads and writes to /etc/shadow and /etc/gshadow. This means that we can simplify the filesystem package immensely, and packages which want to ship their own runtime users can switch to this as well. Note that new IDs are allocated semi-arbitrarily starting from 999 and counting down. Please be aware of the implications of using this if your package ships files owned by the user you're going to create! There's still no way of removing users via sysusers.d, but I think this is fine (Fedora actually never removes users or groups). I'm enthused by this feature and systemd-sysusers can offer a more standard way for managing system users across distro. Nevertheless, It would be nice if we do not fall into the shortcut of not removing users bound to a package when we remove it. That avoid manual removing and I don't see a drawback for doing this. Do you know why they don't implement the same logic (--create, --clean) as systemd-tmpfiles in systemd-sysusers? There will often be files left behind owned by that uid/gid, and deleting the user/group will free up the id to be consumed by the next user/group. There's a potential to leak sensitive information like passwords. Fedora and systemd choose to ignore the ickiness of having dead system users/groups to avoid that issue. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Email domain for TUs
On 2014-08-22 18:56 +0200 Florian Pritz wrote: I didn't document it anywhere. Was there documentation about the old setup? I don't remember where I read about the .forward file. Sorry.
