[Touch-packages] [Bug 1828215] Re: openssl ca -spkac output regressed
Here's a recipe for generating a CA directory for testing. It assumes you have already generated a CA key and cert. touch $CA_DIR/index.txt echo '1000' > $CA_DIR/serial echo '1000' > $CA_DIR/crlnumber mkdir -m 700 $CA_DIR/newcerts mkdir -m 700 $CA_DIR/private mkdir $CA_DIR/certs cp $CA_KEY $CA_DIR/private/ca_key.pem chmod 600 $CA_DIR/private/ca_key.pem cp $CA_CERT $CA_DIR/certs/ca_cert.pem Those paths need to correspond to those set in the "[ CA_default ]" section of the openssl.cnf file. E.g. [ ca ] default_ca = CA_default# The default ca section [ CA_default ] dir = somedir/ca_dir# Where everything is kept certs = $dir/certs# Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database= $dir/index.txt# database index file. unique_subject = no# Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/certs/ca_cert.pem serial = $dir/serial # The current serial number crlnumber = $dir/crlnumber# the current crl number # must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/private/ca_key.pem RANDFILE= $dir/.rand# private random number file The initial crl file can be generated like so: cat ca_key_passphrase_file.txt | openssl ca -gencrl -out $CA_DIR/crl.pem -config /path/to/test.openssl.cnf -passin stdin Use 'openssl req' to generate the cert request private key. Use 'openssl spkac' to generate the spkac cert request data. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1828215 Title: openssl ca -spkac output regressed Status in OpenSSL: Unknown Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Bionic: Confirmed Status in openssl source package in Cosmic: Confirmed Status in openssl source package in Disco: Confirmed Status in openssl source package in Eoan: Confirmed Bug description: [Impact] * openssl command line utility option parsing has regressed in 1.1.0i+ and produces binary output, where text output is expected, breaking applications that parse that. [Test Case] * OPENSSL_ENABLE_MD5_VERIFY=1 openssl ca -config test.openssl.cnf -passin stdin -batch -spkac input_file -startdate 190121130654Z Currently produces binary goop. Should produce PEM format Base64 encoded certificate data in a block surrounded with BEGIN/END certificate. [Regression Potential] * This is a regression in cosmic and up, and impeding regression in bionic with the upcoming 1.1.1 SRU. A bugfix exists upstream. [Other Info] * Originally reported https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/39 To manage notifications about this bug go to: https://bugs.launchpad.net/openssl/+bug/1828215/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
@Dimitri The https://bugs.launchpad.net/openssl/+bug/1828215 issue affects a custom application. I don't know whether any packages shipped in Ubuntu are directly impacted. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: Fix Released Status in python-tornado package in Ubuntu: Confirmed Status in libio-socket-ssl-perl source package in Bionic: Incomplete Status in libnet-ssleay-perl source package in Bionic: Incomplete Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: Confirmed Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in: http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html And analyzed in https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652 [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. - non-application data records. TLSv1.3 sends more of these, when compared with previous versions, and some applications may not handle this correctly. Resulting in application data not being available, when previously expected. Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY or setting max protocol version to TLSv1.2. For example see discussion identified in the perl stack https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034 Similar hangs are possible with prior versions of TLS as well, it is however easier to trigger this with TLSv1.3. * This update bundles python 3.6 and 3.7 point releases [Other Info] * Previous FFe for OpenSSL in 18.10 is at
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Relative to openssl 1.1.0g-2ubuntu4.3, openssl 1.1.1 (via 1.1.0i) has a regression in the "openssl ca -spkac" interface that will break applications that depend on the output of that command: https://github.com/openssl/openssl/issues/8055 The fix is in master, but has not been backported to 1.1.1: https://github.com/openssl/openssl/commit/69f6b3ceaba493e70e1296880ea6c93e40714f0f Would it be possible to include that fix in Ubuntu 18.04 openssl 1.1.1, so as to avoid this regression? ** Bug watch added: github.com/openssl/openssl/issues #8055 https://github.com/openssl/openssl/issues/8055 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: Fix Released Status in python-tornado package in Ubuntu: Confirmed Status in libio-socket-ssl-perl source package in Bionic: Incomplete Status in libnet-ssleay-perl source package in Bionic: Incomplete Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: Confirmed Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in: http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html And analyzed in https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652 [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. - non-application data records. TLSv1.3 sends more of these, when compared with previous versions, and some applications may not handle this correctly. Resulting in application data not being available, when previously expected. Mitigation around these involve disabling/enabling
