Bug#995636: transition: openssl
On Sun, Jun 05, 2022 at 08:44:22PM +0200, Sebastian Andrzej Siewior wrote: > On 2022-06-05 19:42:43 [+0200], Sebastian Ramacher wrote: > > Hi Sebastian > Hi Sebastian, > > > > Otherwise I'd fear that the only other options are openssl breaking > > > libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific > > > name. Given the high number reverse dependencies involved in this > > > transition (and also those depending on bin:openssl), I'd prefer to > > > avoid a Breaks that could have the potential to force the libssl1.1 -> > > > libssl3 upgrade to be more of a lockstep transition than needed. > > > > I see that there was another openssl upload. Any reason a fix for this > > issue wasn't included in the upload of 3.0.3-6? > > I wasn't aware that this is something that we want do. Kurt pointed me > to the testsuite problem which was the primary motivation for the > upload. > Regarding dovecot, Kurt wanted to make some time for it. The patch in > ubuntu is working but is a giant duct tape which is not something I > would wan to upload… > Anyway, regarding the openssl.cnf. Do we want to use openssl-3.cnf for > libssl3? We can't make opnenssl-1.1.cnf happen. The modification > openssl.cnf already happend so people need to make changes manually… > Is this the request here? The suggestion was to make an openssl.cnf that's compatible with 1.1.1, and so remove or comment out everything related to providers. Kurt
Bug#995636: transition: openssl
On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote: > > That leaves #1011051. What's your view on that bug? So my understanding is that 1.1.1 doesn't understand the new configuration file and tries to load an engine (instead of a provider). We could ship a file that's comptabile with 1.1.1. That would make it a little bit harder to load some providers by default, but maybe that's something you want to do per application anyway. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 10:13:25PM +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-22 21:47:52 [+0100], Kurt Roeckx wrote: > > On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > > > OpenSSL signature algorithm check tightening > > > = > > > > > > The OpenSSL update included in this point release includes a change to > > > ensure that the requested signature algorithm is supported by the > > > active security level. > > > > > > Although this will not affect most use-cases, it could lead to error > > > messages being generated if a non-supported algorithm is requested - > > > for example, use of SHA1 with the default security level of 2. In such > > > cases, the security level will need to be explicitly lowered when > > > invoking OpenSSL, using an option such as > > > > > > -cipher "ALL:@SECLEVEL=1" > > > " > > > > So reading it again, I think the "when invoking OpenSSL" is confusing. > > Not only the openssl binary is affected, but also all clients and > > server applications making use of the library are. Some applications > > might have a way to set the cipher in their own configuration file, > > others might need to change the defaults in /etc/ssl/openssl.cfg > > s/openssl.cfg/openssl.cnf > > Kurt correct me if I'm wrong: > This only affects clients which were using TLS1.2 while connecting to > the server and did not send a sig-alg string which let the server > fallback to the default (sha1) which was not checked vs security level. > Would the client have sent sha1 as the sig-cipher then it would fail in > the version d, too. The client can send a list of supported sigalgs. Before the change there were 3 options: - the client didn't send anything, the server selected SHA1 - the client only send SHA1, the server selected SHA1 - the client send both SHA1 and SHA256, the server selected SHA256 With this change, it changes to: - the client didn't send anything, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client only send SHA1, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client send both SHA1 and SHA256, the server selects SHA256. The default client will send both SHA1 and SHA256 for a very long time, but you can change the settings. If the server selects SHA1, before the change the client will accept it, after the change it requires security level <= 1. When talking about SHA1 here, it's really about something RSA+SHA1, as in an RSA signature over a SHA1 hash. > Would the client need a lower protocol (TLSv1.0) then it would fail, too. > In these two cases the server administrator must have lowered the > security level to 1 (for the announced low sig-alg) and/or allow TLSv1 > in order for the client to connect. (The same for the other way around). SHA1 can be used for various things in the protocol. Other uses of SHA1 where already properly rejected, it just allowed SHA1 as signature algorithm. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > OpenSSL signature algorithm check tightening > = > > The OpenSSL update included in this point release includes a change to > ensure that the requested signature algorithm is supported by the > active security level. > > Although this will not affect most use-cases, it could lead to error > messages being generated if a non-supported algorithm is requested - > for example, use of SHA1 with the default security level of 2. In such > cases, the security level will need to be explicitly lowered when > invoking OpenSSL, using an option such as > > -cipher "ALL:@SECLEVEL=1" > " So reading it again, I think the "when invoking OpenSSL" is confusing. Not only the openssl binary is affected, but also all clients and server applications making use of the library are. Some applications might have a way to set the cipher in their own configuration file, others might need to change the defaults in /etc/ssl/openssl.cfg Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > Is the note below accurate? Yes. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 07:37:00PM +, Adam D. Barratt wrote:
> On Mon, 2022-03-21 at 00:12 +0100, Sebastian Andrzej Siewior wrote:
> > The change in openssl is commit
> >cc7c6eb8135b ("Check that the default signature type is allowed")
> >
> > Before the commit in question it connects as:
> > - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)
> >
> > after that, the server throws:
> > 140490373015360:error:14201044:SSL
> > routines:tls_choose_sigalg:internal error:../ssl/t1_lib.c:2880:
> >
> > and it appears that the security level in openssl forbids SHA1 here.
> > The argument on the s_server side
> > -sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256
> >
> > doesn't help here but
> > -cipher "ALL:@SECLEVEL=1"
> >
> > does.
> >
>
> If we wanted to add a note to the release announcement in case users
> face similar issue with other software, is "tls_choose:sigalg:internal
> error" a reliable signal of this situation occurring? Should the
> recommended solution be to lower the security level, or might
> specifying -sigalgs work on its own in some scenarios?
So to clarify things. The problem is that SHA1 was allowed as signature
algorithm while the security level should not have allowed it. If the
peer does not support SHA256, the security level needs to be lowered
so that SHA1 is allowed again.
Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Mon, Mar 21, 2022 at 12:12:11AM +0100, Sebastian Andrzej Siewior wrote:
>
> The change in openssl is commit
>cc7c6eb8135b ("Check that the default signature type is allowed")
So that's:
commit cc7c6eb8135be665d0acc176a5963e1eaf52e4e2
Author: Kurt Roeckx
Date: Thu Jan 2 22:53:32 2020 +0100
Check that the default signature type is allowed
TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the
others. TLS 1.2 sends a list of supported ciphers, but allows not sending
it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory.
When we didn't receive a list from the client, we always used the
defaults without checking that they are allowed by the configuration.
Reviewed-by: Paul Dale
GH: #10784
(cherry picked from commit b0031e5dc2c8c99a6c04bc7625aa00d3d20a59a5)
Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Sun, Mar 20, 2022 at 10:00:15PM +0100, Paul Gevers wrote: > Dear Sebastian, Kurt, > > On 19-03-2022 12:33, Adam D Barratt wrote: > > Upload details > > == > > > > Package: openssl > > Version: 1.1.1n-0+deb10u1 > > > > Explanation: new upstream release > > We're seeing a regression in buster in the autopkgtest of gnutls28 with the > new version of openssl on all tested architectures. Can you please have a > look and advise? (bullseye doesn't seem to have the test anymore, hence it > doesn't fail). > > https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz > > Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > *** Fatal error: A TLS fatal alert has been received. > Failure: Failed > *** Fatal error: A TLS fatal alert has been received. > %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > Failure: Failed > *** Fatal error: A TLS fatal alert has been received. > Failure: Failed > FAIL [11]../../tests/suite/testcompat-main-openssl > > Which, according to me, is this check: > https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307 That test still seems to exist, but is just moved to a different file: https://github.com/gnutls/gnutls/blob/master/tests/suite/testcompat-openssl-cli-common.sh#L255 My understanding is that gnutls now passes the correct list of signature algorithms to use to OpenSSL's s_client to be able to do that test, and that this is probably fixed by: https://github.com/gnutls/gnutls/commit/23958322865a8a77c2f924f569484e5fd150a24b (and https://github.com/gnutls/gnutls/commit/8259a1dc8503ad760c0887eb95278f9957a00667) I'm trying to remember what was changed and why, but I can't find/remember it. Kurt
Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1
On Fri, Mar 18, 2022 at 10:22:57PM +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-18 14:51:32 [+], Adam D. Barratt wrote: > > Boo. Hope you're doing better. > > Thanks, yes. > > > > I would also do the upload for Buster, would that work? I remember > > > that > > > the packages, that broken, were already uploaded a few cycles ago. > > > > Also as 1.1.1n? > > Yes. > > > I assume there haven't been any regressions reported with l/m/n in the > > meantime. I'm not aware of any regressions the past year. Kurt
Bug#995636: transition: openssl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We would like to transition to OpenSSL 3.0.0. It's currently in experimental. It has an soname change, so the binary packages got renamed and binNMUs will be required. We did a rebuild of packages and currently have 105 packages that FTBFS with OpenSSL 3.0.0 that build with 1.1.1. I've started filing bugs for that: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote: > There are a whole bunch of other issues and pull requests related to > this. I hope this is the end of the regressions in the X509 code. So there is something else now: https://github.com/openssl/openssl/issues/13931 https://github.com/openssl/openssl/pull/13982 Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 09:13:49PM +0100, Sebastian Andrzej Siewior wrote: > On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote: > > > Do you have pointers to upstream issues? > > > > There are a whole bunch of other issues and pull requests related to > > this. I hope this is the end of the regressions in the X509 code. > > Okay. Please ping once this gets sorted out and I will prepease > unstalbe/stable uploads. The m2crypto issue got resolved in unstable > \o/. So I went over the open issues and pull requests, and currently don't see a reason not to upload it to unstable with those 2 patches. I don't know about any other regressions in 1.1.1. Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote: > Hi, > > On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote: > > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior > > wrote: > [...] > > > The i release in unstable managed to migrate to testing. It was > > > blocked due to ci by m2crypto and swi-prolog. The swi-prolog issue > > > got fixed in unstable (the testuite was updated) and is not an > > > issue in stable (the package builds, the testsuite gets ignored). > > > The m2crypto issue is a different story and is still open in BTS > > > (#977655). I *think* someone added an override or the ci-system was > > > kind to Kurt/me and looked the other way :) > > > The m2crypto package in stable and bpo will FTBFS with the updated > > > openssl package. > > > > > > I'm not aware of other issues. > > > > I think there are at least 2 upstream issues since the 1.1.1i > > release we want to fix first. As far as I know, they haven't been > > fixed upstream yet. > > Just to confirm, these are issues that you'd want to have fixed before > adding 1.1.1i to stable, presumably requiring further uploads to > unstable first? Yes. > Do you have pointers to upstream issues? They both got merged today: commit 76ed0c0ad119569f6e6f6c96b27b76d3b110413b (origin/OpenSSL_1_1_1-stable) Author: Dr. David von Oheimb Date: Mon Dec 28 11:25:59 2020 +0100 x509_vfy.c: Fix a regression in find_isser() ...in case the candidate issuer cert is identical to the target cert. Fixes #13739 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13749) commit fb1e2411042f0367c2560e4ec5e4b1189ca9cd45 Author: Dr. David von Oheimb Date: Wed Dec 30 09:57:49 2020 +0100 X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed to due to invalid cert This is the backport of #13755 to v1.1.1. Fixes #13698 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13756) There are a whole bunch of other issues and pull requests related to this. I hope this is the end of the regressions in the X509 code. Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote: > On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote: > > > At some point, could we please have a combined / single diff between > > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I > > assume)? > > Please find attached the diff between 1.1.1d-0+deb10u4 and the proposed > 1.1.1i-0+deb10u1. > > The i release in unstable managed to migrate to testing. It was blocked > due to ci by m2crypto and swi-prolog. The swi-prolog issue got fixed in > unstable (the testuite was updated) and is not an issue in stable (the > package builds, the testsuite gets ignored). > The m2crypto issue is a different story and is still open in BTS > (#977655). I *think* someone added an override or the ci-system was kind > to Kurt/me and looked the other way :) > The m2crypto package in stable and bpo will FTBFS with the updated > openssl package. > > I'm not aware of other issues. I think there are at least 2 upstream issues since the 1.1.1i release we want to fix first. As far as I know, they haven't been fixed upstream yet. Kurt
Bug#927437: unblock: openssl/1.1.1b-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
Can you please unblock openssl. It fixes 2 important bugs.
debdiff attached.
Kurt
diff -Nru openssl-1.1.1b/debian/changelog openssl-1.1.1b/debian/changelog
--- openssl-1.1.1b/debian/changelog 2019-02-26 19:52:12.0 +0100
+++ openssl-1.1.1b/debian/changelog 2019-04-16 21:31:11.0 +0200
@@ -1,3 +1,11 @@
+openssl (1.1.1b-2) unstable; urgency=medium
+
+ * Fix BUF_MEM regression (Closes: #923516)
+ * Fix error when config can't be opened (Closes: #926315)
+ * Ship an openssl.cnf in libssl1.1-udeb.dirs
+
+ -- Kurt Roeckx Tue, 16 Apr 2019 21:31:11 +0200
+
openssl (1.1.1b-1) unstable; urgency=medium
[ Sebastian Andrzej Siewior ]
diff -Nru openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs
openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs
--- openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs2019-02-26
19:25:16.0 +0100
+++ openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs2019-04-16
21:31:11.0 +0200
@@ -1 +1,2 @@
usr/lib
+usr/lib/ssl
diff -Nru
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
---
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
1970-01-01 01:00:00.0 +0100
+++
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
2019-04-16 21:23:57.0 +0200
@@ -0,0 +1,118 @@
+From 43bb4dec99f4bed1ec20836c79967ea790594fce Mon Sep 17 00:00:00 2001
+From: Tomas Mraz
+Date: Wed, 3 Apr 2019 12:31:32 +0200
+Subject: [PATCH 1/5] Fix for BIO_get_mem_ptr and related regressions
+
+Reviewed-by: Bernd Edlinger
+Reviewed-by: Matt Caswell
+(Merged from https://github.com/openssl/openssl/pull/8649)
+
+(cherry picked from commit b238fb79709a180ba9b4d837101c9f75e2978dc0)
+---
+ crypto/bio/bss_mem.c | 40
+ 1 file changed, 28 insertions(+), 12 deletions(-)
+
+diff --git a/crypto/bio/bss_mem.c b/crypto/bio/bss_mem.c
+index 10fcbf7a7c..abf0f04111 100644
+--- a/crypto/bio/bss_mem.c
b/crypto/bio/bss_mem.c
+@@ -57,7 +57,12 @@ static const BIO_METHOD secmem_method = {
+ NULL, /* mem_callback_ctrl */
+ };
+
+-/* BIO memory stores buffer and read pointer */
++/*
++ * BIO memory stores buffer and read pointer
++ * however the roles are different for read only BIOs.
++ * In that case the readp just stores the original state
++ * to be used for reset.
++ */
+ typedef struct bio_buf_mem_st {
+ struct buf_mem_st *buf; /* allocated buffer */
+ struct buf_mem_st *readp; /* read pointer */
+@@ -192,6 +197,8 @@ static int mem_read(BIO *b, char *out, int outl)
+ BIO_BUF_MEM *bbm = (BIO_BUF_MEM *)b->ptr;
+ BUF_MEM *bm = bbm->readp;
+
++if (b->flags & BIO_FLAGS_MEM_RDONLY)
++bm = bbm->buf;
+ BIO_clear_retry_flags(b);
+ ret = (outl >= 0 && (size_t)outl > bm->length) ? (int)bm->length : outl;
+ if ((out != NULL) && (ret > 0)) {
+@@ -241,29 +248,36 @@ static long mem_ctrl(BIO *b, int cmd, long num, void
*ptr)
+ BIO_BUF_MEM *bbm = (BIO_BUF_MEM *)b->ptr;
+ BUF_MEM *bm;
+
++if (b->flags & BIO_FLAGS_MEM_RDONLY)
++bm = bbm->buf;
++else
++bm = bbm->readp;
++
+ switch (cmd) {
+ case BIO_CTRL_RESET:
+ bm = bbm->buf;
+ if (bm->data != NULL) {
+-/* For read only case reset to the start again */
+-if ((b->flags & BIO_FLAGS_MEM_RDONLY) || (b->flags &
BIO_FLAGS_NONCLEAR_RST)) {
+-bm->length = bm->max;
++if (!(b->flags & BIO_FLAGS_MEM_RDONLY)) {
++if (b->flags & BIO_FLAGS_NONCLEAR_RST) {
++bm->length = bm->max;
++} else {
++memset(bm->data, 0, bm->max);
++bm->length = 0;
++}
++*bbm->readp = *bbm->buf;
+ } else {
+-memset(bm->data, 0, bm->max);
+-bm->length = 0;
++/* For read only case just reset to the start again */
++*bbm->buf = *bbm->readp;
+ }
+-*bbm->readp = *bbm->buf;
+ }
+ break;
+ case BIO_CTRL_EOF:
+-bm = bbm->readp;
+ ret = (long)(bm->length == 0);
+ break;
+ case BIO_C_SET_BUF_MEM_EOF_RETURN:
+ b->num = (int)num;
+ break;
+ case BIO_CTRL_INFO:
+-bm = bbm->readp;
+ ret = (long)bm->length;
+ if (ptr != NULL) {
+ pptr = (char **)ptr;
+@@ -278,8 +292,9 @@ static long mem_ctrl(BIO *b, int cmd, long num, void *ptr)
+ break;
+ case BIO_C_GET_BUF_MEM_PTR:
+ if (ptr
Re: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed
On Thu, Oct 18, 2018 at 04:05:32PM +0200, Mattia Rizzolo wrote: > On Thu, Oct 18, 2018 at 04:01:59PM +0300, Niko Tyni wrote: > > On Wed, Oct 17, 2018 at 09:21:29PM +0200, Kurt Roeckx wrote: > > > On Wed, Oct 17, 2018 at 09:22:35PM +0300, Niko Tyni wrote: > > > > > > Is it still useful to block openssl 1.1.1 testing migration with this > > > > bug? > > > > > > Things like python are also blocked on it. I have no problem > > > lowering the severity of this issue, to make it migrate. > > > > I'm not sure who should decide this if not you :) > > > > Copying Paul and the release team. Any thoughts? > > I'm neither Paul nor the release team, but I honestly think that at the > very least the openssl maintainers could at least fix their own tests. We've fixed this in git two days after the last upload. There are also some new Breaks in git, it currently looks like: Breaks: python-httplib2 (<< 0.11.3-1), isync (<< 1.3.0-2), python-imaplib2 (<< 2.57-5), python3-imaplib2 (<< 2.57-5) > And possibly write some patches and do NMUs for those reverse > dependencies where Kurt suggested to create new certificates to be used > during the tests. We've been busy working on various packages. Kurt
Bug#907906: stretch-pu: package openssl/1.1.0f-3+deb9u2
On Tue, Sep 04, 2018 at 04:41:32PM +0200, Moritz Mühlenhoff wrote: > > (I've been deploying customs debs of the 1.0.2x and 1.1.0x openssl releases > at work and I haven't run into any compatibility issues/API issues during > that). We should really do upload all the latest point releases to all supported branches. Kurt
Bug#881415: stretch-pu: python2.7/2.7.13-2+deb9u1
On Sat, Nov 18, 2017 at 06:28:03PM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2017-11-11 at 14:36 +0100, Kurt Roeckx wrote: > > I would like to upload python2.7 to fix a problem that it can't > > talk to SSL/TLS sites that use an ECDSA certificate different than > > P256, like a P384 certificate. > > > > Please go ahead. Uploaded. Kurt
Bug#881415: stretch-pu: python2.7/2.7.13-2+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I would like to upload python2.7 to fix a problem that it can't
talk to SSL/TLS sites that use an ECDSA certificate different than
P256, like a P384 certificate.
Here is the debdiff:
diff -u python2.7-2.7.13/debian/changelog python2.7-2.7.13/debian/changelog
--- python2.7-2.7.13/debian/changelog
+++ python2.7-2.7.13/debian/changelog
@@ -1,3 +1,10 @@
+python2.7 (2.7.13-2+deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload with maintainer's permission
+ * Support all groups in TLS communication (Closes: #868143)
+
+ -- Kurt Roeckx <k...@roeckx.be> Thu, 09 Nov 2017 21:58:19 +0100
+
python2.7 (2.7.13-2) unstable; urgency=medium
* Lower priority of interpreter packages to optional.
diff -u python2.7-2.7.13/debian/patches/series.in
python2.7-2.7.13/debian/patches/series.in
--- python2.7-2.7.13/debian/patches/series.in
+++ python2.7-2.7.13/debian/patches/series.in
@@ -71,0 +72 @@
+Dont_use_OpenSSL_1.0.2_fallback_on_1.1.diff
only in patch2:
unchanged:
---
python2.7-2.7.13.orig/debian/patches/Dont_use_OpenSSL_1.0.2_fallback_on_1.1.diff
+++ python2.7-2.7.13/debian/patches/Dont_use_OpenSSL_1.0.2_fallback_on_1.1.diff
@@ -0,0 +1,28 @@
+From 97a145398ce7e36eb355f1fd75011ddbcb37d1b3 Mon Sep 17 00:00:00 2001
+From: Donald Stufft <don...@stufft.io>
+Date: Thu, 2 Mar 2017 11:24:50 -0500
+Subject: [PATCH] bpo-29697: Don't use OpenSSL <1.0.2 fallback on 1.1+
+
+---
+ Modules/_ssl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+Index: python2.7-2.7.13/Modules/_ssl.c
+===
+--- python2.7-2.7.13.orig/Modules/_ssl.c
python2.7-2.7.13/Modules/_ssl.c
+@@ -2166,12 +2166,12 @@ context_new(PyTypeObject *type, PyObject
+ options |= SSL_OP_NO_SSLv3;
+ SSL_CTX_set_options(self->ctx, options);
+
+-#ifndef OPENSSL_NO_ECDH
++#if !defined(OPENSSL_NO_ECDH) && !defined(OPENSSL_VERSION_1_1)
+ /* Allow automatic ECDH curve selection (on OpenSSL 1.0.2+), or use
+prime256v1 by default. This is Apache mod_ssl's initialization
+policy, so we should be safe. OpenSSL 1.1 has it enabled by default.
+ */
+-#if defined(SSL_CTX_set_ecdh_auto) && !defined(OPENSSL_VERSION_1_1)
++#if defined(SSL_CTX_set_ecdh_auto)
+ SSL_CTX_set_ecdh_auto(self->ctx, 1);
+ #else
+ {
Bug#867461: should ca-certificates certdata.txt synchronize across all suites?
On Fri, Jul 21, 2017 at 04:47:23PM -0400, Antoine Beaupré wrote: > On 2017-07-21 22:19:20, Philipp Kern wrote: > > My point was that you state what your delta is and essentially boils > > down to attach the diff of what will actually happen to the .deb. I > > think it's generally fine to add new CAs and remove fully distrusted > > ones, instead of saying "it should just be in sync with unstable". The > > latter contains a lot more nuance if you know that some of the rules are > > only available in code. > > Thank you for taking the time to clarify your position, I understand it > much better now. :) > > Makes perfect sense, I'll try to be clearer in future communications to > avoid such confusion. Mozilla has various extra distrust/partial trust rules that are now coded in either NSS or Firefox itself. But we're not even using the distrust/partial trust information currently in certdata.txt. Other than what is in certdata.txt + code, there are also certificates that are distrusted by using OneCRL. I currently see no reason not to ship certdata.txt in all distributions. In any case, I think we should try to implement all the rules that Mozilla applies in all software that deals with certificate. And at least Mozilla is interested in that, and at least some of the OpenSSL people would also like to see OpenSSL have more checks than that currently happen. Kurt
Bug#863472: unblock: openssl/1.1.0f-1
On Mon, Jun 05, 2017 at 11:33:57AM +0200, Cyril Brulebois wrote:
> Kurt Roeckx <k...@roeckx.be> (2017-06-04):
> > So I've uploaded openssl 1.1.0f-2
>
> Source debdiff lgtm from -1, and installation over https works fine,
> ACK.
So I actually have a new version I want to upload:
Modified: openssl/branches/1.1.0/debian/changelog
===
--- openssl/branches/1.1.0/debian/changelog 2017-06-04 17:21:11 UTC (rev
903)
+++ openssl/branches/1.1.0/debian/changelog 2017-06-05 09:42:35 UTC (rev
904)
@@ -1,3 +1,9 @@
+openssl (1.1.0f-3) unstable; urgency=medium
+
+ * Don't cleanup a thread-local key we didn't create (Closes: #863707)
+
+ -- Kurt Roeckx <k...@roeckx.be> Mon, 05 Jun 2017 11:40:42 +0200
+
openssl (1.1.0f-2) unstable; urgency=medium
* Make the udeb use a versioned depends (Closes: #864080)
Added:
openssl/branches/1.1.0/debian/patches/0001-Only-release-thread-local-key-if-we-created-it.patch
===
---
openssl/branches/1.1.0/debian/patches/0001-Only-release-thread-local-key-if-we-created-it.patch
(rev 0)
+++
openssl/branches/1.1.0/debian/patches/0001-Only-release-thread-local-key-if-we-created-it.patch
2017-06-05 09:42:35 UTC (rev 904)
@@ -0,0 +1,47 @@
+From 73bc53708c386c1ea85941d345721e23dc61c05c Mon Sep 17 00:00:00 2001
+From: Rich Salz <rs...@openssl.org>
+Date: Wed, 31 May 2017 12:14:55 -0400
+Subject: [PATCH] Only release thread-local key if we created it.
+
+Thanks to Jan Alexander Steffens for finding the bug and confirming the
+fix.
+
+Reviewed-by: Richard Levitte <levi...@openssl.org>
+(Merged from https://github.com/openssl/openssl/pull/3592)
+---
+ crypto/err/err.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/crypto/err/err.c b/crypto/err/err.c
+index f866f2fdd0..c55f849590 100644
+--- a/crypto/err/err.c
b/crypto/err/err.c
+@@ -122,6 +122,7 @@ static ERR_STRING_DATA ERR_str_reasons[] = {
+ #endif
+
+ static CRYPTO_ONCE err_init = CRYPTO_ONCE_STATIC_INIT;
++static int set_err_thread_local;
+ static CRYPTO_THREAD_LOCAL err_thread_local;
+
+ static CRYPTO_ONCE err_string_init = CRYPTO_ONCE_STATIC_INIT;
+@@ -260,7 +261,8 @@ DEFINE_RUN_ONCE_STATIC(do_err_strings_init)
+
+ void err_cleanup(void)
+ {
+-CRYPTO_THREAD_cleanup_local(_thread_local);
++if (set_err_thread_local != 0)
++CRYPTO_THREAD_cleanup_local(_thread_local);
+ CRYPTO_THREAD_lock_free(err_string_lock);
+ err_string_lock = NULL;
+ }
+@@ -639,6 +641,7 @@ void ERR_remove_state(unsigned long pid)
+
+ DEFINE_RUN_ONCE_STATIC(err_do_init)
+ {
++set_err_thread_local = 1;
+ return CRYPTO_THREAD_init_local(_thread_local, NULL);
+ }
+
+--
+2.11.0
+
Modified: openssl/branches/1.1.0/debian/patches/series
===
--- openssl/branches/1.1.0/debian/patches/series2017-06-04 17:21:11 UTC
(rev 903)
+++ openssl/branches/1.1.0/debian/patches/series2017-06-05 09:42:35 UTC
(rev 904)
@@ -4,3 +4,4 @@
pic.patch
c_rehash-compat.patch
#padlock_conf.patch
+0001-Only-release-thread-local-key-if-we-created-it.patch
Bug#863472: unblock: openssl/1.1.0f-1
On Sun, Jun 04, 2017 at 06:53:29PM +0200, Cyril Brulebois wrote: > Kurt Roeckx <k...@roeckx.be> (2017-06-04): > > So I changed it this instead: > > dh_makeshlibs -a -V --add-udeb="libcrypto1.1-udeb" -Xengines > > > > the shlib files now looks like: > > libcrypto 1.1 libssl1.1 (>= 1.1.0f) > > libssl 1.1 libssl1.1 (>= 1.1.0f) > > udeb: libcrypto 1.1 libcrypto1.1-udeb (>= 1.1.0f) > > udeb: libssl 1.1 libssl1.1-udeb (>= 1.1.0f) > > > > Since we have symbol files, this does not affect non-udeb > > packages. > > As discussed on IRC (#debian-devel), the earlier syntax (-V with a > version) was fine, and more accurate as it only needs to be bumped > when symbols change. However, using -V without a specific version > should get us updated dependencies every time; they might be stricter > than needed, but that's better than forgetting about bumping the > version IMHO, so fine with me. So I've uploaded openssl 1.1.0f-2 and openssl1.0 1.0.2l-2 Kurt
Bug#863472: unblock: openssl/1.1.0f-1
On Sun, Jun 04, 2017 at 11:09:00AM +, Niels Thykier wrote: > Kurt Roeckx: > > [...] > >> > >> Maybe file this as an RC bug against openssl so that it isn't forgotten > >> about, but ignore it for r0? > > > > So I have prepared an update. Should I upload it? > > > > [...] > > > > > > Kurt > > > > Ack from here, so if KiBi is ok with it, then please go ahead. So I changed it this instead: dh_makeshlibs -a -V --add-udeb="libcrypto1.1-udeb" -Xengines the shlib files now looks like: libcrypto 1.1 libssl1.1 (>= 1.1.0f) libssl 1.1 libssl1.1 (>= 1.1.0f) udeb: libcrypto 1.1 libcrypto1.1-udeb (>= 1.1.0f) udeb: libssl 1.1 libssl1.1-udeb (>= 1.1.0f) Since we have symbol files, this does not affect non-udeb packages. Kurt
Bug#863472: unblock: openssl/1.1.0f-1
On Sun, Jun 04, 2017 at 05:29:21AM +0200, Cyril Brulebois wrote:
> Niels Thykier <ni...@thykier.net> (2017-06-03):
> > Kurt Roeckx:
> > > Package: release.debian.org
> > > User: release.debian@packages.debian.org
> > > Usertags: unblock
> > > Severity: normal
> > >
> > > Hi,
> > >
> > > I've uploaded a new upstream version of openssl that contains bug
> > > fixes. The Debian changelog says:
> > >* New upstream version
> > > - Fix regression in req -x509 (Closes: #839575)
> > > - Properly detect features on the AMD Ryzen processor
> > >(Closes: #861145)
> > > - Don't mention -tls1_3 in the manpage (Closes: #859191)
> > >* Update libssl1.1.symbols for new symbols
> > >* Update man-section.patch
> > >
> > >
> > > Kurt
> > >
> >
> > Hi,
> >
> > Fine by me. CC'ing KiBi for a d-i ack assuming he is ok with this
> > last minute change.
>
> Erm.
>
> The libssl1.1-udeb package is broken, as it fails to depend on an
> appropriate version of libcrypto1.1-udeb, which means I've just
> successfully built a debian-installer against testing with this
> addition: build/localudebs/libssl1.1-udeb_1.1.0f-1_amd64.udeb
> and gotten a broken wget:
> | wget: /usr/lib/libcrypto.so.1.1: version `OPENSSL_1_1_0f' not found
> (required by /usr/lib/libssl.so.1.1)
>
> See the missing version here:
> | $ dpkg --info build/localudebs/libssl1.1-udeb_1.1.0f-1_amd64.udeb|grep
> Depends:
> | Depends: libc6-udeb (>= 2.24), libcrypto1.1-udeb
>
> One could argue they're from the same source and that this isn't a
> practical problem since they're going to migrate at the same time and be
> used together in debian-installer, but further fun could come up when
> other packages start depending on particular symbols (hello wget), so I
> think I'd be nice to have this fixed.
>
> Maybe file this as an RC bug against openssl so that it isn't forgotten
> about, but ignore it for r0?
So I have prepared an update. Should I upload it?
The source changes are:
--- openssl-1.1.0f/debian/changelog 2017-05-25 18:29:01.0 +0200
+++ openssl-1.1.0f/debian/changelog 2017-06-04 12:07:38.0 +0200
@@ -1,3 +1,10 @@
+openssl (1.1.0f-2) unstable; urgency=medium
+
+ * Make the udeb use a versioned depends (Closes: #864080)
+ * Conflict with libssl1.0-dev (Closes: #863367)
+
+ -- Kurt Roeckx <k...@roeckx.be> Sun, 04 Jun 2017 12:07:38 +0200
+
openssl (1.1.0f-1) unstable; urgency=medium
* New upstream version
diff -Nru openssl-1.1.0f/debian/control openssl-1.1.0f/debian/control
--- openssl-1.1.0f/debian/control 2017-01-26 23:19:08.0 +0100
+++ openssl-1.1.0f/debian/control 2017-06-04 12:07:33.0 +0200
@@ -72,6 +72,7 @@
Multi-Arch: same
Recommends: libssl-doc
Depends: libssl1.1 (= ${binary:Version}), ${misc:Depends}
+Conflicts: libssl1.0-dev
Description: Secure Sockets Layer toolkit - development files
This package is part of the OpenSSL project's implementation of the SSL
and TLS cryptographic protocols for secure communication over the
diff -Nru openssl-1.1.0f/debian/rules openssl-1.1.0f/debian/rules
--- openssl-1.1.0f/debian/rules 2017-05-25 18:17:29.0 +0200
+++ openssl-1.1.0f/debian/rules 2017-06-04 11:48:25.0 +0200
@@ -138,7 +138,7 @@
override_dh_makeshlibs:
#dpkg-gensymbols -Pdebian/libssl1.1/ -plibssl1.1 -c4
- dh_makeshlibs -a --add-udeb="libcrypto1.1-udeb" -Xengines
+ dh_makeshlibs -a --add-udeb="libcrypto1.1-udeb (>= 1.1.0f)" -Xengines
# XXX: This needs gets set perl:any by dh_perl which is correct, but
# that breaks debootstrap in jessie (the current stable). This hack
# could be removed once stretch is stable and contains a fixed
It changes the shlibs file from:
libcrypto 1.1 libssl1.1
libssl 1.1 libssl1.1
udeb: libcrypto 1.1 libcrypto1.1-udeb
udeb: libssl 1.1 libssl1.1-udeb
to:
libcrypto 1.1 libssl1.1
libssl 1.1 libssl1.1
udeb: libcrypto 1.1 libcrypto1.1-udeb (>= 1.1.0f)
udeb: libssl 1.1 libssl1.1-udeb (>= 1.1.0f)
It results in the following debdiff change on the binaries:
File lists identical (after any substitutions)
Control files of package libcrypto1.1-udeb: lines which differ (wdiff format)
-
Version: [-1.1.0f-1-] {+1.1.0f-2+}
Control files of package libssl-dev: lines which differ (wdiff format)
--
{+Conflicts: libssl1.0-dev+}
Depends: libssl1.1 (= [-1.1.0f-1)-] {+1.1.0f-2)+}
Version: [-1.1.0f-1-] {+1.1.0f-2+}
Control files of package libssl-doc: lines which differ (wdiff format)
---
Bug#863494: unblock: elfutils/0.168-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Hi, I've uploaded a new version of elfutils which fixes security issues: elfutils (0.168-1) unstable; urgency=medium * Fix CVE-2017-7607 (Closes: #859996) * Fix CVE-2017-7608 (Closes: #859995) * Fix CVE-2017-7609 (Closes: #859994) * Fix CVE-2017-7610 (Closes: #859993) * Fix CVE-2017-7611 (Closes: #859992) * Fix CVE-2017-7612 (Closes: #859991) * Fix CVE-2017-7613 (Closes: #859990) Note that this is not an new upstream version, the version in testing is currently 0.168-0.2 Kurt
Re: [Pkg-openssl-devel] Bug#863367: libecryptfs-dev: unable to install because of unmet dependency
On Sat, May 27, 2017 at 04:00:58PM +0200, David Kalnischkies wrote: > Control: reassign -1 libssl-dev 1.1.0e-2 > Control: retitle -1 libssl-dev: declare conflict with libssl1.0-dev to help > apt find solutions [...] > Not being installable is the problem of the package which isn't > installable – even if that is due to bugs in a package manager! So why does this bug get assigned to libssl-dev then and not to libecryptfs-dev, with maybe a wishlist bug against libssl-dev (and apt)? In general, I disagree that we should declare a conflict at both sides of the conflict and that the package manager should be able to deal with a conflict on just one side. It's not a conflict that involves version numbers. However, if everybody agrees that this is the best solution for the next release, I will need permission from the release team to make such a change. Kurt
Bug#863473: unblock: openssl1.0/1.0.2l-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Hi, I've uploaded a new upstream version of openssl1.0 that contains bug fixes. The Debian changelog says: * New upstream release - Properly detect features on the AMD Ryzen processor (Closes: #861145) * Refresh valgrind.patch Kurt
Bug#863472: unblock: openssl/1.1.0f-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Hi, I've uploaded a new upstream version of openssl that contains bug fixes. The Debian changelog says: * New upstream version - Fix regression in req -x509 (Closes: #839575) - Properly detect features on the AMD Ryzen processor (Closes: #861145) - Don't mention -tls1_3 in the manpage (Closes: #859191) * Update libssl1.1.symbols for new symbols * Update man-section.patch Kurt
Bug#858493: unblock: ntp/4.2.8p10+dfsg-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Hi, I've just uploaded a new version of ntp to unstable that fixes some security issues. Upstreams has the habbit of regenerating all autogenerated files with a random version each time. This time it seems the debdiff is relativly small: 322 files changed, 17920 insertions(+), 50426 deletions(-) The changes in the Debian packages are very minimal: ntp (1:4.2.8p10+dfsg-1) unstable; urgency=high * New upstream version - Fix security issues * Update openssl-disable-check.patch -- Kurt Roeckx <k...@roeckx.be> Wed, 22 Mar 2017 21:53:40 +0100 The upstream changes are: (4.2.8p10) * [Sec 3389] NTP-01-016: Denial of Service via Malformed Config (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3388] NTP-01-014: Buffer Overflow in DPTS Clock (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3387] NTP-01-012: Authenticated DoS via Malicious Config Option (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3386] NTP-01-011: ntpq_stripquotes() returns incorrect Value (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3385] NTP-01-010: ereallocarray()/eallocarray() underused. HStenn * [Sec 3384] NTP-01-009: Privileged execution of User Library code (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3383] NTP-01-008: Stack Buffer Overflow from Command Line (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3382] NTP-01-007: Data Structure terminated insufficiently (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3380] NTP-01-005: Off-by-one in Oncore GPS Receiver (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3379] NTP-01-004: Potential Overflows in ctl_put() functions (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3378] NTP-01-003: Improper use of snprintf() in mx4200_send() (Pentest report 01.2017) <perlin...@ntp.org> * [Sec 3377] NTP-01-002: Buffer Overflow in ntpq when fetching reslist (Pentest report 01.2017) <perlin...@ntp.org * [Sec 3376] Support build "hardening" flags. st...@ntp.org * [Sec 3361] 0rigin (zero origin) DoS. HStenn. * [Bug 3393] clang scan-build findings <perlin...@ntp.org> * [Bug 3363] Support for openssl-1.1.0 without compatibility modes - rework of patch set from <ntp@eroen.eu>. <perlin...@ntp.org> * [Bug 3356] Bugfix 3072 breaks multicastclient <perlin...@ntp.org> * [Bug 3216] libntp audio ioctl() args incorrectly cast to int on 4.4BSD-Lite derived platforms <perlin...@ntp.org> - original patch by Majdi S. Abbas * [Bug 3215] 'make distcheck' fails with new BK repo format <perlin...@ntp.org> * [Bug 3173] forking async worker: interrupted pipe I/O <perlin...@ntp.org> - initial patch by Christos Zoulas * [Bug 3139] (...) time_pps_create: Exec format error <perlin...@ntp.org> - move loader API from 'inline' to proper source - augment pathless dlls with absolute path to NTPD - use 'msyslog()' instead of 'printf() 'for reporting trouble * [Bug 3107] Incorrect Logic for Peer Event Limiting <perlin...@ntp.org> - applied patch by Matthew Van Gundy * [Bug 3065] Quiet warnings on NetBSD <perlin...@ntp.org> - applied some of the patches provided by Havard. Not all of them still match the current code base, and I did not touch libopt. * [Bug 3062] Change the process name of forked DNS worker <perlin...@ntp.org> - applied patch by Reinhard Max. See bugzilla for limitations. * [Bug 2923] Trap Configuration Fail <perlin...@ntp.org> - fixed dependency inversion from [Bug 2837] * [Bug 2896] Nothing happens if minsane < maxclock < minclock - produce ERROR log message about dysfunctional daemon. <perlin...@ntp.org> * [Bug 2851] allow -4/-6 on restrict line with mask <perlin...@ntp.org> - applied patch by Miroslav Lichvar for ntp4.2.6 compat * [Bug 2645] out-of-bound pointers in ctl_putsys and decode_bitflags - Fixed these and some more locations of this pattern. Probably din't get them all, though. <perlin...@ntp.org> * Update copyright year. * bk-7 trigger updates --- (4.2.8p9-win) 2017/02/01 Released by Harlan Stenn <st...@ntp.org> * [Bug 3144] NTP does not build without openSSL. <perlin...@ntp.org> - added missed changeset for automatic openssl lib detection - fixed some minor warning issues * [Bug 3095] More compatibility with openssl 1.1. <perlin...@ntp.org> * configure.ac cleanup. st...@ntp.org * openssl configure cleanup. st...@ntp.org Kurt
Bug#855432: unblock: openssl/1.1.0e-1
On Sun, Feb 19, 2017 at 07:33:20AM +0100, Cyril Brulebois wrote: > Kurt Roeckx <k...@roeckx.be> (2017-02-18): > > On Sat, Feb 18, 2017 at 06:16:28PM +0100, Cyril Brulebois wrote: > > > How soon do you want to see this package in testing? Given I've just > > > fixed a few things related to https support in d-i, it would be nice if > > > I were able to perform a full test with https here, making sure we don't > > > hit a regression there. If a reply this sunday is sufficient, I can do > > > that. > > We have this right now: > > wget-udeb | 1.18-4| testing → built against 1.0.2 > wget-udeb | 1.19.1-1 | unstable → built against 1.1 > > If we're not getting a newer wget for stretch (at least I didn't find > anything wget-related relevant for stretch in my debian-release folder), > I can't think of another libssl user for d-i, which seems confirmed by > looking at libssl*-udeb rdepends in sid. > > Unless I'm missing something obvious: no objections. Can someone please also change the age to 2 days? Kurt
Bug#855432: unblock: openssl/1.1.0e-1
On Sat, Feb 18, 2017 at 06:16:28PM +0100, Cyril Brulebois wrote: > Hi, > > Niels Thykier <ni...@thykier.net> (2017-02-18): > > Kurt Roeckx: > > > Package: release.debian.org > > > User: release.debian@packages.debian.org > > > Usertags: unblock > > > Severity: normal > > > > > > Hi, > > > > > > There was a new upstream release fixing a high severity security > > > issue. > > > > > > The changelog entry is: > > > openssl (1.1.0e-1) unstable; urgency=high > > > > > > * New upstream version > > > - Fixes CVE-2017-3733 > > > - Remove patches that are applied upstream. > > > > > > -- Kurt Roeckx <k...@roeckx.be> Thu, 16 Feb 2017 18:57:58 +0100 > > > > > > I've attached the full debdiff between the version in testing and > > > unstable. > > > > OK from here; KiBi, I need a d-i ack from you, please. :) > > How soon do you want to see this package in testing? Given I've just > fixed a few things related to https support in d-i, it would be nice if > I were able to perform a full test with https here, making sure we don't > hit a regression there. If a reply this sunday is sufficient, I can do > that. Sunday / Monday is fine for me. Kurt
Bug#855432: unblock: openssl/1.1.0e-1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Hi,
There was a new upstream release fixing a high severity security
issue.
The changelog entry is:
openssl (1.1.0e-1) unstable; urgency=high
* New upstream version
- Fixes CVE-2017-3733
- Remove patches that are applied upstream.
-- Kurt Roeckx <k...@roeckx.be> Thu, 16 Feb 2017 18:57:58 +0100
I've attached the full debdiff between the version in testing and
unstable.
Kurt
diff -Nru openssl-1.1.0d/apps/openssl.c openssl-1.1.0e/apps/openssl.c
--- openssl-1.1.0d/apps/openssl.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/openssl.c 2017-02-16 12:58:20.0 +0100
@@ -58,7 +58,6 @@
static void list_disabled(void);
char *default_config_file = NULL;
-static CONF *config = NULL;
BIO *bio_in = NULL;
BIO *bio_out = NULL;
BIO *bio_err = NULL;
@@ -248,8 +247,6 @@
end:
OPENSSL_free(copied_argv);
OPENSSL_free(default_config_file);
-NCONF_free(config);
-config = NULL;
lh_FUNCTION_free(prog);
OPENSSL_free(arg.argv);
diff -Nru openssl-1.1.0d/apps/req.c openssl-1.1.0e/apps/req.c
--- openssl-1.1.0d/apps/req.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/req.c 2017-02-16 12:58:20.0 +0100
@@ -121,7 +121,7 @@
{"multivalue-rdn", OPT_MULTIVALUE_RDN, '-',
"Enable support for multivalued RDNs"},
{"days", OPT_DAYS, 'p', "Number of days cert is valid for"},
-{"set_serial", OPT_SET_SERIAL, 'p', "Serial number to use"},
+{"set_serial", OPT_SET_SERIAL, 's', "Serial number to use"},
{"extensions", OPT_EXTENSIONS, 's',
"Cert extension section (override value in config file)"},
{"reqexts", OPT_REQEXTS, 's',
diff -Nru openssl-1.1.0d/apps/s_cb.c openssl-1.1.0e/apps/s_cb.c
--- openssl-1.1.0d/apps/s_cb.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/s_cb.c 2017-02-16 12:58:20.0 +0100
@@ -922,6 +922,7 @@
BIO_printf(bio_err, "%s: Error adding xcert\n", opt_getprog());
goto err;
}
+*pexc = exc;
exc->certfile = opt_arg();
break;
case OPT_X_KEY:
diff -Nru openssl-1.1.0d/apps/ts.c openssl-1.1.0e/apps/ts.c
--- openssl-1.1.0d/apps/ts.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/ts.c 2017-02-16 12:58:20.0 +0100
@@ -890,9 +890,15 @@
goto err;
f = TS_VFY_VERSION | TS_VFY_SIGNER;
if (data != NULL) {
+BIO *out = NULL;
+
f |= TS_VFY_DATA;
-if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) == NULL)
+if ((out = BIO_new_file(data, "rb")) == NULL)
goto err;
+if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) {
+BIO_free_all(out);
+goto err;
+}
} else if (digest != NULL) {
long imprint_len;
unsigned char *hexstr = OPENSSL_hexstr2buf(digest, _len);
diff -Nru openssl-1.1.0d/CHANGES openssl-1.1.0e/CHANGES
--- openssl-1.1.0d/CHANGES 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/CHANGES 2017-02-16 12:58:20.0 +0100
@@ -2,6 +2,19 @@
OpenSSL CHANGES
___
+ Changes between 1.1.0d and 1.1.0e [16 Feb 2017]
+
+ *) Encrypt-Then-Mac renegotiation crash
+
+ During a renegotiation handshake if the Encrypt-Then-Mac extension is
+ negotiated where it was not in the original handshake (or vice-versa) then
+ this can cause OpenSSL to crash (dependant on ciphersuite). Both clients
+ and servers are affected.
+
+ This issue was reported to OpenSSL by Joe Orton (Red Hat).
+ (CVE-2017-3733)
+ [Matt Caswell]
+
Changes between 1.1.0c and 1.1.0d [26 Jan 2017]
*) Truncated packet could crash via OOB read
diff -Nru openssl-1.1.0d/Configurations/unix-Makefile.tmpl openssl-1.1.0e/Configurations/unix-Makefile.tmpl
--- openssl-1.1.0d/Configurations/unix-Makefile.tmpl 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/Configurations/unix-Makefile.tmpl 2017-02-16 12:58:20.0 +0100
@@ -285,6 +285,7 @@
-$(RM) `find . -name '*{- $objext -}' -a \! -path "./.git/*"`
$(RM) core
$(RM) tags TAGS
+ $(RM) test/.rnd
$(RM) openssl.pc libcrypto.pc libssl.pc
-$(RM) `find . -type l -a \! -path "./.git/*"`
$(RM) $(TARFILE)
diff -Nru openssl-1.1.0d/crypto/aes/asm/aesv8-armx.pl openssl-1.1.0e/crypto/aes/asm/aesv8-armx.pl
--- openssl-1.1.0d/crypto/aes/asm/aesv8-armx.pl 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/crypto/aes/asm/aesv8-armx.pl 2017-02-16 12:58:20.0 +0100
@@ -59,9 +59,12 @@
.text
___
$code.=".arch armv8-a+crypto\n" if ($flavour =~ /64/);
-$code.=".arch armv7-a\n.fpu neon\n.code 32\n" if ($flavour !~ /64/);
- #^^ this is done to simplify adoption by n
Re: [Pkg-openssl-devel] embedding openssl source in sslcan
On Sun, Jan 01, 2017 at 04:37:48PM +0100, Raphael Hertzog wrote: > On Sat, 31 Dec 2016, Julien Cristau wrote: > > On Thu, Dec 22, 2016 at 13:37:11 +0100, Sebastian Andrzej Siewior wrote: > > > > > tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its > > > source? > > > > > > sslscan [0] as packaged in Debian currently relies on external libssl as > > > provided by the openssl package. The openssl package disables support > > > compression, SSLv2 and SSLv3 which is good but it also means that > > > sslscan can not detect a SSL implementation that is still providing > > > support for one of these deprecated protocols or compression. > > > One could say that it is not required to test for SSLv2 because if > > > libssl does not support it then it is not possible for an application to > > > offer it. However libssl is not the only SSL toolkit in Debian and one > > > might need to scan a non-Debian / older machine. > > > > > Is this really something we need to be shipping? If yes, I'd personally > > really like this to get an explicit exemption from normal policy by the > > security team, so please talk to them (debian-security@ldo is not it). > > "need" is somewhat hard to define, but to give an additional data point, > it's one of the things that we do in Kali to make it more useful for > security professionals so it would be nice if it we could do it in Debian > as well. > > That said sslscan is not the only tool where it could be useful and > packaging an alternate openssl-insecure should be considered too if it's > feasible (at least so that we can have alternative versions of the openssl > command line tools that can continue to support SSL2 and SSL3). Note that SSLv2 has been completly removed in the 1.1 version, so you'll never have 1 openssl version that supports both SSLv2 and TLS 1.3. I think one of the other issues they run into is that OpenSSL no longer can send a ClientHello without any extensions, so they can't tests for extenstion tolerances. I think in the long run, those applications should consider using an other implementation of SSL/TLS, or write enough of if to be able to do the tests that they want. And I think there are already such other programs out there that can do that. Kurt
Bug#842919: failed armhf build of xen 4.8.0~rc3-1 [and 1 more messages]
On Mon, Nov 07, 2016 at 08:54:49PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: failed armhf build of xen 4.8.0~rc3-1 [and 1 more
> messages]"):
> > On Mon, Nov 07, 2016 at 08:05:22PM +, Ian Jackson wrote:
> > > Have I done something wrong ? Do the buildd chroots need to be
> > > updated ?
> >
> > The buildd chroots are automatically generated once a week. No
> > package that's installed in the chroot get upgraded without a
> > reason like a Depends requiring them.
>
> Ah. We were unlucky then that the broken bintuils ended up cached
> this way.
>
> > I'll see about upgrading the chroots, I have no idea how to do
> > this myself.
>
> Thanks. I do think this should be done, then, as other packages are
> likely to be affected.
>
> This probably applies to all the architectures, not just armhf and
> i386. The xen package for sid escaped the bug on amd64 because I
> built it myself.
I just gave back xen and set an extra depends for the fixed
version.
The chroots get updated on sunday and wednesday. It seems to be
easier to just wait for wednesday and give back those few that are
affected. It looks like all buildds actually need the new chroot.
Kurt
Bug#842919: failed armhf build of xen 4.8.0~rc3-1 [and 1 more messages]
On Mon, Nov 07, 2016 at 08:05:22PM +, Ian Jackson wrote:
> Debian buildds writes ("failed armhf build of xen 4.8.0~rc3-1"):
> > * Source package: xen
> > * Version: 4.8.0~rc3-1
> > * Architecture: armhf
> > * State: failed
> > * Suite: sid
> > * Builder: hartmann.debian.org
> > * Build log:
> > https://buildd.debian.org/status/fetch.php?pkg=xen=armhf=4.8.0%7Erc3-1=1478544996=log
>
> Debian buildds writes ("failed i386 build of xen 4.8.0~rc3-1"):
> > * Source package: xen
> > * Version: 4.8.0~rc3-1
> > * Architecture: i386
> > * State: failed
> > * Suite: sid
> > * Builder: x86-grnet-01.debian.org
> > * Build log:
> > https://buildd.debian.org/status/fetch.php?pkg=xen=i386=4.8.0%7Erc3-1=1478544915=log
>
> These builds failed because they were done with binutils
> 2.27.51.20161105-1. That version had a severe bug that causes ld to
> spin on the cpu (on amd64 and other architectures, apparently).
>
> I uploaded xen 4.8.0~rc3-1 to sid after I observed that my amd64 sid
> chroot had obtained 2.27.51.20161105-2 which has the fix. 4.8.0~rc3-1
> has no code changes compared to 4.8.0~rc3-0exp2 which built on all
> applicable architectures in experimental.
>
> I see from
> https://buildd.debian.org/status/package.php?p=binutils=sid
> that the fixed version of binutils is showing as "Installed" for armhf
> and i386.
>
> Have I done something wrong ? Do the buildd chroots need to be
> updated ?
The buildd chroots are automatically generated once a week. No
package that's installed in the chroot get upgraded without a
reason like a Depends requiring them.
I'll see about upgrading the chroots, I have no idea how to do
this myself.
Kurt
Bug#827061: transition: openssl
On Sun, Oct 30, 2016 at 10:18:32PM +0200, Adrian Bunk wrote: > > If everything that is important in 1.1.0 should be used by all > users of OpenSSL in stretch, then the best solution for stretch > is to ship only 1.0.2 and add all desired features there. And I guess you're going to add all those features, and support them? Kurt
Bug#827061: transition: openssl
On Wed, Oct 26, 2016 at 10:55:19AM +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 25/10/16 20:09, Moritz Muehlenhoff wrote: > > On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: > >> On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > >>> > >>> I'm sorry but I'm going to have to nack this for Stretch, as much as I > >>> like to > >>> approve transitions and get new stuff in. I have looked at the opened > >>> bugs and > >>> I'm afraid this still is too disruptive. I have noticed that you have > >>> forwarded > >>> some of them and sent patches, and I appreciate that. We can do this > >>> early in > >>> the Buster cycle, so let's look at the status of this and prepare for the > >>> transition when Stretch gets released. > >> > >> Is having 2 version of OpenSSL in Stretch an option? > > > > We've discussed this within the security team and we'd be fine with > > a one-time exception to have two openssl releases in stretch; the API > > changes are clearly too invasive to cover the entire Debian archive, > > but 1.1 also carries sufficiently important new features (like support > > for chacha20/poly1305) to warrant the extra complexity. > > > > (It's the release team's call of course). > > 19:46 < nthykier> pochu: seen jmm_ reply to the libssl thread? > 19:46 < jcristau> adsb: yay for binary debdiffs in q-v! thanks a bunch. > 19:46 < pochu> yep > 19:47 < pochu> nthykier: so my concern was there was a big risk that we > wouldn't finish the transition intime, delaying the release. but if the > security > team is fine with (potentially, as I'll try not to) shipping both, then we > should be fine, and I think I'll ack it > 19:48 < pochu> of course we'll still try to get rid of the old one > 19:48 < nthykier> ack, I think that just made me pro on doing that as well > 19:48 < pochu> cool, good to see we're on the same page > > So let's do this. Let's try to get it finished and only ship openssl 1.1. We > still have three months until the full freeze, and depending on how many > packages (and which ones, for risk management etc) are left to be fixed after > that, I may be happy to grant exceptions. But worst case we just ship both. > > But please, wait a little bit so that we can sort out the PIE fallout. You can > start preparing the updates and upload to experimental to clear NEW if you > want. > We'll let you know once it's ok to upload to sid. So it has been suggested that we keep the libssl-dev package at the 1.0.2 package and create a new -dev package for the 1.1 version. We could then lower the severity of the bugs to important again, and only the packages wanting to make use of 1.1 could switch then. I think the most important new security feature in the 1.1.0 version is the extended master secret support. There are also a bunch of others like the chacha20-poly1305 and x25519, but they're less important. All TLS using applications really should start ussing the EMS, not just a few that want to switch to 1.1. Kurt
Bug#827061: transition: openssl
On Wed, Oct 26, 2016 at 08:53:56PM +0200, Emilio Pozuelo Monfort wrote: > > Adrian Bunk asked whether mixing both OpenSSL versions into the same address > space works fine. Is OpenSSL using symbol versioning? Yes, and all symbols have a different version name in 1.0.2 and 1.1.0. (What is actually the important thing.) > Is this situation > supported or should we expect things to break? This can easily happen if an > app > links against a library libA which uses openssl 1.0, and against libB which > uses > openssl 1.1. When linking you actually get a warning. As far as I know, it should only break when they use dlopen(). They most likely won't be using dlvsym() in that case and then it can pick any version. It could of course also break if they do very weird things. But I guess we'll have to see if something breaks or not. Kurt
Bug#827061: transition: openssl
On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > > I'm sorry but I'm going to have to nack this for Stretch, as much as I like to > approve transitions and get new stuff in. I have looked at the opened bugs and > I'm afraid this still is too disruptive. I have noticed that you have > forwarded > some of them and sent patches, and I appreciate that. We can do this early in > the Buster cycle, so let's look at the status of this and prepare for the > transition when Stretch gets released. Is having 2 version of OpenSSL in Stretch an option? I could upload an openssl102 source package that provides an libssl1.0.2-dev package, so that packages that aren't ready to move to the 1.1.0 version can build-depend on that instead. Kurt
Bug#827061: transition: openssl
On Sun, Sep 18, 2016 at 09:33:43PM +0200, Kurt Roeckx wrote: > On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote: > > On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote: > > > On 11/06/16 20:59, Kurt Roeckx wrote: > > > > OpenSSL will soon release a new upstream version with a new > > > > soname. This new version will break various packages, see: > > > > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > > > > > > > I'm currently not sure when the release will be ready. I would > > > > like to start this transition as soon as possible, but probably > > > > after it's actually released. I don't expect this to take long. > > > > > > 405 packages failed to build during your test rebuild AFAICS. That's > > > going to > > > take some time to sort out... > > > > > > > If I'm ready to upload it to unstable, can I start this > > > > transition? Are there things you want me to do? > > > > > > Please upload to experimental first and let us know when that's happened. > > > > It's in experimental already. The test suite only fails > > on hurd, for some reason it's not finding the engine. I still > > need to look at that. > > > > > We will also need bugs filed, with severity important for now. > > > > Sure, I'll start on that if I find the time. > > > > > Also it may be useful if you can get us the intersection between the > > > packages > > > that failed to build and the key packages[1] (see "Final list of 3302 key > > > source > > > packages" in that file). > > > > That actually seem to be 3247 source package. Anyway, the list is > > below. > > So OpenSSL 1.1.0 was released about 3 weeks ago. Since then we've > been working on the key packages, to get them to build with > OpenSSL 1.1.0. You can see that status of that at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org > > Most of the packages are really trivial to fix, but some do > require that you fix the same issues in many different places and > it can take some time to fix it. > > I would like to motivate more people to work on this by either > marking those bugs as RC, or uploading it to unstable. Ping. Kurt
Bug#827061: transition: openssl
On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote: > On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote: > > On 11/06/16 20:59, Kurt Roeckx wrote: > > > OpenSSL will soon release a new upstream version with a new > > > soname. This new version will break various packages, see: > > > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > > > > > I'm currently not sure when the release will be ready. I would > > > like to start this transition as soon as possible, but probably > > > after it's actually released. I don't expect this to take long. > > > > 405 packages failed to build during your test rebuild AFAICS. That's going > > to > > take some time to sort out... > > > > > If I'm ready to upload it to unstable, can I start this > > > transition? Are there things you want me to do? > > > > Please upload to experimental first and let us know when that's happened. > > It's in experimental already. The test suite only fails > on hurd, for some reason it's not finding the engine. I still > need to look at that. > > > We will also need bugs filed, with severity important for now. > > Sure, I'll start on that if I find the time. > > > Also it may be useful if you can get us the intersection between the > > packages > > that failed to build and the key packages[1] (see "Final list of 3302 key > > source > > packages" in that file). > > That actually seem to be 3247 source package. Anyway, the list is > below. So OpenSSL 1.1.0 was released about 3 weeks ago. Since then we've been working on the key packages, to get them to build with OpenSSL 1.1.0. You can see that status of that at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org Most of the packages are really trivial to fix, but some do require that you fix the same issues in many different places and it can take some time to fix it. I would like to motivate more people to work on this by either marking those bugs as RC, or uploading it to unstable. Kurt
Bug#827061: transition: openssl
On Thu, Sep 15, 2016 at 11:44:42PM +0200, Christoph Berg wrote: > Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be> > > > > If I'm ready to upload it to unstable, can I start this > > > > transition? Are there things you want me to do? > > > > > > Please upload to experimental first and let us know when that's happened. > > > > It's in experimental already. The test suite only fails > > on hurd, for some reason it's not finding the engine. I still > > need to look at that. > > Hi, > > do you expect the transition to be done for stretch? I really would like to have it in stretch. I don't want to have the same situtation like we had with 1.0.2 that didn't make it it to jessie. > I'm asking because the PostgreSQL people want to know if they need to > add support for OpenSSL 1.1 in the older release branches (9.2 .. > 9.4), or if patching 9.5 .. 10 is enough for now. I guess they want to provide binaries for all their releases on apt.postgresql.org? > (Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems > unlikely, but just to confirm?) This is not my plan. Kurt
Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3
On Tue, Aug 23, 2016 at 09:47:22PM +0200, Kurt Roeckx wrote: > The current debdiff we'd like to upload is: > diff -Nru openssl-1.0.1t/debian/changelog openssl-1.0.1t/debian/changelog > --- openssl-1.0.1t/debian/changelog 2016-05-15 21:16:55.0 +0200 > +++ openssl-1.0.1t/debian/changelog 2016-06-11 19:18:11.0 +0200 > @@ -1,3 +1,14 @@ > +openssl (1.0.1t-1+deb8u3) jessie; urgency=medium > + > + [ Kurt Roeckx ] > + * Fix length check for CRLs. (Closes: #826552) > + > + [ Sebastian Andrzej Siewior ] > + * Enable asm optimisation for s390x. Patch by Dimitri John Ledkov. > +(Closes: #833156). > + > + -- Kurt Roeckx <k...@roeckx.be> Sat, 11 Jun 2016 19:18:11 +0200 > + > openssl (1.0.1t-1+deb8u2) jessie; urgency=medium Ping? Kurt
Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3
The current debdiff we'd like to upload is:
diff -Nru openssl-1.0.1t/debian/changelog openssl-1.0.1t/debian/changelog
--- openssl-1.0.1t/debian/changelog 2016-05-15 21:16:55.0 +0200
+++ openssl-1.0.1t/debian/changelog 2016-06-11 19:18:11.0 +0200
@@ -1,3 +1,14 @@
+openssl (1.0.1t-1+deb8u3) jessie; urgency=medium
+
+ [ Kurt Roeckx ]
+ * Fix length check for CRLs. (Closes: #826552)
+
+ [ Sebastian Andrzej Siewior ]
+ * Enable asm optimisation for s390x. Patch by Dimitri John Ledkov.
+(Closes: #833156).
+
+ -- Kurt Roeckx <k...@roeckx.be> Sat, 11 Jun 2016 19:18:11 +0200
+
openssl (1.0.1t-1+deb8u2) jessie; urgency=medium
* add Update-S-MIME-certificates.patch to update expired certificates to
diff -Nru openssl-1.0.1t/debian/patches/debian-targets.patch
openssl-1.0.1t/debian/patches/debian-targets.patch
--- openssl-1.0.1t/debian/patches/debian-targets.patch 2016-05-01
23:53:42.0 +0200
+++ openssl-1.0.1t/debian/patches/debian-targets.patch 2016-06-11
19:18:11.0 +0200
@@ -56,7 +56,7 @@
+"debian-ppc64","gcc:-m64 -DB_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
DES_RISC1
DES_UNROLL:${ppc64_asm}:linux64:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-ppc64el","gcc:-m64 -DL_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
DES_RISC1
DES_UNROLL:${ppc64_asm}:linux64le:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-s390","gcc:-DB_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"debian-s390x","gcc:-DB_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
DES_INT
DES_UNROLL:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"debian-s390x","gcc:-DB_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
DES_INT
DES_UNROLL:${s390x_asm}:64:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-sh3", "gcc:-DL_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-sh4", "gcc:-DL_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-sh3eb", "gcc:-DB_ENDIAN -DTERMIO
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
diff -Nru openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
--- openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
2016-06-11 19:16:05.0 +0200
@@ -0,0 +1,40 @@
+From b583c1bd069f6928c3973dc6d6864930f6c4bb3e Mon Sep 17 00:00:00 2001
+From: "Dr. Stephen Henson" <st...@openssl.org>
+Date: Wed, 4 May 2016 16:09:06 +0100
+Subject: [PATCH] Fix name length limit check.
+
+The name length limit check in x509_name_ex_d2i() includes
+the containing structure as well as the actual X509_NAME. This will
+cause large CRLs to be rejected.
+
+Fix by limiting the length passed to ASN1_item_ex_d2i() which will
+then return an error if the passed X509_NAME exceeds the length.
+
+RT#4531
+
+Reviewed-by: Rich Salz <rs...@openssl.org>
+(cherry picked from commit 4e0d184ac1dde845ba9574872e2ae5c903c81dff)
+---
+ crypto/asn1/x_name.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/crypto/asn1/x_name.c b/crypto/asn1/x_name.c
+index a858c29..26378fd 100644
+--- a/crypto/asn1/x_name.c
b/crypto/asn1/x_name.c
+@@ -199,10 +199,8 @@ static int x509_name_ex_d2i(ASN1_VALUE **val,
+ int i, j, ret;
+ STACK_OF(X509_NAME_ENTRY) *entries;
+ X509_NAME_ENTRY *entry;
+-if (len > X509_NAME_MAX) {
+-ASN1err(ASN1_F_X509_NAME_EX_D2I, ASN1_R_TOO_LONG);
+-return 0;
+-}
++if (len > X509_NAME_MAX)
++len = X509_NAME_MAX;
+ q = p;
+
+ /* Get internal representation of Name */
+--
+2.8.1
+
diff -Nru openssl-1.0.1t/debian/patches/series
openssl-1.0.1t/debian/patches/series
--- openssl-1.0.1t/debian/patches/series2016-05-15 21:16:55.0
+0200
+++ openssl-1.0.1t/debian/patches/series2016-06-11 19:18:11.0
+0200
@@ -20,3 +20,4 @@
openssl_fix_for_x32.patch
ppc64el.patch
Update-S-MIME-certificates.patch
+Fix-name-length-limit-check.patch
Bug#832477: pu: libtool
On Sat, Jul 30, 2016 at 08:45:25PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + pending
>
> On Sat, 2016-07-30 at 10:51 +0200, Kurt Roeckx wrote:
> > On Fri, Jul 29, 2016 at 01:40:17PM +0200, Julien Cristau wrote:
> > > Control: tag -1 confirmed
> > >
> > > On Mon, Jul 25, 2016 at 23:28:14 +0200, Kurt Roeckx wrote:
> [...]
> > > > I would like to fix #800446 in stable. It was caused by the
> > > > uploader not using the current version of automake when uploading
> > > > the binary package. The i386 and amd64 version need to be build
> > > > using the same version.
> > > >
> > > > So I see 2 solutions:
> > > > - We binNMU it on both i386 and amd64
> > > > - I upload a new version with no changes
> > > >
> > > I've scheduled a binNMU for i386 and amd64. Once those are available
> > > can you please double check that the issue is gone and that the upgrade
> > > path is fine?
> >
> > I think you need to approve them before I can check that. In any
> > case I don't see them yet.
>
> /srv/ftp-master.d.o/policy is DD-accessible via the ftp-master mirror
> and contains packages files for {,old}stable-new alongside the binary
> packages.
>
> I've just flagged the uploads for acceptance, so they should hit p-u
> after the next dinstall.
The diff is still:
--- usr/share/libtool/libltdl/Makefile.in2014-10-14
17:40:35.0 +
+++ usr/share/libtool/libltdl/Makefile.in2014-10-14
18:33:42.0 +
@@ -87,7 +87,7 @@
subdir = .
DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
$(top_srcdir)/configure $(am__configure_deps) \
- $(srcdir)/config-h.in lt__strl.c lt__dirent.c argz.c \
+ $(srcdir)/config-h.in lt__dirent.c lt__strl.c argz.c \
$(top_srcdir)/config/depcomp $(am__include_HEADERS_DIST) \
$(am__ltdlinclude_HEADERS_DIST) COPYING.LIB README \
config/compile config/config.guess config/config.sub \
Not sure what is going on yet.
Kurt
Re: Porter roll call for Debian Stretch
On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote: > * If we were to enable -fPIE/-pie by default in GCC-6, should that change >also apply to this port? [0] If -fPIE is the default will -fPIC override it? It will also default to tell the linker to use -pie, but then don't do it when you want to create a shared library? >From what I understand, depending on what the .o file is going to be used for you want different things: - shared library: -fPIC - executable: -fPIC or -fPIE both work, but prefer -fPIE - static library: Same as executables For static libraries we now have a policy to not use -fPIC, should that then get replaced by using -fPIE? Kurt
Bug#832477: pu: libtool
On Fri, Jul 29, 2016 at 01:40:17PM +0200, Julien Cristau wrote: > Control: tag -1 confirmed > > On Mon, Jul 25, 2016 at 23:28:14 +0200, Kurt Roeckx wrote: > > > Package: release.debian.org > > Tags: jessie > > User: release.debian@packages.debian.org > > Usertags: pu > > > > Hi, > > > > I would like to fix #800446 in stable. It was caused by the > > uploader not using the current version of automake when uploading > > the binary package. The i386 and amd64 version need to be build > > using the same version. > > > > So I see 2 solutions: > > - We binNMU it on both i386 and amd64 > > - I upload a new version with no changes > > > I've scheduled a binNMU for i386 and amd64. Once those are available > can you please double check that the issue is gone and that the upgrade > path is fine? I think you need to approve them before I can check that. In any case I don't see them yet. Kurt
Bug#832477: pu: libtool
Package: release.debian.org Tags: jessie User: release.debian@packages.debian.org Usertags: pu Hi, I would like to fix #800446 in stable. It was caused by the uploader not using the current version of automake when uploading the binary package. The i386 and amd64 version need to be build using the same version. So I see 2 solutions: - We binNMU it on both i386 and amd64 - I upload a new version with no changes Kurt
Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3
I guess I should just keep the SSLv2 symbols. I assume you don't have a problem with the other change? Kurt
Re: [Pkg-openssl-devel] Bug#827951: libssl udeb inclusion in Jessie
On Thu, Jun 23, 2016 at 10:58:54AM +0200, Yann Soubeyrand wrote: > Package: openssl > Severity: normal > Version: 1.0.1t-1+deb8u2 > X-Debbugs-CC: debian-release@lists.debian.org > X-Debbugs-CC: debian-b...@lists.debian.org > > Hi, > > Marga Manterola provided a patch to build a libssl udeb as well as the > libcrypto udeb that was included in Sid (#802591). Could this patch be a > candidate for Jessie inclusion? If so, you can find a patch attached to > this mail. Is there a reason why you would like it in jessie? Will the installer start to make use of it? Kurt
Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3
On Mon, Jun 13, 2016 at 10:19:29AM +0200, Julien Cristau wrote: > On Mon, Jun 13, 2016 at 00:50:05 +0200, Kurt Roeckx wrote: > > > I should probably add that I don't intend to fix this in > > testing/unstable. There are probably reverse dependencies that > > saw those symbols are available and then started using them again, > > and so it would break things. But I'm going to change to the 1.1 > > Doesn't the same reasoning apply to stable? There currently shouldn't be reverse dependencies that saw the defines so it could pick up the symbols, but the longer it stays like this the more likely some upload will see it and use it. > Why was this not caught when updating the libssl1.0.2.symbols file for > the new release? The .symbols files just looks like: libcrypto.so.1.0.2 libssl1.0.2 #MINVER# *@OPENSSL_1.0.2d 1.0.2d *@OPENSSL_1.0.2g 1.0.2g libssl.so.1.0.2 libssl1.0.2 #MINVER# *@OPENSSL_1.0.2d 1.0.2d *@OPENSSL_1.0.2g 1.0.2g And the symbols already "existed", they were just not exported. > > soname soon anyway, and it'll get fixed at that point. Also, the > > symbols are available but if you try to use them it's not going to > > do anything useful. > > > > > But I'd like to remove them in stable again, since nothing there > > should use on it now, and it broke something. > > > Can you be more specific than "broke something"? https://github.com/openssl/openssl/issues/1190 But I guess that will solve itself. Kurt
Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3
On Sat, Jun 11, 2016 at 11:35:24PM +0200, Kurt Roeckx wrote: > On Sat, Jun 11, 2016 at 09:57:29PM +0100, Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > > > On Sat, 2016-06-11 at 19:38 +0200, Kurt Roeckx wrote: > > > The SSLv2 methods actually didn't exist in jessie, but some > > > defaults where changed and the SSLv2 methods now in jessie just > > > return NULL. This removes the symbols again. Exposing the > > > symbols in the headers actually seems to have broken something, > > > so this removes them again. It was actually never the intention > > > to introduce those symbols again. > > [...] > > > -CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl > > > --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 no-zlib > > > enable-tlsext no-ssl2 no-ssl3 > > > +CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl > > > --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 no-zlib > > > enable-tlsext no-ssl2 no-ssl2-method no-ssl3 > > > > Does this also affect the 1.0.2 tree? The 1.0.2h package in unstable has > > no-ssl2, no-ssl3, no-ssl3-method but not no-ssl2-method. > > You're right, it has the same problem. I completly forgot that, and > I even commited that myself. > > The reason for splitting no-ssl2 into no-ssl2 and no-ssl2-method > is that we turned no-ssl2 on by default and people were suprised > that SSLv2_* methods actually got removed and it of course broke > various distributions that didn't builld with no-ssl2. So we > changed the default to make those funtions return NULL instead by > default, and then remove them with no-ssl2-method. I should probably add that I don't intend to fix this in testing/unstable. There are probably reverse dependencies that saw those symbols are available and then started using them again, and so it would break things. But I'm going to change to the 1.1 soname soon anyway, and it'll get fixed at that point. Also, the symbols are available but if you try to use them it's not going to do anything useful. But I'd like to remove them in stable again, since nothing there should use on it now, and it broke something. Kurt
Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3
On Sat, Jun 11, 2016 at 09:57:29PM +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Sat, 2016-06-11 at 19:38 +0200, Kurt Roeckx wrote: > > The SSLv2 methods actually didn't exist in jessie, but some > > defaults where changed and the SSLv2 methods now in jessie just > > return NULL. This removes the symbols again. Exposing the > > symbols in the headers actually seems to have broken something, > > so this removes them again. It was actually never the intention > > to introduce those symbols again. > [...] > > -CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl > > --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 no-zlib > > enable-tlsext no-ssl2 no-ssl3 > > +CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl > > --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 no-zlib > > enable-tlsext no-ssl2 no-ssl2-method no-ssl3 > > Does this also affect the 1.0.2 tree? The 1.0.2h package in unstable has > no-ssl2, no-ssl3, no-ssl3-method but not no-ssl2-method. You're right, it has the same problem. I completly forgot that, and I even commited that myself. The reason for splitting no-ssl2 into no-ssl2 and no-ssl2-method is that we turned no-ssl2 on by default and people were suprised that SSLv2_* methods actually got removed and it of course broke various distributions that didn't builld with no-ssl2. So we changed the default to make those funtions return NULL instead by default, and then remove them with no-ssl2-method. Kurt
Bug#827061: transition: openssl
On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote: > On 11/06/16 20:59, Kurt Roeckx wrote: > > OpenSSL will soon release a new upstream version with a new > > soname. This new version will break various packages, see: > > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > > > I'm currently not sure when the release will be ready. I would > > like to start this transition as soon as possible, but probably > > after it's actually released. I don't expect this to take long. > > 405 packages failed to build during your test rebuild AFAICS. That's going to > take some time to sort out... > > > If I'm ready to upload it to unstable, can I start this > > transition? Are there things you want me to do? > > Please upload to experimental first and let us know when that's happened. It's in experimental already. The test suite only fails on hurd, for some reason it's not finding the engine. I still need to look at that. > We will also need bugs filed, with severity important for now. Sure, I'll start on that if I find the time. > Also it may be useful if you can get us the intersection between the packages > that failed to build and the key packages[1] (see "Final list of 3302 key > source > packages" in that file). That actually seem to be 3247 source package. Anyway, the list is below. Kurt bind9 clamav curl cyrus-sasl2 freebsd-utils freerdp gsoap gst-plugins-bad1.0 kde4libs kdelibs4support kopete krb5 libcrypt-openssl-rsa-perl libevent libexosip2 libmicrohttpd libmsn libnet-ssleay-perl libssh links2 m2crypto mariadb-client-lgpl neon27 net-snmp nghttp2 nginx nmap nodejs ntp openhpi openipmi opensc openssh openvpn opusfile php5 pkcs11-helper postfix postgresql-9.5 pulseaudio pypy python-cryptography qca2 qt4-x11 qtbase-opensource-src rdesktop ruby2.3 sendmail serf socat spamassassin spdylay spice spice-gtk stunnel4 tcpdump transmission unbound uw-imap vde2 virtualbox virtuoso-opensource wget wpa xmlsec1 xmms2
Bug#827061: transition: openssl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, OpenSSL will soon release a new upstream version with a new soname. This new version will break various packages, see: https://lists.debian.org/debian-devel/2016/06/msg00205.html I'm currently not sure when the release will be ready. I would like to start this transition as soon as possible, but probably after it's actually released. I don't expect this to take long. If I'm ready to upload it to unstable, can I start this transition? Are there things you want me to do? Kurt
Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3
Package: release.debian.org
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to update the version in stable for openssl. See the
debdiff below.
The SSLv2 methods actually didn't exist in jessie, but some
defaults where changed and the SSLv2 methods now in jessie just
return NULL. This removes the symbols again. Exposing the
symbols in the headers actually seems to have broken something,
so this removes them again. It was actually never the intention
to introduce those symbols again.
The other fix is a regression.
There are also some open CVEs in upstream git, but I'll wait with
those until there is actually a new release.
Kurt
diff -Nru openssl-1.0.1t/debian/changelog openssl-1.0.1t/debian/changelog
--- openssl-1.0.1t/debian/changelog 2016-05-15 21:16:55.0 +0200
+++ openssl-1.0.1t/debian/changelog 2016-06-11 19:20:02.0 +0200
@@ -1,3 +1,11 @@
+openssl (1.0.1t-1+deb8u3) jessie; urgency=medium
+
+ * Disable SSLv2 methods again, changes upstream has split no-ssl2 into
+no-ssl2 and no-ssl2-method
+ * Fix length check for CRLs. (Closes: #826552)
+
+ -- Kurt Roeckx <k...@roeckx.be> Sat, 11 Jun 2016 19:18:11 +0200
+
openssl (1.0.1t-1+deb8u2) jessie; urgency=medium
* add Update-S-MIME-certificates.patch to update expired certificates to
diff -Nru openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
--- openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1t/debian/patches/Fix-name-length-limit-check.patch
2016-06-11 19:16:05.0 +0200
@@ -0,0 +1,40 @@
+From b583c1bd069f6928c3973dc6d6864930f6c4bb3e Mon Sep 17 00:00:00 2001
+From: "Dr. Stephen Henson" <st...@openssl.org>
+Date: Wed, 4 May 2016 16:09:06 +0100
+Subject: [PATCH] Fix name length limit check.
+
+The name length limit check in x509_name_ex_d2i() includes
+the containing structure as well as the actual X509_NAME. This will
+cause large CRLs to be rejected.
+
+Fix by limiting the length passed to ASN1_item_ex_d2i() which will
+then return an error if the passed X509_NAME exceeds the length.
+
+RT#4531
+
+Reviewed-by: Rich Salz <rs...@openssl.org>
+(cherry picked from commit 4e0d184ac1dde845ba9574872e2ae5c903c81dff)
+---
+ crypto/asn1/x_name.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/crypto/asn1/x_name.c b/crypto/asn1/x_name.c
+index a858c29..26378fd 100644
+--- a/crypto/asn1/x_name.c
b/crypto/asn1/x_name.c
+@@ -199,10 +199,8 @@ static int x509_name_ex_d2i(ASN1_VALUE **val,
+ int i, j, ret;
+ STACK_OF(X509_NAME_ENTRY) *entries;
+ X509_NAME_ENTRY *entry;
+-if (len > X509_NAME_MAX) {
+-ASN1err(ASN1_F_X509_NAME_EX_D2I, ASN1_R_TOO_LONG);
+-return 0;
+-}
++if (len > X509_NAME_MAX)
++len = X509_NAME_MAX;
+ q = p;
+
+ /* Get internal representation of Name */
+--
+2.8.1
+
diff -Nru openssl-1.0.1t/debian/patches/series
openssl-1.0.1t/debian/patches/series
--- openssl-1.0.1t/debian/patches/series2016-05-15 21:16:55.0
+0200
+++ openssl-1.0.1t/debian/patches/series2016-06-11 19:19:06.0
+0200
@@ -20,3 +20,4 @@
openssl_fix_for_x32.patch
ppc64el.patch
Update-S-MIME-certificates.patch
+Fix-name-length-limit-check.patch
diff -Nru openssl-1.0.1t/debian/rules openssl-1.0.1t/debian/rules
--- openssl-1.0.1t/debian/rules 2016-05-06 14:16:42.0 +0200
+++ openssl-1.0.1t/debian/rules 2016-06-11 19:18:36.0 +0200
@@ -26,7 +26,7 @@
export CROSS_COMPILE ?= $(DEB_HOST_GNU_TYPE)-
endif
-CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl
--libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 no-zlib
enable-tlsext no-ssl2 no-ssl3
+CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl
--libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 no-zlib enable-tlsext
no-ssl2 no-ssl2-method no-ssl3
OPT_alpha = ev4 ev5
OPT_i386 = i586 i686/cmov
ARCHOPTS = OPT_$(DEB_HOST_ARCH)
Bug#823609: jessie-pu: package openssl/1.0.1t-1+deb8u1
On Sun, May 15, 2016 at 08:09:06PM +0100, Adam D. Barratt wrote: > On Wed, 2016-05-11 at 23:48 +0200, Sebastian Andrzej Siewior wrote: > > control: retitle -1 jessie-pu: package openssl/1.0.1t-1+deb8u2 > > > > On 2016-05-06 16:07:15 [+0200], Kurt Roeckx wrote: > > > > > So I've prepared an update for jessie with version > > > > I prepared an u2 which updates some certs for the testsuite. The old > > expired yesterday and so the testsuite fails and the package won't > > build. New ones are valid till May 26 17:28:31 2023. > > Please go ahead. 1.0.1t-1+deb8u2 has been uploaded. Kurt
Bug#823609: jessie-pu: package openssl/1.0.1t-1+deb8u1
Package: release.debian.org
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
So I've prepared an update for jessie with version
1.0.1t-1+deb8u1. This are the changes:
--- debian/changelog 2016-05-06 15:36:05.976438113 +0200
+++ debian/changelog 2016-05-06 15:56:17.562695936 +0200
@@ -1,3 +1,15 @@
+openssl (1.0.1t-1+deb8u1) jessie; urgency=medium
+
+ [ Sebastian Andrzej Siewior ]
+ * Update to 1.0.1t stable release (drop applied patches and refresh existing
+ones).
+- Use alternate trust chains part of 1.0.1n (Closes: #774882).
+- Use correct digest when exporting keying material (Closes: #807057)
+- Fix CVE-2015-3197 (not affected, SSLv2 disabled)
+- Fix CVE-2015-1793 (1.0.1n+ is affected and last upload was k)
+
+ -- Kurt Roeckx <k...@roeckx.be> Fri, 06 May 2016 15:56:09 +0200
+
openssl (1.0.1k-3+deb8u5) jessie-security; urgency=medium
* Fix CVE-2016-2105
--- debian/rules 2014-10-15 19:11:07.097579808 +0200
+++ debian/rules 2016-05-06 14:16:42.757075129 +0200
@@ -50,6 +50,7 @@
# perl util/ssldir.pl /usr/lib/ssl
# chmod +x debian/libtool
./Configure no-shared $(CONFARGS) debian-$(DEB_HOST_ARCH)
+ make depend
make -f Makefile all
$(MAKE_TEST)
mv libcrypto.a libcrypto.static
@@ -100,6 +101,7 @@
rm -f test/asn1test test/wp_test test/srptest test/jpaketest
rm -f certs/demo/*.0
rm -rf crypto/aes/aes-armv4.S crypto/bn/armv4-gf2m.S
crypto/modes/ghash-armv4.S crypto/sha/*.S
+ find . -type l -exec rm '{}' \;
dh_clean
install: build
The patches in debian/patches have whitespace changes, and for the
rest it removes a whole bunch of patches.
Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Thu, May 05, 2016 at 04:58:05PM +0200, Julien Cristau wrote: > Closing this as resolved, there will not be any further updates to > wheezy, and jessie updates will be handled in separate bugs. You mean I should file an other bug for just the same question? Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Wed, Apr 13, 2016 at 09:36:49PM +0100, Adam D. Barratt wrote: > Assuming that we went ahead with upstream updates to Jessie (and future > supported stable distributions), I'm presuming that the preferred > workflow would be similar to other packages for which we ship upstream > stable trees - via the security archive for issues that merit a DSA, > with lesser severity issues being updated via p-u and thus pushed out to > users as part of a point release. Does that make sense to everyone? > (Does anyone have alternative suggestions?) That would at least make total sense to me. Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Jan 26, 2016 at 06:38:31AM +, Adam D. Barratt wrote: > On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote: > > However 1.0.1q hasn't been in stable at all, which is presumably what > > you'd be proposing introducing to oldstable at this juncture. (and which > > we'd therefore need to introduce to stable first, if we were to agree to > > follow that path.) > > Picking this up again (I hadn't realised the above was so many weeks > ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k > really needs a newer upstream version to be in Jessie first. We also > likely only have two opportunities to get a package in to "Wheezy > proper" before it moves to LTS status - likely a point release in March > and then a "mop up" after the EOL of the base suite. And we're currently already at the end of March ... Kurt
Re: Qt and OpenSSL transition metadata in relation to Mumble package
On Mon, Mar 21, 2016 at 10:20:43PM +0100, Julien Cristau wrote: > I don't think dlopen(libssl) vs gcc -lssl makes any difference > licensing-wise, I suspect either they're both ok or they're both not > ok... I assume the problem is not with Qt itself, but with other applications making use of Qt. Kurt
Bug#765639: Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Jan 26, 2016 at 06:38:31AM +, Adam D. Barratt wrote: > On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote: > > However 1.0.1q hasn't been in stable at all, which is presumably what > > you'd be proposing introducing to oldstable at this juncture. (and which > > we'd therefore need to introduce to stable first, if we were to agree to > > follow that path.) > > Picking this up again (I hadn't realised the above was so many weeks > ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k > really needs a newer upstream version to be in Jessie first. We also > likely only have two opportunities to get a package in to "Wheezy > proper" before it moves to LTS status - likely a point release in March > and then a "mop up" after the EOL of the base suite. > > > Admittedly, the description of the changes between 1.0.1k and 1.0.1q, > > according to NEWS/CHANGES don't immediately look crazy. > > Comparing those against the package changelog and Security Tracker and > ignoring changes which are apparently only relevant if SSLv2 is enabled > leaves us with: > > *) dhparam: generate 2048-bit parameters by default. > [Kurt Roeckx and Emilia Kasper] > > *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs. > This changes the decoding behaviour for some invalid messages, > though the change is mostly in the more lenient direction, and > legacy behaviour is preserved as much as possible. > [Emilia Käsper] > > *) In DSA_generate_parameters_ex, if the provided seed is too short, > return an error > [Rich Salz and Ismo Puustinen <ismo.puusti...@intel.com>] > > *) Build fixes for the Windows and OpenVMS platforms > [Matt Caswell and Richard Levitte] > > The last of those is obviously irrelevant. Have there been any reports > of issues related to the other fixes listed? I can't remember any report about one of the above changes, nor can I find any. The base64 change is that it did weird things when receiving invalid base64, which you shouldn't get in practice, and now at least acts sane. The DSA entry in CHANGES is actually wrong, that's how it was changed in the master branch. It was merged to the stable branches and then reverted without reverting the CHANGES, and then fixed to instead do what was previously documented and uses a random seed if the seed is too short. I'll see about getting that CHANGES entry fixed. We reverted that because we think it wasn't an acceptable change in behaviour in the stable branches. The dhparam thing is really about a default that if you generate DH parameters that it defaults to 2048 instead of 1024. This shouldn't break anything itself, nor do I know of any other software that would get broken by this. You can always override this default when generating them. The most reports about breakage we get actually have to do with the security fixes themself, like enforcing the minimum size of 768 bit when using DH and then finding out that there is software that uses 512 bit DH. (The upcomming release will actually change that to 1024, as announced.) Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Sun, Dec 06, 2015 at 11:46:01AM +0100, Moritz Mühlenhoff wrote: > Hi, > Personally I'm in favour of following the openssl point updates and I'd > like to add an additional data point to the discussion: > > CVE-2015-3196 was already fixed as a plain bugfix in an earlier point > release, but the security impact was only noticed later on, so following > the point updates would have fixed this bug five months ago. So now CVE-2015-7575 (SLOTH) has been made public. This is yet an other example of an issue fixed a long time ago. It only affected wheezy because was fixed just after the version in wheezy. Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote: > > Even a naively filtered diff - excluding documentation and tests - > between the 1.0.1k tag and HEAD on upstream's stable branch is much > larger than I'd imagined (1091 files changed, 73609+, 68591-), but > paging through it there's a significant amount of "no-op" changes such > as > > - seed_len, > - param_len; > + seed_len, param_len; > > that git diff is sadly too dumb to be able to ignore (or I'm too dumb to > be able to drive it to do so). There was a reformat of the code between those releases. See: https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/ It includes the tags before and after the reformat. Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote: > [dropped explicit CCs to RT and TC members] > > On Tue, 2015-10-20 at 20:37 +0200, Kurt Roeckx wrote: > > On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote: > > > So from what I'm gathering, this looks like a case where there isn't > > > enough eyeballs to adequately review this particularly set of updates, > > > coupled with the importance of making sure that these updates are > > > correct and don't cause any unintended issues. > > > > There is always the case that one persons bug is an other persons > > feature. But those new upstream versions have been in stable and > > testing for a while now without actually breaking anything. > > (I'm assuming "unstable".) I really meant stable. stable has a newer version than oldstable from the same 1.0.1 series. Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Wed, Nov 04, 2015 at 11:57:00AM -0600, Don Armstrong wrote: > > In this specific case, the specific set of changes which have been made, > coupled with documenting the policy of upstream for testing and making > changes to openssl would be a good start. I've pointed to upstream's policy before, but the URL has actually changedin the mean time: https://www.openssl.org/policies/releasestrat.html I've also gave some information about testing that is happening in the stable branches at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639#110 I'm not sure what you mean with "specific set of changes which have been made". There have been more than 900 upstream commits since the 1.0.1e release that's in wheezy. Most of those are security issues being solved and bug reports that are getting fixed. Then there are lots of things we notice in the master branch that we also fix in the other branches like not checking return values, memory leaks, and so on. But there really is too much to get into details here I think and if you really want to know just look at the git commit messages. Kurt
Bug#797926: transition: openssl: remove SSLv3 methods
On Sat, Nov 07, 2015 at 12:30:11PM +0100, Emilio Pozuelo Monfort wrote: > All the rdeps have been binNMUed at this stage. Now bugs need to be reported > so > the buggy packages are either fixed or leave testing. I'll work on it when I have time. Kurt
Bug#797926: transition: openssl: remove SSLv3 methods
On Sun, Nov 01, 2015 at 06:52:08PM +0100, Emilio Pozuelo Monfort wrote: > >> Do the rdeps build against the new version? IOW, are there any users of the > >> removed methods? > > > > There are users of the removed method. But all known ones should > > have been changed to either not use it anymore or use it > > conditionally. > > By conditionally do you mean guarded by #ifdefs ? Yes. I do wish they just removed it though. > Anyway, let's go ahead with this. Ok, I'll upload it to unstable soon. Kurt
Bug#797926: transition: openssl: remove SSLv3 methods
On Sun, Nov 01, 2015 at 03:22:29PM +0100, Emilio Pozuelo Monfort wrote: > On 26/10/15 23:28, Emilio Pozuelo Monfort wrote: > > On 24/10/15 11:22, Kurt Roeckx wrote: > >> On Wed, Sep 16, 2015 at 10:17:10PM +0100, Jonathan Wiltshire wrote: > >>> On Wed, Sep 09, 2015 at 12:25:16PM +0200, Kurt Roeckx wrote: > >>>> On Thu, Sep 03, 2015 at 10:36:33PM +0100, Jonathan Wiltshire wrote: > >>>>>> So do I start with an soname change and upload that to > >>>>>> experimental? > >>>>> > >>>>> Yes please. > >>>> > >>>> So that has passed the new queue now. Please let me know when I > >>>> can start this in unstable. > >>> > >>> Looking at the tracker there are (as I suspected) quite a number of > >>> collisions with the ongoing g++ work. We'll try and arrange a slot when > >>> things are calmer. > >> > >> So any idea when you'll have time for this? > > > > Possibly after the perl one, if the libstdc++ one allows for this (I need to > > check). This is in my radar. > > Do the rdeps build against the new version? IOW, are there any users of the > removed methods? There are users of the removed method. But all known ones should have been changed to either not use it anymore or use it conditionally. Kurt
Bug#765639: wheezy-pu: openssl new upstream version
On Sat, Oct 31, 2015 at 02:20:22PM +, Adam D. Barratt wrote: > On Sun, 2015-06-14 at 11:52 +0200, Kurt Roeckx wrote: > > On Sun, Jun 14, 2015 at 12:22:52PM +1000, Julien Cristau wrote: > > > Is the policy for what gets included in the stable branches described > > > somewhere? > > > > It's documented at: > > https://www.openssl.org/about/releasestrat.html > > > > > What kind of automated or manual regression (or other) > > > testing is done on the stable branches? > > > > We have a test suite. It does test a lot of the functionality, > > but no test suite is perfect. > > Is it run manually or automatically? How frequently? We're currently using things like travis, including on the stable braches, see: https://travis-ci.org/openssl/openssl/branches (The 0.9.8 branch isn't really supported anymore, not sure if someone will bother fixing the targets that fail in that branch.) We've also had other people (Cisco) do it regularly but I'm not sure which branches are covered there. We also have things like coverity specially for the release branch. I'm not sure if other such tools get run on regular basis. > > > What rate of changes are we talking about? > > > > There have been about 300 commits so far this year in the > > OpenSSL_1_0_1-stable branch, so averging about 2 per day. > > Are any other distributions following the upstream branches directly? > From a quick look, Ubuntu Trusty (which is the LTS released after > Wheezy) still appears to contain 1.0.1f. I really have no idea, but I don't think so. Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Sat, Oct 31, 2015 at 02:22:04PM +, Adam D. Barratt wrote: > On Sat, 2015-10-31 at 00:02 +0100, Kurt Roeckx wrote: > > On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote: > > > On Tue, 20 Oct 2015, Don Armstrong wrote: > > > > If there's something specific that you'd like the CTTE to try to do > > > > beyond what I've just reported now, let me know. > > > > > > Let me know if you'd like the CTTE to do something beyond what I've > > > already done. > > > > I guess I would like to know what the options are. The way I see > > it: > > - The release team makes a decision > > - The release team asks someone else to make the decision > > - Someone makes a policy of what is acceptable, not the current > > situtation where there don't seem to be any rules. > > If one of those things happened and the resulting decision was that new > OpenSSL upstream releases don't get blanket exceptions, would that be > the end of this discussion? Yes. Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote: > On Tue, 20 Oct 2015, Don Armstrong wrote: > > If there's something specific that you'd like the CTTE to try to do > > beyond what I've just reported now, let me know. > > Let me know if you'd like the CTTE to do something beyond what I've > already done. I guess I would like to know what the options are. The way I see it: - The release team makes a decision - The release team asks someone else to make the decision - Someone makes a policy of what is acceptable, not the current situtation where there don't seem to be any rules. - The DPL removes that power from their delegation. (One can argue that the DPL didn't have the power to delegate that in the first place.) - Start a GR to overrule the DPL's delegate. And I guess I would like advise on how to proceed. Kurt
Bug#797926: transition: openssl: remove SSLv3 methods
On Wed, Sep 16, 2015 at 10:17:10PM +0100, Jonathan Wiltshire wrote: > On Wed, Sep 09, 2015 at 12:25:16PM +0200, Kurt Roeckx wrote: > > On Thu, Sep 03, 2015 at 10:36:33PM +0100, Jonathan Wiltshire wrote: > > > > So do I start with an soname change and upload that to > > > > experimental? > > > > > > Yes please. > > > > So that has passed the new queue now. Please let me know when I > > can start this in unstable. > > Looking at the tracker there are (as I suspected) quite a number of > collisions with the ongoing g++ work. We'll try and arrange a slot when > things are calmer. So any idea when you'll have time for this? Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Oct 20, 2015 at 09:57:04AM -0500, Don Armstrong wrote: > On Sat, 17 Oct 2015, Kurt Roeckx wrote: > > I've been waiting for the release team for a while to make a decision > > on #765639 for a year now. Could you help in getting a decision? > > > > I've actually been waiting for longer than that, I can't directly find > > all links, but previous discussions about it are at least: > > https://lists.debian.org/debian-devel/2013/09/msg00466.html > > https://lists.debian.org/debian-project/2013/12/msg00140.html > > Is there anything that it would be helpful for the technical committee > to do here to help facilitate coming to a decision on this? > > Specifically, this being (FWICT), bringing a new(er) version of openssl > into jessie and/or wheezy. > > I personally don't have enough information to form an opinion yet, but > I recognize that some decision should be made. So to clarify my point of view, I just want to have a decision on my issue. I understand that the release team is having a hard time making a decision, but I'm not sure why. So I guess my initial question is to try and understand why they don't make a decision. I also wonder if it would help them if they delegated the decision to the ctte. There might also be a need to clarify the policy for such updates. Kurt
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote: > On Tue, 20 Oct 2015, Don Armstrong wrote: > > On Sat, 17 Oct 2015, Kurt Roeckx wrote: > > > I've been waiting for the release team for a while to make a decision > > > on #765639 for a year now. Could you help in getting a decision? > > > > > > I've actually been waiting for longer than that, I can't directly find > > > all links, but previous discussions about it are at least: > > > https://lists.debian.org/debian-devel/2013/09/msg00466.html > > > https://lists.debian.org/debian-project/2013/12/msg00140.html > > > > Is there anything that it would be helpful for the technical committee > > to do here to help facilitate coming to a decision on this? > > From discussions (briefly) on IRC: > >my general thoughts offhand are that new upstream versions in > stable always make me twitchy, new upstream versions that > introduce features or are sensitive / important packages more > so, new upstream versions that do both doubly. and we try and > avoid ending up saying no to people, which often ends up > actually making things worse as they linger (and we're not > doing that well at keeping up with the "easy" requests right > now) So as already pointed out before, since the 1.0.0 release there is a new release strategy that in the 1.0.x series, where x doesn't change, no new features are added unless it's really needed for either security reasons or compatibility reasons. As far as I know between the version in oldstable (a patched 1.0.1e) and 1.0.1p only 1 feature got added, and people really have been asking for that one. OpenSSL upstream also already has a policy that at least 2 people from the team should review all the changes. Since there are so many changes I don't think it's reasonable for the release team to review all of them. The alternative is that I go and cherry pick the important bug fixes. By this time there are really a lot that I would like to have in the stable releases and I think going that way actually has a higher chance of breaking things. > So from what I'm gathering, this looks like a case where there isn't > enough eyeballs to adequately review this particularly set of updates, > coupled with the importance of making sure that these updates are > correct and don't cause any unintended issues. There is always the case that one persons bug is an other persons feature. But those new upstream versions have been in stable and testing for a while now without actually breaking anything. Kurt
Bug#802159: New OpenSSL upstream version
Package: tech-ctte Hi, I've been waiting for the release team for a while to make a decision on #765639 for a year now. Could you help in getting a decision? I've actually been waiting for longer than that, I can't directly find all links, but previous discussions about it are at least: https://lists.debian.org/debian-devel/2013/09/msg00466.html https://lists.debian.org/debian-project/2013/12/msg00140.html Kurt
Bug#765639: wheezy-pu: openssl new upstream version
On Fri, Aug 21, 2015 at 07:31:53PM +0200, Kurt Roeckx wrote: > On Sun, Jun 14, 2015 at 11:52:07AM +0200, Kurt Roeckx wrote: > > On Sun, Jun 14, 2015 at 12:22:52PM +1000, Julien Cristau wrote: > > > Is the policy for what gets included in the stable branches described > > > somewhere? > > > > It's documented at: > > https://www.openssl.org/about/releasestrat.html > > > > > What kind of automated or manual regression (or other) > > > testing is done on the stable branches? > > > > We have a test suite. It does test a lot of the functionality, > > but no test suite is perfect. > > > > > What rate of changes are we talking about? > > > > There have been about 300 commits so far this year in the > > OpenSSL_1_0_1-stable branch, so averging about 2 per day. > > So I'm still waiting for a reply to this. Today I had yet an other request to backport some of the changes that went into the stable releases. Someone please make a decision, so that I know I can either upload that, or annoy you with about 100 patches you get to review instead. Kurt
Bug#797926: transition: openssl: remove SSLv3 methods
On Thu, Sep 03, 2015 at 10:36:33PM +0100, Jonathan Wiltshire wrote: > > So do I start with an soname change and upload that to > > experimental? > > Yes please. So that has passed the new queue now. Please let me know when I can start this in unstable. Kurt
Bug#797926: transition: openssl: remove SSLv3 methods
Package: release.debian.org Hi, I would like to remove the last support for SSLv3 in openssl. This means that I'll be dropping 3 symbols from the shared library: SSLv3_method(); SSLv3_server_method(); SSLv3_client_method(); Those can still be used to set up SSLv3 connections, while using the SSLv23_* methods won't talk SSLv3. This change will result in the define OPENSSL_NO_SSL3_METHOD becoming defined. Some software in Debian already checks for either that define or the presence of the functions to enable support for it or not. I find those changes very unfortunate, they should just have dropped SSLv3 support completly. My question is how you want to proceed with this. I see a few options: - Change the soname, rebuild everything against that new soname. - Just drop the symbols, adding Breaks on at least some packages like curl and python that are known to need a rebuild against the changed headers. As far as I know all the major packages making use of those symbols should be fixed now, or have a fix available. Kurt
Bug#797926: transition: openssl: remove SSLv3 methods
On Thu, Sep 03, 2015 at 10:06:17PM +0200, Julien Cristau wrote: > On Thu, Sep 3, 2015 at 20:51:05 +0200, Kurt Roeckx wrote: > > > - Just drop the symbols, adding Breaks on at least some > > packages like curl and python that are known to need a rebuild > > against the changed headers. > > > Definitely not. So do I start with an soname change and upload that to experimental? Kurt
Bug#765639: wheezy-pu: openssl new upstream version
On Sun, Jun 14, 2015 at 11:52:07AM +0200, Kurt Roeckx wrote: On Sun, Jun 14, 2015 at 12:22:52PM +1000, Julien Cristau wrote: Is the policy for what gets included in the stable branches described somewhere? It's documented at: https://www.openssl.org/about/releasestrat.html What kind of automated or manual regression (or other) testing is done on the stable branches? We have a test suite. It does test a lot of the functionality, but no test suite is perfect. What rate of changes are we talking about? There have been about 300 commits so far this year in the OpenSSL_1_0_1-stable branch, so averging about 2 per day. So I'm still waiting for a reply to this. Kurt
Bug#765639: wheezy-pu: openssl new upstream version
On Sun, Jun 14, 2015 at 12:22:52PM +1000, Julien Cristau wrote: Is the policy for what gets included in the stable branches described somewhere? It's documented at: https://www.openssl.org/about/releasestrat.html What kind of automated or manual regression (or other) testing is done on the stable branches? We have a test suite. It does test a lot of the functionality, but no test suite is perfect. What rate of changes are we talking about? There have been about 300 commits so far this year in the OpenSSL_1_0_1-stable branch, so averging about 2 per day. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150614095207.ga31...@roeckx.be
Bug#765639: wheezy-pu: openssl new upstream version
On Sat, Dec 27, 2014 at 06:05:49PM +0100, Kurt Roeckx wrote: On Thu, Oct 16, 2014 at 10:12:16PM +0200, Kurt Roeckx wrote: I would really like to upload new upstream openssl versions from the 1.0.1-stable branch to wheezy. Could someone please say something about this request? I'm still waiting for this, and have the same question for jessie now. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150611200154.ga26...@roeckx.be
Bug#780902: unblock: openssl/1.0.1k-2
On Sat, Mar 21, 2015 at 07:51:32PM +, Adam D. Barratt wrote: Control: tags -1 + d-i On Sat, 2015-03-21 at 10:40 +0100, Kurt Roeckx wrote: 1.0.1k-2 contains security fixes. Could you please unblock it? Unblocked but needs a d-i ack as usual. I've just make an upload of 1.0.1k-3 that reverts one of the commits that is known to cause issues. Please update the hint. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150324204859.ga12...@roeckx.be
Bug#780902: unblock: openssl/1.0.1k-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, 1.0.1k-2 contains security fixes. Could you please unblock it? Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150321094038.ga19...@roeckx.be
Re: bastardizing packages or stepping down
On Thu, Mar 05, 2015 at 01:38:29PM +0300, Michael Tokarev wrote: But once I uploaded a next release of busybox to the archive, it was rebuilt using older, unfixed glibc, and the original problem reappeared. I didn't see any request to make sure the chroots are updated. Not having read the whole thing, would this solve your problem? Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150306094626.ga32...@roeckx.be
Bug#777329: unblock: ntp/1:4.2.6.p5+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, ntp 1:4.2.6.p5+dfsg-5 has 2 security fixes. Can you please unblock it? Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150207131104.ga1...@roeckx.be
Bug#775025: unblock: openssl/1.0.1k-1
Hi, Can you ACK that, or is there someone else in the d-i team that can do that? Kurt On Wed, Jan 14, 2015 at 05:52:58PM +0100, Niels Thykier wrote: Control: tags -1 d-i On 2015-01-10 12:01, Kurt Roeckx wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I've uploaded a new upstream version of openssl to unstable. This contains fixes for 7 security issues affecting jessie. It also contains a lot of other bug fixes. Can you please unblock it? Kurt No problems from my PoV. CC'ing KiBi for d-i ACK. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b69eea.7020...@thykier.net -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150120121730.ga20...@roeckx.be
Bug#775025: unblock: openssl/1.0.1k-1
On Sat, Jan 10, 2015 at 12:01:33PM +0100, Kurt Roeckx wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I've uploaded a new upstream version of openssl to unstable. This contains fixes for 7 security issues affecting jessie. It also contains a lot of other bug fixes. Can you please unblock it? I'm still waiting for this. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015011308.ga32...@roeckx.be
Bug#775025: unblock: openssl/1.0.1k-1
On Wed, Jan 14, 2015 at 12:00:52AM +0100, Julien Cristau wrote: Kurt, On Tue, Jan 13, 2015 at 23:22:08 +0100, Kurt Roeckx wrote: On Sat, Jan 10, 2015 at 12:01:33PM +0100, Kurt Roeckx wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I've uploaded a new upstream version of openssl to unstable. This contains fixes for 7 security issues affecting jessie. It also contains a lot of other bug fixes. Can you please unblock it? I'm still waiting for this. The way to avoid waiting is to make sure your package complies with the freeze policy, i.e. only include RC bug fixes. This doesn't qualify, so it gets to wait until somebody has time to look at it. I guess it'll have to wait 6 months like all my requests. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150114000630.ga2...@roeckx.be
Bug#775025: unblock: openssl/1.0.1k-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I've uploaded a new upstream version of openssl to unstable. This contains fixes for 7 security issues affecting jessie. It also contains a lot of other bug fixes. Can you please unblock it? Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150110110133.ga4...@roeckx.be
Bug#774299: wheezy-pu: openssl: disable SSLv3 by default
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I would like to disable SSLv3 by default in wheezy. Attached is a
debdiff.
Kurt
diff -Nru openssl-1.0.1e/debian/changelog openssl-1.0.1e/debian/changelog
--- openssl-1.0.1e/debian/changelog 2014-10-15 19:45:48.0 +0200
+++ openssl-1.0.1e/debian/changelog 2014-12-31 13:46:02.0 +0100
@@ -1,3 +1,15 @@
+openssl (1.0.1e-2+deb7u14) wheezy-security; urgency=medium
+
+ * Disable SSLv3 by default. It can be enabled again by calling
+SSL_CTX_clear_options() or SSL_clear_options() with SSL_OP_NO_SSLv3.
+It can also be enabled again by setting OPENSSL_ALLOW_SSLv3 in the
+environment to anything.
+This fixes the POODLE issue (CVE-2014-3566).
+ * Fix CVE-2014-3569. We're not affected by it since we don't build with
+the no-ssl3 option (yet).
+
+ -- Kurt Roeckx k...@roeckx.be Wed, 31 Dec 2014 13:45:07 +0100
+
openssl (1.0.1e-2+deb7u13) wheezy-security; urgency=medium
* Fixes CVE-2014-3513
diff -Nru openssl-1.0.1e/debian/patches/disable_sslv3.patch openssl-1.0.1e/debian/patches/disable_sslv3.patch
--- openssl-1.0.1e/debian/patches/disable_sslv3.patch 1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1e/debian/patches/disable_sslv3.patch 2014-12-31 13:41:07.0 +0100
@@ -0,0 +1,14 @@
+diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
+index d09bb7d..bc3cbc7 100644
+--- a/ssl/ssl_lib.c
b/ssl/ssl_lib.c
+@@ -2060,6 +2060,9 @@ SSL_CTX *SSL_CTX_new(const SSL_METHOD *meth)
+ */
+ ret-options |= SSL_OP_LEGACY_SERVER_CONNECT;
+
++ if (getenv(OPENSSL_ALLOW_SSLv3) == NULL)
++ ret-options |= SSL_OP_NO_SSLv3;
++
+ return(ret);
+ err:
+ SSLerr(SSL_F_SSL_CTX_NEW,ERR_R_MALLOC_FAILURE);
diff -Nru openssl-1.0.1e/debian/patches/Keep-old-method-in-case-of-an-unsupported-protocol.patch openssl-1.0.1e/debian/patches/Keep-old-method-in-case-of-an-unsupported-protocol.patch
--- openssl-1.0.1e/debian/patches/Keep-old-method-in-case-of-an-unsupported-protocol.patch 1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1e/debian/patches/Keep-old-method-in-case-of-an-unsupported-protocol.patch 2014-12-31 13:44:16.0 +0100
@@ -0,0 +1,44 @@
+From 392fa7a952e97d82eac6958c81ed1e256e6b8ca5 Mon Sep 17 00:00:00 2001
+From: Kurt Roeckx k...@roeckx.be
+Date: Tue, 21 Oct 2014 20:45:15 +0200
+Subject: [PATCH] Keep old method in case of an unsupported protocol
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When we're configured with no-ssl3 and we receive an SSL v3 Client Hello, we set
+the method to NULL. We didn't used to do that, and it breaks things. This is a
+regression introduced in 62f45cc27d07187b59551e4fad3db4e52ea73f2c. Keep the old
+method since the code is not able to deal with a NULL method at this time.
+
+CVE-2014-3569, PR#3571
+
+Reviewed-by: Emilia Käsper emi...@openssl.org
+---
+ ssl/s23_srvr.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/ssl/s23_srvr.c b/ssl/s23_srvr.c
+index 38960ba..858420d 100644
+--- a/ssl/s23_srvr.c
b/ssl/s23_srvr.c
+@@ -615,12 +615,14 @@ int ssl23_get_client_hello(SSL *s)
+ if ((type == 2) || (type == 3))
+ {
+ /* we have SSLv3/TLSv1 (type 2: SSL2 style, type 3: SSL3/TLS style) */
+-s-method = ssl23_get_server_method(s-version);
+- if (s-method == NULL)
++ const SSL_METHOD *new_method;
++ new_method = ssl23_get_server_method(s-version);
++ if (new_method == NULL)
+ {
+ SSLerr(SSL_F_SSL23_GET_CLIENT_HELLO,SSL_R_UNSUPPORTED_PROTOCOL);
+ goto err;
+ }
++ s-method = new_method;
+
+ if (!ssl_init_wbio_buffer(s,1)) goto err;
+
+--
+2.1.4
+
diff -Nru openssl-1.0.1e/debian/patches/series openssl-1.0.1e/debian/patches/series
--- openssl-1.0.1e/debian/patches/series 2014-10-15 19:30:33.0 +0200
+++ openssl-1.0.1e/debian/patches/series 2014-12-31 13:45:00.0 +0100
@@ -72,4 +72,5 @@
Fix-for-SRTP-Memory-Leak.patch
Fix-for-session-tickets-memory-leak.patch
Fix-no-ssl3-configuration-option.patch
-
+disable_sslv3.patch
+Keep-old-method-in-case-of-an-unsupported-protocol.patch
Bug#774299: wheezy-pu: openssl: disable SSLv3 by default
On Wed, Dec 31, 2014 at 02:00:23PM +, Adam D. Barratt wrote: Control: tags -1 + moreinfo On Wed, 2014-12-31 at 13:52 +0100, Kurt Roeckx wrote: I would like to disable SSLv3 by default in wheezy. Do we know how well other packages in wheezy cope with that? (I'm going to guess not as well as in jessie.) I have no reason to believe there is a difference between jessie and wheezy in how packages cope with SSLv3 being disabled. Please note that this only affects the SSLv23_* methods and that it just sets SSL_OP_NO_SSLv3 by default now. In jessie SSLv3 is just disabled, for wheezy I would change it to disabled by default with a way to turn it back on. What could break is that apache for instance will now disable SSLv3 by default even though the config file doesn't seem to indicate that it's disabled. That could then result in it not working with some clients that do not support TLSv1 or newer. But that is also already the case in jessie. One package that might be affected by this change is that python has a test suite that tries all possible combinations of settings and the test suite is probably going to fail because it's going to expect to be able to set up an SSLv3 connection. Attached is a debdiff. +openssl (1.0.1e-2+deb7u14) wheezy-security; urgency=medium That's at least confusing. Right, I should probably change that to wheezy instead. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141231154129.ga18...@roeckx.be
Bug#765639: wheezy-pu: openssl new upstream version
On Thu, Oct 16, 2014 at 10:12:16PM +0200, Kurt Roeckx wrote: I would really like to upload new upstream openssl versions from the 1.0.1-stable branch to wheezy. Could someone please say something about this request? Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141227170549.ga19...@roeckx.be
Bug#772487: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote: Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() This has no effect in jessie. SSLv2 and SSLv3 are disabled if you use the SSLv23_* methods. The only way to enable SSLv3 is to use the SSLv3_* methods. You should always use the SSLv23 method as those are the only that support more than 1 protocol version. I would love to see people stopping the SSLv3 methods, and they have been removed in experimental. I'm also working on only having the SSLv23 method available. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208101220.ga13...@roeckx.be
Bug#772487: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 11:42:28AM +0100, Daniel Pocock wrote: On 08/12/14 11:12, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote: Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() This has no effect in jessie. SSLv2 and SSLv3 are disabled if you use the SSLv23_* methods. The only way to enable SSLv3 is to use the SSLv3_* methods. You should always use the SSLv23 method as those are the only that support more than 1 protocol version. Can you please clarify that - if somebody explicitly calls SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support for SSLv3 in SSLv23_method? No, the library doesn't support SSLv3 in combination with the SSLv23 method. Setting or clearing SSL_OP_NO_SSLv3 doesn't have any effect. I would love to see people stopping the SSLv3 methods, and they have been removed in experimental. I'm also working on only having the SSLv23 method available. In VoIP, this is not so trivial. People have devices like IP phones and ISDN gateways to use on their LAN. Some of the older ones may not support anything more than SSL v3 very well. If these devices are used on a private VLAN then the risk of using old crypto is not the same as the risk on the public Internet so I prefer to give these people config options to support their hardware but disabled by default. So why use SSL at all? Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? I would expect that both should support that. There is an example of it here: https://issues.asterisk.org/jira/browse/ASTERISK-13845 and it looks something like this: Secure Sockets Layer SSLv2 Record Layer: Client Hello ... Version: TLS 1.0 (0x0301) ... I've noticed that the reSIProcate code using TLSv1_method refuses to accept connections from peers like that. Should SSLv23_method support that even with v2 and v3 disabled? Yes it should. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208113655.ga25...@roeckx.be
Bug#772487: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote: Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? I would expect that both should support that. With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 So I start an s_server with: openssl s_server -tls1 And then: openssl s_client: TLSv1 openssl s_client -tls1: TLSv1 I tried the s_server and s_client on both jessie and wheezy. This should just work. If both sides drop the -tls1 of course changes to TLSv1.2. But it really should always work, and if doesn't I'd argue that's a bug. But you say that it sends an SSLv2 compatible client hello. By default it shouldn't be doing that unless you change the ciphers suite to include SSLv2 ciphers and aren't using any extentions, and as far as I know you currently can't disable extentions in either wheez or jessie. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208125312.gc11...@roeckx.be
Bug#772487: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 02:35:00PM +0100, Daniel Pocock wrote: I have no idea what technology is in use in the remote/client system. If my server socket is using TLSv1_method it is rejecting the connection and logging those errors on my server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 My server then sends TCP RST to the client So I can actually reproduce this with the s_client from squeeze, since that still generates an SSLv2 compatible client hello. That does fail talking to any server using the TLSv1 method but works talking to the SSLv23 method. Since I'm actually going to remove support for the TLSv1 method I don't intend to fix this. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208175834.ga11...@roeckx.be
Bug#772487: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 07:22:33PM +0100, Daniel Pocock wrote: Will the TLSv1 method be removed in jessie or while jessie is still supported? This is something post jessie. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208182501.ga3...@roeckx.be
