Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

On 2018-05-26 23:35:46 [+0200], To sub...@bugs.debian.org wrote:
> The Error in the testsuite could be due to:
> 1.1.1~~pre6-1 changelog):
> |   * Increase default security level from 1 to 2. This moves from the 80 bit
> | security level to the 112 bit securit level and will require 2048 bit 
> RSA
> | and DHE keys.

No, it is not. It is a TLS1.3 issue. If I limit max protocol to TLS1.2
then the testsuite passes. The problem with TLS1.3 could be that
SSL_read() could return SSL_ERROR_WANT_READ asking to do the same. Was
there a workaround for this or do I mix up things?
Anyway, it seems that SSL_connect() returns SSL_ERROR_WANT_READ.

Sebastian

Bug#912864: [Pkg-openssl-devel] Bug#912864: Bug#912864: openssl: new version of openssl breaks some openvpn clients

[Sebastian Andrzej Siewior]

On 2018-11-04 11:39:59 [-0800], James Bottomley wrote:
> > > OK, so I'm weary of trying to construct a theory of what the bug
> > > actually is, why don't you try to come up with one.  The symptoms
> > > are
> > > that openvpn in openwrt works with server 1.1.0 and fails with
> > > server
> > > 1.1.1 if you don't specify tls-version-min 1.0 on the command line.
> > 
> > On which side do you use tls-version-min?
> 
> client
> 
> >  Can you please give the version of both openvpn and openssl on both
> > sides.
> 
> Client is openwrt, server is debian testing.  The package of the server
> was already provided in the bug report, but again it's
> 
> openssl 1.1.1-2
> openvpn 2.4.6-1
> 
> Packages on the openwrt client are
> 
> libopenssl 1.0.2g-1
> openvpn-openssl  2.3.6-5

That matches what I see. The Jessie version (which matches your openwrt
client) does TLSv1.0 only by default. If you specify tls-version-min
(even 1.0) then it tries 1.0+ and does the best possible protocol which
is TLS1.2 in my case.
Stretch seems to do the best possible version by default.
Buster/Testing has TLS1.0 disabled by default.
So in your environment the client tries TLS1.0 only and server does
TLS1.2 only. Adding tls-version-min on the client side enables
TLS1.0+ and handshakes with TLS1.2.

This behaviour has been reported as #912650 on the Debian side.

> James

Sebastian

Bug#912737: [Pkg-openssl-devel] Bug#912737: Bug#912737: openssl: SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed

[Sebastian Andrzej Siewior]

On 2018-11-04 15:10:42 [+0100], Julien Lecomte wrote:
> Hello
Hi,

> Thanks to your remark I tried connecting my computer directly to the set-top
> box.
> 
> Connected directly, the file downloads fine (verified via md5sum).
> Connected indirectly, the download shows the issues I encountered.
> 
> The "indirect" route is desktop <-> ubiquiti unifi switch <-> ubiquiti unifi
> security gateway <-> set-top box.
> 
> I'll move the issue directly to ubiquiti to figure out what is going wrong.

Okay. Could you please try
openssl s_client -connect download.lenovo.com:443

and check if you see the same ciphers & certificate with and without the
ubiquiti HW in between?

> Thanks
> Julien

Sebastian

Bug#909545: python-boto: diff for NMU version 2.44.0-1.1

[Sebastian Andrzej Siewior]

Control: tags 909545 + patch
Control: tags 909545 + pending


Dear maintainer,

I've prepared an NMU for python-boto (versioned as 2.44.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
Sebastian
diff -u python-boto-2.44.0/debian/changelog python-boto-2.44.0/debian/changelog
--- python-boto-2.44.0/debian/changelog
+++ python-boto-2.44.0/debian/changelog
@@ -1,3 +1,10 @@
+python-boto (2.44.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add SNI support. Thanks to Witold Baryluk for testing (Closes: #909545).
+
+ -- Sebastian Andrzej Siewior   Sun, 04 Nov 2018 12:37:23 +0100
+
 python-boto (2.44.0-1) unstable; urgency=medium
 
   * New upstream release.
only in patch2:
unchanged:
--- python-boto-2.44.0.orig/boto/connection.py
+++ python-boto-2.44.0/boto/connection.py
@@ -821,23 +821,24 @@
 h = http_client.HTTPConnection(host)
 
 if self.https_validate_certificates and HAVE_HTTPS_CONNECTION:
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+
 msg = "wrapping ssl socket for proxied connection; "
 if self.ca_certificates_file:
 msg += "CA certificate file=%s" % self.ca_certificates_file
+context.load_verify_locations(cafile=self.ca_certificates_file)
 else:
 msg += "using system provided SSL certs"
+context.load_default_certs()
 boto.log.debug(msg)
 key_file = self.http_connection_kwargs.get('key_file', None)
 cert_file = self.http_connection_kwargs.get('cert_file', None)
-sslSock = ssl.wrap_socket(sock, keyfile=key_file,
-  certfile=cert_file,
-  cert_reqs=ssl.CERT_REQUIRED,
-  ca_certs=self.ca_certificates_file)
-cert = sslSock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not https_connection.ValidateCertificateHostname(cert, hostname):
-raise https_connection.InvalidCertificateException(
-hostname, cert, 'hostname mismatch')
+if key_file:
+context.load_cert_chain(certfile=cert_file, keyfile=key_file)
+
+sslSock = context.wrap_socket(sock, server_hostname=host)
 else:
 # Fallback for old Python without ssl.wrap_socket
 if hasattr(http_client, 'ssl'):
only in patch2:
unchanged:
--- python-boto-2.44.0.orig/boto/https_connection.py
+++ python-boto-2.44.0/boto/https_connection.py
@@ -119,20 +119,20 @@
 sock = socket.create_connection((self.host, self.port), self.timeout)
 else:
 sock = socket.create_connection((self.host, self.port))
+
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+if self.key_file:
+context.load_cert_chain(certfile=self.cert_file, keyfile=self.key_file)
+
 msg = "wrapping ssl socket; "
 if self.ca_certs:
 msg += "CA certificate file=%s" % self.ca_certs
+context.load_verify_locations(cafile=self.ca_certs)
 else:
 msg += "using system provided SSL certs"
+context.load_default_certs()
 boto.log.debug(msg)
-self.sock = ssl.wrap_socket(sock, keyfile=self.key_file,
-certfile=self.cert_file,
-cert_reqs=ssl.CERT_REQUIRED,
-ca_certs=self.ca_certs)
-cert = self.sock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not ValidateCertificateHostname(cert, hostname):
-raise InvalidCertificateException(hostname,
-  cert,
-  'remote hostname "%s" does not match '
-  'certificate' % hostname)
+
+self.sock = context.wrap_socket(sock, server_hostname=self.host)
only in patch2:
unchanged:
--- python-boto-2.44.0.orig/debian/patches-for-reference/boto-try-to-add-SNI-support-v2.patch
+++ python-boto-2.44.0/debian/patches-for-reference/boto-try-to-add-SNI-support-v2.patch
@@ -0,0 +1,92 @@
+From: Sebastian Andrzej Siewior 
+Date: Sat, 29 Sep 2018 21:47:11 +0200
+Subject: [PATCH] boto: try to add SNI support
+
+Add SNI support. Newer OpenSSL (with TLS1.3) fail to connect if the
+hostname is missing.
+
+Link: https://bugs.debian.org/909545
+Tested-by: Witold Baryluk 
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ boto/connection.py   | 19 ++-
+ boto/https_connection.py | 22 +++---
+ 2 files changed, 21 in

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Sebastian Andrzej Siewior]

On 2018-11-01 19:50:35 [-0400], Theodore Y. Ts'o wrote:
> On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> > Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> > bare metal with nothing fancy I have:
> > [3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
> > [   10.363377] r8169 :05:00.0 eth0: link up
> > [   41.966375] random: crng init done
> > 
> > which means I have to wait about half a minute until I can ssh into. And
> > there is no way to speed it up?
> 
> So that surprises me.  Can you tell me more about the hardware?  Is it
> something like a Rasberry Pi?  Or is it an x86 server or desktop?  In
> my experience for most x86 platforms this isn't an issue.

another boot on the same box:
|  dmesg |grep -i random
| [0.00] random: get_random_bytes called from start_kernel+0x94/0x52e 
with crng_init=0
| [1.774332] random: fast init done
| [7.318640] random: systemd: uninitialized urandom read (16 bytes read)
| [7.318925] random: systemd: uninitialized urandom read (16 bytes read)
| [7.338074] random: systemd: uninitialized urandom read (16 bytes read)
| [   68.791389] random: crng init done
| [   68.791397] random: 7 urandom warning(s) missed due to ratelimiting

This is a headless i7-Sandy Bridge. A small rootfs partition and there
are hardly any daemons comming up. It waits for a remote login. Running
Debian unstable (incl. kernel).

> The main reason why I've talked about VM system is because this is
> where it where most of the problems that people ahve reported to me.
Yes. Thanks for that. I have another box which I use as a desktop
machine (basically a terminal). It is older than the i7 but I unlock the
crypted root disk as part of the boot process and I assume that due to
this it initializes in less than 10secs. Same goes for my notebook.  But
the i7 has just two cables…

> So if I make a blanket recommendation, and it causes Debian to ship
> some kind of default that causes Debian users to be insecure, I'm
> going to be feel really bad.  This is why I'm very cautious about what
> I say.  If you want to do whatever you want on your own system, hey
> consulting adults can do whatever they want.  :-)

I have a few other headless boxes but those are newer and support
RDRAND. I assume that this makes a difference because otherwise I don't
see a difference (and they don't take long to init).

> > You did not oppose RNDADDTOENTCNT/RNDADDENTROPY but you wanted to make
> > it configureable and not default, correct?
> 
> I'd want to see a full design doc, or a git repository, or set of
> changes before I give it an unqualified endorsement, but there *are*
> configurations where such a thing would be sane.
> 
> That's the problem with security recommendations.  It's much like a
> lawyer giving legal advice.  They're very careful about doing that in
> an unstructured circumstances.  If it gets taken in the wrong way,
> they could be legally liable and people might blame/sue them.
> 
> And then on top of that, there are the political considerations.
> Suppose I told you, "just use RDRAND and be happy".  Some people who
> sure that RDRAND has been backdoored would claim that I'm in the
> pocket of the NSA and/or Intel.  That's why all I'm going to say is,
> "I'm comfortable turning RDRAND on my own systems; you can do what you
> want."

Okay, okay. Let sum that up:
- openssh uses openssl's random number generator which now uses
  getrandom().
- getrandom() blocks until the random pool is initializes. Can be
  checked in dmesg:
  [  TIME.STAMP] random: crng init done
  This wasn't the case earlier where /dev/urandom was used.
- random entropy like interrupts or HW random support ( chaos
  key) will speed the initalisation process up.
- emulated hardware / KVM can take long to init but it helps if a hw-rnd
  device is added as part of qemu setup.
- it is possible to manually increase the entropy count and/or tell the
  random pool to init asap but it shouldn't be done because it will
  probably lead to weak random pool and probably used in wrong setups.

> Cheers,
> 
>   - Ted
> 
> P.S…
> I
> certainly would recommend that you spend the $40 USD to get a Chaos
> Key and just be *done* with it.

I do own a Nitrokey which can create random. That is not the problem. I
just have one devel box which requires me to wait a minute before I can
login and I have to figure out how to deal with it.

Sebastian

Bug#912634: [Pkg-clamav-devel] Bug#912634: clamav scanner didn't unpack RAR archives

[Sebastian Andrzej Siewior]

On 2018-11-02 08:11:49 [+0700], Dmitriy wrote:
> I've some problems with scanning RAR archives in emails. Clamav daemon in
> debug mode don't show any info about

do you have libclamunrar7 installed?

Sebastian

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Sebastian Andrzej Siewior]

On 2018-10-31 18:41:06 [-0400], Theodore Y. Ts'o wrote:
> On Wed, Oct 31, 2018 at 11:21:59AM +0000, Sebastian Andrzej Siewior wrote:
> > On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o"  
> > wrote:
> > >
> > >So it's complicated.  It's not a binary trusted/untrusted sort of
> > >thing.  
> > 
> > What about RNDRESEEDCRNG? Would it be reasonable to issue it after writing 
> > the seed as part of the boot process?
> 
> No, that's for debugging purposes only.

Okay. I'm asking because it has been added to the kernel, marked stable
and the man page has not been updated. So it did not look like a
debugging interface :)

> When there is sufficient entropy added (either through a hw_random
> subsystem, or because RDRAND is trusted, or the RNDADDENTORPY ioctl),
> the crng is automatically reseeded by credit_entropy_bits().  So it's
> not needed to use RNDRESEEDCRNG.

Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
bare metal with nothing fancy I have:
[3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
[   10.363377] r8169 :05:00.0 eth0: link up
[   41.966375] random: crng init done

which means I have to wait about half a minute until I can ssh into. And
there is no way to speed it up?
You did not oppose RNDADDTOENTCNT/RNDADDENTROPY but you wanted to make
it configureable and not default, correct?

> 
>   - Ted

Sebastian

Bug#912604: [Pkg-openssl-devel] Bug#912604: libssl1.1: libssl version 1.1.1 breaks burp backup buster clients with stretch server

[Sebastian Andrzej Siewior]

control: reassign -1 src:burp 

On 2018-11-01 18:56:30 [+0100], Antoine Sirinelli wrote:
> I have a setup with a burp backup server running with an up to date
> stretch distribution. The backup clients are running on either stretch
> or buster workstation. Since the recent update of libssl1.1 from version
> 1.1.0h-4 to 1.1.1-1 for the buster clients, the backups are now failing.
> 
> This can be easily debugged with openssl, the error is:
> 
> Verify return code: 68 (CA signature digest algorithm too weak)
> 
> It seems it is linked to the fact that libssl is now selecting the
> algorithm SHA512 instead of SHA256 for signing the digest. I have
> attached the detailed logs of the openssl s_client output.

nope:

|$ openssl x509 -in 912604.cert -text | grep Signature
|Signature Algorithm: sha1WithRSAEncryption
|Signature Algorithm: sha1WithRSAEncryption

The point is that your server certificate is signed with SHA1 while
the minimum is SHA256. Please note that all publicly issued certificates
are signed with SHA256 these days.

I would suggest a *note* in burp to notify users of burp which created
self-signed certificates with pre-Buster machines that they might need
to recreate their certificate if it is sigend with SHA1. Thus
resssigning to burp.
I just tried the Buster version of burp and myClient.crt, myServer.crt
and CA_myCA.crt is signed with SHA256. I would assume that the script
does not set the signing method and the default is used which changed.

> This can be solved by degrading the cipher requirements in
> /etc/ssl/openssl.cnf:
> 
> -CipherString = DEFAULT@SECLEVEL=2
> +CipherString = DEFAULT@SECLEVEL=1
> 
> This new version is therefore including an incompatibility between
> stretch and buster.

libssl1.1's news file worte a note and suggested to notify the remote
side instead of switching the defaults. This affects only users which
used self-signed certificates.

> Antoine

Sebastian

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Sebastian Andrzej Siewior]

On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o"  wrote:
>
>So it's complicated.  It's not a binary trusted/untrusted sort of
>thing.  

What about RNDRESEEDCRNG? Would it be reasonable to issue it after writing the 
seed as part of the boot process?

>Cheers,
>
>   - Ted


-- 
Sebastian

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Sebastian Andrzej Siewior]

On 2018-10-29 23:33:34 [+0100], Kurt Roeckx wrote:
> On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> > > So I believe this is not an openssl issue, but something in the
> > > order that the kernel's RNG is initialized and openssh is started.
> > > Potentionally the RNG isn't initialized at all and you actually
> > > have to wait for the kernel to get it's random data from the slow
> > > way.
> > > 
> > > So I'm reassigning this to systemd and openssh-server, I have no
> > > idea where the problem really is.
> > 
> > I see it, too. So during boot someone invokes "sshd -t" which invokes
> 
> That's:
> ExecStartPre=/usr/sbin/sshd -t
> 
> > getrandom(, 32, 0)
> > and this blocks.
> 
> And did systemd-random-seed.service get run before that?

Yes, but it does not matter from what I can see in the code. On my
system this writes 512 to /dev/urandom at timestamp 11.670639. But sshd
does this:

  sshd-2638  [004] ...22.445819: __x64_sys_getrandom: 1| 32 0
sshd asks for 32 bytes (flags = 0)

  sshd-2638  [004] ...22.445824: __x64_sys_getrandom: 2
-> crng_ready() is not true so we wait_for_random_bytes()

  sshd-3164  [004] ...   117.577454: __x64_sys_getrandom: 3
-> "crng init done", sshd's getrandom() resumed.

The problem is that the entropy is added but the entropy count is not
increased. So we wait.

Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
/dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
the entropy count after it was written. Those two are documented in
random(4). Or RNDRESEEDCRNG could be used to force crng to be reseeded.
It does also the job, too.

Ted, is there any best practise what to do with the seed which as
extrected from /dev/urandom on system shutdown? Using RNDADDTOENTCNT to
speed up init or just write to back to urandom and issue RNDRESEEDCRNG?

> Kurt

Sebastian

Bug#912087: [Pkg-openssl-devel] Bug#912087: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Sebastian Andrzej Siewior]

On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> So I believe this is not an openssl issue, but something in the
> order that the kernel's RNG is initialized and openssh is started.
> Potentionally the RNG isn't initialized at all and you actually
> have to wait for the kernel to get it's random data from the slow
> way.
> 
> So I'm reassigning this to systemd and openssh-server, I have no
> idea where the problem really is.

I see it, too. So during boot someone invokes "sshd -t" which invokes
getrandom(, 32, 0)
and this blocks. I get a login prompt and everything but sshd is started
"late" due to this.

> Kurt

Sebastian

Bug#858938: fixed in kopete 4:18.04.1-1

[Sebastian Andrzej Siewior]

On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > > > Source: kopete
> > > > Source-Version: 4:18.04.1-1
> > > > 
> > > > We believe that the bug you reported is fixed in the latest version of
> > > > kopete, which is due to be installed in the Debian FTP archive.
> > > 
> > > Any plans to upload this to unstable?
> > 
> > There are just two packages left in testing which use openssl1.0. The
> > last kopete upload was in mid June. Is there anything blocking an upload
> > to unstable?
> 
> The other one just got fixed in unstable, so this will soon be the
> only package in testing still depending on libssl1.0.2.

kopete is the only package in testing still using libssl1.0.2. Could
someone please comment on this?

> Kurt

Sebastian

Bug#897882: Bug#859784: NMU for validns

[Sebastian Andrzej Siewior]

On 2018-10-27 18:36:12 [+0200], Christoph Biedl wrote:
> +--- a/ipseckey.c
>  b/ipseckey.c
> +@@ -111,8 +111,11 @@
> + default:
> + strcpy(gw, "??");
> + }
> ++#pragma GCC diagnostic push
> ++#pragma GCC diagnostic ignored "-Wformat-truncation"
> + snprintf(s, 1024, "( %d %d %d %s ... )",
> +  rr->precedence, rr->gateway_type, rr->algorithm, gw);
> ++#pragma GCC diagnostic pop

This looks odd. There has to be a better way of dealing with this than
just shutting off the warning so things compile again.

> diff -Nru validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch 
> validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch
> --- validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch  
> 1970-01-01 01:00:00.0 +0100
> +++ validns-0.8+git20160720/debian/patches/use-openssl-1.1.patch  
> 2018-10-27 18:13:35.0 +0200
> +--- a/dnskey.c
>  b/dnskey.c
> +@@ -154,6 +154,7 @@
> + unsigned int e_bytes;
> + unsigned char *pk;
> + int l;
> ++   BIGNUM *n, *e;
> + 
> + rsa = RSA_new();
> + if (!rsa)
> +@@ -174,11 +175,12 @@
> + if (l < e_bytes) /* public key is too short */
> + goto done;
> + 
> +-rsa->e = BN_bin2bn(pk, e_bytes, NULL);
> ++   e = BN_bin2bn(pk, e_bytes, NULL);

BN_bin2bn() and EVP_MD_CTX_new() which were introduced as part of this
patch may return NULL. Not a single instance in the patch checks the
return value. This is just sloppy.

> + pk += e_bytes;
> + l -= e_bytes;
> + 
> +-rsa->n = BN_bin2bn(pk, l, NULL);
> ++   n = BN_bin2bn(pk, l, NULL);
> ++   RSA_set0_key(rsa, n, e, NULL);
> + 
> + pkey = EVP_PKEY_new();
> + if (!pkey)
> +--- a/rrsig.c
>  b/rrsig.c
> +@@ -374,7 +374,7 @@
> + static pthread_mutex_t *lock_cs;
> + static long *lock_count;
> + 
> +-static unsigned long pthreads_thread_id(void)
> ++unsigned long pthreads_thread_id(void)

not only there is no need for this hunk IMHO the thread locking used
here is not required for openssl 1.1.0+.

> + {
> + unsigned long ret;
> + 

Sebastian

Bug#907631: [Pkg-openssl-devel] Bug#907631: Problème de connexion avec OpenSSL v1.1.1~~pre9-1 / connection problem with OpenSSL v1.1.1~~pre9-1

[Sebastian Andrzej Siewior]

On 2018-08-30 13:35:27 [+0200], David BERCOT wrote:
> With OpenSSL vv1.1.1~~pre9-1, I can't connect to my entreprise network (Wifi, 
> PEAP\MSCHAPv2).
> 
> The connection attempt arrives at the Radius server but, obviously, the 
> exchange is "disturbed" and raises the following error:
> wlp60s0: deauthenticating from c0:62:6b:e4:c4:e1 by local choice (Reason: 
> 3=DEAUTH_LEAVING)
> 
> If I come back to OpenSSL v1.1.0h-4 (from testing), everything returns in 
> order.
> 
> So, I've added a pinning to keep the testing version of OpenSSL.

I'm sorry, this slipped my mind. Could you please try using `iwd'
instead of wpa_supplicant and reporting if this works or not?.

As a workaround with wpa_supplicant you could try
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912067#20

and please let the remote side know to update their radius server.

> David BERCOT.

Sebastian

Bug#912067: [Pkg-openssl-devel] Bug#912067: Bug#912067: libssl1.1: please add getmail/getmail4 to the dependencies to check

[Sebastian Andrzej Siewior]

On 2018-10-27 17:18:22 [-0400], ant wrote:
>   here is the message:
> 
> =
> getmail version 5.6
> Copyright (C) 1998-2012 Charles Cazabon.  Licensed under the GNU GPL version 
> 2.
> SimplePOP3SSLRetriever:a...@anthive.com@mail.anthive.com:995:
> rc-03ant: socket error ([SSL: UNSUPPORTED_PROTOCOL] unsupported protocol 
> (_ssl.c:726))
>   0 messages (0 bytes) retrieved, 0 skipped
> =

from https://www.htbridge.com/ssl/?id=0v7rEeNT
|The server's Diffie-Hellman parameter is too small.
|The server supports protocols that have known weaknesses and are considered 
unsafe.
|The server supports cipher suites that are not approved by PCI DSS 
requirements, NIST guidelines and HIPAA guidance.
|The TLS engine does not support newer version than TLSv1.0 and seems outdated.
|The server's certificate is untrusted.
|The server has TLS 1.0 enabled. Since the 30th of June 2018 it is 
non-compliant with PCI DSS 3.2.1.
|The server is vulnerable to POODLE over SSL.
…
|List of all SSL/TLS protocols supported by the server:
|
|SSLv3
|TLSv1.0
|DIFFIE-HELLMAN PARAMETER WEAK
|The Diffie-Hellman parameter's size is only 1024 bits . A longer one must be 
generated to prevent Logjam vulnerability.Non-compliant with PCI DSS 
requirements
|POODLE OVER SSL 
|The server is vulnerable to POODLE over SSL. SSLv3 should be 
disabled.Non-compliant with PCI DSS requirements

>   thanks for your response,
> 
> 
>   ant

Sebastian

Bug#911389: libssl1.1: loss of WLAN connectivity after upgrading; it's not the library's job to disable TLSv1.0

[Sebastian Andrzej Siewior]

On 2018-10-19 21:26:13 [+], Thorsten Glaser wrote:
> Ondřej Surý dixit:
> 
> >Your initial bug report was inappropriate.
> 
> No, it was not.

I think it was. I don't care much about the tone here others might. From
the technical point of view you used severity `grave' which is wrong
because it does not break it for everyone. It only breaks enterprise
setups where the remote site only supports a protocol version less than
TLSv1.2.

> >It is _absolutely_ job of the security library to set the system-wide
> >security policies.
> 
> It is absolutely *not* the job of the SSL *library* to *incompatibly*
> change the behaviour of *all* applications depending on it, even those
> that don’t have as high security requirements as javascript-HTTP combo,
> especially when those *other* programs don’t even expose the knobs to
> change the settings but the high security requirement ones *do*.

The policy was and is to disable protocols and ciphers in
unstable(+testing) if they turn out to be weak or are considered
insecure for a reason. This will happen via security (for current
(old-)+stable) for things that are considered very insecure.
To give you an example:
- SSLv2 + SSLv3 was disabled in stable (at the time) via security
  because it was determined that it is broken and must not be used
  anymore. While most applications worked fine (because they negotiated
  the latest possible protocol level) a few of them hardcoded to use
  SSLv2 or SSLv3. Those did not work until manual care/upload.
  Unstable lacked the SSLv2/v3 functions/macros and failed to compiled
  and required manual fixup. Not so stable. Should the radius server in
  question provide only SSLv3 or less then you would have the very same
  problem.

- RC4 and 3DES was disabled due to `sweet32' if I recall correctly. The
  severity here was not serious enough to propagate the change to the
  stable release (at that time). After the Debian stable release, which
  included this change, we received a few bug reports from people that
  were not able to connect to their mail server because the mail server
  supported only the RC4 and 3DES cipher.

In both cases it was the library's responsibility to ensure that sane
security is provided.

> >The Radius server in question needs to be fixed, not the OpenSSL options.
> 
> Did you even understand a single thing I wrote?
> 
> That particular RADIUS server might eventually be fixed,
> but one at a customer’s site would have caused massive issues.

The customer might need to be made aware that he runs old setup which
needs to be touched once every few years.

Now, on the productive site after that long letter. I intend to add an
entry to the NEWS file about this and close this bug with this change. I
think you suggested this somehwere in this bug report.  I will ping Kurt
to ack my wording because we don't want people blindly make those
changes.
Also, one thing you could try: Please try to use `iwd' instead of
wpasupplicant. It supports various enterprise configs so it should work
for you. As of now NetworkManager has an iwd backend and supports
"personal" networks but "enterprise" configuration is still on the work.
However providing the config file manually and using iwctl should work.
iwd is using in-kernel crypto and does not rely on any SSL library. Do
you mind testing it?

Sebastian

Bug#900158: python3.5: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

On 2018-10-26 16:13:35 [+0200], intrigeri wrote:
> Hi!
Hi,

> Given python3.5 was removed from testing, won't be shipped in Buster,
> and has no reverse dependencies left for release architectures (see
> #883630, situation today is almost entirely the same as since
> 3 months), I don't see any reason why this bug should be a blocker for
> #907015.

So do I. As far I see (saw) from the build log it only fails the
testsuite due to the key size restriction. If there is nothing else, I
don't see a reason why it should remain a blocker.

> Cheers,

Sebastian

Bug#911186: stretch-pu: package clamav/0.100.1+dfsg-0+deb9u1

[Sebastian Andrzej Siewior]

On 2018-10-20 10:42:06 [+0100], Adam D. Barratt wrote:
> On Wed, 2018-10-17 at 00:26 +0200, Sebastian Andrzej Siewior wrote:
> > clamav upstream published a new version which contains security
> > relevant bug fixes, one of them has CVE-2018-15378 assigned.
> 
> Is the expectation that this would be pushed via -updates?

Yes, please.

CVE-2018-15378

Vulnerability in ClamAV's MEW unpacking feature that could allow an
unauthenticated, remote attacker to cause a denial-of-service (DoS)
condition on an affected device.

> Regards,
> 
> Adam

Sebastian

Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

[Sebastian Andrzej Siewior]

On 2018-10-17 21:21:29 [+0200], Kurt Roeckx wrote:
> > - src:foolscap #898800: foolscap: FTBFS against openssl 1.1.1
> 
> I'm not sure if this is actually still a problem, there have been
> fixes on the python and openssl side for this. reproducible builds
> shows it as having problems trying to install the build
> dependencies for months.

added #911271 to the pile. Not sure if foolscape is usable in testing
due to #905253 (it depends on python-txtorcon).

> > - src:python-boto #909545: SSL CERTIFICATE_VERIFY_FAILED when using gs 
> > (Google Cloud Storage) backend
> 
> Patch is available.

does it make sense to NMU it?

> Kurt

Sebastian

Bug#911272: RM: python-txtorcon -- NBS; decruft

[Sebastian Andrzej Siewior]

Package: ftp.debian.org
Severity: normal

Hi,

The source package txtorcon no longer builds the binary package
python-txtorcon. The binary package is still in archive and was not
auto-decrufted. Removing the package breakds two other packages:

|bigeasy@coccia:~$ dak rm -Rnb python-txtorcon
|Will remove the following packages from unstable:
|
|python-txtorcon |   18.0.2-1 | all
|
|Maintainer: Debian Privacy Tools Maintainers 

|
|--- Reason ---
|
|--
|
|Checking reverse dependencies...
|# Broken Depends:
|ooniprobe/contrib: ooniprobe
|
|# Broken Build-Depends:
|foolscap: python-txtorcon
|ooniprobe/contrib: python-txtorcon (>= 0.14.2)
|
|Dependency problem found.

Both packages have a RC bug open:
- #909866 ooniprobe: (Build-) Depends on vanished package python-txtorcon
- #911271 foolscap: (Build) Depends on non existing python-txtorcon

python-txtorcon itself can't be installed in unstable anymore (#905253)
so I doubt it makes sense to wait until the two packages get fixed.
It seems that BTS things that #905253 is still open because the package
is in archive and piuparts tests with the old binary and fails. I think
this is the reason why the package can't migrate to testing. I don't
understand however why the package does not pop up in the cruft report.

Sebastian

Bug#911271: foolscap: (Build) Depends on non existing python-txtorcon

[Sebastian Andrzej Siewior]

Package: foolscap
Version: 0.13.1-1
Severity: serious

txtorcon does not build the Python2 variant (python-txtorcon) since its
last upload, only the python3 one (python3-txtorcon) remains.

As of now the package can't be built due to missing packages.

Sebastian

Bug#911186: stretch-pu: package clamav/0.100.1+dfsg-0+deb9u1

[Sebastian Andrzej Siewior]

 
if(sizelimit) {
diff -Nru clamav-0.100.1+dfsg/configure clamav-0.100.2+dfsg/configure
--- clamav-0.100.1+dfsg/configure   2018-06-27 21:12:10.0 +0200
+++ clamav-0.100.2+dfsg/configure   2018-09-19 21:29:07.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.100.1.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.100.2.
 #
 # Report bugs to <https://bugzilla.clamav.net/>.
 #
@@ -592,8 +592,8 @@
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.100.1'
-PACKAGE_STRING='ClamAV 0.100.1'
+PACKAGE_VERSION='0.100.2'
+PACKAGE_STRING='ClamAV 0.100.2'
 PACKAGE_BUGREPORT='https://bugzilla.clamav.net/'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -1533,7 +1533,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.100.1 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.100.2 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1604,7 +1604,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.100.1:";;
+ short | recursive ) echo "Configuration of ClamAV 0.100.2:";;
esac
   cat <<\_ACEOF
 
@@ -1825,7 +1825,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.100.1
+ClamAV configure 0.100.2
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2294,7 +2294,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.100.1, which was
+It was created by ClamAV $as_me 0.100.2, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -3480,7 +3480,7 @@
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.100.1'
+ VERSION='0.100.2'
 
 
 # Some tools Automake needs.
@@ -5221,7 +5221,7 @@
 
 
 
-VERSION="0.100.1"
+VERSION="0.100.2"
 
 LC_CURRENT=8
 LC_REVISION=1
@@ -25787,7 +25787,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.100.1, which was
+This file was extended by ClamAV $as_me 0.100.2, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -25854,7 +25854,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.100.1
+ClamAV config.status 0.100.2
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
@@ -28400,7 +28400,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.100.1, which was
+This file was extended by ClamAV $as_me 0.100.2, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -28467,7 +28467,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.100.1
+ClamAV config.status 0.100.2
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru clamav-0.100.1+dfsg/configure.ac clamav-0.100.2+dfsg/configure.ac
--- clamav-0.100.1+dfsg/configure.ac2018-06-27 21:12:10.0 +0200
+++ clamav-0.100.2+dfsg/configure.ac2018-09-19 21:29:07.0 +0200
@@ -20,7 +20,7 @@
 AC_PREREQ([2.59])
 dnl For a release change [devel] to the real version [0.xy]
 dnl also change VERSION below
-AC_INIT([ClamAV], [0.100.1], [https://bugzilla.clamav.net/], [clamav], 
[https://www.clamav.net/])
+AC_INIT([ClamAV], [0.100.2], [https://bugzilla.clamav.net/], [clamav], 
[https://www.clamav.net/])
 
 AH_BOTTOM([#include "platform.h"])
 dnl put configure auxiliary into config
diff -Nru clamav-0.100.1+dfsg/debian/changelog 
clamav-0.100.2+dfsg/debian/changelog
--- clamav-0.100.1+dfsg/debian/changelog    2018-07-21 13:13:59.00000 
+0200
+++ clamav-0.100.2+dfsg/debian/changelog2018-10-12 23:44:44.0 
+0200
@@ -1,3 +1,14 @@
+clamav (0.100.2+dfsg-0+deb9u1) stretch; urgency=medium
+
+  * Import new upstream
+- Bump symbol version due to new version.
+- CVE-2018-15378 (Closes: #910430).
+  * add NEWS.md and README.md from upstream

Bug#911101: nmu: kannel-sqlbox_0.7.2-5

[Sebastian Andrzej Siewior]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hi,

kannel-sqlbox was uploaded slightly after kannel 1.4.5-2. On most
architectures, kannel-sqlbox was built against newer kannel-dev
resulting in a dependency on libssl1.1. On a few architectures it was
built against the older kannel package and still depends on libssl1.0.2.
Please binNMU to correct this.

nmu kannel-sqlbox_0.7.2-5 . armel mipsel kfreebsd-i386 kfreebsd-amd64 . -m 
"rebuild against kannel-dev (>= 1.4.5-2)"

While at it, one could set additional B-D for kannel-sqlbox on x32.

dw  kannel-sqlbox_0.7.2-5 . x32 . -m 'kannel-dev (>= 1.4.5-2)'

Sebastian

Bug#904111: clamav-daemon causing deadlocks/blocking I/O

[Sebastian Andrzej Siewior]

On 2018-08-05 13:18:26 [+0200], To Marc Dequènes wrote:
> I didn't manage to reproduce it yet. My plan was to to gather enough

this is still the case.

> informations to reproduce it and forward it upstream.
> Is there anything wrong / different with my setup compared to your?
> Maybe different filesystem or something like that (if everything else is
> the same).

I uploaded 0.100.2 to unstable. I will attempt to upload it soon to
Stretch. They (upstream) disabled something related. Maybe it fixes
this, too.
-> https://bugzilla.clamav.net/show_bug.cgi?id=12048

I have no idea what to do here since I can't reproduce it.

Sebastian

Bug#909545: SSL CERTIFICATE_VERIFY_FAILED when using gs (Google Cloud Storage) backend.

[Sebastian Andrzej Siewior]

control: forwarded -1 https://github.com/boto/boto/pull/3836

On 2018-09-30 22:17:05 [+0200], Witold Baryluk wrote:
> Needed a small change to your patch:
> 
> Line 126 in boto/https_connection.py  in connect function needs to be
> protected by check::
> 
> 126 if self.key_file:
> 127 context.load_cert_chain(certfile=self.cert_file,
> keyfile=self.key_file)

Thank you. Attached the fixed version and forwarded upstream.

Sebastian
>From f5e7f6c98b46ff622f60a4661ffc9ce07216d109 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Sat, 29 Sep 2018 21:47:11 +0200
Subject: [PATCH] boto: try to add SNI support

Add SNI support. Newer OpenSSL (with TLS1.3) fail to connect if the
hostname is missing.

Link: https://bugs.debian.org/bug=909545
Tested-by: Witold Baryluk 
Signed-off-by: Sebastian Andrzej Siewior 
---
 boto/connection.py   | 19 ++-
 boto/https_connection.py | 22 +++---
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/boto/connection.py b/boto/connection.py
index 34b428f101df7..b4867a7657465 100644
--- a/boto/connection.py
+++ b/boto/connection.py
@@ -824,23 +824,24 @@ DEFAULT_CA_CERTS_FILE = os.path.join(os.path.dirname(os.path.abspath(boto.cacert
 h = http_client.HTTPConnection(host)
 
 if self.https_validate_certificates and HAVE_HTTPS_CONNECTION:
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+
 msg = "wrapping ssl socket for proxied connection; "
 if self.ca_certificates_file:
 msg += "CA certificate file=%s" % self.ca_certificates_file
+context.load_verify_locations(cafile=self.ca_certificates_file)
 else:
 msg += "using system provided SSL certs"
+context.load_default_certs()
 boto.log.debug(msg)
 key_file = self.http_connection_kwargs.get('key_file', None)
 cert_file = self.http_connection_kwargs.get('cert_file', None)
-sslSock = ssl.wrap_socket(sock, keyfile=key_file,
-  certfile=cert_file,
-  cert_reqs=ssl.CERT_REQUIRED,
-  ca_certs=self.ca_certificates_file)
-cert = sslSock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not https_connection.ValidateCertificateHostname(cert, hostname):
-raise https_connection.InvalidCertificateException(
-hostname, cert, 'hostname mismatch')
+if key_file:
+context.load_cert_chain(certfile=cert_file, keyfile=key_file)
+
+sslSock = context.wrap_socket(sock, server_hostname=host)
 else:
 # Fallback for old Python without ssl.wrap_socket
 if hasattr(http_client, 'ssl'):
diff --git a/boto/https_connection.py b/boto/https_connection.py
index ddc31a152292e..a5076f6f9b261 100644
--- a/boto/https_connection.py
+++ b/boto/https_connection.py
@@ -119,20 +119,20 @@ from boto.compat import six, http_client
 sock = socket.create_connection((self.host, self.port), self.timeout)
 else:
 sock = socket.create_connection((self.host, self.port))
+
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+if self.key_file:
+context.load_cert_chain(certfile=self.cert_file, keyfile=self.key_file)
+
 msg = "wrapping ssl socket; "
 if self.ca_certs:
 msg += "CA certificate file=%s" % self.ca_certs
+context.load_verify_locations(cafile=self.ca_certs)
 else:
 msg += "using system provided SSL certs"
+context.load_default_certs()
 boto.log.debug(msg)
-self.sock = ssl.wrap_socket(sock, keyfile=self.key_file,
-certfile=self.cert_file,
-cert_reqs=ssl.CERT_REQUIRED,
-ca_certs=self.ca_certs)
-cert = self.sock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not ValidateCertificateHostname(cert, hostname):
-raise InvalidCertificateException(hostname,
-  cert,
-  'remote hostname "%s" does not match '
-  'certificate' % hostname)
+
+self.sock = context.wrap_socket(sock, server_hostname=self.host)
-- 
2.19.0

Bug#909545: SSL CERTIFICATE_VERIFY_FAILED when using gs (Google Cloud Storage) backend.

[Sebastian Andrzej Siewior]

control: tags -1 patch

On 2018-09-25 03:04:49 [+0200], Witold Baryluk wrote:
> Now it takes few minutes on any command, and then errors out:
> Cleaning older backups
> Traceback (innermost last):
…
>  SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed 
> (_ssl.c:726)

It looks like missing SNI support.
Could you please try if the patch attached works? It is completly
untested it just looks like it might work…

Sebastian
>From 978e87c8f0dfb93c26814b5e5806d2f2332db164 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Sat, 29 Sep 2018 21:47:11 +0200
Subject: [PATCH] boto: try to add SNI support

Signed-off-by: Sebastian Andrzej Siewior 
---
 boto/connection.py|  18 +-
 boto/https_connection.py  |  21 ++---

diff --git a/boto/connection.py b/boto/connection.py
index 2fef44872ffa7..b86c0cdec58e1 100644
--- a/boto/connection.py
+++ b/boto/connection.py
@@ -821,23 +821,23 @@ DEFAULT_CA_CERTS_FILE = os.path.join(os.path.dirname(os.path.abspath(boto.cacert
 h = http_client.HTTPConnection(host)
 
 if self.https_validate_certificates and HAVE_HTTPS_CONNECTION:
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+
 msg = "wrapping ssl socket for proxied connection; "
 if self.ca_certificates_file:
 msg += "CA certificate file=%s" % self.ca_certificates_file
+context.load_verify_locations(cafile=self.ca_certificates_file)
 else:
 msg += "using system provided SSL certs"
+context.load_default_certs()
 boto.log.debug(msg)
 key_file = self.http_connection_kwargs.get('key_file', None)
 cert_file = self.http_connection_kwargs.get('cert_file', None)
-sslSock = ssl.wrap_socket(sock, keyfile=key_file,
-  certfile=cert_file,
-  cert_reqs=ssl.CERT_REQUIRED,
-  ca_certs=self.ca_certificates_file)
-cert = sslSock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not https_connection.ValidateCertificateHostname(cert, hostname):
-raise https_connection.InvalidCertificateException(
-hostname, cert, 'hostname mismatch')
+context.load_cert_chain(certfile=cert_file, keyfile=key_file)
+
+sslSock = context.wrap_socket(sock, server_hostname=host)
 else:
 # Fallback for old Python without ssl.wrap_socket
 if hasattr(http_client, 'ssl'):
diff --git a/boto/https_connection.py b/boto/https_connection.py
index ddc31a152292e..949956178cea0 100644
--- a/boto/https_connection.py
+++ b/boto/https_connection.py
@@ -119,20 +119,19 @@ from boto.compat import six, http_client
 sock = socket.create_connection((self.host, self.port), self.timeout)
 else:
 sock = socket.create_connection((self.host, self.port))
+
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+context.load_cert_chain(certfile=self.cert_file, keyfile=self.key_file)
+
 msg = "wrapping ssl socket; "
 if self.ca_certs:
 msg += "CA certificate file=%s" % self.ca_certs
+context.load_verify_locations(cafile=self.ca_certs)
 else:
 msg += "using system provided SSL certs"
+context.load_default_certs()
 boto.log.debug(msg)
-self.sock = ssl.wrap_socket(sock, keyfile=self.key_file,
-certfile=self.cert_file,
-cert_reqs=ssl.CERT_REQUIRED,
-ca_certs=self.ca_certs)
-cert = self.sock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not ValidateCertificateHostname(cert, hostname):
-raise InvalidCertificateException(hostname,
-  cert,
-  'remote hostname "%s" does not match '
-  'certificate' % hostname)
+
+self.sock = context.wrap_socket(sock, server_hostname=self.host)
-- 
2.19.0

Bug#907427: openssl 1.1.1 breaks ssl tests

[Sebastian Andrzej Siewior]

On 2018-08-27 22:52:06 [+0200], Sandro Knauß wrote:
> Source: qtbase-opensource-src, kimap
> Version: kimap/18.07.90-1
> Control: block 907015 by -1
> 
> When I built my KDE PIM packages locally I built against openssl 1.1.0h-4 and 
> I had no issues running the KIMAP tests.
> With openssl 1.1.1~~pre9-1 (experimental) the tests breaks. See [1] for more 
> examples.
> 
> You may want to merge with #907340 or #907340, as those are also failings 
> tests because of openssl 1.1.1.
> 
> hefee
> 
> [1] https://buildd.debian.org/status/package.php?p=kimap=experimental
> 
> [...]
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "Error 
> loading local certificate, error:140AB18F:SSL 
> routines:SSL_CTX_use_certificate:ee key too small"
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> QAbstractSocket::SocketError(21)
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "Unable 
> to init SSL Context: "
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> QAbstractSocket::SocketError(20)
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "The 
> remote host closed the connection"
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> QAbstractSocket::RemoteHostClosedError
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> org.kde.pim.kimap: Connection to server lost  0
> FAIL!  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> 'login->exec()' returned FALSE. ()
>Loc: [/<>/autotests/loginjobtest.cpp(250)]

Could you try to increase the keys used in the testsuite to atleast
2048bit? Then it should pass. If that is the case than please unblock
the bug.

Sebastian

Bug#907807: After upgrading to OpenSSL 1.1.1, many sites are unreachable

[Sebastian Andrzej Siewior]

On 2018-09-05 10:30:23 [-0400], Antoine Beaupré wrote:
> Control: block 907807 by 907015
> 
> On 2018-09-05 15:53:46, Vincent Bernat wrote:
> >  ❦  5 septembre 2018 09:30 -0400, Antoine Beaupré :
> >
> >> So I've forwarded the bug upstream to see if we can get a hint there. I
> >> originally thought this was a 1.1 transition problem, but as it turns
> >> out, linkchecker loads those sites fine in buster, which still has
> >> 1.1.0.
> >
> > It's 1.1.1 which comes with more strict checks on everything. I think
> > there is a metabug about this:
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907015
> 
> I see. So I guess this blocks that then, adding to the pile.

but why?

| - ones without SNI

huh. If linkchecker is lacking SNI support than please add this to
linkcheker. Once this is done, I can a versioned break to libssl.
Otherwise I don't understand.

| - ones with DH parameters too small
| - ones using TLS 1.0
| - ones still using SHA1 for the signature (get.adobe.com)

This is a limitation of the remote site. You can either get the remote
site fix it (TLS1.0 in 2018, srsly?) or override the default openssl
policy (please consider this as the last resort).

> A.

Sebastian

Bug#907118: error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small

[Sebastian Andrzej Siewior]

On 2018-08-29 11:38:54 [-0600], dann frazier wrote:
> > > error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small
> > > 
> > > I found that backporting bip 0.9.0~rc3-1 to jessie worked. I further found
> > > that just cherry-picking the following commit back to bip 0.8.9 seems to 
> > > be
> > > sufficient:
> > > 
> > >   39414f8 Handle OpenSSL version 1.1
> > 
> > I just tried backporting commit 39414f8 to the bip version in stretch,
> > and it doesn't really fix the issue. There is probably some other commit
> > that is needed.
> 
> I literally poked that patch into debian/patches{/series}, quilt
> applied it and rebuilt, and it started working for me. Maybe there's
> something different about our configs?

May I ask what is the problem here is? It looks like DH key is less than
1024bits in size. This is not per-se an openssl problem but "policy"
(which could be changed but I suggest to update the key instead).
If there is anything that needs to be fixed in bip in order to work
(like missing SNI) then I would add a versioned BREAK to #907015 (after
an upload so please let me know).
Otherwise I would unbreak this bug with #907015.

Sebastian

Bug#907788: "dh key too small" since openssl upgrade

[Sebastian Andrzej Siewior]

control: unblock 907015 by 907788

On 2018-09-02 09:59:11 [+0200], VA wrote:
> Since openssl upgrade to 1.1.1~~pre9-1, curl is not able anymore to do
> requests to some sites. For example:
> 
> % curl https://www.credit-cooperatif.coop/
> curl: (35) error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
> 
> It used to work with curl, and it still works with wget (which uses gnutls).
> 
> I suspect it's related to #907015.

I would close that if I were the curl maintainer. The remote site in the
example uses a small DH key [0]. If you can't get owner to upgrade the
site and want still to access the site I suggest to remove
CipherString = DEFAULT@SECLEVEL=2
from /etc/ssl/openssl.cnf.

[0] https://www.ssllabs.com/ssltest/analyze.html?d=www.credit-cooperatif.coop

Sebastian

Bug#907790: ruby2.5: FTBFS due to openssl 1.1.1: test suite times out

[Sebastian Andrzej Siewior]

On 2018-09-02 10:20:13 [+0200], Paul Gevers wrote:
> Dear ruby2.5 maintainers,
> 
> Recently openssl was updated to upstream version 1.1.1. There have been
> multiple changes to increase security. As a result, some packages
> started to time out during autopkgtest and/or building of the package.
> Your package is one of them and does both:
The autopkgtest was always broken. So lets take a look at the testsuite
against 1.1:

|  1) Error:
|Net::TestSMTP#test_eof_error_backtrace:
|Errno::EADDRINUSE: Address already in use - listen(2)
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `listen'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `block in 
tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `each'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:757:in `tcp_server_sockets'
|/srv/ruby2.5-2.5.1/test/net/smtp/test_smtp.rb:166:in 
`test_eof_error_backtrace'
|
|  2) Error:
|Net::TestSMTP#test_tls_connect:
|Errno::EADDRINUSE: Address already in use - listen(2)
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `listen'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `block in 
tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `each'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:757:in `tcp_server_sockets'
|/srv/ruby2.5-2.5.1/test/net/smtp/test_smtp.rb:107:in `test_tls_connect'
|
|  3) Error:
|Net::TestSMTP#test_tls_connect_timeout:
|Errno::EADDRINUSE: Address already in use - listen(2)
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `listen'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `block in 
tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `each'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:757:in `tcp_server_sockets'
|/srv/ruby2.5-2.5.1/test/net/smtp/test_smtp.rb:143:in 
`test_tls_connect_timeout'
|
|  4) Error:
|TestNetHTTPLocalBind#test_bind_to_local_host:
|Errno::EADDRINUSE: Address already in use - listen(2)
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `listen'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `block in 
tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `each'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:757:in `tcp_server_sockets'
|/srv/ruby2.5-2.5.1/lib/webrick/utils.rb:65:in `create_listeners'
|/srv/ruby2.5-2.5.1/lib/webrick/ssl.rb:165:in `listen'
|/srv/ruby2.5-2.5.1/lib/webrick/server.rb:108:in `initialize'
|/srv/ruby2.5-2.5.1/lib/webrick/httpserver.rb:47:in `initialize'
|/srv/ruby2.5-2.5.1/test/net/http/utils.rb:67:in `new'
|/srv/ruby2.5-2.5.1/test/net/http/utils.rb:67:in `spawn_server'
|/srv/ruby2.5-2.5.1/test/net/http/utils.rb:32:in `setup'
|
|  5) Error:
|TestNetHTTPLocalBind#test_bind_to_local_port:
|Errno::EADDRINUSE: Address already in use - listen(2)
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `listen'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:709:in `block in 
tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `each'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:708:in `tcp_server_sockets_port0'
|/srv/ruby2.5-2.5.1/.ext/common/socket.rb:757:in `tcp_server_sockets'
|/srv/ruby2.5-2.5.1/lib/webrick/utils.rb:65:in `create_listeners'
|/srv/ruby2.5-2.5.1/lib/webrick/ssl.rb:165:in `listen'
|/srv/ruby2.5-2.5.1/lib/webrick/server.rb:108:in `initialize'
|/srv/ruby2.5-2.5.1/lib/webrick/httpserver.rb:47:in `initialize'
|/srv/ruby2.5-2.5.1/test/net/http/utils.rb:67:in `new'
|/srv/ruby2.5-2.5.1/test/net/http/utils.rb:67:in `spawn_server'
|/srv/ruby2.5-2.5.1/test/net/http/utils.rb:32:in `setup'
|
|Finished tests in 258.296938s, 67.0778 tests/s, 8762.6320 assertions/s.
|17326 tests, 2263361 assertions, 0 failures, 5 errors, 59 skips
|
|ruby -v: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
|make: *** [uncommon.mk:698: yes-test-almost] Error 5

For some reason those five tests always fail here (with "already in
use"). Lets look at openssl 1.1.1 without the "key-too-small" contraint.
First TLS1.0 … TLS1.2:

|  1) Failure:
|OpenSSL::TestSSL#test_minmax_version 
[/srv/ruby2.5-2.5.1/test/openssl/utils.rb:280]:
|exceptions on 1 threads:
|#:
|/srv/ruby2.5-2.5.1/test/lib/minitest/unit.rb:201:in `assert': <"TLSv1.2"> 
expected but was
|<"TLSv1.3">. (MiniTest::Assertion)
|   from /srv/ruby2.5-2.5.1/test/lib/test/unit/assertions.rb:37:in `assert'
|   from /srv/ruby2.5-2.5.1/test/lib/test/unit/assertions.rb:300:in 
`assert_equal'
|   from /srv/ruby2.5-2.5.1/test/openssl/test_ssl.rb:982:in `block (3 
levels) in test_minmax_version'
|   from /srv/ruby2.5-2.5.1/test/openssl/test_ssl.rb:1538:in 

Bug#828475: openssh and OpenSSL 1.1

[Sebastian Andrzej Siewior]

On 2018-09-26 11:44:14 [+0100], Colin Watson wrote:
> 
> Upstream committed the necessary changes to switch to the 1.1 API
> earlier this month, so that should be in OpenSSH 7.9.  There's usually a
> release every few months, so I think we should be OK to just wait for
> that now.

okay, thanks for the update.

Sebastian

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-31 21:40:25 [+0200], To Emilio Pozuelo Monfort wrote:
> On 2018-07-28 10:11:47 [+0200], Emilio Pozuelo Monfort wrote:
> > We never break packages in testing (unless it's a critical situation, and 
> > this
> > obviously isn't). Also the cruft package in unstable doesn't hurt much, so 
> > it
> > can be left around for a while longer. What we want to do here is to get 
> > rid of
> > the old library in testing in order to finish the transition there: the 
> > only two
> > options for that are to remove scilab or to fix it. Given it's a key 
> > package and
> > probably has rdeps that'd mean the latter.
> 
> Okay. scilab received an upload an built properly. This was the only
> keypackage. We have four packages left, none of them is in testing. Can
> we close this transition now? :)

While four are still left (only) in unstable, one of them is fixed in
experimental.

> > Cheers,
> > Emilio

Sebastian

Bug#858938: fixed in kopete 4:18.04.1-1

[Sebastian Andrzej Siewior]

On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > Source: kopete
> > Source-Version: 4:18.04.1-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > kopete, which is due to be installed in the Debian FTP archive.
> 
> Any plans to upload this to unstable?

There are just two packages left in testing which use openssl1.0. The
last kopete upload was in mid June. Is there anything blocking an upload
to unstable?

> Kurt

Sebastian

Bug#828475: openssh and OpenSSL 1.1

[Sebastian Andrzej Siewior]

On 2018-07-28 07:56:58 [+0200], Kurt Roeckx wrote:
> Hi,
Hi,

> Any update on this?
...

> There are very few packages in testing that still use OpenSSL
> 1.0.2, and it looks like openssh is the only reason to keep it
> around.

we are down to two users in testing with one of them fixed in
experimental.

> Kurt

Sebastian

Bug#907079: Not using SNI

[Sebastian Andrzej Siewior]

control: tags -1 patch
https://github.com/jcristau/imaplib2/commit/a7ce7da1d573849ac2e1d740d8f3238e0ad8d88c

Sebastian

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Sebastian Andrzej Siewior]

On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote:
> Dmitry already implemented my short-term workaround:
> https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/
> 
> When this has been built on all release architectures openssl can bump 
> the version requirement.
> 
> Even more cautious would be to wait until testing migration of Qt.

now after what happens I consider this issue (#908567) fixed since the
only affected package by this is fixed. Also adding versioned depends is
not easy as I expected it in the morning without too much mess around
it.

> cu
> Adrian

Sebastian

Bug#907774: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Sebastian Andrzej Siewior]

On 2018-09-11 12:57:17 [+0300], Adrian Bunk wrote:
> > I'm on buster and with the latest updates from yesterday came 
> > qtbase-opensource-src 5.11.1+dfsg-7
> > and SSL started to fail in Qt5 programs. This was reported in bug 907774 ~ 
> > 2 weeks ago.
> > 
> > Basically libssl 1.1.1 (in whatever 1.1.1 version - my guess is 
> > 1.1.1~~pre9-1 from the changelog)
> > changed the definition of TLS_MAX_VERSION from TLS1_2_VERSION to 
> > TLS1_3_VERSION, which will start to
> > break all software in buster using that symbol, until libssl1.1 moves to 
> > buster.
> 
> I'd say that at least for the SSL_CTX_ctrl() symbol the created 
> dependency has to be increased.
> 
> Raising the severity of both bugs to RC to make the problem more visible,
> and to avoid further duplicate bugs.
> 
> Since the new OpenSSL won't enter buster anytime soon, the reasonable 
> short-term workaround for testing would be an upload to use 
> TLS1_2_VERSION instead of TLS_MAX_VERSION in qtbase-opensource-src.

So hmm. If I increase the version for the symbol then your new upload of
QT won't migrate to testing because it will depend on openssl which
currently won't migrate. This MAX version probably affectes not only QT.

There are a couple of bugs blocking on the other openssl bug which
forbids migration. Most of them are "run time errors" because the key or
signature is too small. All of them should be fixed and are mostly
testsuite. Keys which can't be fixed because of $reason should alter
their .cnf. According to Kurt there are few packages broken because they
don't send SNI anymore. This is probably worth fixing before migration
to testing.

Now. Any suggestions on how to handle this?

> cu
> Adrian

Sebastian

Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

[Sebastian Andrzej Siewior]

On 2018-08-23 09:07:31 [+0200], Paul Gevers wrote:
> 2) enable the openssl package to collect information which packages it
> breaks and which version of those package fix the issue. With that
> information the openssl package can add versioned Breaks
> 
> We believe that the versioned Breaks are needed to enable a smooth
> upgrade path for testing users as well as for users that upgrade from
> stretch to buster. For users a Breaks is also required if the new
> OpenSSL just exposed an existing bug in the reverse dependency.

how is a versioned break helping anything? The minimal key limit, hash
and TLS version can be overriden via config file and this what is
causing the problems from what I can tell. So either the remote side
upgrades their things or the users enabled "lower security" mode.
Is there anything that skipped my mind?

Sebastian

Bug#907906: stretch-pu: package openssl/1.1.0f-3+deb9u2

[Sebastian Andrzej Siewior]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal

I prepared an update for OpenSSL to synchronize it with upstream's
latest stable release (i).  The i release is an OpenSSL stable release
within the 1.1.0 series with no additional features. It contains only
fixes which don't fix anything security related but still qualify as
something that should be fixed with a stable release.
The BTS bugs #903566 and #907457 are two examples which were raised
within Debian.

As part of my QA I rebuilt all openssl's and libssl1.1 reverse
dependencies [0]. Some packages (like nova) failed to build against this
and current (currently Stretch) openssl due its testsuite and it might
have something todo with by sbuild setup since it succeeded in the
"reproducible builds" build. However, openbsc also FTBFS in
"reproducible builds". Everything that FTBFS against that i also FTBFS
against the current openssl in my setup except for one package.

The package python-cryptography fails to build due to an API change of
BIO_callback_ctrl() in OpenSSL. While is a no-no in a stable release, it
has been explained [1] that the function / callback was always used with
a different prototype. I fixed this by removing the function / prototype
from the python wrapper while upstream removed the almost all BIO
related wrappers [2].
I would submit a pu bugs for python-cryptography if there is nothing
wrong with this one.

I am attaching a diff of the debian/ folder of the update (the openssl
part is replaced with the new version). The whole diff is 24MiB in size
and can be fetched from [4] compressed.

If the release team would like some additional tests, please let me
know.

[0] https://breakpoint.cc/openssl-rebuild/2018-09-02-rebuild-stretch-1.1.0i/
[1] https://github.com/openssl/openssl/pull/4493#discussion_r143505277
[2] https://github.com/pyca/cryptography/pull/4220
[3] 
https://breakpoint.cc/openssl-rebuild/2018-09-02-rebuild-stretch-python-cryptography/
[4] 
https://breakpoint.cc/openssl-rebuild/2018-09-02-rebuild-stretch-1.1.0i/ossl_1.1.0f-3deb9u2_to_1.1.0i.patch.xz

Sebastian
diff --git a/debian/changelog b/debian/changelog
index 3c231b9b2cf9a..886d06e39674d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+openssl (1.1.0i-1~deb9u1) stretch; urgency=medium
+
+  * Import 1.1.0i
+- Fix segfault ERR_clear_error (Closes: #903566)
+- Fix commandline option for CAengine (Closes: #907457)
+  * Abort the build if symbols are discovered which are not part of the
+symbols file.
+
+ -- Sebastian Andrzej Siewior   Mon, 03 Sep 2018 23:59:02 +0200
+
 openssl (1.1.0f-3+deb9u2) stretch-security; urgency=high
 
   * CVE-2017-3738 (rsaz_1024_mul_avx2 overflow bug on x86_64)
diff --git a/debian/libssl1.1.symbols b/debian/libssl1.1.symbols
index 9d70f3748ca03..84875cff36446 100644
--- a/debian/libssl1.1.symbols
+++ b/debian/libssl1.1.symbols
@@ -4,6 +4,9 @@ libcrypto.so.1.1 libssl1.1 #MINVER#
  *@OPENSSL_1_1_0c 1.1.0c
  *@OPENSSL_1_1_0d 1.1.0d
  *@OPENSSL_1_1_0f 1.1.0f
+ *@OPENSSL_1_1_0g 1.1.0g
+ *@OPENSSL_1_1_0h 1.1.0h
+ *@OPENSSL_1_1_0i 1.1.0i
 libssl.so.1.1 libssl1.1 #MINVER#
  *@OPENSSL_1_1_0 1.1.0
  *@OPENSSL_1_1_0d 1.1.0d
diff --git a/debian/patches/0001-Only-release-thread-local-key-if-we-created-it.patch b/debian/patches/0001-Only-release-thread-local-key-if-we-created-it.patch
deleted file mode 100644
index 835b95d00696e..0
diff --git a/debian/patches/CVE-2017-3735.patch b/debian/patches/CVE-2017-3735.patch
deleted file mode 100644
index d152ddd387949..0
diff --git a/debian/patches/CVE-2017-3736.patch b/debian/patches/CVE-2017-3736.patch
deleted file mode 100644
index e60063fb65544..0
diff --git a/debian/patches/Fix-a-Proxy-race-condition.patch b/debian/patches/Fix-a-Proxy-race-condition.patch
deleted file mode 100644
index a2b72b8b79f66..0
diff --git a/debian/patches/Fix-race-condition-in-TLSProxy.patch b/debian/patches/Fix-race-condition-in-TLSProxy.patch
deleted file mode 100644
index 24b05c7e14139..0
diff --git a/debian/patches/Limit-ASN.1-constructed-types-recursive-definition-d.patch b/debian/patches/Limit-ASN.1-constructed-types-recursive-definition-d.patch
deleted file mode 100644
index 45e0feb25dc07..0
diff --git a/debian/patches/bn-asm-rsaz-avx2.pl-fix-digit-correction-bug-in-rsaz.patch b/debian/patches/bn-asm-rsaz-avx2.pl-fix-digit-correction-bug-in-rsaz.patch
deleted file mode 100644
index dbd3573187081..0
diff --git a/debian/patches/c_rehash-compat.patch b/debian/patches/c_rehash-compat.patch
index de24948e8dfac..199480af27e4d 100644
--- a/debian/patches/c_rehash-compat.patch
+++ b/debian/patches/c_rehash-compat.patch
@@ -1,15 +1,16 @@
-From 83f318d68bbdab1ca898c94576a838cc97df4700 Mon Sep 17 00:00:00 2001
 From: Ludwig Nussel 
 Date: Wed, 21 Apr 2010 15:52:10 +0200
 Subject: [PATCH] also create old hash for compatibility
 
 ---

Bug#904111: clamav-daemon causing deadlocks/blocking I/O

[Sebastian Andrzej Siewior]

On 2018-07-27 23:56:53 [+0200], To Marc Dequènes wrote:
> On 2018-07-25 22:03:46 [+0200], To Marc Dequènes wrote:
> > > I just tried loading Adam's configuration on another system to test the
> > > ScanOnAccess, copied a clamav test file in one of the protected directory
> > > and hit the problem. After that the whole machine becomes totally
> > > unresponsive in a few seconds.
> 
> bootet Stretch with 0.100.0+dfsg-0+deb9u2. Using the attached
> clamd.conf. I see
> |clamd (810): Using fanotify permission checks may lead to deadlock; tainting 
> kernel
> 
> in the kernel log. I can copy the test-files but I can't read them. I
> can delete them.  The system is still working. I have
>   linux-image-4.9.0-7-amd64 4.9.110-1
> installed and I have btrfs as rootfs on that box. What could I miss
> there in order to reproduce this?

I didn't manage to reproduce it yet. My plan was to to gather enough
informations to reproduce it and forward it upstream.
Is there anything wrong / different with my setup compared to your?
Maybe different filesystem or something like that (if everything else is
the same).

Sebastian

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-28 10:11:47 [+0200], Emilio Pozuelo Monfort wrote:
> We never break packages in testing (unless it's a critical situation, and this
> obviously isn't). Also the cruft package in unstable doesn't hurt much, so it
> can be left around for a while longer. What we want to do here is to get rid 
> of
> the old library in testing in order to finish the transition there: the only 
> two
> options for that are to remove scilab or to fix it. Given it's a key package 
> and
> probably has rdeps that'd mean the latter.

Okay. scilab received an upload an built properly. This was the only
keypackage. We have four packages left, none of them is in testing. Can
we close this transition now? :)

> Cheers,
> Emilio

Sebastian

Bug#904199: stretch-pu: package clamav/ 0.100.0+dfsg-0+deb9u2

[Sebastian Andrzej Siewior]

On 2018-07-29 22:01:20 [+0100], Adam D. Barratt wrote:
> 
> ClamAV is an AntiVirus toolkit for Unix.
> 
> Upstream published version 0.100.1.
> 
> This is a mostly a bug-fix release. The changes are not strictly
> required for operation, but users of the previous version in stretch
> may not be able to make use of all current virus signatures and might
> get warnings.
> 
> Changes since 0.100.0 currently in stretch include fixes for two
> security issues.
> 
> CVE-2018-0360
> 
>   ClamAV before 0.100.1 has an HWP integer overflow with a resultant
>   infinite loop via a crafted Hangul Word Processor file.
> 
> CVE-2018-0361
> 
>   ClamAV before 0.100.1 lacks a PDF object length check, resulting
>   in an unreasonably long time to parse a relatively small file.
> 

perfect, thank you.

> Apologies if the initial section is incorrect, it wasn't entirely clear
> to me whether there would be warnings for the bump from 0.100.0 to
> 0.100.1.

no worries.

> Regards,
> 
> Adam

Sebastian

Bug#904199: stretch-pu: package clamav/ 0.100.0+dfsg-0+deb9u2

[Sebastian Andrzej Siewior]

On 2018-07-28 09:24:28 [+0100], Adam D. Barratt wrote:
> Was the intent that the package would be pushed via -updates?

Yes, please. If you need additinal information I can provide then on
Sunday evening.

> Regards,
> 
> Adam

Sebastian

Bug#904111: clamav-daemon causing deadlocks/blocking I/O

[Sebastian Andrzej Siewior]

On 2018-07-25 22:03:46 [+0200], To Marc Dequènes wrote:
> > I just tried loading Adam's configuration on another system to test the
> > ScanOnAccess, copied a clamav test file in one of the protected directory
> > and hit the problem. After that the whole machine becomes totally
> > unresponsive in a few seconds.

bootet Stretch with 0.100.0+dfsg-0+deb9u2. Using the attached
clamd.conf. I see
|clamd (810): Using fanotify permission checks may lead to deadlock; tainting 
kernel

in the kernel log. I can copy the test-files but I can't read them. I
can delete them.  The system is still working. I have
linux-image-4.9.0-7-amd64 4.9.110-1
installed and I have btrfs as rootfs on that box. What could I miss
there in order to reproduce this?

Sebastian


clamd.conf.xz
Description: application/xz

Bug#904111: [Pkg-clamav-devel] Bug#904111: clamav-daemon causing deadlocks/blocking I/O

[Sebastian Andrzej Siewior]

On 2018-07-25 12:14:17 [+0900], Marc Dequènes (duck) wrote:
> Quack,
> 
> I did not try to switch on ScanOnAccess on my production system, but with my
> configuration, which is not that different, I do not have the problem.
> 
> I just tried loading Adam's configuration on another system to test the
> ScanOnAccess, copied a clamav test file in one of the protected directory
> and hit the problem. After that the whole machine becomes totally
> unresponsive in a few seconds.

okay, that is good to know.

> I am using kernel 4.16.16-2~bpo9+1 on this machine.

Yeah. That "deadlock" message is only printed on Debian's kernel.

> \_o<
> 

Sebastian

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-25 10:47:50 [+0200], Emilio Pozuelo Monfort wrote:
> > Any suggestions from the D-Science folks?
> 
> Maybe send this to the scilab bug rather than the curl transition one?

I Cced the scilab folks. I was more interrested in the release team's
opinion if it is worth fixing those and get it built in order to
complete the curl transition or if it does not make sense (to fix only
one of those RC bugs) and breaking the package (i.e. removing libcurl3
from unstable) would be an option.

> btw that failure may be due to the ongoing gfortran transition, and it may 
> just
> need to wait for the binNMUs to happen (which are ongoing).

Ah thanks, that is good to know.

> Cheers,
> Emilio

Sebastian

Bug#904111: [Pkg-clamav-devel] Bug#904111: Bug#904111: Bug#904111: clamav-daemon causing deadlocks/blocking I/O.

[Sebastian Andrzej Siewior]

On 2018-07-24 11:06:01 [+], Scott Kitterman wrote:
> On July 24, 2018 10:42:44 AM UTC, richard lucassen 
>  wrote:
> >http://tmp.xaq.nl/clamd.strace
…
> >plus a vanilla install of clamav-unofficial-sigs.
> 
> That looks like a different issue.  Does it still happen if you remove 
> clamav-unofficial-sigs?

This is #902899, the strace shows

|clamd: yara_exec.c:177: yr_execu

so were done here :)

> Scott K

Sebastian

Bug#904111: [Pkg-clamav-devel] Bug#904111: clamav-daemon causing deadlocks/blocking I/O

[Sebastian Andrzej Siewior]

On 2018-07-23 17:54:44 [+0900], Marc Dequènes wrote:
> Quack,
Hi,

> I just upgraded and cannot reproduce this problem. I'm not using the
> ScanOnAccess feature.

just to confirm: you can not reproduce the problem.

> Follows collected config info.
> \_o<

Sebastian

Bug#904111: [Pkg-clamav-devel] Bug#904111: clamav-daemon causing deadlocks/blocking I/O.

[Sebastian Andrzej Siewior]

On 2018-07-23 18:26:04 [+0200], Richard Lucassen wrote:
> Same here (6 Postfix front-end servers), non-systemd, non-GUI system
> running Debian Stretch. Downgrading to 0.99 is a workaround.
> ScanOnAccess is set to false.

Is the kernel complaining about something like in the other report where
it claimed something about a deadlock?

> R.

Sebastian

Bug#903834: [Pkg-clamav-devel] Bug#903834: clamav-freshclam: AppArmor denies access to /procp//status

[Sebastian Andrzej Siewior]

On 2018-07-22 20:10:08 [+0800], intrigeri wrote:
> Looking at the Journal, it looks very much like the clamav-freshclam
> service is started before the /usr/bin/freshclam AppArmor profile
> is loaded.
> 
> I think this is potentially racy, which might be why the problem can't
> trivially be reproduced in sid.

Is this something the clamav ppl need to improve or is this generic AppArmor /
debhelper thingy?

> Cheers,

Sebastian

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-19 00:39:27 [+0200], To Emilio Pozuelo Monfort wrote:
> - scilab
>   rebuilt everywhere except for i386. Plus
>   #891351 [G|  |  ] [scilab] scilab segfaults at startup
>   #875790 [S|⛺+|  ] [src:scilab] scilab: depends on openjdk-8
>   #884033 [S|  |☣] [scilab] scilab segfaults building 
> scilab-{ann,celestlab,plotlib}
>   #902826 [S|  |  ] [src:scilab] scilab: FTBFS on i386 - seg. fault during 
> build
> 
>   Building currently without all (#902826).  Assuming it works, would it
>   make sense to NMU+2d it? We would get rid of one RC bug for curl but…

This one got worse since gcc-8 is the default[0], this is amd64:

|/bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/twodq.lo 
src/fortran/twodq.f
| /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/dqagse.lo 
src/fortran/dqagse.f
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/xerrwv.f  -fPIC -o 
src/fortran/.libs/xerrwv.o
| /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/greatr.lo 
src/fortran/greatr.f
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/twodq.f  -fPIC -o 
src/fortran/.libs/twodq.o
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/dqagse.f  -fPIC -o 
src/fortran/.libs/dqagse.o
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/greatr.f  -fPIC -o 
src/fortran/.libs/greatr.o
| /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/hpdel.lo 
src/fortran/hpdel.f
| src/fortran/twodq.f:373:17:
|
|call tridv(node,node1,node2,0.5d0,1)
|  1
| Error: Actual argument contains too few elements for dummy argument 'node' 
(9/10) at (1)
| make[3]: *** [Makefile:1444: src/fortran/twodq.lo] Error 1

I am not fluent in fortran so I can't tell if this is a temporary glitch
or a new permant FTBFS.
Any suggestions from the D-Science folks?

[0] I *think* it is gcc-8 because I built it recently and it built on
amd64 but today it doesn't anymore.

Sebastian

Bug#904213: stretch-pu: package libclamunrar/0.99-3+deb9u1

[Sebastian Andrzej Siewior]

the website to submit FPs/FNs.)], [no])
+else
+CL_MSG_STATUS([clamsubmit  ], [no (missing libcurl-devel. Use the website to submit FPs/FNs.)], [no])
+fi
+fi
+fi
 
 AC_MSG_NOTICE([Summary of engine performance features])
 if test "x$enable_debug" = "xyes"; then
@@ -189,10 +213,12 @@ have_jit="no"
 if test "$subdirfailed" = "no"; then
 have_jit="yes"
 fi
-if test "x$llvm_linking" = "x"; then
-   CL_MSG_STATUS([llvm],[$have_jit, from $system_llvm],[$enable_llvm])
+if test "$enable_llvm" = "no"; then
+   CL_MSG_STATUS([llvm],[$have_jit],[$enable_llvm])
+elif test "x$llvmconfig" = "x"; then
+   CL_MSG_STATUS([llvm],[$have_jit ($llvmver), from internal],[$enable_llvm])
 else
-   CL_MSG_STATUS([llvm],[$have_jit, from $system_llvm ($llvm_linking)],[$enable_llvm])
+   CL_MSG_STATUS([llvm],[$have_jit ($llvmver), from $llvmconfig ($llvm_linking)],[$enable_llvm])
 fi
 CL_MSG_STATUS([mempool ],[$have_mempool],[$enable_mempool])
 
@@ -200,20 +226,25 @@ AC_MSG_NOTICE([Summary of engine detection features])
 CL_MSG_STATUS([bzip2   ],[$bzip_check],[$want_bzip2])
 CL_MSG_STATUS([zlib],[$ZLIB_HOME],[yes])
 CL_MSG_STATUS([unrar   ],[$want_unrar],[$want_unrar])
-if test "x$LIBJSON_HOME" != "x"; then
-CL_MSG_STATUS([libjson ],[$LIBJSON_HOME],[$have_json])
+if test "X$have_json" = "Xyes"; then
+CL_MSG_STATUS([preclass],[yes (libjson-c-dev found at $LIBJSON_HOME)],[yes])
+else
+CL_MSG_STATUS([preclass],[no (missing libjson-c-dev)],[no])
 fi
 if test "x$PCRE_HOME" = "x"; then
 CL_MSG_STATUS([pcre],[no],[$have_pcre])
 else
 CL_MSG_STATUS([pcre],[$PCRE_HOME],[$have_pcre])
 fi
+CL_MSG_STATUS([libmspack   ],[yes],[$mspack_msg])
 if test "x$XML_LIBS" = "x"; then 
 CL_MSG_STATUS([libxml2 ],[no],[])
 else
 CL_MSG_STATUS([libxml2 ],[yes, from $XML_HOME],[])
 fi
 CL_MSG_STATUS([yara],[$enable_yara],[$enable_yara])
+CL_MSG_STATUS([fts ],[yes],[$lfs_fts_msg])
+
 
 # Yep, downgrading the compiler avoids the bug too:
 # 4.0.x, and 4.1.0 are the known buggy versions
diff --git a/debian/changelog b/debian/changelog
index 41eebea1f85b..31692b60a46f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+libclamunrar (0.100.1-0+deb9u1) stretch; urgency=medium
+
+  [ Sebastian Andrzej Siewior ]
+  * New upstream version
+- Buffer over-read in unRAR code due to missing max value checks in table
+  initialization. Reported by Rui Reis.
+- drop all patches (were picked from upstream, the openssl patch is
+  obsolete).
+
+  [ Scott Kitterman ]
+  * Delete symlinks to files no longer shipped in libclamav7 (Closes: #903792)
+
+ -- Sebastian Andrzej Siewior   Sat, 21 Jul 2018 18:25:22 +0200
+
 libclamunrar (0.99-3+deb9u1) stretch; urgency=medium
 
   * Team upload.
diff --git a/debian/libclamunrar7.links b/debian/libclamunrar7.links
index 876ecb03db8e..300ea38600bb 100644
--- a/debian/libclamunrar7.links
+++ b/debian/libclamunrar7.links
@@ -1,7 +1,2 @@
-/usr/share/doc/libclamav7/AUTHORS /usr/share/doc/libclamunrar7/AUTHORS
-/usr/share/doc/libclamav7/BUGS /usr/share/doc/libclamunrar7/BUGS
-/usr/share/doc/libclamav7/FAQ /usr/share/doc/libclamunrar7/FAQ
-/usr/share/doc/libclamav7/README.gz /usr/share/doc/libclamunrar7/README.gz
 /usr/share/doc/libclamav7/README.Debian.gz /usr/share/doc/libclamunrar7/README.Debian.gz
 /usr/share/doc/libclamav7/NEWS.Debian.gz /usr/share/doc/libclamunrar7/NEWS.Debian.gz
-/usr/share/doc/libclamav7/changelog.gz /usr/share/doc/libclamunrar7/changelog.gz
diff --git a/debian/patches/bb11600.patch b/debian/patches/bb11600.patch
deleted file mode 100644
index cbb384fff6fb..
--- a/debian/patches/bb11600.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-From 155190a0a5000ffb0b516c04a1a9091a5c4dc2b3 Mon Sep 17 00:00:00 2001
-From: Steven Morgan 
-Date: Tue, 12 Jul 2016 12:36:29 -0400
-Subject: bb11600 - fix out of bounds stack read.
-
-Patch-Name: bb11600.patch

- libclamunrar/unrar20.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/libclamunrar/unrar20.c b/libclamunrar/unrar20.c
-index ecfe40cf32f3..d938c472e1d8 100644
 a/libclamunrar/unrar20.c
-+++ b/libclamunrar/unrar20.c
-@@ -117,7 +117,8 @@ static int read_tables20(int fd, unpack_data_t *unpack_data)
- 			n = (rar_getbits(unpack_data) >> 14) + 3;
- 			rar_addbits(unpack_data, 2);
- 			while ((n-- > 0) && (i < table_size)) {
--table[i] = table[i-1];
-+if (i>0)
-+	table[i] = table[i-1];
- i++;
- 			}
- 		} else {
diff --git a/debian/patches/bb11600_pt2.patch b/debian/patches/bb11600_pt2.patch
deleted file mode 100644
index 2cf8f8156d8b..
--- a/debian/patches/bb11600_pt2.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-From 4ba0a93c2887e5cea

Bug#904156: [Pkg-openssl-devel] Bug#904156: openssl: ALPN protocol: http/1.1, instead of h2. This occured on my server after updating.

[Sebastian Andrzej Siewior]

On 2018-07-20 17:16:40 [-0400], Mike Rotondo wrote:
>I expected an update to roll out that fixed the problem

Thank you for the informative bug report. If I put the pieces correctly
together then since the point release you have your apache2 server not
serving ALPN/h2 but only "normal" http/1.1 as you put it. Am I correct?

If so, then this bug should be moved to openssl1.0 because apache2 in
Stretch is using libssl1.0.2 and not libssl1.1. Other than that: Could
you please check if downgrading either apache2 or libssl1.0.2 helps?
The part that puzzles me most is that you received an update to
libssl1.0.2 (and libssl1.1) via the point release and not via security
which would be a good idea. Like *really* good idea.

Now, if you downgrade I bet that downgrading apache2 helps. In that
case we could move that report over to apache or close it right away. I
speculate on apache because of this piece in its changelog [0]:

|Unfortunately, this also removes support for http2 when running on
|mpm_prefork.

[0] 
https://tracker.debian.org/news/969425/accepted-apache2-2425-3deb9u5-source-amd64-all-into-proposed-updates-stable-new-proposed-updates/

Sebastian

Bug#904158: glibc: pthread_cond_wait() is broken in the pshared case

[Sebastian Andrzej Siewior]

Package: glibc
Version: 2.24-11+deb9u3
Severity: important

The short version is that pthread_cond_wait() is broken in the pshared
case in glibc in Stretch. The version in Sid is not affected because
that part received a large rewrite (that is why I use explicit the
version Stretch for the report).

The full explanation is attached as a patch. I also attached a testcase
to verify. Please note that x86 has handwritten assembly code for the
function which does not have the problem. All other architectures are
using the generic C code and share the problem.
On amdahl.d.o:~bigeasy/glibc you can try the following:

|strace -f ../testcase 
|clone(child_stack=0x99483b10, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x994842d0, tls=0x994848f0, child_tidptr=0x994842d0) 
= 26581
|[pid 26581] futex(0xda3d40fc, FUTEX_WAIT_REQUEUE_PI, 1, NULL, 
0xda3d40b8 
|[pid 26579] clone(child_stack=0x98c83b10, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x98c842d0, tls=0x98c848f0, child_tidptr=0x98c842d0) 
= 26582
|[pid 26582] futex(0xda3d40fc, FUTEX_WAIT_REQUEUE_PI, 2, NULL, 
0xda3d40b8 
|[pid 26579] futex(0xda3d40fc, FUTEX_WAKE_OP, 1, 1, 0xda3d40f8, 
FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = -1 EINVAL (Invalid argument)
|[pid 26579] futex(0xda3d40fc, FUTEX_WAKE, 1) = -1 EINVAL (Invalid argument)

As you see the two waiting threads do FUTEX_WAIT_REQUEUE_PI and the
waker does FUTEX_WAKE* which is not valid. The program hangs at this
point.
With the patch attached:
|LD_LIBRARY_PATH=x/lib/aarch64-linux-gnu/ strace -f ../testcase 
|child_stack=0x8edb6b10, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x8edb72d0, tls=0x8edb78f0, child_tidptr=0x8edb72d0) 
= 26660
|[pid 26660] futex(0xe4e1c0fc, FUTEX_WAIT, 1, NULL 
|[pid 26659] clone(child_stack=0x8e5b6b10, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x8e5b72d0, tls=0x8e5b78f0, child_tidptr=0x8e5b72d0) 
= 26661
|[pid 26661] futex(0xe4e1c0fc, FUTEX_WAIT, 2, NULL 
|[pid 26659] futex(0xe4e1c0fc, FUTEX_WAKE_OP, 1, 1, 0xe4e1c0f8, 
FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = 1
and so on, the program finishes.

Sebastian
From: John Ogness 
Date: Wed, 16 May 2018 22:34:41 +0200
Subject: [PATCH] condvar: do not use requeue for pshared condvars

With commit e42a990eccb (Update.) condvars were changed to not
store the mutex address when pshared. Instead, ~0l is stored.
This value is checked for in USE_REQUEUE_PI() to determine if
requeue should be used.

pthread_cond_signal() and pthread_cond_broadcast() both use
USE_REQUEUE_PI() with the mutex address stored on the condvar.

However, pthread_cond_wait() and pthread_cond_timedwait() use
USE_REQUEUE_PI() on the mutex address passed in from the caller
(even though that address is *not* stored on the condvar in the
pshared case). The result is that in the pshared case, the
wait functions are using requeue and the wake functions are
not! This is not allowed by the kernel (the waking futex call
returns EINVAL).

Modify the wait functions to use USE_REQUEUE_PI() on the mutex
address stored on the condvar, thus mirroring the behavior of
the wake functions.

Signed-off-by: John Ogness 
Acked-by: Sebastian Andrzej Siewior 
Reviewed-by: Kurt Kanzenbach 
Signed-off-by: Kurt Kanzenbach 
---
 nptl/pthread_cond_timedwait.c | 4 +++-
 nptl/pthread_cond_wait.c  | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/nptl/pthread_cond_timedwait.c b/nptl/pthread_cond_timedwait.c
index 711a51de20..9e6a393a43 100644
--- a/nptl/pthread_cond_timedwait.c
+++ b/nptl/pthread_cond_timedwait.c
@@ -163,6 +163,8 @@ __pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
to check just the former.  */
 #if (defined lll_futex_timed_wait_requeue_pi \
  && defined __ASSUME_REQUEUE_PI)
+  pthread_mutex_t *mut = cond->__data.__mutex;
+
   /* If pi_flag remained 1 then it means that we had the lock and the mutex
 	 but a spurious waker raced ahead of us.  Give back the mutex before
 	 going into wait again.  */
@@ -171,7 +173,7 @@ __pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
 	  __pthread_mutex_cond_lock_adjust (mutex);
 	  __pthread_mutex_unlock_usercnt (mutex, 0);
 	}
-  pi_flag = USE_REQUEUE_PI (mutex);
+  pi_flag = USE_REQUEUE_PI (mut);
 
   if (pi_flag)
 	{
diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c
index 3f62acc6bd..7a4313cda6 100644
--- a/nptl/pthread_cond_wait.c
+++ b/nptl/pthread_cond

Bug#904111: clamav-daemon causing deadlocks/blocking I/O.

[Sebastian Andrzej Siewior]

On 2018-07-19 13:38:04 [-0700], Adam Lambert wrote:
> clamd (28514): Using fanotify permission checks may lead to deadlock; 
> tainting kernel
> and shortly thereafter

This seems to become true.

> INFO: task clamd:28512 blocked for more than 120 seconds.

That is deadlock that happens.

> I downgraded to 0.99.4+dfsg-1+deb9u1 and system remains stable as it had been 
> heretofore.
interresting.

> I suspect this is related to my use of ScanOnAccess true, but not sure.
I think that causes the problem. Could you try to switch it off?
Do you use clamav / the machine for something like a mailserver or so?

Sebastian

Bug#901879: RM wvdial, no more info for wvstreams

[Sebastian Andrzej Siewior]

control: tags 901361 - moreinfo
control: reassign 901879 ftp.debian.org
control: retitle 901879 RM: wvdial -- unmaintained, dead upstream, depends on 
wvdial

here I am one month later. Nobody tried to adopt wvdial or wvstreams
within the last month.
Please remove both from unstable.

Sebastian

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-05-28 17:43:15 [+0200], Emilio Pozuelo Monfort wrote:
> Let's go with this. I'll schedule the binNMUs soon.

atm we have:

- netsurf (sid only)
  #867694 [G|  |  ] [netsurf-fb] netsurf-fb: Completely unusable due to missing 
dependencies, symlinks and documentation
  #859230 [S|  |  ] [netsurf] netsurf: Please migrate to openssl1.1 in Buster
  #869600 [S|⛺|  ] [src:netsurf] netsurf FTBFS: error: conflicting types for 
'svgtiny_color_lookup' 

  NMU+2d to fix #859230 + #869600. #867694 is still there but…
  
- frobtads (sid only)
  #836934 [S|+|  ] [src:frobtads] frobtads: FTBFS with GCC 6: error: exception 
cleanup for this placement new selects non-placement operator delete
  #871215 [S|+|  ] [src:frobtads] frobtads: FTBFS with GCC-7: error: ISO C++ 
forbids comparison between pointer and integer

  There are patches attached. Maybe NMU?

- gambas3 (sid only)
  #867306 [S|  |  ] [src:gambas3] gambas3: spurious libqtwebkit-dev build 
dependency
  #899515 [S|  |  ] [src:gambas3] gambas3: Invalid maintainer address 
pkg-gambas-de...@lists.alioth.debian.org
  #900998 [S|u|  ] [src:gambas3] gambas3: FTBFS w/SDL2 2.0.7+: 
MIX_INIT_FLUIDSYNTH undeclared
  #867930 [S|  |↝] [src:gambas3] gambas3: Build-Depends on deprecated 
libgnome-keyring-dev

  Hmm. So based on https://hg.libsdl.org/SDL_mixer/rev/92882ef2ab81 it
  seems that MIX_INIT_FLUIDSYNTH -> MIX_INIT_MID would make it build
  again. And Upstream did almost the same thing:
  
https://gitlab.com/gambas/gambas/commit/caf54c5b75d62d3136f12a6e5657df4e2ec555ba
  
  Not sure about the other bugs. Worth fixing that one?

- scilab
  rebuilt everywhere except for i386. Plus
  #891351 [G|  |  ] [scilab] scilab segfaults at startup
  #875790 [S|⛺+|  ] [src:scilab] scilab: depends on openjdk-8
  #884033 [S|  |☣] [scilab] scilab segfaults building 
scilab-{ann,celestlab,plotlib}
  #902826 [S|  |  ] [src:scilab] scilab: FTBFS on i386 - seg. fault during build

  Building currently without all (#902826).  Assuming it works, would it
  make sense to NMU+2d it? We would get rid of one RC bug for curl but…

- xmltooling (sid only)
  #859831 [S|  |♔☣] [xmltooling] xmltooling: Please migrate to openssl1.1 in 
Buster
  Can't be built at the moment. We are waiting for new upstream version.

- freeipa (sid only)
  hardcoded "libcurl3 (>= 7.22.0)" in freeipa-client. There is
  #901430 conflict: freeipa depends upon libcurl3 and (curl --> libcurl4)
  Dropping the build-depend on libcurl3, NMU 4d.
  Maybe I should rise that to 'serious'?

- kcov (sid only)
  #780620 [S|+|  ] [src:kcov] control file not policy compliant and build 
failures almost everywhere
  #790912 [S|⛺|  ] [kcov] FTBFS: ld: CMakeFiles/kcov.dir/capabilities.cc.o .. 
recompile with -fPIC
  #839374 [S|  |  ] [src:kcov] kcov: FTBFS: ld: final link failed: 
Nonrepresentable section on output
  #880344 [S|  |  ] [src:kcov] kcov: FTBFS: Test failures

  Ehm, yes. 

- openalpr (sid only)
  #896793 [S|⛺|  ] [src:openalpr] openalpr: missing build dependency on 
python3-distutils
  Adding B-D, NMU+2d

> Cheers,
> Emilio

Sebastian

Bug#901430: freeipa: diff for NMU version 4.6.3-1.1

[Sebastian Andrzej Siewior]

Control: tags 901430 + patch
Control: tags 901430 + pending

Dear maintainer,

I've prepared an NMU for freeipa (versioned as 4.6.3-1.1) and
uploaded it to DELAYED/4. Please feel free to tell me if I
should delay it longer.

Regards.
Sebastian
diff -Nru freeipa-4.6.3/debian/changelog freeipa-4.6.3/debian/changelog
--- freeipa-4.6.3/debian/changelog	2018-02-02 16:27:44.0 +0100
+++ freeipa-4.6.3/debian/changelog	2018-07-19 00:03:21.0 +0200
@@ -1,3 +1,10 @@
+freeipa (4.6.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop the libcurl3 dependency (Closes: #901430).
+
+ -- Sebastian Andrzej Siewior   Thu, 19 Jul 2018 00:03:21 +0200
+
 freeipa (4.6.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru freeipa-4.6.3/debian/control freeipa-4.6.3/debian/control
--- freeipa-4.6.3/debian/control	2018-02-01 13:14:03.0 +0100
+++ freeipa-4.6.3/debian/control	2018-07-19 00:00:17.0 +0200
@@ -186,7 +186,6 @@
  dnsutils,
  freeipa-common (= ${source:Version}),
  krb5-user,
- libcurl3 (>= 7.22.0),
  libnss3-tools,
  libnss-sss,
  libpam-sss,

Bug#896793: openalpr: diff for NMU version 2.3.0-1.1

[Sebastian Andrzej Siewior]

Control: tags 896793 + patch
Control: tags 896793 + pending

Dear maintainer,

I've prepared an NMU for openalpr (versioned as 2.3.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
Sebastian
diff -Nru openalpr-2.3.0/debian/changelog openalpr-2.3.0/debian/changelog
--- openalpr-2.3.0/debian/changelog	2016-09-17 18:27:25.0 +0200
+++ openalpr-2.3.0/debian/changelog	2018-07-18 23:52:45.0 +0200
@@ -1,3 +1,10 @@
+openalpr (2.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add python3-distutils to Build-depends (Closes: #896793).
+
+ -- Sebastian Andrzej Siewior   Wed, 18 Jul 2018 23:52:45 +0200
+
 openalpr (2.3.0-1) unstable; urgency=low
 
   * Added plate detection mask and prewarp config changes via API
diff -Nru openalpr-2.3.0/debian/control openalpr-2.3.0/debian/control
--- openalpr-2.3.0/debian/control	2016-09-17 17:28:22.0 +0200
+++ openalpr-2.3.0/debian/control	2018-07-18 23:52:07.0 +0200
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>= 9), cmake, quilt, 
  libtesseract-dev, libleptonica-dev, liblog4cplus-dev,
  libcurl3-dev, libopencv-dev, default-jdk,
- python, python3, dh-python
+ python, python3, dh-python, python3-distutils
 Standards-Version: 3.9.6
 Homepage: https://github.com/openalpr/openalpr
 Vcs-Browser: https://github.com/openalpr/openalpr

Bug#859230: netsurf: diff for NMU version 3.6-3.2

[Sebastian Andrzej Siewior]

control: tags -1 patch pending

Dear maintainer,

I've prepared an NMU for netsurf (versioned as 3.6-3.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
Sebastian
diff -Nru netsurf-3.6/debian/changelog netsurf-3.6/debian/changelog
--- netsurf-3.6/debian/changelog	2017-02-08 21:10:34.0 +0100
+++ netsurf-3.6/debian/changelog	2018-07-18 23:25:47.0 +0200
@@ -1,3 +1,11 @@
+netsurf (3.6-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Depend on libssl-dev (Closes: #859230).
+  * Get it build again new gperf (Closes: #869600).
+
+ -- Sebastian Andrzej Siewior   Wed, 18 Jul 2018 23:25:47 +0200
+
 netsurf (3.6-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru netsurf-3.6/debian/control netsurf-3.6/debian/control
--- netsurf-3.6/debian/control	2017-02-08 21:08:27.0 +0100
+++ netsurf-3.6/debian/control	2017-02-08 21:10:34.0 +0100
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Vincent Sanders 
 Uploaders: Daniel Silverstone 
-Build-Depends: debhelper (>= 9~), libcurl3-dev, libpng-dev, libgtk2.0-dev, flex, bison, libhtml-parser-perl, librsvg2-dev, libjpeg-dev, imagemagick, libfreetype6-dev, libvncserver-dev, libsdl1.2-dev, libxcb1-dev, libxcb-icccm4-dev, libxcb-image0-dev, libxcb-keysyms1-dev, libxcb-util0-dev, libssl1.0-dev | libssl-dev (<< 1.1), gperf
+Build-Depends: debhelper (>= 9~), libcurl3-dev, libpng-dev, libgtk2.0-dev, flex, bison, libhtml-parser-perl, librsvg2-dev, libjpeg-dev, imagemagick, libfreetype6-dev, libvncserver-dev, libsdl1.2-dev, libxcb1-dev, libxcb-icccm4-dev, libxcb-image0-dev, libxcb-keysyms1-dev, libxcb-util0-dev, libssl-dev, gperf
 Standards-Version: 3.9.8
 Homepage: http://www.netsurf-browser.org
 Vcs-Browser: http://source.netsurf-browser.org/packaging/debian.git/
diff -Nru netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch
--- netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch	1970-01-01 01:00:00.0 +0100
+++ netsurf-3.6/debian/patches/Build-Include-gperf-generated-code-directly.patch	2017-02-08 21:10:34.0 +0100
@@ -0,0 +1,92 @@
+From: Michael Drake 
+Date: Thu, 20 Apr 2017 09:51:07 +
+Subject: [PATCH] Build: Include gperf-generated code directly.
+
+Previously we built the generated code separatly and then linked to
+it.  However, this caused problems with certain compilers and gperf
+versions.  This change includes the generated code directly in
+svgtiny.c instead, which is the only place its used.
+
+Source: http://source.netsurf-browser.org/libsvgtiny.git/commit/?id=4390f1c84e8fee51fc22468821e6fc158e783053
+---
+ libsvgtiny/src/Makefile   | 13 +++--
+ libsvgtiny/src/colors.gperf   |  8 
+ libsvgtiny/src/svgtiny.c  |  3 +++
+ libsvgtiny/src/svgtiny_internal.h |  5 -
+ 4 files changed, 10 insertions(+), 19 deletions(-)
+
+diff --git a/libsvgtiny/src/Makefile b/libsvgtiny/src/Makefile
+index a97972023257..fb8a72f9c2ff 100644
+--- a/libsvgtiny/src/Makefile
 b/libsvgtiny/src/Makefile
+@@ -1,13 +1,14 @@
+ # Sources
+ DIR_SOURCES := svgtiny.c svgtiny_gradient.c svgtiny_list.c
+ 
+-SOURCES := $(SOURCES) $(BUILDDIR)/src_colors.c
++SOURCES := $(SOURCES)
+ 
+-$(BUILDDIR)/src_colors.c: src/colors.gperf
++$(DIR)autogenerated_colors.c: src/colors.gperf
+ 	$(VQ)$(ECHO) "   GPERF: $<"
+-	$(Q)gperf --output-file=$@.tmp $<
+-# Hack for GCC 4.2 compatibility (gperf 3.0.4 solves this properly)
+-	$(Q)$(SED) -e 's/#ifdef __GNUC_STDC_INLINE__/#if defined __GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__/' $@.tmp >$@
+-	$(Q)$(RM) $@.tmp
++	$(Q)gperf --output-file=$@ $<
++
++PRE_TARGETS := $(DIR)autogenerated_colors.c
++
++CLEAN_ITEMS := $(DIR)autogenerated_colors.c
+ 
+ include $(NSBUILD)/Makefile.subdir
+diff --git a/libsvgtiny/src/colors.gperf b/libsvgtiny/src/colors.gperf
+index 96d5b9e5debf..a836787bf306 100644
+--- a/libsvgtiny/src/colors.gperf
 b/libsvgtiny/src/colors.gperf
+@@ -17,14 +17,6 @@
+ #include "svgtiny.h"
+ #include "svgtiny_internal.h"
+ 
+-/* This unusual define shennanigan is to try and prevent the gperf
+- * generated function from being inlined.  This is pointless given
+- * it (a) is in a separate .c file and (b) has external linkage.
+- */
+-#ifdef __inline
+-#undef __inline
+-#define __inline
+-#endif
+ %}
+ 
+ struct svgtiny_named_color;
+diff --git a/libsvgtiny/src/svgtiny.c b/libsvgtiny/src/svgtiny.c
+index 4661a58a2dff..bbefb888a263 100644
+--- a/libsvgtiny/src/svgtiny.c
 b/libsvgtiny/src/svgtiny.c
+@@ -20,6 +20,9 @@
+ #include "svgtiny.h"
+ #include "svgtiny_internal.h"
+ 
++/* Source file generated by `gperf`. */
++#include "autogenerated_colors.c"
++
+ #ifndef M_PI
+ #define M_PI		3.14159265358979323846
+ #endif
+diff --git a/libsvgtiny/src/svgtiny_internal.h b/libsvgtiny/s

Bug#903566: libssl1.1.0f: segfault in ERR_clear_error

[Sebastian Andrzej Siewior]

On 2018-07-11 14:25:46 [+0200], Bernd Zeimetz wrote:
> Hi,
Hi,

> This is fixed since one year in the openssl 1.1.0 stable branch.

so I do have a little side project where I try to bring the latest 1.1.0
stable release into Debian stable via p-u for reasons like this.

Do I understand this correctly that you have a fix localy and would
like that it does not get lost after the next security update? If so I
would leave it for now and attempt to get this closed via the p-u update
or as part the next CVE fix round via security if they play along.

Sebastian

Bug#902899: me too

[Sebastian Andrzej Siewior]

On 2018-07-09 22:45:15 [+0200], Matija Nalis wrote:
> I got bitten by this too in jessie-updates (after wasting some time
> being *sure* local signature I was just creating at the time made
> clamd crash silently)...

wasn't there an assert which made clamd exit?

…
> Still wondering how much of protection is lost without YARA rules? 
Go though your log files and check for yourself how many mails where
checked positiv with one of the rules. 

I don't know if all rules were broken or just one. The earlier release
just ignored the broken/wrong rule.

Sebastian

Bug#875423: [Pkg-openssl-devel] Bug#875423: Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

[Sebastian Andrzej Siewior]

On 2018-07-10 04:05:58 [+0200], Philippe Metzger wrote:
> For now it seems that OpenSSL 1.1.0f-3+deb9u2 available in stretch/security
> force TLS 1.2 only in https when using Apache (whatever SSLProtocol
> Directive specify).

This is not true. Stretch has TLS1.0 and up enabled by default.

> Is there any way to allow TLS 1 and TLS 1.1 with apache in stable ?

This bug is sid only. Testing (as asked by the reported) has TLS1.0+
enabled again. The bug is open because the proper way of getting this
fixed is currently in experimental.

> Thanks a lot

Sebastian

Bug#903148: libssl1.1: no debug package

[Sebastian Andrzej Siewior]

On 7 July 2018 04:24:20 CEST, Shawn Landden  wrote:
>I would like it if there was a debug package for libssl1.1 so I could
>better profile transmission with perf.

What is wrong with dbgsym we currently provide?
Take a look at https://wiki.debian.org/AutomaticDebugPackages
on how to install them.

>
>Thank you.



Sebastian

Bug#898805: fixed in nodejs 8.11.2~dfsg-1

[Sebastian Andrzej Siewior]

control: reopen -1
control: notfixed -1 8.11.2~dfsg-1

On 2018-05-17 18:10:35 [+], Jérémy Lal wrote:
> Source: nodejs
> Source-Version: 8.11.2~dfsg-1
…
>* Upstream openssl 1.1.1 wip patches (Closes: #898805)
>  Also make sure tests still run with openssl 1.1.0

I rebuilt 8.11.2~dfsg-1 against libssl1.1 1.1.1~~pre8-1 from exp and it
failed with the small key in the testsuite:

|not ok 1875 sequential/test-tls-connect
|  ---
|  duration_ms: 0.609
|  severity: fail
|  stack: |-
|_tls_common.js:98
|  c.context.setCert(options.cert);
|^
|
|Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
|at Object.createSecureContext (_tls_common.js:98:17)
|at Object.exports.connect (_tls_wrap.js:1053:48)
|at Object. 
(/<>/test/sequential/test-tls-connect.js:40:20)
|at Module._compile (module.js:652:30)
|at Object.Module._extensions..js (module.js:663:10)
|at Module.load (module.js:565:32)
|at tryModuleLoad (module.js:505:12)
|at Function.Module._load (module.js:497:3)
|at Function.Module.runMain (module.js:693:10)
|at startup (bootstrap_node.js:191:16)

full log at
  
https://breakpoint.cc/openssl-rebuild/2018-07-06-rebuild-openssl1.1.1-pre8/attempted/nodejs_8.11.2~dfsg-1_amd64-2018-07-05T19%3A01%3A58Z

Sebastian

Bug#902899: clamd: yara_exec.c:177: yr_execute_code: Assertion `sp == 0' failed in stable update

[Sebastian Andrzej Siewior]

On 2018-07-05 23:52:31 [+0200], Bernhard Schmidt wrote:
> Hi Sebastian,
Hi Bernhard,

> I totally agree and I have already done this. I have filed a bug because
> I assume this will hit at least some people on the next Stretch point
> release hard. Not sure whether one can workaround this in clamav (and it
> might already be too late).

Today is last day I guess due to the freeze for the point release. I
sneaked into a fix for removed options but I think this is it. I have
currently no idea where to start working around the yara thing. It is
known by both upstram sides (clamav and unofficial-sigs) since April or
so and there was no progress since. And I can't change the world :)

So lets see how many people complain here after the point release…

> Bernhard

Sebastian

Bug#902899: clamd: yara_exec.c:177: yr_execute_code: Assertion `sp == 0' failed in stable update

[Sebastian Andrzej Siewior]

control: forwarded -1 https://bugzilla.clamav.net/show_bug.cgi?id=12077

On 2018-07-05 22:54:58 [+0200], Bernhard Schmidt wrote:
> On 04.07.2018 14:00, Sebastian Andrzej Siewior wrote:
> 
> Hi Sebastian,
Hi Bernhard,

> Attached. Note that antidebug_antivm.yar is the one with the errors on
> loading, but the actual assertion is later when the first (?) mail is
> processed with clamd. So it might be related to any of the .yara? files.
> 
> Thanks for looking into this.

While trying to forward this upstream I found a report :) So upstream
wants to address it but has no timeline. It considers the rule file as
broken and it doesn't work bug now clamav actually complains.

I suggest you remove the offending file. I have no other recommendation.

> Bernhard

Sebastian

Bug#903005: stretch-pu: package clamav/0.100.0+dfsg-0+deb9u1

[Sebastian Andrzej Siewior]

On 2018-07-05 06:25:45 [+0100], Adam D. Barratt wrote:
> Please go ahead.

uploaded, thanks.

> Regards,
> 
> Adam

Sebastian

Bug#903005: stretch-pu: package clamav/0.100.0+dfsg-0+deb9u1

[Sebastian Andrzej Siewior]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal

0.100.0 clamav version had a few config options removed. This is covered
by postinst as long as the config is handled by debconf. If the user
makes changes manually then ucf ask the user to resolve it and if nothing 
happens
(during unattended-upgrades) then the old options remain set and clamav
refuses to start.
This was reported during the deb8 point upgrade. To avoid this during
the upcomming deb9 upgrade I hereby propose a patch to simply declare
the removed options as "deprecated" which results in a warning like
| clamd[8720]: WARNING: Ignoring deprecated option StatsTimeout at line 88
| clamd[8720]: WARNING: Ignoring deprecated option StatsPEDisabled at line 89

in the log file and clamav continues.

In terms of full disclosure: There is a yara regression within clamav
(that is if you use clamav-unofficial-sigs) as reported in #902899
yesterday. The bug has been reported on 16th April to
clamav-unofficial-sigs upstream (as per the forwarded link in BTS) and
nothing happend since. Give the freeze this weekend I don't think that
this will change for Stretch.

Sebastian
diff -Nru clamav-0.100.0+dfsg/debian/changelog clamav-0.100.0+dfsg/debian/changelog
--- clamav-0.100.0+dfsg/debian/changelog	2018-04-25 21:59:49.0 +0200
+++ clamav-0.100.0+dfsg/debian/changelog	2018-07-04 23:14:43.0 +0200
@@ -1,3 +1,9 @@
+clamav (0.100.0+dfsg-0+deb9u2) stretch; urgency=medium
+
+  * Don't fail on recently removed config options (Closes: #902290).
+
+ -- Sebastian Andrzej Siewior   Wed, 04 Jul 2018 23:14:43 +0200
+
 clamav (0.100.0+dfsg-0+deb9u1) stretch; urgency=medium
 
   [ Sebastian Andrzej Siewior ]
diff -Nru clamav-0.100.0+dfsg/debian/.git-dpm clamav-0.100.0+dfsg/debian/.git-dpm
--- clamav-0.100.0+dfsg/debian/.git-dpm	2018-04-25 21:59:43.0 +0200
+++ clamav-0.100.0+dfsg/debian/.git-dpm	2018-07-04 22:11:57.0 +0200
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-7a040ad8b6aad81cd3b37661345727e43e3cd78a
-7a040ad8b6aad81cd3b37661345727e43e3cd78a
+e7d1d6e337cc5ecf533b991879c6374a71c0bf18
+e7d1d6e337cc5ecf533b991879c6374a71c0bf18
 c6bf3661e036ec9579e544d999438b0147e75315
 c6bf3661e036ec9579e544d999438b0147e75315
 clamav_0.100.0+dfsg.orig.tar.xz
diff -Nru clamav-0.100.0+dfsg/debian/patches/Deprecate-unused-options-instead-of-removing-it.patch clamav-0.100.0+dfsg/debian/patches/Deprecate-unused-options-instead-of-removing-it.patch
--- clamav-0.100.0+dfsg/debian/patches/Deprecate-unused-options-instead-of-removing-it.patch	1970-01-01 01:00:00.0 +0100
+++ clamav-0.100.0+dfsg/debian/patches/Deprecate-unused-options-instead-of-removing-it.patch	2018-07-04 22:11:57.0 +0200
@@ -0,0 +1,60 @@
+From e7d1d6e337cc5ecf533b991879c6374a71c0bf18 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Wed, 4 Jul 2018 21:26:50 +0200
+Subject: Deprecate unused options instead of removing it
+
+The following options were removed:
+- StatsHostID
+- StatsEnabled
+- StatsPEDisabled
+- StatsTimeout
+- SubmitDetectionStats
+- DetectionStatsCountry
+- DetectionStatsHostID
+
+and if they remain in the config file (during automatic upgrade without
+user action which would be required by ucf) then clamav will refuse the
+start. By marking them as deprecated clamav will point it out and
+continue. This patch will be dropped by moving to next Debian stable
+version (the user is expected to edit the config manually at this
+point if it did not happen earlier).
+
+BTS: https://bugs.debian.org/902290
+Patch-Name: Deprecate-unused-options-instead-of-removing-it.patch
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ shared/optparser.c | 14 ++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/shared/optparser.c b/shared/optparser.c
+index b5a7208..7dea853 100644
+--- a/shared/optparser.c
 b/shared/optparser.c
+@@ -194,6 +194,14 @@ const struct clam_option __clam_options[] = {
+ 
+ { "LogFile", "log", 'l', CLOPT_TYPE_STRING, NULL, -1, NULL, 0, OPT_CLAMD | OPT_MILTER | OPT_CLAMSCAN | OPT_CLAMDSCAN, "Save all reports to a log file.", "/tmp/clamav.log" },
+ 
++{ "StatsHostID", "stats-host-id", 0, CLOPT_TYPE_STRING, NULL, -1, NULL, 0, OPT_FRESHCLAM | OPT_CLAMD | OPT_CLAMSCAN | OPT_DEPRECATED, "HostID in the form of an UUID to use when submitting statistical information. See the clamscan manpage for more information.", "default" },
++
++{ "StatsEnabled", "enable-stats", 0, CLOPT_TYPE_BOOL, MATCH_BOOL, 0, NULL, 0, OPT_CLAMD | OPT_FRESHCLAM | OPT_CLAMSCAN | OPT_DEPRECATED, "Enable submission of statistical data", "yes" },
++
++{ "StatsPEDisabled", "disable-pe-stats", 0, CLOPT_TYPE_BOOL, MATCH_BOOL, 0, NULL, 0, OPT_CLAMD | OPT_CLAMSCAN | OPT_DEPRECATED, "Disable submission of PE section stati

Bug#902290: Too abrupt removal of configuration option in stable update

[Sebastian Andrzej Siewior]

control: tags -1 patch

On 2018-07-04 14:06:54 [+0200], To Hans van Kranenburg wrote:
> On 2018-06-24 17:12:19 [+0200], Hans van Kranenburg wrote:
> > My mailserver logs now contain 'ERROR: Parse error at line 74: Unknown
> > option StatsHostID', and when that's removed, it reports the next option
> > that is removed, 'StatsPEDisabled', and so on.
> …
> > Or, alternatively when throwing newer versions in stable, they have to
> > be closely inspected to detect options that are removed and get patches
> > like you did for #826406.
> 
> I'm sorry. I've seen the removal of options and I didn't think about
> this. If handle the config file with debconf then the option should
> vanish automaticaly. However if you edit the file manually then user's
> input is required and if nothing happens then clamav will abort.
> 
> I intend to address this to for deb9 and document this behaviour so I
> will remember it next time. I have to figure out who is in charge of
> deb8 and I *think* it is LTS by now.

so I added a fix [0] to the Stretch branch for this. It would be nice if
you could have a look on the Stretch package in case something else is
missing :)

With this change you should see something like
| Jul 04 22:14:08 deb9amd64 clamd[8720]: WARNING: Ignoring deprecated option 
StatsTimeout at line 88
| Jul 04 22:14:08 deb9amd64 clamd[8720]: WARNING: Ignoring deprecated option 
StatsPEDisabled at line 89

and move on.
Now Jessie. It would be nice if the LTS team could pick it up. On the
other hand the point-release exposed the problem and everyone had to
deal with it…

[0] 
https://salsa.debian.org/clamav-team/clamav/blob/stretch/debian/patches/Deprecate-unused-options-instead-of-removing-it.patch

> > Thanks,

Sebastian

Bug#902290: [Pkg-clamav-devel] Bug#902290: Too abrupt removal of configuration option in stable update

[Sebastian Andrzej Siewior]

On 2018-06-24 17:12:19 [+0200], Hans van Kranenburg wrote:
> My mailserver logs now contain 'ERROR: Parse error at line 74: Unknown
> option StatsHostID', and when that's removed, it reports the next option
> that is removed, 'StatsPEDisabled', and so on.
…
> Or, alternatively when throwing newer versions in stable, they have to
> be closely inspected to detect options that are removed and get patches
> like you did for #826406.

I'm sorry. I've seen the removal of options and I didn't think about
this. If handle the config file with debconf then the option should
vanish automaticaly. However if you edit the file manually then user's
input is required and if nothing happens then clamav will abort.

I intend to address this to for deb9 and document this behaviour so I
will remember it next time. I have to figure out who is in charge of
deb8 and I *think* it is LTS by now.

> Thanks,

Sebastian

Bug#902899: [Pkg-clamav-devel] Bug#902899: clamd: yara_exec.c:177: yr_execute_code: Assertion `sp == 0' failed in stable update

[Sebastian Andrzej Siewior]

On 2018-07-03 09:04:21 [+0200], Bernhard Schmidt wrote:
> Jul 03 07:30:24 mail clamd[21927]: LibClamAV Error: yyerror(): 
> /var/lib/clamav/antidebug_antivm.yar line 544 undefined identifier "pe"
> Jul 03 07:30:24 mail clamd[21927]: LibClamAV Error: yyerror(): 
> /var/lib/clamav/antidebug_antivm.yar line 557 undefined identifier "pe"
> Jul 03 07:30:24 mail clamd[21927]: LibClamAV Error: yyerror(): 
> /var/lib/clamav/antidebug_antivm.yar line 603 undefined identifier "pe"
> Jul 03 07:30:24 mail clamd[21927]: LibClamAV Error: yyerror(): 
> /var/lib/clamav/antidebug_antivm.yar line 614 undefined identifier "pe"
> Jul 03 07:30:24 mail clamd[21927]: LibClamAV Warning: cli_loadyara: failed to 
> parse or load 7 yara rules from file /var/lib/clamav/antidebug_antivm.yar, 
> successfully 
> Jul 03 07:40:12 mail clamd[21927]: clamd: yara_exec.c:177: yr_execute_code: 
> Assertion `sp == 0' failed.
> 
> 0.99.4+dfsg-1+deb9u1 -> 0.100.0+dfsg-0+deb9u1
> 
> This is probably related to using third-party signatures, but still a 
> regression.

okay. It is not just "probably". Could you please make the file
available? I will try to forwarded it to clamav upstream and see what
they intend to do about it. The progress on the github issue looks
stale.

> Best Regards,
> Bernhard

Sebastian

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-06-13 08:19:32 [+0200], To Axel Beckert wrote:
> I asked upstream what they thing about ignoring these errors because the
> perl script does so. On the other hand what about cleaning up these
> dangling symlinks?

ca-certificate maintainers: what do we do here?

[ ] we intend to figure out why there are dangling symlinks, no need to
change "openssl rehash" in anyway.

[ ] we intend to figure out why there are dangling symlinks but in the
meantime "openssl rehash" should not error out on them.

[ ] "openssl rehash" should not error out on certificates which can not
be opened. This is the old behavioud and required due to $reason.
 
> > Regards, Axel

Sebastian

Bug#901879: O: wvdial -- intelligent Point-to-Point Protocol dialer

[Sebastian Andrzej Siewior]

Package: wnpp
Severity: normal

I intend to orphan the wvdial package. The package has been removed from
testing because wvstreams is RC-buggy due to the its dependency on
libssl1.0.2. The whole story is in #901361 [0].
The persons that intends to adopt wvdial should also look after
wvstreams. wvdial is the only reverse dependency of wvdial.
I will request the removal of wvdial (including wvstreams) in one month
time if nobody adopts it.

The package description is:
 WvDial sacrifices some of the flexibility of programs like "chat" in order
 to make dialup configuration easier. With WvDial,
 modems are detected automatically and only three additional parameters
 are required: the telephone number, username, and password. WvDial knows
 enough to dial with most modems and log in to most servers without any
 other help.
 .

[0] https://bugs.debian.org/901361

Sebastian

Bug#859719: sslscan: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Marvin, do you have any plans here? Upstream made it clear that they
won't support openssl 1.1.0+ and I doubt that an embedded copy of the
ssl library will work here (not saying it won't, it is not my
decision).

Sebastian

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-06-13 00:10:57 [+0200], Axel Beckert wrote:
> Hi Sebastian,
Hi Axel,

> Sebastian Andrzej Siewior wrote:
> > > I don't think so unless a future upload of OpenSSL to unstable fixes
> > > this. The recent one to unstable didn't.
> > 
> > forwarded https://github.com/openssl/openssl/issues/6475
> > 
> > Just a little question: The missing certificates:
> > |rehash: error: skipping Swisscom_Root_CA_1.pem, cannot open file
> > |rehash: error: skipping Swisscom_Root_CA_2.pem, cannot open file
> > |rehash: error: skipping GeoTrust_Global_CA_2.pem, cannot open file
> > |rehash: error: skipping Swisscom_Root_EV_CA_2.pem, cannot open file
> > 
> > where are they from?
> 
> From the ca-certificates package I assume. At least those errors go
> away if I downgrade to 20170717 again and they reappear as soon as I
> upgrade to 20180409 on that machine. At least the file names are the
> same as in my mail from 12th of April[1] (just in different order).
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895482#10
> 
> I just checked: All four CAs are CAs I've chosen to be enabled. But
> they're by far not the only CAs which are enabled from ca-certificates
> on that machine. So I have no idea what makes those four special.

Okay. So this is "normal" debconf and nothing more. Just wanted to make
sure.

> > Is there something specific you did to get those
> > symlinks which now don't belong to a real file?
> 
> No. As mentioned in the initial report, I have ca-certificates to ask
> me every time on new CAs if I want to enable them or not. And I'm
> rather conservative with enabling CAs. I also do this on most of my
> machines, usually with slight differences in the list of enabled CAs.
> Nevertheless this only happened on two of my machines.

I asked upstream what they thing about ignoring these errors because the
perl script does so. On the other hand what about cleaning up these
dangling symlinks?

>   Regards, Axel

Sebastian

Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-06-12 22:29:42 [+0200], Axel Beckert wrote:
> Shall I try the version from Experimental, too?
no.

> > (Should some Breaks be added, Depends made stricter?)
> 
> I don't think so unless a future upload of OpenSSL to unstable fixes
> this. The recent one to unstable didn't.

forwarded https://github.com/openssl/openssl/issues/6475

Just a little question: The missing certificates:
|rehash: error: skipping Swisscom_Root_CA_1.pem, cannot open file
|rehash: error: skipping Swisscom_Root_CA_2.pem, cannot open file
|rehash: error: skipping GeoTrust_Global_CA_2.pem, cannot open file
|rehash: error: skipping Swisscom_Root_EV_CA_2.pem, cannot open file

where are they from? Is there something specific you did to get those
symlinks which now don't belong to a real file?

>   Regards, Axel

Sebastian

Bug#901361: RM: wvstreams -- unmaintained, dead upstream, depends on libssl1.0.2

[Sebastian Andrzej Siewior]

Package: ftp.debian.org

wvstreams is rc-buggy due to its libssl1.0.2 requirement, QA maintained.
I asked about its status on d-qa-packages@l.d.o [0] and later on
d-devel@l.d.o [1].

wvstreams is dead upstream, last github commit is from 2011.
Its only reverse dependency is wvdial (Debian maintainer on Cc:).

wvdial is dead upstream (homepage not reachable), last upload in 2012.
Its only reverse dependency is gnome-ppp.

gnome-ppp is dead upstream, not part of the gnome project (explained in
[2]). Last upload moved the package to QA in 2017 and the upload before
that was in 2012. Alexey Loginov asked to replace it with a fork in
#813804 and he has been added Cc.

It looks to me that gnome-ppp could be removed without hesitation.
People interested in wvdial should also show interest in wvstreams,
too.

Alternatives as suggested in [2]:
|Alternatives to wvdial include pppconfig (orphaned) or configuring
|pppd by writing configuration files directly (hardly user-friendly,
|but probably enough for retrocomputing enthusiasts).

and [3] added:
|If someone is really enthusiastic, they might want to write a
|plugin for MM supporting their favourite ZyXEL or whatever.
|Shouldn't be hard and would automatically integrate into the
|wonderful world of NM. Needs C and glib knowledge.

Based on popcon the reason for wvstreams is wvdial.
With that background I am asking for the removal of wvstreams and its
reverse dependencies. I could also clone this bug as an O: bug against
each package and if nobody adopts the package (especially wvstreams)
within one Month I would reassign it back here.

[0] 
https://lists.debian.org/msgid-search/20180531220103.p56ajmkirte3p...@breakpoint.cc
[1] 
https://lists.debian.org/msgid-search/20180605194636.igsc6xuhpbm2b...@breakpoint.cc
[2] 
https://lists.debian.org/msgid-search/20180605221528.ga32...@espresso.pseudorandom.co.uk
[3] https://lists.debian.org/msgid-search/20180605222635.GA29088@fama

Sebastian

Bug#833692: pinot: links GPLv2+ code with OpenSSL

[Sebastian Andrzej Siewior]

On 2017-03-01 12:53:23 [+1300], Olly Betts wrote:
> Upstream addressed this by avoiding linking libxapianbackend.so to
> openssl (apparently it doesn't use it anyway):
> 
> https://github.com/FabriceColin/pinot/commit/3a40d5abe159a106f3aabaedf1a199020946b3b5

pinot has currently two RC bugs and failed to build during the curl4
transition / binNMU.
Does it make sense to add the two patches (Olly pointed to) and upload
it or would a RM make sense?

> Cheers,
> Olly
> 

Sebastian

Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

[Sebastian Andrzej Siewior]

On 2018-04-22 16:55:21 [+0200], Axel Beckert wrote:
> Hi Michael,
Hi,

> Michael Shuler wrote:
> > Thanks for the details. #895473 reported a similar error on locally
> > installed CA certificates, which I think may be related.
> 
> That other bug report indeed looks similar albeit not identical.
…
> (That's why I've now downgraded ca-certificates on my two affected
> machines.)

I've read about this bug (and the other one) on d-devel. I uploaded
recently a new version of openssl to unstable (1.1.0h-3)which changes
the exit code of "openssl rehash" to zero in case of a duplicate or if a
certificate can no be open.
I left this bug open in case the maintainer of this package wants to
investigate why there are duplicates or non-existing certificates.

>   Regards, Axel

Sebastian

Bug#900160: ruby-eventmachine: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: ruby-eventmachine
Version: 1.0.7-4
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|TestSSLMethods: 
|  test_ssl_methods:
140136548670336:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too 
small:../ssl/ssl_rsa.c:310:
|ruby2.5: ssl.cpp:173: SslContext_t::SslContext_t(bool, const string&, const 
string&): Assertion `e > 0' failed.
|Aborted

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/ruby-eventmachine_1.0.7-4_amd64-2018-05-01T21%3A04%3A28Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/ruby-eventmachine_1.0.7-4_amd64-2018-05-02T18%3A51%3A11Z

Sebastian

Bug#900161: ruby-openssl: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: ruby-openssl
Version: 2.0.5-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|/<>/test/test_ssl.rb:1280:in `initialize': 
SSL_CTX_use_certificate: ee key too small (OpenSSL::SSL::SSLError)

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/ruby-openssl_2.0.5-1_amd64-2018-05-01T21%3A05%3A24Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/ruby-openssl_2.0.5-1_amd64-2018-05-02T18%3A51%3A30Z

Sebastian

Bug#900159: python-glanceclient: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: python-glanceclient
Version: 1:2.9.1-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|==
|FAIL: 
glanceclient.tests.unit.test_ssl.TestHTTPSVerifyCert.test_v2_requests_cert_verification
|glanceclient.tests.unit.test_ssl.TestHTTPSVerifyCert.test_v2_requests_cert_verification
|--
|_StringException: Traceback (most recent call last):
|  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
|return func(*args, **keywargs)
|  File "glanceclient/tests/unit/test_ssl.py", line 128, in 
test_v2_requests_cert_verification
|self.fail('No certificate failure message is received')
|  File "/usr/lib/python2.7/dist-packages/unittest2/case.py", line 690, in fail
|raise self.failureException(msg)
|AssertionError: No certificate failure message is received

might be due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/python-glanceclient_2.9.1-2_amd64-2018-05-01T20%3A53%3A40Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/python-glanceclient_2.9.1-2_amd64-2018-05-02T18%3A49%3A00Z

Sebastian

Bug#900158: python3.5: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: python3.5
Version: 3.5.5-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
| ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:2976)

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/python3.5_3.5.5-1_amd64-2018-05-02T02%3A25%3A07Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/python3.5_3.5.5-1_amd64-2018-05-02T18%3A48%3A29Z

Sebastian

Bug#900156: puma: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: puma
Version: 3.11.3-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|TestPumaServerSSLClient#test_verify_client_cert = 
|E: Build killed with signal TERM after 150 minutes of inactivity

might be due to the fact that once TLS1.3 is enabled, the SSL_read()
function might return error SSL_ERROR_WANT_READ asking it for a retry.
An "automatic" fix to this behaviour is currently discussed upstream [3]
but it has been always part of the doccumentation - it just hardly
occured before.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/puma_3.11.3-1_amd64-2018-05-01T23%3A16%3A10Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/puma_3.11.3-1_amd64-2018-05-02T18%3A47%3A34Z
[3] https://github.com/openssl/openssl/issues/6234

Sebastian

Bug#900157: python2.7: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: python2.7
Version: 2.7.15-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:2779)

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/python2.7_2.7.15-1_amd64-2018-05-02T02%3A16%3A01Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/python2.7_2.7.15-1_amd64-2018-05-02T18%3A47%3A42Z

Sebastian

Bug#900154: pion: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: pion
Version: 5.0.7+dfsg-4
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|unknown location(0): fatal error: in 
"WebServerTests_S/checkSendRequestsAndReceiveResponsesUsingSSL": 
boost::exception_detail::clone_impl: use_certificate_file: ee key too small

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/pion_5.0.7%2Bdfsg-4_amd64-2018-05-01T20%3A49%3A03Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/pion_5.0.7%2Bdfsg-4_amd64-2018-05-02T18%3A47%3A26Z

Sebastian

Bug#900153: openvswitch: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: openvswitch
Version: 
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
| 2018-05-01T21:13:48Z|3|stream_ssl|ERR|SSL_use_certificate_file: 
error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/openvswitch_2.8.1%2Bdfsg1-6_amd64-2018-05-01T20%3A39%3A52Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/openvswitch_2.8.1%2Bdfsg1-6_amd64-2018-05-02T18%3A47%3A08Z

Sebastian

Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: nsca-ng
Version: 1.5-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error in the testsuite could be due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/nsca-ng_1.5-2_amd64-2018-05-01T20%3A31%3A09Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/nsca-ng_1.5-2_amd64-2018-05-02T18%3A46%3A37Z

Sebastian

Bug#898807: nova: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: nova
Version: 2:17.0.0-4
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|==
|FAIL: 
nova.tests.unit.virt.xenapi.test_xenapi.XenAPIDiffieHellmanTestCase.test_encrypt_newlines_inside_message
|nova.tests.unit.virt.xenapi.test_xenapi.XenAPIDiffieHellmanTestCase.test_encrypt_newlines_inside_message
|--
|_StringException: pythonlogging:'': {{{2018-05-01 20:48:09,960 WARNING 
[oslo_config.cfg] Config option key_manager.api_class  is deprecated. Use 
option key_manager.backend instead.}}}
|
|Traceback (most recent call last):
|  File "/<>/nova/tests/unit/virt/xenapi/test_xenapi.py", line 
1592, in test_encrypt_newlines_inside_message
|self._test_encryption('Message\nwith\ninterior\nnewlines.')
|  File "/<>/nova/tests/unit/virt/xenapi/test_xenapi.py", line 
1577, in _test_encryption
|enc = self.alice.encrypt(message)
|  File "/<>/nova/virt/xenapi/agent.py", line 432, in encrypt
|return self._run_ssl(text).strip('\n')
|  File "/<>/nova/virt/xenapi/agent.py", line 428, in _run_ssl
|raise RuntimeError(_('OpenSSL error: %s') % err)
|RuntimeError: OpenSSL error: *** WARNING : deprecated key derivation used.
|Using -iter or -pbkdf2 would be better.

seems to be due to an additional message on stderr.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/nova_17.0.0-4_amd64-2018-05-01T20%3A39%3A38Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/nova_17.0.0-4_amd64-2018-05-02T18%3A46%3A36Z

Sebastian

Bug#898805: nodejs: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: nodejs
Version: 8.11.1~dfsg-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/nodejs_8.11.1~dfsg-2_amd64-2018-05-01T20%3A40%3A21Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/nodejs_8.11.1~dfsg-2_amd64-2018-05-02T18%3A46%3A33Z

Sebastian

Bug#898804: myproxy: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: myproxy
Version: 6.1.28-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

|The Error
|Problem with server credentials. GSS Major Status: General failure GSS Minor 
Status Error Chain: globus_gsi_gssapi: Error with GSI credential 
globus_gsi_gssapi: Error with gss credential handle globus_gsi_gssapi: Error 
with openssl: Couldn't set the certificate to be used for the SSL context 
OpenSSL Error: ../ssl/ssl_rsa.c:310: in library: SSL routines, function 
SSL_CTX_use_certificate: ca md too weak  
|FAIL myproxy-test-wrapper (exit status: 1)

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/myproxy_6.1.28-2_amd64-2018-05-01T20%3A28%3A31Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/myproxy_6.1.28-2_amd64-2018-05-02T18%3A46%3A02Z

Sebastian

Bug#898803: globus-gssapi-gsi: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: globus-gssapi-gsi
Version: 13.5-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

I suspect the failure due to a too small key in the testsuite
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/globus-gssapi-gsi_13.5-1_amd64-2018-05-01T20%3A05%3A40Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/globus-gssapi-gsi_13.5-1_amd64-2018-05-02T18%3A43%3A41Z

Sebastian

Bug#898802: globus-gram-job-manager: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: globus-gram-job-manager
Version: 14.36-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

I suspect a too small key in the testsuite 1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/globus-gram-job-manager_14.36-2_amd64-2018-05-01T20%3A03%3A44Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/globus-gram-job-manager_14.36-2_amd64-2018-05-02T18%3A43%3A40Z

Sebastian

Bug#898801: globus-gass-copy: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: globus-gass-copy
Version: 9.28-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?
The Error 
|# 530-OpenSSL Error: ../ssl/ssl_rsa.c:310: in library: SSL routines, function 
SSL_CTX_use_certificate: ee key too small

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/globus-gass-copy_9.28-1_amd64-2018-05-01T20%3A03%3A39Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/globus-gass-copy_9.28-1_amd64-2018-05-02T18%3A43%3A39Z

Sebastian

Bug#898800: foolscap: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: foolscap
Version: 0.13.1-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
There was a discussion about this on openssl's issue tracker [3], [4].

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/foolscap_0.13.1-1_amd64-2018-05-02T00%3A10%3A30Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/foolscap_0.13.1-1_amd64-2018-05-02T18%3A43%3A34Z
[3] https://github.com/openssl/openssl/issues/6228
[4] https://github.com/openssl/openssl/issues/6234

Sebastian

Bug#898470: openssl says "Can't load /root/.rnd into RNG"

[Sebastian Andrzej Siewior]

On 2018-05-12 05:38:05 [+], Sander Jonkers wrote:
> Second command (goed wrong):
> # openssl req -new -x509 -key example.com.key -out example.com.cert -days 
> 3650 -subj /CN=example.com  
> Can't load /root/.rnd into RNG
> 140283178746304:error:2406F079:random number generator:RAND_load_file:Cannot 
> open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
> 
> I would have expected no error.

It does say error, but everything completes as expected, correct?

Sebastian

Bug#897658: m2crypto: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: m2crypto
Version: 0.27.0-5
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look? It seems not to like the new version
string:

|I: pybuild base:217: python2.7 setup.py clean 
|Traceback (most recent call last):
|  File "setup.py", line 256, in 
|if openssl_version('1.1.0', required=True):
|  File "setup.py", line 84, in openssl_version
|return StrictVersion(ver_str) >= StrictVersion(req_ver)
|  File "/usr/lib/python2.7/distutils/version.py", line 40, in __init__
|self.parse(vstring)
|  File "/usr/lib/python2.7/distutils/version.py", line 107, in parse
|raise ValueError, "invalid version number '%s'" % vstring
|ValueError: invalid version number '1.1.1-pre6'
|E: pybuild pybuild:336: clean: plugin distutils failed with: exit code=1: 
python2.7 setup.py clean 
|dh_auto_clean: pybuild --clean --test-pytest -i python{version} -p 2.7 
returned exit code 13
|make: *** [debian/rules:15: clean] Error 25

this is probably temporary until the `-preX' suffix vanishes in the
final release but it would nice to handle it in the meantime.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/m2crypto_0.27.0-5_amd64-2018-05-02T20%3A11%3A27Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/m2crypto_0.27.0-5_amd64-2018-05-02T18%3A45%3A27Z

Sebastian

Bug#897652: globus-ftp-client: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: globus-ftp-client
Version: 8.36-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The problem is the 1024bit RSA key in the testsuite due to (1.1.1~~pre6-1
changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

The key can be upgraded via
sed s@1024@2048 -i test/Makefile.am

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/globus-ftp-client_8.36-2_amd64-2018-05-01T22%3A33%3A50Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/globus-ftp-client_8.36-2_amd64-2018-05-02T18%3A43%3A38Z

Sebastian