This audio issue was resolved for me with the SoC updates included in
stable linux-image:
5.10.0-21-amd64 5.10.162-1 (2023-01-21) x86_64
For reference, my machine info:
Product Name: 20QDCTO1WW
Version: ThinkPad X1 Carbon 7th
BIOS Version: N2HET68W (1.51)
Audio PCI info:
00:1f.3
-git a/debian/changelog b/debian/changelog
index 2a146c2..7b1e0bc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ca-certificates (20211010) UNRELEASED; urgency=medium
+
+ [ Michael Shuler ]
+ * Fix error on install when TEMPBUNDLE missing. Closes: #996005
+
+ -- Michael Sh
On 8/17/21 9:40 AM, Alex wrote:
I am not sure if ca-certificates-mono was installed at all. I do not
have mono on the system.
The machine did have the packages below installed at some point.
$ dpkg -l|grep mono|grep -v fonts-|grep -v python3-monotonic
rc ca-certificates-mono
Control: notfound -1 20210119
Control: reassign -1 ca-certificates-mono
Control: tags -1 + moreinfo
On 8/16/21 4:58 PM, Alex wrote:
...
Updating Mono key store
/etc/ca-certificates/update.d/mono-keystore: 10: /usr/bin/cert-sync: not found
Done
Reassigning to appropriate package,
properly.
Some information about this package:
Package: ca-certificates
Binary: ca-certificates, ca-certificates-udeb
Version: 20190110
Maintainer: Michael Shuler
Uploaders: Raphael Geissert , Thijs Kinkhorst
Build-Depends: debhelper-compat (= 12), po-debconf
Build-Depends-Indep: python, openssl
, Michael Shuler wrote:
On 6/11/20 1:33 PM, Adam D. Barratt wrote:
Just to confirm - will the certificates be automatically re-
added (assuming that users have either the automatically trust
or prompt options enabled)?
(stretch-pu report cc'ed, since same applies)
Excellent question. I believe
On 6/11/20 1:33 PM, Adam D. Barratt wrote:
Just to confirm - will the certificates be automatically re-added
(assuming that users have either the automatically trust or prompt
options enabled)?
(stretch-pu report cc'ed, since same applies)
Excellent question. I believe we're going to hit
611~deb9u1 with the
following changes:
ca-certificates (20200611~deb9u1) stretch; urgency=medium
* Rebuild for stretch.
* This oldstable release Closes: #962596, #942915
-- Michael Shuler Thu, 11 Jun 2020 09:11:56
-0500
ca-certificates (20200611) unstable; urgency=medium
11~deb10u1 with the
following changes:
ca-certificates (20200611~deb10u1) buster; urgency=medium
* Rebuild for buster.
* This stable release Closes: #962596, #942915
-- Michael Shuler Thu, 11 Jun 2020 09:07:27
-0500
ca-certificates (20200611) unstable; urgency=medium
* mozilla
ss 3 Public Primary Certification Authority - G5"
+ "VeriSign Universal Root Certification Authority"
.
[ Gianfranco Costamagna ]
* debian/{rules,control}:
Merge Ubuntu patch from Matthias Klose to use Python3 during build.
Closes: #942915
Regards,
--
Michael Shuler
Control: severity -1 serious
Control: tags -1 + pending
Control: tags 942915 + pending
Bump severity. Pending branch commits:
master: commit 679daf6e9bf6fcdcb574b8029297d24836fafde0
Revert "Set release 20200601; add Symantec CAs to blacklist"
This reverts commit
Control: severity -1 important
(cc'ed bug reporters and those on a direct email to ack)
On 6/10/20 3:27 PM, Carlos Alberto Lopez Perez wrote:
On 10/06/2020 16:51, Philippe Normand wrote:
Since the update of ca-certificates to version 20200601 I can no longer access
webkit.org websites.
The
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
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 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
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
ts expired "AddTrust External
Root". Closes: #956411, #955038, #911289, #961907
Thank you sponsor!
--
Kind regards,
Michael Shuler
/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
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
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
ficate can be blacklisted to effectively remove it.
CCing #955038 (remove in later replies, please) and BCCing the original
and secondary reporters to acknowledge. Thanks for report and follow up
on the error.
Kind regards,
Michael Shuler
--
$ openssl x509 -noout -startdate -enddate -in
/us
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
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
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
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
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
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 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 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/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 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 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
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/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
"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
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: tags -1 + pending
Quick update for the new git repo location and tag pending.
https://salsa.debian.org/mshuler-guest/ifmetric
--
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
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 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)
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,
>
>
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
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 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
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 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
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
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) !=
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
severity 895482 important
thanks
Dropped severity to allow testing migration.
--
Michael
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.
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
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
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:
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,
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
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
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
.
--
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/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
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 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
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 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
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 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
Clone the repo and `dpkg-buildpackage`.
--
Kind regards,
Michael
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.
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,
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 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
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
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
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':
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
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
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
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
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 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 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/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/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/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 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
1 - 100 of 313 matches
Mail list logo
