On 12/14/2015 06:22 PM, Andrew Ayer wrote:
> I'm curious why the 2.6 update wasn't included with the 20151204
> release.
Thanks.
Thijs and/or Raphael. Please, hold until some additional changes can be
committed to include 2.6.
NSS released 2.6 while working on 2.5, essentially, Andrew.
--
Control: tags -1 + pending
Committed to master for next upload. Thanks, Daniel!
--
Kind regards,
Michael
On 12/14/2015 06:18 PM, Andrew Ayer wrote:
> Hi Michael,
>
> Have you given any more thought to a redesign of ca-certificates that
> separates the email certificates from the TLS certificates? I suspect
Yep - got a patch? :-)
> that the vast majority of packages that depend on ca-certificates
On 12/14/2015 07:45 PM, Andrew Ayer wrote:
> On Mon, 14 Dec 2015 18:45:40 -0600
> Michael Shuler <mich...@pbandjelly.org> wrote:
>
>>> As always, let me know if you could use any help. I'm going to
>>> start looking through the reverse depends for ca-cert
Control: tags -1 + pending
http://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/commit/?id=24b5bdcb3a3ede1d9664958b55cd480fc43e97b3
--
Kind regards,
Michael
On 12/28/2015 03:53 PM, Michael Shuler wrote:
`openssl s_client -CApath /etc/ssl/certs -connect
wrapdb.mesonbuild.com:443` shows the cert for wrapdb.mesonbuild.com,
issued by CN=Let's Encrypt Authority X1, but no intermediate, which is
cross-signed by DST Root CA X3 and should validate properly
On 12/28/2015 01:54 PM, Jussi Pakkanen wrote:
Currently trying to connect to a server that has letsencrypt enabled
will fail. For example this command:
wget https://wrapdb.mesonbuild.com
will error out saying that the certificate is not trusted because it has
no known issuer. The connection
Control: tags -1 + pending
On 11/22/2015 12:28 PM, Richard Ipsum wrote:
> The attached patch is based on the patch provided by Andrew Wilcox,
> I've verified that this patched version of certdata2pem.py produces
> the same certificate filenames when run with python2 and python3 and
> also when
On 11/22/2015 12:28 PM, Richard Ipsum wrote:
The attached patch is based on the patch provided by Andrew Wilcox,
I've verified that this patched version of certdata2pem.py produces
the same certificate filenames when run with python2 and python3 and
also when run with python2 without this patch.
On 11/25/2015 03:13 PM, Andrew Ayer wrote:
>> The April release contained the 2.4 bundle from Mozilla. CA bundle 2.5
>> was recently released in NSS and an upload to unstable is being
>> prepped.
I was incorrect about the NSS release relative time being as recent as I
recalled. See below.
> I'm
Control: tags -1 + pending
On 11/25/2015 11:28 AM, Andrew Ayer wrote:
> ca-certificates hasn't been updated since April 2015. Since then, 14
> CAs have been removed from the NSS root store[1, 2]. ca-certificates in
> stable hasn't been updated since October 2014. Since then, 6 additional
> CAs
On 02/05/2016 05:49 AM, Rich wrote:
subject says it all.
Please provide a specific URL to test. The "Baltimore CyberTrust Root"
CA may be a different issue, looking at several mozilla bugzilla
tickets, but I can't tell without any detail.
Thanks, Michael
On 01/27/2016 06:47 AM, Christian Beer wrote:
I tested with a current Jessie and Stretch installation and it turns out
that openssl 1.0.2 verifies the "Thawte Primary Root CA" correctly
because it is in the certificate store. With openssl 1.0.1 this
verification fails because it looks for the
On 02/02/2016 02:22 PM, Tim Small wrote:
#813468 is similar but impacting a different application. I did come
across a patch which backports the fix included in newer versions of the
upstream OpenSSL 1.0.1 branch, to the 1.0.1k derived package in Jessie.
I haven't reviewed or tested the fix
On 02/20/2016 06:53 AM, Adam D. Barratt wrote:
> For reference, neither the above nor the message opening the bug made it
> to debian-release, presumably for size reasons.
Thanks for the follow up.
> Looking at the diff:
>
> diff -Nru ca-certificates-20130119+deb7u1/debian/config
>
On 02/16/2016 11:22 AM, Tony den Haan wrote:
> openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
>
> on jessie: (and ubuntu lts :)
> Verify return code: 20 (unable to get local issuer certificate)
>
> on testing:
> Verify return code: 0 (ok)
>
This appears to be unrelated
On 02/25/2016 08:58 AM, Tony den Haan wrote:
> That is the problem, it requires -CApath, while /etc/ssl/certs should be
> default. On testing it works ok without it.
Which is unrelated to the ca-certificates package - that's my point :)
Feel free to open a new bug report for the openssl package
On 02/22/2016 04:12 AM, Christian Beer wrote:
> It seems that the openssl update is not happening soon. Can you please
> include the 1024bit certificates again to solve this regression?
Yeah, I have a work in progress branch that re-includes the 1024-bit
CAs. Ran back into #743339 on upgrade, so
On 01/24/2016 09:49 AM, gregor herrmann wrote:
On Sun, 24 Jan 2016 12:32:39 +0100, Rosario Maddox wrote:
Yesterday I did: sudo apt-get upgrade, and I have this now:
Can't send SMS: 500 Can't connect to api.twilio.com:443 (certificate
verify failed) at /usr/share/perl5/SMS/Send.pm line 270.
Backlog of $REAL_LIFE work has kept me super busy. I ran into upgrade
issues (sorry, don't have the existing bts#), and it looks like Ubuntu
did a similar addition using a 'mozilla-1024/' directory, which may
solve the immediate upgrade problem with previously removed
certificates. I have not
reassign 816541 ca-certificates-java 20140324
thanks
See /etc/ca-certificates/update.d/jks-keystore hook, which is run by
update-ca-certificates, but is from the ca-certificates-java. There are
still users of Sun Java 6, so IMO, this is a non-issue, but I'll let the
package maintainer decide
On 06/28/2016 07:57 AM, Jonathan Wiltshire wrote:
>
> The attached patch updates the package to the latest Mozilla bundle.
Thanks for the update patch and the recent bug triage, Jonathan. I
appreciate the help!
--
Warm regards,
Michael
signature.asc
Description: OpenPGP digital signature
The ca-certificates triggers were added to deal with
installation/upgrade problems in https://bugs.debian.org/537051
Do you have a suggested patch that also properly handles the issues
presented in #537051? I would suggest that downloader packages possibly
might pre-depend on ca-certificates, if
Thanks for the follow up. I'll get this fixed and resubmit a new debdiff
for stable update.
--
Kind regards,
Michael
PU request sent!
https://bugs.debian.org/852040
Thanks again,
Michael
-certificates (20141019+deb8u3) stable; urgency=medium
+
+ * sbin/update-ca-certificates:
+Update local certificates directory when calling --fresh. Closes: #783615
+
+ -- Michael Shuler <mich...@pbandjelly.org> Wed, 18 Jan 2017 15:54:56 -0600
+
ca-certificates (20141019+deb8u2) stable; u
On 01/18/2017 03:25 PM, Adrian Bunk wrote:
> after a discussion with someone who ran into this bug in stable I have
> set the severity to serious, since this should IMHO also be fixed in
> stable.
This does look like a good patch to backport to stable. I'll get this
commited to git and work on
On 09/11/2016 03:48 AM, Andreas Beckmann wrote:
> The fix is quite easy: we just need to run update-ca-certificates
> *without* processing the hooks during postinst configure:
>
> update-ca-certificates --hooksdir ""
Thanks Andreas! I'll test this out as soon as I can.
> This should be
Control: tags -1 + pending
On 08/04/2016 07:02 AM, Jonathan Wiltshire wrote:
> Can I be any help in moving this along? It would be nice to get a stable
> update underway too, and the next point release isn't far away.
Thanks for the ping. I have committed the 2.7 bundle to the collab-maint
On 11/08/2016 10:07 PM, Thomas Lange wrote:
> My /usr/local file system is mounted read-only via NFS. This results
> in an error:
>
>
> stretch[~]# dpkg --configure ca-certificates
> Setting up ca-certificates (20161102) ...
> chmod: changing permissions of '/usr/local/share/ca-certificates':
Thanks for the patches to enable the use of HTTPS in the installer. This
does sound useful. (And apologies for the holiday delay in replying.)
I'd like to complete a pending stable upload, first, then I'll work on
this request.
--
Kind regards,
Michael
Stable update requested! Thanks again for the report, Andreas.
https://bugs.debian.org/844746
"jessie-pu: package ca-certificates/20141019+deb8u2"
--
Kind regards,
Michael Shuler
signature.asc
Description: OpenPGP digital signature
d flag for all options.
* debian/patches/ifmetric.8_typo:
Fix typo in man page.
-- Michael Shuler <mich...@pbandjelly.org> Thu, 03 Nov 2016 18:09:20 -0500
Thanks for your time!
--
Kind regards,
Michael
signature.asc
Description: OpenPGP digital signature
Just a quick follow up. Thijs uploaded ca-certificates_20161130 this
morning, and it is currently in the NEW binary-BYHAND queue for approval.
--
Kind regards,
Michael
On 01/01/2017 12:40 PM, Thomas Lange wrote:
> There's still no fix. Do you need help for a fix?
If you have a patch idea, that would be great! Apologies for the delay
in getting something together to reproduce and test a fix.
--
Kind regards,
Michael
On 03/23/2017 04:02 AM, Chris Lamb wrote:
> StartCom and WoSign certificates are now untrusted by the major browser
> vendors[0][1], making websites that use certs from these vendors
> inaccessible.
I followed these events on dev-security-policy and libnss performs date
checks on certs signed by
Control: tags -1 - moreinfo + pending
Thanks for the details. Those appear to be a few of the removals in the
2.11 bundle, which are committed, but not released yet. Those will make
it to a stable proposed update, too.
On 03/20/2017 12:59 PM, Alex Gaynor wrote:
> Confirmed that with the package from `git`, this is resolved! Awesome.
Great! Thanks a bunch for the confirmation.
--
Warm regards,
Michael
Control: tags -1 + moreinfo
On 03/17/2017 04:38 PM, Alex Gaynor wrote:
> Package: ca-certificates
> Severity: normal
What version of ca-certificates?
> The ca-certificates package includes legacy root certificates which have
> 1024-bit RSA keys. These are considered weak by modern standards,
Clone the repo and `dpkg-buildpackage`.
--
Kind regards,
Michael
I appreciate the research and suggestions. I'd be happy to review a
patch submission to fix this. I'm not a mutt nor S/MIME user, so perhaps
there may be some fallout from simple removal of email-only roots, if
there are people using them. There's no way I know of to tell how many
users use
On 04/17/2017 03:22 PM, Thomas Lange wrote:
> The fix works for me. Please try to fix it soon, so the fixed version
> will be going into the stretch release.
Thanks for the patch, Antoine, and confirmation, Thomas - I'll get an
upload ready as soon as I can.
--
Kind regards,
Michael
On 07/06/2017 11:13 PM, Paul Wise wrote:
> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote:
>
>> For what it's worth, my opinion is that we should attempt to synchronize
>> certdata.txt (and blacklist.txt, for that matter) across all suites (but
>> not other changes to the packaging). This
.
--
Kind regards,
Michael
(master)mshuler@hana:~/git/ifmetric$ git-buildpackage
dpkg-buildpackage -rfakeroot -D -us -uc -i -I
dpkg-buildpackage: source package ifmetric
dpkg-buildpackage: source version 0.3-5
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by Michael
On 07/21/2017 12:46 AM, Michael Shuler wrote:
> I committed this patch to git and started to test, but it fails to
> compile for me. Quick repro:
>
> git clone https://anonscm.debian.org/git/collab-maint/ifmetric.git
> cd ifmetric/
> git-buildpackage
>
> Due to harde
The patch was committed to collab-maint master a few days ago and I
tagged this bug as pending yesterday. It's on the way :)
--
Kind regards,
Michael
Testing against a new build for jessie, it looks as if the
ca-certificates-java hook does nothing with new CA certificate
additions, either? None of the newly added CAs appear to have made it to
the keystore upon package upgrade, but were added in --fresh. It appears
the hook is not doing the
On 04/28/2017 11:39 AM, Adam D. Barratt wrote:
> On Fri, 2017-04-28 at 00:58 +0200, Andreas Beckmann wrote:
>>
>> Attached is the combined debdiff of the commits backported by Michael
>> and me. I verified in piuparts that "running update-certificates without
>> hooks initially" now actually works
Hi Jim,
Thanks for the patch. Do you happen to know if this patch presents any
adverse behavior on kernel versions <4.4, or if this ends up being a
no-op? I ask because Jessie is 3.16 by default, with a 4.9 kernel
version in backports.
Thanks!
Michael
On 05/26/2017 02:18 PM, Jacob Hoffman-Andrews wrote:
> Hi, just checking in on the status of this. I provided a patch above;
> does it look good to you?
The patch is simple, so I see no particular issue with it. My time has
been crunched lately, but I have some vacation soon with plans for some
On 05/19/2017 10:07 AM, Chris Lamb wrote:
> I've uploaded ca-certificates 20161130+nmu1 to DELAYED/5:
>
> ca-certificates (20161130+nmu1) unstable; urgency=medium
>
> * Non-maintainer upload.
> * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they
> are
>
On 09/03/2017 09:09 AM, Julien Cristau wrote:
> ca-certificates 20170717 added the "TUBITAK Kamu SM SSL Kok Sertifikasi
> - Surum 1" CA, but when that was added to nss it was restricted to a
> small set of domains[1]. Thus I wonder if it wouldn't be better to
> blacklist it from ca-certificates,
severity 895482 important
thanks
Dropped severity to allow testing migration.
--
Michael
On 06/08/2018 03:37 PM, Adam D. Barratt wrote:
Ping? We're a week away from the final chance to get an update into
jessie-as-oldstable before it becomes jessie-lts.
Thanks for the ping. I updated the debian-jessie branch of
ca-certificates with mozilla bundle 2.22, and it's ready to be
On 06/13/2018 02:35 AM, Cyril Brulebois wrote:
It seems the block-udeb isn't the only blocker though:
Migration status: BLOCKED: Rejected/introduces a regression
Updating ca-certificates introduces new bugs: #895482
and I see no severity downgrade in that bug report?
It was upgraded
Control: tags -1 + moreinfo
On 02/07/2018 03:29 PM, Nicholas D Steeves wrote:
https://piuparts.debian.org/stretch2buster-rcmd/fail/ca-certificates_20170717.log
1m9.6s DEBUG: Modified(user, group, mode, size, target):
/etc/ca-certificates.conf expected(root, root, - 100644, 6488, None) !=
frozen[1], as noted a couple days ago on d-d-announce (thank you for
this note!).
Kind regards,
Michael Shuler
[0] https://bugs.debian.org/895482
[1] https://qa.debian.org/excuses.php?package=ca-certificates
On 05/30/2018 12:46 PM, Sebastian Andrzej Siewior wrote:
I've read about this bug (and the other one) on d-devel. I uploaded
recently a new version of openssl to unstable (1.1.0h-3)which changes
the exit code of "openssl rehash" to zero in case of a duplicate or if a
certificate can no be open.
On 06/20/2018 04:33 PM, Sebastian Andrzej Siewior wrote:
On 2018-06-13 08:19:32 [+0200], To Axel Beckert wrote:
I asked upstream what they thing about ignoring these errors because the
perl script does so. On the other hand what about cleaning up these
dangling symlinks?
ca-certificate
On 07/05/2018 03:37 PM, Adam D. Barratt wrote:
On Sun, 2018-06-10 at 21:22 -0500, Michael Shuler wrote:
I would like to upload ca-certificates_20161130+nmu1+deb9u1 with the
following fixes:
- update Mozilla CA bundle in Stretch to 2.22 (#858064)
- fix postinst failure on read-only /usr/local
Control: tags -1 + moreinfo
On 07/07/2018 10:21 AM, guidot wrote:
> I just updated from 20141019+deb8u3 to 20141019+deb8u4 using
>
> aptitude safe-upgrade
>
> and got these errors:
>
> Updating certificates in /etc/ssl/certs... unable to load certificate
>
On 04/11/2018 04:01 PM, Pr0metheus wrote:
>
>* What led up to the situation?
>
> apt-get upgrade
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> Cannot fix the problem
>
>* What was the outcome of this action?
>
> Setting up
Thanks for the details. #895473 reported a similar error on locally
installed CA certificates, which I think may be related.
Each of the list of `rehash: skipping .. cannot open file` in your
errors appears to be on CAs that were removed in the package during this
update, so somewhere we have a
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894282
This appears to be a bug in openssl with a new version to address the
regression.
--
Kind regards,
Michael
On 03/28/2018 09:07 AM, Helmut Grohne wrote:
> Package: ca-certificates
> Version: 20170717
> Severity: grave
> Justification:
Thanks, I'll take a look. From memory, I recall this was a "certificates
after X date" logic in NSS, but the CAs are still in certdata.txt.
--
Kind regards,
Michael
Did you run `update-ca-certificates --fresh`?
That's the flag that clears all symlinks, then updates.
--
Kind regards,
Michael
On 10/18/18 8:08 AM, Laurent Bigonville wrote:
> Package: ca-certificates
> Version: 20180409
> Severity: normal
> File: /usr/sbin/update-ca-certificates
>
> Hi,
>
>
"Certplus Root CA G2"
- "OpenTrust Root CA G1"
- "OpenTrust Root CA G2"
- "OpenTrust Root CA G3"
- "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
- "Visa eCommerce Root"
-- Michael Shuler Thu, 10 Jan 2019 19:31:31 -0600
--
Kind regards,
Michael
signature.asc
Description: OpenPGP digital signature
I've been able to test this error by creating a bogus symlink in
/etc/ssl/certs and I committed a patch that removes any orphan symlinks,
prior to running `openssl rehash`.
https://salsa.debian.org/debian/ca-certificates/commit/cfe7064cb707ed2e8ac587877c1153029d46dc28
--
Kind regards,
Michael.
On 10/18/18 8:08 AM, Laurent Bigonville wrote:
>
> In the past I've added certificates in /usr/local/share/ca-certificates
>
> After running update-ca-certificates symlinks were added in
> /etc/ssl/certs
>
> After removing the files from /usr/local/share/ca-certificates and
> running
Control: tags -1 + pending
Quick update for the new git repo location and tag pending.
https://salsa.debian.org/mshuler-guest/ifmetric
--
Kind regards,
Michael
nel
4.4+. Thanks for the patch, Jim Paris. Closes: #864889
-- Michael Shuler Thu, 10 Jan 2019 13:17:26 -0600
The package is lintian clean with a couple pedantic warnings.
The package shows 2 warnings on the mentors site that I have not been
able to resolve (bugs with mentors site?):
- Build
Control: reassign -1 ca-certificates-java 20180516
Purge (not just remove) of the ca-certificates-java package should
remove config files, including
/etc/ca-certificates/update.d/jks-keystore. Reassigning to appropriate
package, ca-certificates-java, but perhaps this is wontfix.
--
Kind
On 12/19/18 3:10 AM, Maurizio Sartori wrote:
>
>* Possible correction
> The problem seems to be in
> /var/lib/dpkg/info/ca-certificates.postinst
> the stat command should have the '-L' switch
>
> So for example:
> chmod $(stat -c %a /usr/local)
What version of the openssl package is installed?
This does sound like a potential issue with `openssl rehash`. Your
workaround looks OK for the moment, but the problem is that the openssl
devs would like to remove the deprecated `c_rehash` utility. At this
point in the release cycle, it's
On 2/28/19 4:30 PM, James Pooton wrote:
>
>> What version of the openssl package is installed?
>
> Currently we’ve got the following versions getting installed:
>
> openssl: Installed: 1.1.1a-1 Candidate: 1.1.1a-1 Version table: ***
> 1.1.1a-1 500 500 http://deb.debian.org/debian buster/main
On 2/28/19 7:37 PM, James Pooton wrote:
> So installing ca-certificates (20170717) with the latest openssl
> (1.1.1a-1), does produce the hashes in /etc/ssl/certs when doing an ARM
> 32bit build via QEMU.
>
> One interesting thing is that the 382 syscalls were still present in the
> build, so
On 3/7/19 8:13 AM, Michael Stapelberg wrote:
> Package: ca-certificates
> Version: 20190110
> Severity: normal
>
> The i3 continuous integration testing on travis-ci.org currently fails:
>
> Setting up ca-certificates (20190110) ...
> Updating certificates in /etc/ssl/certs...
> mv: cannot move
On 3/5/19 11:47 AM, Arthur de Jong wrote:
> I have created a merge request in Salsa for this:
> https://salsa.debian.org/debian/ca-certificates/merge_requests/2
Thank for the MR. I'll take a look.
--
Kind regards,
Michael
On 3/19/19 3:29 AM, Michael Stapelberg wrote:
> So I debugged this some more, and found out that the problem is that
> moving *any files* from /tmp to /etc does not work, but only within the
> Docker container running on travis-ci, and only when configured with
> “group: deprecated-2017Q3”. The
On 2/11/19 12:51 PM, Michel Meyers wrote:
> Mystery solved: Somebody (or something) placed a private key in a file
> called privkey.pem and stored it in /etc/ssl/certs. This caused openssl
> rehash to silently exit with error code 1, thus causing the whole
> postinst script to fail.
>
> After
Control: tag -1 moreinfo
On 2/11/19 9:58 AM, Michel Meyers wrote:
>
> Setting up ca-certificates (20190110) ...
> Updating certificates in /etc/ssl/certs...
> dpkg: error processing package ca-certificates (--configure):
> installed ca-certificates package post-installation script
On 1/24/19 7:54 AM, Dimitris Aragiorgis wrote:
>
> It seems that update-ca-certificates temporarily removes the
> /etc/ssl/certs/ca-certificates.crt bundle.
I remember this bug. c_rehash behavior was "fixed" at some point and
resulted in multiple symlinks to ca-certificates.crt, so moving it out
On 4/24/19 5:22 PM, Soppy bear wrote:
1. This is a Debian problem because the end user should be able to
use TLS without having to import/use certificates without any
practical use for normal operations.
Users *can* configure the ca-certificate package and set CA trust for
each and every CA,
On 2/5/20 11:12 AM, Dan Nicholson wrote:
I recently ran into this same issue and dug into it for a while. The
real problem stems from
https://sourceware.org/bugzilla/show_bug.cgi?id=23960. The issue is
that glibc 2.28 changed readdir to always use getdents64. This causes
problems when you're
Thanks for the bug report. I've checked in the latest release branch
certdata, so the recent adds/removes will be up in the next release.
I'll try to get that release built soon, it has indeed been a while.
Kind regards,
Michael
tags 911289 + pending
tags 955038 + pending
tags 956411 + pending
tags 961907 + pending
thanks
This commit on master is good to go to fix the above bugs in unstable -
marking them pending:
commit b3a8980b781bc9a370e42714a605cd4191bb6c0b
Commit: Michael Shuler
CommitDate: Mon Jun 1 14:38
ge changes from 20200601
- d/control; set d/gbp.conf branch to debian-buster
* This security release updates the Mozilla CA bundle and blacklists
distrusted Symantec roots and the expired AddTrust External Root.
Regards,
Michael Shuler
- "thawte Primary Root CA"
- "thawte Primary Root CA - G2"
- "thawte Primary Root CA - G3"
- "VeriSign Class 3 Public Primary Certification Authority - G4"
- "VeriSign Class 3 Public Primary Certification Authority - G5"
- "VeriSign Universal Root Certification Authority"
Regards,
Michael Shuler
ge changes from 20200601
- d/control
* This security release updates the Mozilla CA bundle and blacklists
distrusted Symantec roots and the expired AddTrust External Root.
Regards,
Michael Shuler
On 6/5/20 10:37 AM, Adam D. Barratt wrote:
On Thu, 2020-06-04 at 20:48 -0500, Michael Shuler wrote:
Thanks again, uploaded to mentors:
RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
https://bugs.debian.org/962245
I re-uploaded to mentors the updated 20200601~deb9u1
On 6/5/20 10:35 AM, Adrian Bunk wrote:
Except for keeping debian/NEWS you were actually backporting everything
that was possible, this was not a 20161130+nmu1+deb9u2 release that
cherry-picked only one or few changes.
Given the nature of ca-certificates it was IMHO the correct decision
to
since
there is no secret info in here:
Forwarded Message
Subject: ca-certificates: buster-security & stretch-security (and sid)
uploads
Date: Mon, 1 Jun 2020 22:22:47 -0500
From: Michael Shuler
To: t...@security.debian.org
Hi Security Team,
I committed changes to to git
tags 942915 + pending
thanks
On 6/3/20 6:25 AM, Gianfranco Costamagna wrote:
the patch is now committed on the shared git, but I don't plan to upload it.
(I don't like to touch native packages when possible)
I was just looking at this exact change last night, thanks for the
commit. It
/nssckbi.h |6
7 files changed, 2731 insertions(+), 2518 deletions(-)
Full debdiff.gz attached, due to the size of certdata changes.
--
Kind regards,
Michael Shuler
ca-certificates_20200601~deb9u1.debdiff.gz
Description: application/gzip
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
* Note: Please, upload this to buster-updates as well to fix ongoing
issues with failing web services from the expired AddTrust certificate.
See #961907 for details.
I would
ts expired "AddTrust External
Root". Closes: #956411, #955038, #911289, #961907
Thank you sponsor!
--
Kind regards,
Michael Shuler
Thanks again, uploaded to mentors:
RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
https://bugs.debian.org/962245
--
Kind regards,
Michael
Thank you. Uploaded to mentors:
RFS: ca-certificates/20200601~deb10u1 [RC] -- Common CA certificates
https://bugs.debian.org/962244
--
Kind regards,
Michael
Root". Closes: #956411, #955038, #911289, #961907
* Fix permissions on /usr/local/share/ca-certificates when using
symlinks.
Closes: #916833
Thank you sponsor!
--
Kind regards,
Michael Shuler
On 6/5/20 4:15 AM, Adrian Bunk wrote:
Compared to 20200601 and 20200601~deb10u1 this contains the following
additional files:
/usr/share/ca-certificates/mozilla/AddTrust_Low-Value_Services_Root.crt
/usr/share/ca-certificates/mozilla/Camerfirma_Chambers_of_Commerce_Root.crt
201 - 300 of 313 matches
Mail list logo
