[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#927118: unblock: python-trustme/0.4.0-3



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

Please unblock package python-trustme

This fixes a second FTBFS, further to the previous unblock request in
bug 925576. This time the build failed on the buildds but not in my
local testing because openssl was installed there, which (correctly)
isn't a build dependency.

The fix is to generate larger keys. The same change has now been
accepted by upstream.

diff -Nru python-trustme-0.4.0/debian/changelog python-trustme-0.4.0/debian/changelog
--- python-trustme-0.4.0/debian/changelog	2018-10-13 22:48:59.000000000 +0100
+++ python-trustme-0.4.0/debian/changelog	2019-04-13 17:30:43.000000000 +0100
@@ -1,3 +1,19 @@
+python-trustme (0.4.0-3) unstable; urgency=medium
+
+  * d/p/keysize: bump test key sizes to 2048 to fulfil Debian's new default
+    requirement. This fixes another FTBFS due to test failure in the case that
+    the openssl binary package is installed, which is not a build dependency,
+    but apparently the buildds have it by default. Closes: #926652.
+
+ -- Robie Basak <robie@justgohome.co.uk>  Sat, 13 Apr 2019 17:30:20 +0100
+
+python-trustme (0.4.0-2) unstable; urgency=medium
+
+  * Explicitly build-depend on python3-idna to fix FTBFS.
+    Closes: #925566.
+
+ -- Robie Basak <robie@justgohome.co.uk>  Tue, 26 Mar 2019 23:22:42 +0000
+
 python-trustme (0.4.0-1) unstable; urgency=low
 
   * Initial release. Closes: #910951.
diff -Nru python-trustme-0.4.0/debian/control python-trustme-0.4.0/debian/control
--- python-trustme-0.4.0/debian/control	2018-10-13 22:48:59.000000000 +0100
+++ python-trustme-0.4.0/debian/control	2019-04-13 17:22:21.000000000 +0100
@@ -6,6 +6,7 @@
 Build-Depends: debhelper (>= 9~),
                dh-python,
                python3,
+               python3-idna,
                python3-openssl,
                python3-pytest,
                python3-service-identity,
diff -Nru python-trustme-0.4.0/debian/patches/keysize python-trustme-0.4.0/debian/patches/keysize
--- python-trustme-0.4.0/debian/patches/keysize	1970-01-01 01:00:00.000000000 +0100
+++ python-trustme-0.4.0/debian/patches/keysize	2019-04-13 17:26:01.000000000 +0100
@@ -0,0 +1,33 @@
+From 96b8799325fa0f53fad4db529cbd2d25af42ebff Mon Sep 17 00:00:00 2001
+From: Robie Basak <robie@justgohome.co.uk>
+Date: Sat, 13 Apr 2019 17:02:53 +0100
+Subject: [PATCH] Increase key size to 2048 bits
+
+Debian changed the default security level to 2 since openssl package
+version 1.1.1~~pre9-1 (August 2018), which requires a minimum key size
+of 2048 bit or larger RSA and DHE keys. To avoid test failures on newer
+Debian systems against OpenSSL, use a key size of at least 2048 bits.
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926652
+Forwarded: https://github.com/python-trio/trustme/pull/45
+Last-Update: 2019-04-13
+---
+ trustme/__init__.py | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/trustme/__init__.py
++++ b/trustme/__init__.py
+@@ -33,7 +33,12 @@
+ # On my laptop, making a CA + server certificate using 1024 bit keys takes ~40
+ # ms, and using 4096 bit keys takes ~2 seconds. We want tests to run in 40 ms,
+ # not 2 seconds.
+-_KEY_SIZE = 1024
++#
++# However, Debian changed the default security level to 2 in openssl
++# 1.1.1~~pre9-1 (August 2018), which requires a minimum key size of 2048 bit or
++# larger for RSA and DHE keys. To avoid test failures on newer Debian systems
++# against OpenSSL, we must therefore use a key size of at least 2048 bits.
++_KEY_SIZE = 2048
+ 
+ def _name(name):
+     return x509.Name([
diff -Nru python-trustme-0.4.0/debian/patches/series python-trustme-0.4.0/debian/patches/series
--- python-trustme-0.4.0/debian/patches/series	1970-01-01 01:00:00.000000000 +0100
+++ python-trustme-0.4.0/debian/patches/series	2019-04-13 17:25:34.000000000 +0100
@@ -0,0 +1 @@
+keysize

unblock python-trustme/0.4.0-3

Attachment: signature.asc
Description: PGP signature


Reply to: