Bug#867461: jessie-pu: package ca-certificates/20141019+deb8u3
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu The ca-certificates package in jessie is still vulnerable to #858539, that is it still ships the WoSign and StartCom certificates which have been marked as blacklisted after october 21st 2016 by the Mozilla team. There was a NMU to unstable in may that seems to have trickled down into stable (stretch) but obviously not oldstable (jessie). I think it may be worth making an update for this. I have sent a patch for both jessie and wheezy (the latter of which I can take of myself) in the bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858539#66 .. and attached. I wonder, however, if we should not also update the certdata.txt file to sync with upstream, as this features interesting additions like the Let's Encrypt root and removal of other certificates: + "AC RAIZ FNMT-RCM" + "Amazon Root CA 1" + "Amazon Root CA 2" + "Amazon Root CA 3" + "Amazon Root CA 4" + "LuxTrust Global Root 2" + "Symantec Class 1 Public Primary Certification Authority - G4" + "Symantec Class 1 Public Primary Certification Authority - G6" + "Symantec Class 2 Public Primary Certification Authority - G4" + "Symantec Class 2 Public Primary Certification Authority - G6" - "Buypass Class 2 CA 1" - "EBG Elektronik Sertifika Hizmet Saglayicisi" - "Equifax Secure CA" - "Equifax Secure Global eBusiness CA" - "Equifax Secure eBusiness CA 1" - "IGC/A" - "Juur-SK" - "RSA Security 2048 v3" - "Root CA Generalitat Valenciana" - "S-TRUST Authentication and Encryption Root CA 2005 PN" - "Verisign Class 1 Public Primary Certification Authority" - "Verisign Class 2 Public Primary Certification Authority - G2" - "Verisign Class 3 Public Primary Certification Authority" This update, from upstream NSS 2.4 to 2.11 has yet to be uploaded in unstable however, so I guess this would need to wait a trickle down into buster and a synchronous update to stretch/jessie? In general, this raises the question of whether we want the same certdata.txt across all suites or we are okay with having that file out of date in older releases. Let me know how this should be managed. A. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) From 9ac1618482517826a10a9dc0a49c8b3bc5595cb3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Thu, 6 Jul 2017 13:28:22 -0400 Subject: [PATCH] merge in NMU for #858539 --- debian/changelog | 9 + mozilla/blacklist.txt | 16 2 files changed, 25 insertions(+) diff --git a/debian/changelog b/debian/changelog index a6b8b1e..88a7f1d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +ca-certificates (20141019+deb8u4) jessie; urgency=medium + + [ Chris Lamb ] + * Non-maintainer upload. + * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they are +now untrusted by the major browser vendors. Closes: #858539 + + -- Antoine Beaupré Thu, 06 Jul 2017 13:18:47 -0400 + ca-certificates (20141019+deb8u3) jessie; urgency=medium [ Michael Shuler ] diff --git a/mozilla/blacklist.txt b/mozilla/blacklist.txt index 911f9f1..6ea1732 100644 --- a/mozilla/blacklist.txt +++ b/mozilla/blacklist.txt @@ -5,3 +5,19 @@ # DigiNotar Root CA (see debbug#639744) "DigiNotar Root CA" + +# StartCom and WoSign certificates are now untrusted by the major browser +# vendors[0]. See [1] for discussion. The list was generated by: +# +# $ egrep 'WoSign|StartCom' mozilla/certdata.txt \ +# | grep UTF | sed 's/CKA_LABEL UTF8 //' | uniq +# +# [0] https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ +# [1] https://bugs.debian.org/858539 +# +"StartCom Certification Authority" +"StartCom Certification Authority G2" +"WoSign" +"WoSign China" +"Certification Authority of WoSign G2" +"CA WoSign ECC Root" -- 2.11.0
Bug#867461: should ca-certificates certdata.txt synchronize across all suites?
Hi everyone, In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for wheezy, I noticed the issue was also pending in jessie. Furthermore, the idea originally raised by pabs[1] was to also update the packages for the latest changes in certdata.txt in wheezy, including the ISRG Root for Let's Encrypt (LE). While it should be fairly trivial to do this update, I wonder if the same logic should apply to jessie itself. Right now, jessie and stretch are synchronized, but that's only because there's an update pending in unstable to synchronize with the upstream 2.11 NSS database. This raises the question of how synchronized we want this file to be? It seems a little arbitrary to me to synchronize the file from jessie to wheezy only for this one certificate authority (LE). How about the other authorities? It doesn't seem like we should be calling the shots on this: if we follow the Mozilla policies here, either we update all supported suites at once, or we accept that some suites will have outdated material. I have therefore opened this specific discussion with the release team in #867461 (in CC as well). Hopefully this will bring a consistent policy. 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 would remove another decision point in our infrastructure and ensure harmonious X509 processing across suites. [1]: https://lists.debian.org/1490430746.9127.2.ca...@debian.org Thanks for any feedback. For now I'll hold on another week or so for the wheezy update, since it seems unreasonable to push that update out before jessie is updated and that question is resolved. A. -- We won't have a society if we destroy the environment. - Margaret Mead
Bug#867479: stretch-pu: package adwaita-icon-theme/3.22.0-1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Hi, It seems that the version 3.22.0-1 of adwaita-icon-theme is shipping a malformed .svg icon. The attached patch if fixing that. It will be fixed in unstable/testing in the next adwaita-icon-theme upload. Regards, Laurent Bigonville -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Index: debian/patches/series === --- debian/patches/series (nonexistent) +++ debian/patches/series (révision 52608) @@ -0,0 +1 @@ +01_fix_send-to-symbolic.patch Index: debian/patches/01_fix_send-to-symbolic.patch === --- debian/patches/01_fix_send-to-symbolic.patch(nonexistent) +++ debian/patches/01_fix_send-to-symbolic.patch(révision 52608) @@ -0,0 +1,41 @@ +From 58cd459e1fdba84f3c7e745636188750ad6d44c8 Mon Sep 17 00:00:00 2001 +From: Iain Lane +Date: Tue, 13 Dec 2016 11:52:56 + +Subject: symbolic: re-render send-to + +Re-render send-to to clean up merge conflict grabage. + +https://bugzilla.gnome.org/show_bug.cgi?id=772031 +--- + Adwaita/scalable/actions/send-to-symbolic.svg | 8 ++-- + 1 file changed, 2 insertions(+), 6 deletions(-) + +diff --git a/Adwaita/scalable/actions/send-to-symbolic.svg b/Adwaita/scalable/actions/send-to-symbolic.svg +index ac20050..0b661cb 100644 +--- a/Adwaita/scalable/actions/send-to-symbolic.svg b/Adwaita/scalable/actions/send-to-symbolic.svg +@@ -1,7 +1,7 @@ + + + +- ++ + + + +@@ -11,11 +11,7 @@ + + + +-<<< HEAD +- +-=== +- +->>> db54204... symbolic: odd recoloring issue workaround ++ + + + Gnome Symbolic Icon Theme +-- +cgit v0.12 + Index: debian/changelog === --- debian/changelog(révision 52605) +++ debian/changelog(révision 52608) @@ -1,3 +1,10 @@ +adwaita-icon-theme (3.22.0-1+deb9u1) UNRELEASED; urgency=medium + + * debian/patches/01_fix_send-to-symbolic.patch: Fix malformed +send-to-symbolic icon (Closes: #838961) + + -- Laurent Bigonville Thu, 06 Jul 2017 20:12:11 +0200 + adwaita-icon-theme (3.22.0-1) unstable; urgency=medium [ Andreas Henriksson ]
Bug#867335: stretch-pu: package systemd/232-25
Hi, Michael Biebl (2017-07-05): > I'd like to make a stable upload for systemd. > > All changes are already in unstable. > An annotated changelog follows: Just had a quick glance at git, and it feels like there's a booboo… > systemd (232-25+deb9u1) stretch; urgency=medium > > [ Dimitri John Ledkov ] > * Fix out-of-bounds write in systemd-resolved. > CVE-2017-9445 (Closes: #866147, LP: #1695546) > > https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch-proposed&id=986c0be9809e6234680c001b731c5b3099f41c1c > > That's probably the most important one to get into stretch. > The security team wanted us to fix this issue via a stable upload. What's up with this extra patch, which seems entirely unrelated? debian/patches/debian/fsckd-daemon-for-inter-fsckd-communication.patch I'll have a closer look at the rest when time permits. KiBi. signature.asc Description: Digital signature
Bug#865225: stretch-pu: package request-tracker4/4.4.1-3+deb9u2
On Sun, Jul 02, 2017 at 11:18:43PM +0200, Cyril Brulebois wrote: > Hi, > > Dominic Hargreaves (2017-06-27): > > Sorry, this is not yet uploaded. I somehow got this and the anope > > bug mixed up. > > Alright, no worries; for the avoidance of doubt, I can't spot any > uploads of the request-tracker4 package to stretch at the moment. Should be there now :)
Bug#864745: Update on base.pm jessie point release
+ debian-perl as it possible affects how we deal with FTBFS module packages. On Wed, Jul 05, 2017 at 07:46:39AM +0200, Cyril Brulebois wrote: > Hi Dominic, > > Dominic Hargreaves (2017-07-04): > > 1) this commit is identical to those now in upstream release candidates. > > 2) This has now been filed as #867164 (sorry that this was missing before) > > Thanks for the update, much appreciated. > > I have to say that giving you a green light to update perl in stable with this > kind of fix makes me a little nervous, sorry. :( Okay, it would be useful to know in a bit more detail why you think this, as it doesn't seem any different from other similar fixes to perl we have requested in the past (and we've learnt our lesson from lack of mass rebuild testing where that was an issue previously) But anyway, there are two options: 1) proceed with the update as proposed. This should be fairly low risk since we have test-rebuilt all packages build-depending on perl and found no regressions, and the problem it is fixing only affected a handful of unusual cases. Given the lack of bug reports, I assume the imperfect base.pm change hasn't actually affected anyone in the real world, but of course that might be a rash assumption. 2) work around the problem by patching away the issue like we have for stretch in the half dozen or so affected packages. This would leave jessie's perl in a slightly awkward state in carrying around for the rest of its days a patch that was rejected by upstream in favour of another one. But in practice it may not make all that difference. And probably the risk in doing this is slightly less in not touching a core package, though it is a bit more work. Overall I'm in favour of 1) but happy to defer to you. Does anyone else in pkg-perl have an opinion on this? > > 3) this particular bug doesn't strictly apply to stretch/sid, but we plan > >to fix it in sid at least for consistency and to fix the minor remaining > >security bug (see #867170) > > I'm not sure how we feel about similar-yet-kind-of-different bugs in > other suites (as in: not sure whether fixing those would be considered > a hard requirement before an update in (old)stable). Even if you reject the patch for jessie, I hope you will consider it in stretch, as there is actually fixes a minor security issue (in due course it will end up in a new upstream point release, and it's quite likely we'll want a wholesale upgrade to that anyway). Indeed, if that would also make you uncomfortable we should discuss that in more detail... I will aim to get the s-p-u bug for that filed soon. Thanks, Dominic.
Bug#867335: stretch-pu: package systemd/232-25
Am 06.07.2017 um 20:10 schrieb Cyril Brulebois: > Hi, > > Michael Biebl (2017-07-05): >> I'd like to make a stable upload for systemd. >> >> All changes are already in unstable. >> An annotated changelog follows: > > Just had a quick glance at git, and it feels like there's a booboo… > >> systemd (232-25+deb9u1) stretch; urgency=medium >> >> [ Dimitri John Ledkov ] >> * Fix out-of-bounds write in systemd-resolved. >> CVE-2017-9445 (Closes: #866147, LP: #1695546) >> >> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=stretch-proposed&id=986c0be9809e6234680c001b731c5b3099f41c1c >> >> That's probably the most important one to get into stretch. >> The security team wanted us to fix this issue via a stable upload. > > What's up with this extra patch, which seems entirely unrelated? > debian/patches/debian/fsckd-daemon-for-inter-fsckd-communication.patch > > I'll have a closer look at the rest when time permits. That's a bit of patch noise generated by gbp pq export. You can simply ignore that bit. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#864745: Update on base.pm jessie point release
Dominic Hargreaves (2017-07-06):
> + debian-perl as it possible affects how we deal with FTBFS module
> packages.
>
> On Wed, Jul 05, 2017 at 07:46:39AM +0200, Cyril Brulebois wrote:
> > Hi Dominic,
> >
> > Dominic Hargreaves (2017-07-04):
> > > 1) this commit is identical to those now in upstream release
> > >candidates.
> > > 2) This has now been filed as #867164 (sorry that this was missing
> > >before)
> >
> > Thanks for the update, much appreciated.
> >
> > I have to say that giving you a green light to update perl in stable
> > with this kind of fix makes me a little nervous, sorry. :(
>
> Okay, it would be useful to know in a bit more detail why you think
> this, as it doesn't seem any different from other similar fixes to
> perl we have requested in the past (and we've learnt our lesson from
> lack of mass rebuild testing where that was an issue previously)
Well, I'm not the one having accepted past proposed-updates, and since
I've been active on quite a number of {jessie,stretch}-pu requests over
the past few weeks, that was mainly a hint for other release team
members that I wasn't going to green or red light this request myself.
> But anyway, there are two options:
>
> 1) proceed with the update as proposed. This should be fairly low risk
> since we have test-rebuilt all packages build-depending on perl and found
> no regressions, and the problem it is fixing only affected a handful
> of unusual cases. Given the lack of bug reports, I assume the imperfect
> base.pm change hasn't actually affected anyone in the real world, but of
> course that might be a rash assumption.
>
> 2) work around the problem by patching away the issue like we have
> for stretch in the half dozen or so affected packages. This would leave
> jessie's perl in a slightly awkward state in carrying around for the
> rest of its days a patch that was rejected by upstream in favour
> of another one. But in practice it may not make all that difference.
> And probably the risk in doing this is slightly less in not touching a
> core package, though it is a bit more work.
>
> Overall I'm in favour of 1) but happy to defer to you. Does anyone
> else in pkg-perl have an opinion on this?
I see a third one:
0) Wait from someone else from the release team to comment on this.
Hope this clarifies.
KiBi.
signature.asc
Description: Digital signature
Bug#867490: stretch-pu: package perl/5.24.1-3+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
We would like to apply the following fixes to perl in stretch for the
next point release:
* Backport various Getopt-Long fixes from upstream 2.49..2.51.
(Closes: #855532, #864544)
* Backport upstream patch fixing regexp "Malformed UTF-8 character"
crashes. (Closes: #864782)
* Apply upstream base.pm no-dot-in-inc fix (from 5.24.2-RC1)
(Closes: #867170)
Hopefully the bug reports provide all the relevant context. The
jessie-pu bug #864745 is somewhat related as the third change above
is also being proposed there; the others are regressions from jessie
which appeared in stretch.
Thanks,
Dominic.
diff --git a/MANIFEST b/MANIFEST
index e4331f1..e6a3dd9 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -3007,6 +3007,7 @@ dist/base/t/fields-5_6_0.tSee if fields work
dist/base/t/fields-5_8_0.t See if fields work
dist/base/t/fields-base.t See if fields work
dist/base/t/fields.t See if fields work
+dist/base/t/incdot.t Test how base.pm handles '.' in @INC
dist/base/t/isa.t See if base's behaviour doesn't change
dist/base/t/lib/Broken.pm Test module for base.pm
dist/base/t/lib/Dummy.pm Test module for base.pm
diff --git a/cpan/Getopt-Long/lib/Getopt/Long.pm
b/cpan/Getopt-Long/lib/Getopt/Long.pm
index fdc96bd..e71fee8 100644
--- a/cpan/Getopt-Long/lib/Getopt/Long.pm
+++ b/cpan/Getopt-Long/lib/Getopt/Long.pm
@@ -1110,10 +1110,29 @@ sub FindOption ($) {
# Check if there is an option argument available.
if ( $gnu_compat ) {
- my $optargtype = 0; # 0 = none, 1 = empty, 2 = nonempty
- $optargtype = ( !defined($optarg) ? 0 : ( (length($optarg) == 0) ? 1 :
2 ) );
- return (1, $opt, $ctl, undef)
- if (($optargtype == 0) && !$mand);
+ my $optargtype = 0; # none, 1 = empty, 2 = nonempty, 3 = aux
+ if ( defined($optarg) ) {
+ $optargtype = (length($optarg) == 0) ? 1 : 2;
+ }
+ elsif ( defined $rest || @$argv > 0 ) {
+ # GNU getopt_long() does not accept the (optional)
+ # argument to be passed to the option without = sign.
+ # We do, since not doing so breaks existing scripts.
+ $optargtype = 3;
+ }
+ if(($optargtype == 0) && !$mand) {
+ if ( $type eq 'I' ) {
+ # Fake incremental type.
+ my @c = @$ctl;
+ $c[CTL_TYPE] = '+';
+ return (1, $opt, \@c, 1);
+ }
+ my $val
+ = defined($ctl->[CTL_DEFAULT]) ? $ctl->[CTL_DEFAULT]
+ : $type eq 's' ? ''
+ :0;
+ return (1, $opt, $ctl, $val);
+ }
return (1, $opt, $ctl, $type eq 's' ? '' : 0)
if $optargtype == 1; # --foo= -> return nothing
}
@@ -2322,11 +2341,14 @@ do. Without C, C<--opt=> gives an error.
With C,
C<--opt=> will give option C and empty value.
This is the way GNU getopt_long() does it.
+Note that C<--opt value> is still accepted, even though GNU
+getopt_long() doesn't.
+
=item gnu_getopt
This is a short way of setting C C C
C. With C, command line handling should be
-fully compatible with GNU getopt_long().
+reasonably compatible with GNU getopt_long().
=item require_order
diff --git a/debian/.git-dpm b/debian/.git-dpm
index e62f968..28b4395 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-641936971e243d39e8eee510824e076c75965fc6
-641936971e243d39e8eee510824e076c75965fc6
+ceaa6f3d1fd7942ad1de321197030bb2306bd7ec
+ceaa6f3d1fd7942ad1de321197030bb2306bd7ec
13beb365bfa6ab6c49c061bd55769bf272a5e1bf
13beb365bfa6ab6c49c061bd55769bf272a5e1bf
perl_5.24.1.orig.tar.xz
diff --git a/debian/changelog b/debian/changelog
index c48cff7..d05b73a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+perl (5.24.1-3+deb9u1) UNRELEASED; urgency=medium
+
+ * Backport various Getopt-Long fixes from upstream 2.49..2.51.
+(Closes: #855532, #864544)
+ * Backport upstream patch fixing regexp "Malformed UTF-8 character"
+crashes. (Closes: #864782)
+ * Apply upstream base.pm no-dot-in-inc fix (from 5.24.2-RC1)
+(Closes: #867170)
+
+ -- Dominic Hargreaves Fri, 23 Jun 2017 21:31:26 +0100
+
perl (5.24.1-3) unstable; urgency=high
* [CVE-2017-6512] Fix file permissions race condition in File-Path;
diff --git a/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt2.diff
b/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt2.diff
new file mode 100644
index 000..fd44d21
--- /dev/null
+++ b/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt2.diff
@@ -0,0 +1,206 @@
+From ceaa6f3d1fd7942ad1de321197030bb2306bd7ec Mon Sep 17 00:00:00 2001
+From: Aristotle Pagaltzis
+Date: Mon, 13 Feb 2017 01:28:14 +0100
+Subject: wip
+
+[latest version of base.pm no-dot-in-inc fix,
+ back
Bug#864745: Update on base.pm jessie point release
On Thu, Jul 06, 2017 at 09:01:21PM +0200, Cyril Brulebois wrote:
> Dominic Hargreaves (2017-07-06):
> > + debian-perl as it possible affects how we deal with FTBFS module
> > packages.
> >
> > On Wed, Jul 05, 2017 at 07:46:39AM +0200, Cyril Brulebois wrote:
> > > Hi Dominic,
> > >
> > > Dominic Hargreaves (2017-07-04):
> > > > 1) this commit is identical to those now in upstream release
> > > >candidates.
> > > > 2) This has now been filed as #867164 (sorry that this was missing
> > > >before)
> > >
> > > Thanks for the update, much appreciated.
> > >
> > > I have to say that giving you a green light to update perl in stable
> > > with this kind of fix makes me a little nervous, sorry. :(
> >
> > Okay, it would be useful to know in a bit more detail why you think
> > this, as it doesn't seem any different from other similar fixes to
> > perl we have requested in the past (and we've learnt our lesson from
> > lack of mass rebuild testing where that was an issue previously)
>
> Well, I'm not the one having accepted past proposed-updates, and since
> I've been active on quite a number of {jessie,stretch}-pu requests over
> the past few weeks, that was mainly a hint for other release team
> members that I wasn't going to green or red light this request myself.
>
> > But anyway, there are two options:
> >
> > 1) proceed with the update as proposed. This should be fairly low risk
> > since we have test-rebuilt all packages build-depending on perl and found
> > no regressions, and the problem it is fixing only affected a handful
> > of unusual cases. Given the lack of bug reports, I assume the imperfect
> > base.pm change hasn't actually affected anyone in the real world, but of
> > course that might be a rash assumption.
> >
> > 2) work around the problem by patching away the issue like we have
> > for stretch in the half dozen or so affected packages. This would leave
> > jessie's perl in a slightly awkward state in carrying around for the
> > rest of its days a patch that was rejected by upstream in favour
> > of another one. But in practice it may not make all that difference.
> > And probably the risk in doing this is slightly less in not touching a
> > core package, though it is a bit more work.
> >
> > Overall I'm in favour of 1) but happy to defer to you. Does anyone
> > else in pkg-perl have an opinion on this?
>
> I see a third one:
>
> 0) Wait from someone else from the release team to comment on this.
>
>
> Hope this clarifies.
That makes perfect sense, sorry for the misunderstanding!
Dominic.
Bug#867461: should ca-certificates certdata.txt synchronize across all suites?
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 would remove another decision > point in our infrastructure and ensure harmonious X509 processing across > suites. I would like to see that happen too. -- bye, pabs https://wiki.debian.org/PaulWise
