Bug#867461: should ca-certificates certdata.txt synchronize across all suites?
What's the latest status on this? Thanks, Jacob
Bug#721976: ca-certificates contains both server and email certificates
Hi, sending you a gentle ping on this. Would love to get this fix landed. Thanks!
Bug#721976: (no subject)
Hi, just checking in on the status of this. I provided a patch above; does it look good to you?
Bug#721976: (no subject)
Hi! Any updates on this? Thanks!
Bug#721976: (no subject)
Great! Here's my proposed patch. It winds up being pretty small, just
removing the lines from certdata2pem.py that pull in email certificates.
Thanks,
Jacob
>From 68bc5e229a474fc2815dea530cc246e3d3b55008 Mon Sep 17 00:00:00 2001
From: Jacob Hoffman-Andrews <git...@hoffman-andrews.com>
Date: Mon, 20 Mar 2017 12:28:55 -0700
Subject: [PATCH] Remove email-only roots from mozilla trust store
These roots are trusted in the Mozilla program only for S/MIME, so should not be
included in ca-certificates, which most applications use to validate TLS
certificates.
Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721976, the only MUAs that
depend on or suggest ca-certificates are Mutt and Sylpheed. Sylpheed doesn't use
ca-certificates for S/MIME. Mutt does, but I think it is still safe to remove
thes because:
(a) S/MIME is relatively uncommon, and
(b) The CAs that have both TLS and S/MIME bits will continue to work, and
(c) Nearly all of the 12 removed email-only CAs have ceased operation of their
email certificate services
Verisign Class 1 Public Primary Certification Authority - G3
Verisign Class 2 Public Primary Certification Authority - G3
UTN USERFirst Email Root CA
SwissSign Platinum CA - G2
AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.
TC TrustCenter Class 3 CA II
ComSign CA
S-TRUST Universal Root CA
Symantec Class 1 Public Primary Certification Authority - G6
Symantec Class 2 Public Primary Certification Authority - G6
Symantec Class 1 Public Primary Certification Authority - G4
Symantec Class 2 Public Primary Certification Authority - G4
---
mozilla/certdata2pem.py | 2 --
1 file changed, 2 deletions(-)
diff --git a/mozilla/certdata2pem.py b/mozilla/certdata2pem.py
index f91422b..0b02b2a 100644
--- a/mozilla/certdata2pem.py
+++ b/mozilla/certdata2pem.py
@@ -104,8 +104,6 @@ for obj in objects:
print("Certificate %s blacklisted, ignoring." % obj['CKA_LABEL'])
elif obj['CKA_TRUST_SERVER_AUTH'] == 'CKT_NSS_TRUSTED_DELEGATOR':
trust[obj['CKA_LABEL']] = True
-elif obj['CKA_TRUST_EMAIL_PROTECTION'] == 'CKT_NSS_TRUSTED_DELEGATOR':
-trust[obj['CKA_LABEL']] = True
elif obj['CKA_TRUST_SERVER_AUTH'] == 'CKT_NSS_NOT_TRUSTED':
print('!'*74)
print("UNTRUSTED BUT NOT BLACKLISTED CERTIFICATE FOUND: %s" % obj['CKA_LABEL'])
--
2.8.0-rc3
Bug#858064: (no subject)
What are the next steps for the package to get released? Is there anything we can help with? Thanks!
Bug#721976: (no subject)
Sorry, meant to address my previous message to Michael. :-) I've done a little digging, and according to the first-level results from: apt-rdepends --reverse --show=Depends,Recommends,Suggests ca-certificates The only MUAs that depend, recommend, or suggest ca-certificates are mutt and Sylpheed. Sylpheed uses ca-certificates just for SSL: https://github.com/jan0sch/sylpheed/blob/master/libsylph/ssl.c#L58. Mutt seems to be the only MUA that uses ca-certificates for S/MIME. It ships with /etc/Muttrc.d/smime.rc, which has: set smime_ca_location=`for f in $HOME/.smime/ca-certificates.crt $HOME/.smime/ca-bundle.crt /etc/ssl/certs/ca-certificates.crt ; do if [ -e $f ] ; then echo $f ; exit ; fi ; done` These are the remaining CAs in the latest version of ca-certificates from git that are present only because they have the email trust bit: "Verisign Class 1 Public Primary Certification Authority - G3" "Verisign Class 2 Public Primary Certification Authority - G3" "UTN USERFirst Email Root CA" "SwissSign Platinum CA - G2" "AC Ra\xC3\xADz Certic\xC3\xA1mara S.A." "TC TrustCenter Class 3 CA II" "ComSign CA" "S-TRUST Universal Root CA" "Symantec Class 1 Public Primary Certification Authority - G6" "Symantec Class 2 Public Primary Certification Authority - G6" "Symantec Class 1 Public Primary Certification Authority - G4" "Symantec Class 2 Public Primary Certification Authority - G4" It's entirely possible that none of these CAs are actually used for S/MIME by any Mutt user. For instance, Symantec end-of-lifed their email offering in August 2016: https://www.symantec.com/products/information-protection/digital-ids-secure-email. ComSign doesn't offer email certificates anywhere on their site: https://www.comsign.co.uk/. VeriSign was bought by Symantec ages ago. After doing this research, I'd actually argue in favor of dropping these CA's from ca-certificates outright, without making special provision for S/MIME.
Bug#721976: ca-certificates contains both server and email certificates
Hi Marc, I work on EFF's Encrypt the Web project and the Let's Encrypt certificate authority. I'd like to lend support to what Andrew's saying: It's both urgent and important to remove the email roots from the default set of certificates trusted on Debian. I think Andrew's proposal is good; alternately, a simpler fix that doesn't involve new packages would be to simply move the email roots to a different directory, for instance /usr/share/ca-certificates/mozilla-email. That would immediately improve security for all TLS clients, while still making the email roots available for those who want them. Below are the first-level reverse depends for ca-certificates. None of these packages support S/MIME, so I think it is quite safe to make this change. In addition, the most common use of S/MIME is with a company-internal CA, because it only really works well if you have a directory to go with it. I think either Andrew or I would be happy to produce a patch if you agree that this is the right direction. What do you think? apt-rdepends --reverse ca-certificates ca-certificates Reverse Depends: 0install-core (2.7-3) Reverse Depends: boinc-client (7.4.23+dfsg-1) Reverse Depends: ca-certificates-java (>= 20140324) Reverse Depends: esniper (2.31.0-1) Reverse Depends: freeradius (2.2.5+dfsg-0.2) Reverse Depends: glib-networking-tests (2.42.0-2) Reverse Depends: gnustep-base-common (1.24.7-1) Reverse Depends: kdelibs5-data (4:4.14.2-5+deb8u1) Reverse Depends: lava-dev (2014.09.1-1) Reverse Depends: libgwenhywfar-data (4.12.0beta-3) Reverse Depends: liblwp-protocol-https-perl (6.06-2) Reverse Depends: liblwpx-paranoidagent-perl (1.10-5) Reverse Depends: libwww-perl (6.08-1) Reverse Depends: nodejs-dev (0.10.29~dfsg-2) Reverse Depends: osc (0.149.0-2) Reverse Depends: php-google-api-php-client (0.6.7-2) Reverse Depends: php-guzzle (3.9.2+dfsg-4) Reverse Depends: php-guzzlehttp-ringphp (1.0.0-1) Reverse Depends: python-httplib2 (0.9+dfsg-2) Reverse Depends: python-pip (1.5.6-5) Reverse Depends: python-requests (2.4.3-6) Reverse Depends: python-requests-whl (2.4.3-6) Reverse Depends: python-tornado (3.2.2-1.1) Reverse Depends: python-txaws (0.2.3-1) Reverse Depends: python3-httplib2 (0.9+dfsg-2) Reverse Depends: python3-pip (1.5.6-5) Reverse Depends: python3-requests (2.4.3-6) Reverse Depends: python3-tornado (3.2.2-1.1) Reverse Depends: rubygems-integration (1.8) Reverse Depends: software-properties-common (0.92.25debian1) Reverse Depends: ssh-import-id (3.21-1) Reverse Depends: sympa (6.1.23~dfsg-2+deb8u1) Reverse Depends: wordpress (4.1+dfsg-1+deb8u11) Thanks, Jacob
Bug#856698: (no subject)
Also, how many files and directories do you have under /etc/letsencrypt/archive? find /etc/letsencrypt/archive | wc -l ls /etc/letsencrypt/archive | wc -l There is a known issue with Certbot performing poorly when many old certificates are present.
Bug#856698: (no subject)
What is the command that is running when certbot consumes a lot of memory? Can you provide the contents of /etc/cron.d/certbot, and /var/log/letsencrypt.log from a run where certbot consumed a lot of memory? If you're using the Nginx or Apache configurators, can you provide your Nginx or Apache configs?
Bug#764512: postfix: Outbound STARTTLS disabled in default config
Package: postfix Version: 2.9.6-2 Severity: normal Dear Maintainer, The default config for a newly installed Postfix supports inbound STARTTLS, but it does not support outbound STARTTLS, even if the remote host advertises support. I think the default Postfix config in Debian should have this line: smtp_tls_security_level = may This will instruct Postfix to use STARTTLS encryption with hosts that advertise it, but go ahead and send in plaintext for those that don't. This would be an important step up in default email privacy. Thanks, Jacob -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-rc7-xen-teo.en.ming-sgp (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postfix depends on: ii adduser3.113+nmu3 ii cpio 2.11+dfsg-0.1 ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.12 ii libc6 2.13-38+deb7u1 ii libdb5.1 5.1.29-5 ii libsasl2-2 2.1.25.dfsg1-6+deb7u1 ii libsqlite3-0 3.7.13-1+deb7u1 ii libssl1.0.01.0.1e-2+deb7u5 ii lsb-base 4.1+Debian8+deb7u1 ii netbase5.0 ii ssl-cert 1.0.32 Versions of packages postfix recommends: ii python 2.7.3-4+deb7u1 Versions of packages postfix suggests: pn dovecot-common none ii libsasl2-modules 2.1.25.dfsg1-6+deb7u1 ii mailutils [mail-reader] 1:2.99.97-3 pn postfix-cdb none pn postfix-doc none pn postfix-ldap none pn postfix-mysqlnone pn postfix-pcre none pn postfix-pgsqlnone pn procmail none ii resolvconf 1.67 pn sasl2-binnone pn ufw none -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
