[Touch-packages] [Bug 1469834] Re: openssl 1.0.1f-1ubuntu2.15 prevents connection to WPA Enterprise networks

[Adrien Nader]

Thanks for the analysis and testing. I think we can mark this issue as
Won't Fix, especially after all this time.

-- 
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/1469834

Title:
  openssl 1.0.1f-1ubuntu2.15 prevents connection to WPA Enterprise
  networks

Status in openssl package in Ubuntu:
  Triaged

Bug description:
  The current version of openssl/libssl in Ubuntu 14.04
  (1.0.1f-1ubuntu2.15) breaks wireless connectivity to WPA Enterprise
  networks at my institution.  WPA 2 personal networks are unaffected
  (my home setup).  If I install the "-1ubuntu2.12" version of openssl,
  libssl (amd64 and i386) I can once again connect to the WPA Enterprise
  network (I need to manually restart networking via network-manager
  *and* make sure to kill wpa_supplicant from the command line to make
  sure that the broken library is no longer loaded).


  The WPA Enterprise network in question can be accessed a few different
  ways.  One way uses TLS and certs, the other uses Tunneled TLS, no
  cert, but a username/password combination.  Both methods break upon
  installing the new openssl & libssl.

  I'm marking this as a security vulnerability because the only way (for
  me) to currently access WPA Enterprise networks is to run an older
  version of openssl

  lsb_release -rd
  Description:  Ubuntu 14.04.2 LTS
  Release:  14.04

  *Working* version of package:
  apt-cache policy openssl
  openssl:
Installed: 1.0.1f-1ubuntu2.12
Candidate: 1.0.1f-1ubuntu2.15
Version table:
   1.0.1f-1ubuntu2.15 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 
Packages
   *** 1.0.1f-1ubuntu2.12 0
  100 /var/lib/dpkg/status
   1.0.1f-1ubuntu2 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

  The "candidate" version listed above breaks WPA enterprise.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: openssl 1.0.1f-1ubuntu2.12
  ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20
  Uname: Linux 3.13.0-55-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Jun 29 13:05:58 2015
  SourcePackage: openssl
  UpgradeStatus: Upgraded to trusty on 2014-06-03 (391 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1469834/+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 1832822] Re: functionality stopped working (extra new_oids policy)

[Adrien Nader]

I've tried to reproduce on Lunar and got a CSR. I'm going to mark this
as Fix Released.

** Changed in: openssl (Ubuntu)
   Status: New => Fix Released

-- 
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/1832822

Title:
  functionality stopped working (extra new_oids policy)

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Unable to generate certificate request targeting new_oids policy.

  It used to work on this machine, looks like openssl got updated just
  few days ago: 12-06-2019

  The command and exit result:
  gge@itstools-04:~/ssl_ownca/direct_1$ openssl req -new -key direct_1.key -out 
direct_1.csr -subj '/2.5.4.97=direct_1/O=Sample Direct 
1/C=NL/ST=NorthHolland/L=Amsterdam/CN=direct_1.sample.net'problem creating 
object psd2=2.5.4.97
  140648544747968:error:08064066:object identifier routines:OBJ_create:oid 
exists:../crypto/objects/obj_dat.c:709:
  gge@itstools-04:~/ssl_ownca/direct_1$ echo $?
  1

  No CSR file is produced
  (openssl1.1.1-1ubuntu2.1~18.04.1)

  
  re-playing this on different machines provides correct results:
fresh unupdated ubuntu-18.04.1-live-server-amd64.iso install:  openssl   
1.1.0g-2ubuntu4.1
old unupdated CentOS release 6.10 (Final):  openssl-1.0.1e-57.el6.x86_64

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
  Uname: Linux 4.15.0-50-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  Date: Fri Jun 14 10:00:10 2019
  ProcEnviron:
   LANG=en_US.UTF-8
   SHELL=/bin/bash
   TERM=xterm
   PATH=(custom, no user)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.ssl.openssl.cnf: 2019-06-14T09:29:39.313665

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832822/+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 50333] Re: Default configuration file prevents the creation of a valid Certificate Authority

[Adrien Nader]

I'm leaning towards marking this bug as Won't Fix. As stated above, this
is needed by a minority of users and the current configuration (which is
still the same regarding this) is therefore sound for the vast majority
of users. Moreover this would have consequences for this majority of
users as stated in the configuration:

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

-- 
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/50333

Title:
  Default configuration file prevents the creation of a valid
  Certificate Authority

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  When using the default configuration file and the script
  /usr/lib/ssl/misc/CA.[sh|pl] -newca is run, the certificate authority
  created by the script is not authorized to issue certificates.

  An error is issued by Windows' clients after the certificate is
  imported:

  "This Certificate is not valid because one of the certification
  authorities in the certification path does not appear to be allowed to
  issue certificates or this certificate cannot be used as an end-entity
  certificate."

  To correct the problem, one line needs to be modified in the [
  CA_default ] section of /etc/ssl/openssl.cnf:

  Change this:

  x509_extensions = usr_crt

  To this:

  x509_extensions = v3_ca

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/50333/+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 429907] Re: md4 should be deprecated

[Adrien Nader]

And as far as I can tell, gnutls doesn't use MD4 anymore. Marking as Fix
released also for gnutls26.

** Changed in: gnutls26 (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/429907

Title:
  md4 should be deprecated

Status in gnutls26 package in Ubuntu:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  openssl s_client and konqueror seem to accept md4 signatures.

  IMO md4 is weak - there is preimage attack [1] of 2 rounds 7 steps in
  8 hours (the full md4 is 3 rounds == 48 steps == 2 rounds 16 steps.

  having in mind the 8 hours attack is by m$, i am inclined to believe
  an attack by skilful attacker will take seconds.

  note that it is irrelevant if any CA issues new md4 certs - it is
  enough to have old valid md4 signature.

  [1] http://sat07.ecs.soton.ac.uk/slides/kumarasubramanian-sat07-talk.pdf
  Inversion Attacks on Secure Hash Functions using Sat Solvers

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/429907/+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 654896] Re: SCTP DTLS support

[Adrien Nader]

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Fix Released

-- 
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/654896

Title:
  SCTP DTLS support

Status in OpenSSL:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssl

  Ubuntu's OpenSSL does not yet provide support for SCTP DTLS. This
  would be nice ;-)

  As an interim measure, it would be helpful to see Ubuntu move toward
  OpenSSL 1.0.1 as this can be replaced with a patched version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/654896/+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 1404029] Re: Segfault in openssl command line utility

[Adrien Nader]

The file private_key.pem was not provided and this makes it impossible
to run the reproducer unfortunately.

** Changed in: openssl (Ubuntu)
   Status: New => Incomplete

-- 
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/1404029

Title:
  Segfault in openssl command line utility

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  
  openssl (1.0.1-4ubuntu5.20) on 12.04(.5) crashes with segfault when 
attempting to decrypt a malformed SMIME file. The reproducer is attached and 
the command line which yields the crash is:

  $ openssl smime -decrypt -inkey /tmp/private_key.pem <
  /tmp/sample.smime

  Upstream openssl seems to correctly report an error when reading the
  file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1404029/+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 1144408] Re: libssl upgrade causes failure from old clients

[Adrien Nader]

As far as I can understand from the mailing-list thread, the patch
unfortunately did not get merged. However, the versions against which
this issue has been reported are also very old at this point and I think
this means the issue will be WONTFIX.

-- 
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/1144408

Title:
  libssl upgrade causes failure from old clients

Status in openssl package in Ubuntu:
  New

Bug description:
  Upgrade of libssl1.0.0 Precise from version 1.0.1-4ubuntu5.5 to
  version 1.0.1-4ubuntu5.7 causes failure of negotiation by old clients.

  I am running apache2 on servers with self-signed certs (I enclose one
  such). Before upgrade, I can do a 'curl -k' (insecure) and connect
  successfully whether or not the CN in the self-signed certificate
  matches the CN in the URL, and irrespective of the version of libssl
  running on the client (for this test I am using an IP address and a
  domain name mapping to that IP address).

  Certs are generated with
openssl genrsa -out foo.key 1024
openssl req -new -key foo.key foo.csr -subj 
"/C=XX/ST=Test/L=Test/O=Test/OU=Test/CN=${ENDPOINT}"
openssl x509 -req -days 36500 -in foo.csr -signkey foo.key -out foo.crt

  After the upgrade, all works fine from the host itself (i.e. curl to
  the IP address in the CN, or curl to a DNS name pointing to it but not
  in the CN), but connection from older clients report:

  Ximines:~ amb$ curl -vv -k "https://cp.dev2.flexiant.net:4443/?wsdl; ; 
echo ""
  * About to connect() to cp.dev2.flexiant.net port 4443 (#0)
  *   Trying 10.20.0.2... connected
  * Connected to cp.dev2.flexiant.net (10.20.0.2) port 4443 (#0)
  * SSLv3, TLS handshake, Client hello (1):
  * error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
  * Closing connection #0
  curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

  whereas

  $ curl -k "https://10.20.0.2:4443/?wsdl;

  works fine

  This error is ONLY produced when connecting to a URL not matching the
  CN. If I connect to a URL that does match the CN it works fine
  (presumably it bails out earlier).

  If I force version 3 negotiation with the -3 option, it works fine.

  As the version of curl has not changed, I suspect libssl, though it's
  possible curl is not checking for all error conditions.

  
  Self-signed cert that errors (private key is worthless so included too):

  -BEGIN CERTIFICATE-
  MIICMzCCAZwCCQCX1VMZB/s5ozANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJY
  WDENMAsGA1UECAwEVGVzdDENMAsGA1UEBwwEVGVzdDENMAsGA1UECgwEVGVzdDEN
  MAsGA1UECwwEVGVzdDESMBAGA1UEAwwJMTAuMjAuMC4yMCAXDTEyMTEwMjExNTIz
  N1oYDzIxMTIxMDA5MTE1MjM3WjBdMQswCQYDVQQGEwJYWDENMAsGA1UECAwEVGVz
  dDENMAsGA1UEBwwEVGVzdDENMAsGA1UECgwEVGVzdDENMAsGA1UECwwEVGVzdDES
  MBAGA1UEAwwJMTAuMjAuMC4yMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1
  1b1RegfDBSATwP7W5kxY6oB1dgBQDmxU9gOhGo06NEyUt88mZmRCLuw9eI9c3Ho/
  2P3DleB1HC+8buFn4b0+1c6Chk+gGifsX+3mHmVgjoeoxxk8+3wOjw848FxJ+RZ1
  H/FHFPDSjQPfIg6jFPo5Wab4g7Depb/PoDOjgWQ+nQIDAQABMA0GCSqGSIb3DQEB
  BQUAA4GBAArf2LS6G3Mh21qrR0UiAc1ekFw3JQvjRG8MSl+nCX3eHjBk1PDvMYs0
  Hfh6HVRCBcleQn7xMHxTXw7wNyaoFeI4hl+GYHwzJONcVVSq+1wfIuzPC0YY6uPi
  jUOSgUdnWvbZje0W4VM3/437793wPtP+fUVwEAAOGT70tC65R3CI
  -END CERTIFICATE-

  -BEGIN RSA PRIVATE KEY-
  MIICXAIBAAKBgQC11b1RegfDBSATwP7W5kxY6oB1dgBQDmxU9gOhGo06NEyUt88m
  ZmRCLuw9eI9c3Ho/2P3DleB1HC+8buFn4b0+1c6Chk+gGifsX+3mHmVgjoeoxxk8
  +3wOjw848FxJ+RZ1H/FHFPDSjQPfIg6jFPo5Wab4g7Depb/PoDOjgWQ+nQIDAQAB
  AoGAJgWzuL3Tsav4sSjCIR23CUC/68/o8NSTQpDO4Xkz3t/gw5hL8LOoc05sh84V
  7E0OIxu0tJk6fkKOmNB2wcoqUAbcFnyItvi76EirQ2nu7x7zBhVNhJuYBGvTegG9
  ByN7+arc+jvRq1Y36c999SN0wYEZpMdIKKOLBO2RgYnmQ+ECQQDoKVd6aH3fOlAC
  ufTLH9duOILjeshH+N/Zuedq1eSA7tBTl3pdbHBbtGmim78brjelhqMn1GWqF3Y1
  qWgyIq3jAkEAyIGAEb8EUGT/qOfMdvH52PvQGfMn3ZHT7FTC2m2ScV8kJb6UgrCi
  mw6ZYDgSbMhm6xA7ow3wxORq4+s9ChEJfwJASEtXak7Po4vNDoxJplcsBq6iU6QQ
  ahkd2/cAEUy580xqox0whZcXBfeQTYqiYERIH8tlUynY3rafoOY4BCS4cQJAOcSl
  43cHhSo0RrPSQwrgk1Wp1XArMjlLt7GMGmarZKKmxYEtRKIjl00Tf5doJ5Nto5gf
  tpDTp8avzU7/XSEffQJBALupHWw2N+OZd1k2XVVp2AKaL1qRzna5xl6SfP9rIhme
  LdZdCMkt4nSKJ1f0HGdIYnbUXm8zeffSnOlWwaeCLRg=
  -END RSA PRIVATE KEY-

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1144408/+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 861137] Re: Openssl TLS errors while connecting to SSLv3 sites

[Adrien Nader]

This ticket will be WONTFIX because SSL3 is not supported anymore (and
it's now known that supporting SSL2, SSL3 and TLS1.x at the same time
with the same code was a mistake, which makes issues like this one not
surprising).

-- 
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/861137

Title:
  Openssl TLS errors while connecting to SSLv3 sites

Status in openssl package in Ubuntu:
  Confirmed
Status in python-apns-client package in Ubuntu:
  New

Bug description:
  I upgraded to Oneiric Ocelot beta1. OpenSSL version is "1.0.0e 6 Sep
  2011"

  Now, when I connect to certain HTTPs servers with wget or curl I get a
  TLS error.

  With wget : OpenSSL: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 
alert internal error
  With curl : curl: (35) error:14077438:SSL 
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error

  In wget, this can be fixed by specifying --secure-protocol=sslv3 option
  In curl, this can be fixed by specifying -sslv3 option

  The issue is that the automatic check for the version seems to be
  failing. This is working fine in Natty systems using older versions of
  openssl.

  The impact of this will be in scripts using curl, wget etc. which will
  start failing after an upgrade.

  Ubuntu version

  Description:  Ubuntu oneiric (development branch)
  Release:  11.10

  OpenSSL version : OpenSSL 1.0.0e 6 Sep 2011

  openssl:
Installed: 1.0.0e-2ubuntu2
Candidate: 1.0.0e-2ubuntu2
Version table:
   *** 1.0.0e-2ubuntu2 0
  500 http://us.archive.ubuntu.com/ubuntu/ oneiric/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/861137/+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 1475228] Re: openssl/curl error: SSL23_GET_SERVER_HELLO:tlsv1 alert internal error on TLS only configured server

[Adrien Nader]

There has been no activity on this bug for 7 years. Marc stated 1.0.2
connects successfully. Moreover, the last comments were about this
occuring with 1.0.1f on 14.04 (8 years old). Lastly, the corresponding
code seems to be gone. I'll mark this as Fix Released.

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Fix Released

-- 
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/1475228

Title:
  openssl/curl error: SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
  on TLS only configured server

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  (taken from http://askubuntu.com/questions/649000/openssl-curl-error-
  ssl23-get-server-hellotlsv1-alert-internal-
  error?noredirect=1#comment931621_649000)

  
  We encounter very strange problems connecting with openssl or curl to one of 
our servers, from Ubuntu 14.04

  Executing:

  openssl s_client -connect ms.icometrix.com:443
  gives:

  CONNECTED(0003)
  140557262718624:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
  internal error:s23_clnt.c:770:
  A similar error when executing:

  curl https://ms.icometrix.com
  curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
  internal error
  Output of openssl version (on client/server):

  OpenSSL 1.0.1f 6 Jan 2014
  The funny thing is, the problem vanishes when connecting with other versions 
of Openssl:

  From a mac, OpenSSL 0.9.8zd 8 Jan 2015, all ok
  From centos, OpenSSL 1.0.1e-fips 11 Feb 2013, all ok
  Latest stable release on Ubuntu 14.04, OpenSSL 1.0.2d 9 Jul 2015, all ok.
  From server side, we do not see anything strange. The problem started when we 
disabled SSL3 on our machines.

  Might there be a problem with the build in the apt-get?

  We also test other versions, the one proposed by apt-cache showpkg,
  but the problem remains...

  
  BTW: I don't consider this the same as 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/861137?comments=al 
because, they're talking about SSL enabled servers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1475228/+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 1307190] Re: postinst script does not restart services

[Adrien Nader]

*** This bug is a duplicate of bug 1971650 ***
https://bugs.launchpad.net/bugs/1971650

This is not strictly a duplicate of
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1971650 since
this one is now about switching to needrestart, but I believe it
subsumes the current bug enough to mark it as duplicate of the newer
one.

** This bug has been marked a duplicate of bug 1971650
   wrong check for "server" in libssl3.postinst

-- 
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/1307190

Title:
  postinst script does not restart services

Status in openssl package in Ubuntu:
  Triaged

Bug description:
  I have updated openssl to 1.0.1e-3ubuntu1.2 (Ubuntu 13.10 here). This
  update did not automatically restart services that were using the
  previously installed version (apache2 in my case), because the
  postinst script at /var/lib/dpkg/info/openssl.postinst does not do
  that. In effect, these services were still affected by the security
  vulnerabilities fixed in the update (among them in the latest update
  the fix for CVE-2014-0160 "Heartbleed"). The services had to be
  restarted manually, which in the case of a web server that gets its
  updates automatically via unattended-upgrades can mean a potentially
  dangerous delay.

  Expected behavior is instead that the openssl postinst script restarts
  all services that use the previous version. This is how it was handled
  in openssl 0.9.8b-3 for example (as documented in issue #69239 , see
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/69239 ).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1307190/+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 1046462] Re: CVE-2011-4109 erroneously listed in changelog as CVE-2011-4019

[Adrien Nader]

There is no mention of either CVE-2011-4019 or 4109 at the moment in
debian/changelog. As such there is nothing to do.

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2011-4019

-- 
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/1046462

Title:
  CVE-2011-4109 erroneously listed in changelog as CVE-2011-4019

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl098 package in Ubuntu:
  Invalid

Bug description:
  While researching repair status for CVE-2011-4109 on Ubuntu 10.04 LTS,
  found details in changelog for CVE-2011-4019, which appear consistent
  with CVE-2011-4109.  I believe that -4109 has been repaired , but has
  erroneously been added to the changelog as -4019.   -4019 pertains to
  a Cisco product.

  Changelog:
  https://launchpad.net/ubuntu/+source/openssl/0.9.8k-7ubuntu8.8

  Referred here after posting question to
  https://answers.launchpad.net/ubuntu/+source/openssl098/+question/207684

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1046462/+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 692589] Re: Bug in libssl-dev package, pem.h

[Adrien Nader]

I've tried to reproduce the issue (thanks for the reproducer!) and
didn't manage to. I'm not sure the API is still there and in the same
form but also, pem.h is vastly different and much much simpler. I think
there's nothing to do and this bug should be WONTFIX.

-- 
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/692589

Title:
  Bug in libssl-dev package, pem.h

Status in openssl package in Ubuntu:
  New

Bug description:
  Binary package hint: openssl

  Error when tring to compile that code:

  #include 
  #include 
  #include 

  SSL *p_ssl

  BIO *p_mem_bio;
  SSL_SESSION *p_session;

  PEM_write_bio_SSL_SESSION(p_mem_bio, p_session);


  
  We have complie error 

  error: invalid conversion from ‘void*’ to ‘char*’
  error:   initializing argument 4 of ‘int PEM_ASN1_write_bio(int (*)(void*, 
unsigned char**), const char*, BIO*, char*, const EVP_CIPHER*, unsigned char*, 
int, int (*)(char*, int, int, void*), void*)’

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/692589/+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 1075916] Re: 'openssl ca' segfaults on second run

[Adrien Nader]

I've tried to reproduce the issue but to no avail. Having the exact
steps coule be helpful.

** Changed in: openssl (Ubuntu)
   Status: New => Incomplete

-- 
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/1075916

Title:
  'openssl ca' segfaults on second run

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Openssl binary segfault on try to sign certificate.

  Steps to reproduce:

  1. create root CA (self-signed certificate)
  2. create 'local CA' directory structure by something like this (see full 
shell script in attach):

  CA_DIR=demoCA
  mkdir -p $CA_DIR/signedcerts# contains copies of each signed certificate
  mkdir -p $CA_DIR/private# contains the private key
  mkdir -p $CA_DIR/tmp# temporary certificate sign request files
  echo '01' > $CA_DIR/serial
  touch $CA_DIR/index.txt

  3. Generate sign request and sign first certificate (openssl req,
  openssl ca)

  4. Try do it again for next certificate.

  Actual result:

  First certificate is signed, but on try to sign second openssl
  segfaults.

  Expected result:

  Explain what wron with 'demoCA' directory instead of segfault.

  Additional details:

  Into attachment small script for reproduce the bug.

  Possible it is my (I'm not sure):
  
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fopenssl%3A11%3Aasn1_cb%3ACONF_parse_list%3AASN1_generate_v3%3Aasn1_multi%3AASN1_generate_v3

  Ubuntu 12.04.1 LTS   x86_64
  openssl1.0.1-4ubuntu5.5

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: openssl 1.0.1-4ubuntu5.5
  ProcVersionSignature: Ubuntu 3.2.0-32.51-generic 3.2.30
  Uname: Linux 3.2.0-32-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.0.1-0ubuntu14
  Architecture: amd64
  Date: Wed Nov  7 12:16:31 2012
  InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 
(20120425)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1075916/+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 597984] Re: Some patents have expired but still openssl package does not support them.

[Adrien Nader]

Camellia is available IIRC although it is going away. IDEA already went
away in real-world scenarios (but it might be available anyway) and
MDC-2 is something I hadn't heard of before now.

I'm marking this as Invalid because there is no single Status meaningful
here since this mentions three different algorithms and three different
tickets would therefore be needed to properly express the outcome.

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Invalid

-- 
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/597984

Title:
  Some patents have expired but still openssl package does not support
  them.

Status in openssl package in Ubuntu:
  Invalid

Bug description:
  Binary package hint: openssl

  Is it possible to recompile openssl and libssl with enable-IDEA
  enable-mdc2 and enable-camellia

  because:

  In http://www.openssl.org/support/faq.html:

  FYI: Patent numbers and expiry dates of US patents: MDC-2: 4,908,861
  13/03/2007 IDEA: 5,214,703 25/05/2010 RC5: 5,724,428 03/03/2015

  therefore:

  mdc-2 and IDEA patents expired.

  Additionally the cipher "Camellia":

  Royalty Free   ===>  http://en.wikipedia.org/wiki/Camellia_(cipher)

  NTT and Mitsubishi have patents and pending patents on the Camellia
   algorithm, but allow use at no charge without requiring an explicit
   licensing agreement: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html

  In Fedora 13 "Camellia" is enable in default openssl package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/597984/+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 654493] Re: infinit loop with "openssl s_client -connect xmpp-gmx.gmx.net:5222 -starttls xmpp"

[Adrien Nader]

Actually that's fix released instead. Maybe the "invalid" status comes
from rt.openssl.org becoming unreachable.

** Bug watch added: github.com/openssl/openssl/issues #3980
   https://github.com/openssl/openssl/issues/3980

-- 
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/654493

Title:
  infinit loop with "openssl s_client -connect xmpp-gmx.gmx.net:5222
  -starttls xmpp"

Status in OpenSSL:
  Invalid
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssl

  i try to check sertifikat of jabber server i use, with fallowing result:
  openssl s_client -connect xmpp-gmx.gmx.net:5222 -starttls xmpp -debug

  CONNECTED(0003)
  write to 0x258bf60 [0x7fff56396990] (121 bytes => 121 (0x79))
   - 3c 73 74 72 65 61 6d 3a-73 74 72 65 61 6d 20 78   
  read from 0x258bf60 [0x2582e70] (8192 bytes => 238 (0xEE))
   - 3c 3f 78 6d 6c 20 76 65-72 73 69 6f 6e 3d 27 31   <
  00e0 - 2f 73 74 72 65 61 6d 3a-65 72 72 6f 72 3e /stream:error>
  read from 0x258bf60 [0x2582e70] (8192 bytes => 16 (0x10))
   - 3c 2f 73 74 72 65 61 6d-3a 73 74 72 65 61 6d 3e   
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: openssl 0.9.8o-1ubuntu4
  Uname: Linux 2.6.36-rc4-00134-g03a7ab0 x86_64
  Architecture: amd64
  Date: Mon Oct  4 12:39:43 2010
  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100803.1)
  ProcEnviron:
   LANG=de_DE.utf8
   SHELL=/bin/bash
  SourcePackage: openssl

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/654493/+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 654493] Re: infinit loop with "openssl s_client -connect xmpp-gmx.gmx.net:5222 -starttls xmpp"

[Adrien Nader]

Btw, discussion upstream at
https://github.com/openssl/openssl/issues/3980 (you can see everything
has been imported in 2017).

** Changed in: openssl (Ubuntu)
   Status: Invalid => Fix Released

-- 
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/654493

Title:
  infinit loop with "openssl s_client -connect xmpp-gmx.gmx.net:5222
  -starttls xmpp"

Status in OpenSSL:
  Invalid
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssl

  i try to check sertifikat of jabber server i use, with fallowing result:
  openssl s_client -connect xmpp-gmx.gmx.net:5222 -starttls xmpp -debug

  CONNECTED(0003)
  write to 0x258bf60 [0x7fff56396990] (121 bytes => 121 (0x79))
   - 3c 73 74 72 65 61 6d 3a-73 74 72 65 61 6d 20 78   
  read from 0x258bf60 [0x2582e70] (8192 bytes => 238 (0xEE))
   - 3c 3f 78 6d 6c 20 76 65-72 73 69 6f 6e 3d 27 31   <
  00e0 - 2f 73 74 72 65 61 6d 3a-65 72 72 6f 72 3e /stream:error>
  read from 0x258bf60 [0x2582e70] (8192 bytes => 16 (0x10))
   - 3c 2f 73 74 72 65 61 6d-3a 73 74 72 65 61 6d 3e   
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: openssl 0.9.8o-1ubuntu4
  Uname: Linux 2.6.36-rc4-00134-g03a7ab0 x86_64
  Architecture: amd64
  Date: Mon Oct  4 12:39:43 2010
  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100803.1)
  ProcEnviron:
   LANG=de_DE.utf8
   SHELL=/bin/bash
  SourcePackage: openssl

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/654493/+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 654493] Re: infinit loop with "openssl s_client -connect xmpp-gmx.gmx.net:5222 -starttls xmpp"

[Adrien Nader]

I'm going to replicate the status used by upstream (Invalid) even though
rt.openssl.org has unfortunately been decomissioned.

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Invalid

-- 
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/654493

Title:
  infinit loop with "openssl s_client -connect xmpp-gmx.gmx.net:5222
  -starttls xmpp"

Status in OpenSSL:
  Invalid
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssl

  i try to check sertifikat of jabber server i use, with fallowing result:
  openssl s_client -connect xmpp-gmx.gmx.net:5222 -starttls xmpp -debug

  CONNECTED(0003)
  write to 0x258bf60 [0x7fff56396990] (121 bytes => 121 (0x79))
   - 3c 73 74 72 65 61 6d 3a-73 74 72 65 61 6d 20 78   
  read from 0x258bf60 [0x2582e70] (8192 bytes => 238 (0xEE))
   - 3c 3f 78 6d 6c 20 76 65-72 73 69 6f 6e 3d 27 31   <
  00e0 - 2f 73 74 72 65 61 6d 3a-65 72 72 6f 72 3e /stream:error>
  read from 0x258bf60 [0x2582e70] (8192 bytes => 16 (0x10))
   - 3c 2f 73 74 72 65 61 6d-3a 73 74 72 65 61 6d 3e   
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))
  read from 0x258bf60 [0x2582e70] (8192 bytes => 0 (0x0))

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: openssl 0.9.8o-1ubuntu4
  Uname: Linux 2.6.36-rc4-00134-g03a7ab0 x86_64
  Architecture: amd64
  Date: Mon Oct  4 12:39:43 2010
  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100803.1)
  ProcEnviron:
   LANG=de_DE.utf8
   SHELL=/bin/bash
  SourcePackage: openssl

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/654493/+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 592442] Re: fopen fails on some SSL urls

[Adrien Nader]

It looks like php5 was changed to accomodate whatever openssl was doing.
It's difficult to tell whether something has been changed on the openssl
side in the meantime but considering how long it's been, I see no reason
to keep this bug open.

-- 
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/592442

Title:
  fopen fails on some SSL urls

Status in php:
  Unknown
Status in openssl package in Ubuntu:
  Confirmed
Status in php5 package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: php5

  Description:  Ubuntu 10.04 LTS
  Release:  10.04

  php5:
Installed: 5.3.2-1ubuntu4.2
Candidate: 5.3.2-1ubuntu4.2
Version table:
   *** 5.3.2-1ubuntu4.2 0
  500 http://archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
  100 /var/lib/dpkg/status
   5.3.2-1ubuntu4 0
  500 http://archive.ubuntu.com/ubuntu/ lucid/main Packages

  For some reason I can't seem to get the following to work. I suspect a
  SSL problem. Maybe the intermediate SSL cert is not being recognized
  properly? The server cert is signed by geotrust (which is an
  intermediate of equifax[1]).

  I put the following in a file called /tmp/fopen.php:

  https://www.google.com","r;)) { print "www.google.com worked\n"; }
  if (fopen("https://cas.ucdavis.edu","r;)) { print "cas.ucdavis.edu worked\n"; 
}
  ?>

  Then I run the php via an apache web and/or via the php5-cli (the
  results are the same in both cases):

  $ php /tmp/fopen.php
  www.google.com worked
  PHP Warning:  fopen(): SSL operation failed with code 1. OpenSSL Error 
messages:
  error:140773F2:SSL routines:func(119):reason(1010) in /tmp/fopen.php on line 3
  PHP Warning:  fopen(): Failed to enable crypto in /tmp/fopen.php on line 3
  PHP Warning:  fopen(https://cas.ucdavis.edu): failed to open stream: 
operation failed in /tmp/fopen.php on line 3
  $

  When I run the above command on a karmic or jaunty machine it works
  fine for both fopen() calls. I've attached a tcpdump of the above
  script.

  As you can see from the dump, Google is working but my server is not. I get 
an SSL alert packet (packet #29) back with code 10
  (unexpected message).  Maybe this is an intermediate cert verification 
problem?

  What is funny is that I get an ACK right before that. It seems like
  maybe the server is sending an ACK, client starts talking, server
  isn't ready and sends an out-of-order message.

  Scott
  ---
  [1] https://www.geotrust.com/resources/root-certificates/index.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/php/+bug/592442/+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 1018307] Re: SSL renegotiation fails

[Adrien Nader]

I'm going to mark this bug as Incomplete. If it is encountered again,
please try to provide a reproducer: having to reproduce against a multi-
tenant postgresql is a lot of work (especially when you're not familiar
with pg).

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Incomplete

-- 
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/1018307

Title:
  SSL renegotiation fails

Status in openssl package in Ubuntu:
  Incomplete
Status in postgresql-9.4 package in Ubuntu:
  Confirmed
Status in postgresql package in Juju Charms Collection:
  Fix Released

Bug description:
  With PostgreSQL 9.1, SSL renegotiation is enabled by default. This
  fails under Ubuntu 12.04, most noticeably when using streaming
  replication as the renegotiation limit is hit quickly.

  On the master:

  2012-06-25 16:16:26 PDT LOG:  SSL renegotiation failure
  2012-06-25 16:16:26 PDT LOG:  SSL error: unexpected record
  2012-06-25 16:16:26 PDT LOG:  could not send data to client: Connection reset 
by peer

  On the hot standby:

  2012-06-25 11:12:11 PDT FATAL:  could not receive data from WAL stream: SSL 
error: sslv3 alert unexpected message
  2012-06-25 11:12:11 PDT LOG:  record with zero length at 1C5/95D2FE00

  If our SSL libraries do not support SSL renegotiation, the default
  setting is wrong and perhaps warnings emitted if attempts are made to
  enable it.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: postgresql-9.1 9.1.4-0ubuntu12.04
  ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
  Uname: Linux 3.2.0-25-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.0.1-0ubuntu8
  Architecture: amd64
  Date: Wed Jun 27 16:38:33 2012
  ProcEnviron:
   LANGUAGE=en_AU:en
   TERM=xterm
   PATH=(custom, user)
   LANG=en_AU.UTF-8
   SHELL=/bin/bash
  SourcePackage: postgresql-9.1
  UpgradeStatus: Upgraded to precise on 2012-04-27 (60 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1018307/+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 595415] Re: Curl (openssl) fails to open some https URLs with "illegal parameter" error

[Adrien Nader]

I'm going to mark this as Fix Released due to the message above even
though I wasn't able to try to reproduce today (due to so many things
having changed since 2012).

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/595415

Title:
  Curl (openssl) fails to open some https URLs with "illegal parameter"
  error

Status in curl package in Ubuntu:
  Incomplete
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: curl

  Some HTTPS urls cause curl to fail with an "illegal parameter" error.
  This error goes away if you manually specify "--sslv3"

  e.g.

  $ curl --version
  curl 7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 
libidn/1.15
  Protocols: tftp ftp telnet dict ldap ldaps http file https ftps
  Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

  $ curl  https://www.orange.sk/
  curl: (35) error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
illegal parameter

  $ curl  --sslv3 https://www.orange.sk/
  http://www.w3.org/1999/xhtml; xml:lang="sk" lang="sk">
  ...etc

  This is particularly problematic if using an application which uses
  libcurl, but does not allow setting of the --sslv3 flag, e.g. nagios's
  check_http utility.

  This redhat bug https://bugzilla.redhat.com/show_bug.cgi?id=525496
  appears to describe the same problem, and has a patch

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/595415/+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 357998] Re: openssh-client (amd64) can't login after upgrade to jaunty

[Adrien Nader]

** Changed in: seahorse
   Status: New => Incomplete

-- 
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/357998

Title:
  openssh-client (amd64) can't login after upgrade to jaunty

Status in seahorse:
  Incomplete
Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Binary package hint: openssh-client

  Hi,

  I've just upgraded an AMD64 machine from intrepid to jaunty, and since
  then my ssh-client can't login to a debian machine with its sshd
  anymore. The secret key is not accepted anymore. The client just says
  that the server did not accept the public key. The (unmodified) debian
  server has for each login attempt an entry in the log

  sshd[680]: error: RSA_public_decrypt failed:
  error:0407006A:lib(4):func(112):reason(106)

  The login still worked two hours ago, just until the upgrade from
  intrepid to jaunty.

  Interestingly, I did not see that problem on an x86 machine where I
  did the same upgrade. Seems to be an AMD64 specific bug in the crypto
  stuff.

  regards

To manage notifications about this bug go to:
https://bugs.launchpad.net/seahorse/+bug/357998/+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 429907] Re: md4 should be deprecated

[Adrien Nader]

AFAIU, MD4 is officially deprecated in openssl and it should also be
forbidden with openssl's seclevel.

Right now I actually have troubles finding definitive answers because of
how long this has probably been.

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/429907

Title:
  md4 should be deprecated

Status in gnutls26 package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  openssl s_client and konqueror seem to accept md4 signatures.

  IMO md4 is weak - there is preimage attack [1] of 2 rounds 7 steps in
  8 hours (the full md4 is 3 rounds == 48 steps == 2 rounds 16 steps.

  having in mind the 8 hours attack is by m$, i am inclined to believe
  an attack by skilful attacker will take seconds.

  note that it is irrelevant if any CA issues new md4 certs - it is
  enough to have old valid md4 signature.

  [1] http://sat07.ecs.soton.ac.uk/slides/kumarasubramanian-sat07-talk.pdf
  Inversion Attacks on Secure Hash Functions using Sat Solvers

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/429907/+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 795355] Re: Intermittent SSL connection faults when using TLSv1

[Adrien Nader]

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Incomplete

-- 
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/795355

Title:
  Intermittent SSL connection faults when using TLSv1

Status in OEM Priority Project:
  Won't Fix
Status in OEM Priority Project lucid series:
  Won't Fix
Status in apache package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Binary package hint: openssl

  Reported intermittent SSL connection issue on some apache mod_ssl
  vhosts.

  Platform:  Ubuntu 10.04.2 LTS
  Tested: Apache2-2.2.14-5ubuntu8.4 and backported 2.2.17-1ubuntu1 from Natty

  Firefox client will intermittently report:
  Secure Connection Failed
  An error occurred during a connection to oem-ibs.canonical.com.
  Peer's certificate has an invalid signature.
  (Error code: sec_error_bad_signature)

  Condition will clear on reload.

  Occassionally the server will alternately serve a good page followed
  by an SSL error until Apache is restarted. I am unable to reproduce
  the condition on demand, but have output from when the fault occurs.
  When the fault condition occurs it can be reproduced with any SSL
  client.

  The fault presents on multiple distinct servers.

  Initially suspected to be a bug with mod_ssl
  https://issues.apache.org/bugzilla/show_bug.cgi?id=46952, backport has
  eliminated this as has anecdotal reports of this same error presented
  from Dovecot.

  Tested with SSL certs from different CAs.

  Example:

  $ openssl s_client -connect oem-ibs.canonical.com:443
  CONNECTED(0003)
  depth=2 /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 
thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
  verify error:num=20:unable to get local issuer certificate
  verify return:0
  14563:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type 
is not 01:rsa_pk1.c:100:
  14563:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check 
failed:rsa_eay.c:697:
  14563:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad 
signature:s3_clnt.c:1449:

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/795355/+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 95001] Re: Please provide FIPS compliant version

[Adrien Nader]

I think this should be won't fix since there is now a FIPS version
available and it's 100% sure it must not be the default version (and
that it wouldn't make a lot of sense even for people who want FIPS
stuff).

-- 
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/95001

Title:
  Please provide FIPS compliant version

Status in openssl package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: openssl

  It should be considered to supply the FIPS validated version of
  OpenSSL unless there are major disadvantages to this version.

  http://www.oss-institute.org/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/95001/+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 396818] Re: openssl s_client behaves strangely without CAPath

[Adrien Nader]

I'm not seeing that behaviour on a 23.04 system and I expect it to be
the same since 22.04 at least. As such I'm going to mark this as Fix
Released.

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Fix Released

-- 
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/396818

Title:
  openssl s_client behaves strangely without CAPath

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssl

  1) lsb_release -rd
  Description:Ubuntu 8.04.2
  Release:8.04

  2) apt-cache policy openssl
  openssl:
Installed: 0.9.8g-4ubuntu3.7
Candidate: 0.9.8g-4ubuntu3.7
Version table:
   *** 0.9.8g-4ubuntu3.7 0
  500 http://us.archive.ubuntu.com hardy-updates/main Packages
  500 http://security.ubuntu.com hardy-security/main Packages
  100 /var/lib/dpkg/status
   0.9.8g-4ubuntu3 0
  500 http://us.archive.ubuntu.com hardy/main Packages

  3) openssl s_client -connect gmail.com:443 command should look into the CA 
directory to verify the cert of the site.
  4) example output:
  Bad behaviour:
  openssl s_client -quiet -connect gmail.com:443
  depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  verify error:num=20:unable to get local issuer certificate
  verify return:0
  Bad behaviour:
  openssl s_client -quiet -connect gmail.com:443 -CApath /dev/null
  depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification 
Authority
  verify return:1
  depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  verify return:1
  depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
  verify return:1

  
  It looks the openssl does not honor the -CApath parameter and takes the 
default, but if you dont specify the -CApath it doesnt look the CA directory at 
all

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/396818/+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 665209] Re: Ctrl-\ after rejected key-encryption password causes hang

[Adrien Nader]

I tried this again (openssl3) and got the following:

40C75734AE7F:error:1465:UI routines:UI_set_result_ex:result too 
small:../crypto/ui/ui_lib.c:884:You must type in 4 to 1024 characters
40C75734AE7F:error:146B:UI routines:UI_process:processing 
error:../crypto/ui/ui_lib.c:544:while reading strings
40C75734AE7F:error:0480006D:PEM routines:PEM_def_callback:problems 
getting password:../crypto/pem/pem_lib.c:62:
40C75734AE7F:error:07880109:common libcrypto 
routines:do_ui_passphrase:interrupted or cancelled:../crypto/passphrase.c:184:
40C75734AE7F:error:1C80009F:Provider routines:p8info_to_encp8:unable to 
get passphrase:../providers/implementations/encode_decode/encode_key2any.c:116:

I'm going to mark this as Fix Released.

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Fix Released

-- 
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/665209

Title:
  Ctrl-\ after rejected key-encryption password causes hang

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: openssl

  Create the following shell script:

  #!/bin/sh
  openssl genrsa -aes256

  And run it.

  After a key is generated, you will be prompted for an encryption
  password.  Press enter.  Since empty passwords are not allowed here,
  you will be prompted a second time.  Now press Ctrl-\.  Openssl then
  falls into an infinite loop of repeatedly displaying the password
  prompt without responding to user input.

  This behavior does *not* seem to occur if:

  1. You run openssl directly from the shell rather than from a shell script; or
  2. You press Ctrl-\ immediately without first having a password rejected; or
  3. You use an openssl built from upstream sources.  Hence, this seems to be a 
Debian- or Ubuntu-specific bug.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: openssl 0.9.8o-1ubuntu4.1
  ProcVersionSignature: Ubuntu 2.6.35-22.35-virtual 2.6.35.4
  Uname: Linux 2.6.35-22-virtual i686
  Architecture: i386
  Date: Fri Oct 22 16:33:12 2010
  Ec2AMI: ami-508c7839
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: us-east-1d
  Ec2InstanceType: t1.micro
  Ec2Kernel: aki-407d9529
  Ec2Ramdisk: unavailable
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/665209/+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 1075916] Re: 'openssl ca' segfaults on second run

[Adrien Nader]

Seth pointed out that there was actually a reproducer attached. I'm
sorry to have missed it, especially considering how complete it is.

Anyway, I tried it and it's successful at the moment so we'll close this
bug.

-- 
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/1075916

Title:
  'openssl ca' segfaults on second run

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  Openssl binary segfault on try to sign certificate.

  Steps to reproduce:

  1. create root CA (self-signed certificate)
  2. create 'local CA' directory structure by something like this (see full 
shell script in attach):

  CA_DIR=demoCA
  mkdir -p $CA_DIR/signedcerts# contains copies of each signed certificate
  mkdir -p $CA_DIR/private# contains the private key
  mkdir -p $CA_DIR/tmp# temporary certificate sign request files
  echo '01' > $CA_DIR/serial
  touch $CA_DIR/index.txt

  3. Generate sign request and sign first certificate (openssl req,
  openssl ca)

  4. Try do it again for next certificate.

  Actual result:

  First certificate is signed, but on try to sign second openssl
  segfaults.

  Expected result:

  Explain what wron with 'demoCA' directory instead of segfault.

  Additional details:

  Into attachment small script for reproduce the bug.

  Possible it is my (I'm not sure):
  
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fopenssl%3A11%3Aasn1_cb%3ACONF_parse_list%3AASN1_generate_v3%3Aasn1_multi%3AASN1_generate_v3

  Ubuntu 12.04.1 LTS   x86_64
  openssl1.0.1-4ubuntu5.5

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: openssl 1.0.1-4ubuntu5.5
  ProcVersionSignature: Ubuntu 3.2.0-32.51-generic 3.2.30
  Uname: Linux 3.2.0-32-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.0.1-0ubuntu14
  Architecture: amd64
  Date: Wed Nov  7 12:16:31 2012
  InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 
(20120425)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1075916/+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 1305175] Re: openssl 1.0.1f 'ssl handshake failure' connection failure

[Adrien Nader]

RC4-MD5 was already considered pretty bad when this bug was filled; now
they're clearly deprecated and Ubuntu's openssl is actively pushing for
higher security standards. As such I think this bug should be WONTFIX.

-- 
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/1305175

Title:
  openssl 1.0.1f 'ssl handshake failure' connection failure

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  When attempting 'curl' or 'openssl s_client' I have been getting
  "error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
  failure"

  openssl version
  OpenSSL 1.0.1f 6 Jan 2014

  examples:

  ```Normal connect
  # openssl s_client -connect centinel1000.cardinalcommerce.com:443 -showcerts
  CONNECTED(0003)
  140148901013152:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
failure:s23_lib.c:177:
  ---
  no peer certificate available
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 0 bytes and written 317 bytes
  ---
  New, (NONE), Cipher is (NONE)
  Secure Renegotiation IS NOT supported
  Compression: NONE
  Expansion: NONE
  ---

  
  ```Explicit SSLv3
  # openssl s_client -connect centinel1000.cardinalcommerce.com:443 -showcerts 
-ssl3
  CONNECTED(0003)
  depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU 
= "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
  verify error:num=20:unable to get local issuer certificate
  verify return:0
  ---
  Certificate chain
   0 s:/C=US/ST=Ohio/L=Mentor/O=CardinalCommerce 
Corporation/CN=*.cardinalcommerce.com
 i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
  -BEGIN CERTIFICATE-
  MIIEqjCCA5KgAwIBAgIQfI2U+db8heb8kd3m/BmmITANBgkqhkiG9w0BAQUFADA8
  MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMuMRYwFAYDVQQDEw1U
  aGF3dGUgU1NMIENBMB4XDTEzMDMxOTAwMDAwMFoXDTE1MDQxODIzNTk1OVowdTEL
  MAkGA1UEBhMCVVMxDTALBgNVBAgTBE9oaW8xDzANBgNVBAcUBk1lbnRvcjElMCMG
  A1UEChQcQ2FyZGluYWxDb21tZXJjZSBDb3Jwb3JhdGlvbjEfMB0GA1UEAxQWKi5j
  YXJkaW5hbGNvbW1lcmNlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
  ggEBAMUnIwZ0yEJa80hN4sta/wbr04ogq9XwlY7V7iWiLlfoP/wfpccPt/282+AN
  oySwuxMWE5EPHC54WXjCowoj3Kdq7fuH11R6DBoXGfuhIJ9l9L187hEPPk6bLq3H
  F1diHFxGYT0zCNshm7w7Qe/LmQ8N0WSUs21KuB/WZxEts7sIYi4xY/Ig1Mbt6dVV
  z3w3mfSqpXmdZa5ht7/QUEy3/04uGlSXAN01BVmxHbZeM5epocUCt/TwhtUzRb+N
  9S4VEe3kzP8Oz8Wphg1CueP5yH9nRQTzLct5wCBC5+N+RjdadhuRm4FPgbsO+sX4
  LHQ1jgE6CTqYquyYAeXuvdOqz6kCAwEAAaOCAW0wggFpMCEGA1UdEQQaMBiCFiou
  Y2FyZGluYWxjb21tZXJjZS5jb20wCQYDVR0TBAIwADBCBgNVHSAEOzA5MDcGCmCG
  SAGG+EUBBzYwKTAnBggrBgEFBQcCARYbaHR0cHM6Ly93d3cudGhhd3RlLmNvbS9j
  cHMvMA4GA1UdDwEB/wQEAwIFoDAfBgNVHSMEGDAWgBSnooO7NEVAPfzVME8SuT6h
  AZ/22zA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vc3ZyLW92LWNybC50aGF3dGUu
  Y29tL1RoYXd0ZU9WLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
  aQYIKwYBBQUHAQEEXTBbMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUu
  Y29tMDUGCCsGAQUFBzAChilodHRwOi8vc3ZyLW92LWFpYS50aGF3dGUuY29tL1Ro
  YXd0ZU9WLmNlcjANBgkqhkiG9w0BAQUFAAOCAQEAQKaqABf0+hz+MkHwn6HhnZ6T
  3D7u3a3ePrQQgtZWFo+7A5s0C+UA6SBRcvEZDRP7TMZaU+Ft+stglyby33b3koTQ
  2X1F484ncBJGyiOBk0M/KQHIsQGUmeXKNLfZlqXhicbT2nq7SktybPR0rsPJoiqN
  gR8pNlHseb1aHM79NcV9IbpW8B71fEMFQRd7sUvmxGizqOneG4nGXCk04CRRy5H3
  raU6Xb2CRi5UdjsJPWjLjLDQZBF5aA0IgOZDi7BghU9cy+P4t2PdBBvPP0ctWI3O
  LYMF6figGyaw3kCLi4epJ0ZA4ayg8R7KrDNGA7oWI2roknlJd0YEDE3z0Fg2JA==
  -END CERTIFICATE-
   1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
 i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 
thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
  -BEGIN CERTIFICATE-
  MIIEbDCCA1SgAwIBAgIQTV8sNAiyTCDNbVB+JE3J7DANBgkqhkiG9w0BAQUFADCB
  qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf
  Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIw
  MDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV
  BAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMTAwMjA4MDAwMDAwWhcNMjAw
  MjA3MjM1OTU5WjA8MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMu
  MRYwFAYDVQQDEw1UaGF3dGUgU1NMIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
  MIIBCgKCAQEAmeSFW3ZJfS8F2MWsyMip09yY5tc0pi8M8iIm2KPJFEyPBaRF6BQM
  WJAFGrfFwQalgK+7HUlrUjSIw1nn72vEJ0GMK2Yd0OCjl5gZNEtB1ZjVxwWtouTX
  7QytT8G1sCH9PlBTssSQ0NQwZ2ya8Q50xMLciuiX/8mSrgGKVgqYMrAAI+yQGmDD
  7bs6yw9jnw1EyVLhJZa/7VCViX9WFLG3YR0cB4w6LPf/gN45RdWvGtF42MdxaqMZ
  pzJQIenyDqHGEwNESNFmqFJX1xG0k4vlmZ9d53hR5U32t1m0drUJN00GOBN6HAiY
  XMRISstSoKn4sZ2Oe3mwIC88lqgRYke7EQIDAQABo4H7MIH4MDIGCCsGAQUFBwEB
  BCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AudGhhd3RlLmNvbTASBgNVHRMB
  Af8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudGhhd3Rl
  LmNvbS9UaGF3dGVQQ0EuY3JsMA4GA1UdDwEB/wQEAwIBBjAoBgNVHREEITAfpB0w
  GzEZMBcGA1UEAxMQVmVyaVNpZ25NUEtJLTItOTAdBgNVHQ4EFgQUp6KDuzRFQD38
  1TBPErk+oQGf9tswHwYDVR0jBBgwFoAUe1tFz6/Oy3r9MZIaarbzRutXSFAwDQYJ
  KoZIhvcNAQEFBQADggEBAIAigOBsyJUW11cmh/NyNNvGclYnPtOW9i4lkaU+M5en
  

[Touch-packages] [Bug 1334300] Re: after installing updates for OpenSSL there is no advice to reboot the PC

[Adrien Nader]

*** This bug is a duplicate of bug 1971650 ***
https://bugs.launchpad.net/bugs/1971650

I think this is pretty much a duplicate of 1971650 which is about
migrating to needrestart from the current postinst. Like with another
bug I recently marked as duplicate, I don't think it is exactly the same
bug but they way the fix will cover both.

** This bug has been marked a duplicate of bug 1971650
   wrong check for "server" in libssl3.postinst

-- 
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/1334300

Title:
  after installing updates for OpenSSL there is no advice to reboot the
  PC

Status in openssl package in Ubuntu:
  New

Bug description:
  There where a lot of updates for OpenSSL in the last weeks and every time 
there is a instruction in the USN to reboot the PC - like here:
  http://www.ubuntu.com/usn/usn-2232-3/

  "To update your system, please follow these instructions:
  https://wiki.ubuntu.com/Security/Upgrades.

  After a standard system update you need to reboot your computer to make all
  the necessary changes."

  But in the indicator on the panel is no advice to reboot the PC for safety 
reasons.
  I'm not shure if this is a problem of OpenSSL or the indicator plugin from 
XFCE4 itself - but the reboot advice should be pop up in every desktop 
installation to sensibilize the user about the security risk.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: openssl 1.0.1-4ubuntu5.16
  ProcVersionSignature: Ubuntu 3.2.0-64.97-generic 3.2.59
  Uname: Linux 3.2.0-64-generic i686
  ApportVersion: 2.0.1-0ubuntu17.6
  Architecture: i386
  Date: Wed Jun 25 16:14:59 2014
  InstallationMedia: Xubuntu 12.04.1 LTS "Precise Pangolin" - Release i386 
(20120817.3)
  MarkForUpload: True
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1334300/+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 1260230] Re: Memory leak in libcrypto.so\libssl.so

[Adrien Nader]

I wasn't able to reproduce the issue. I've tried the attached reproducer but:
- I don't have a file "TrustStore.pem",
- if I comment out the block of code that tries to load this file, I get 
"Certificate verification error: 20",
- in both cases, valgrind reports no memory lost or still reachable.

I'll mark this bug as Incomplete.

** Changed in: openssl (Ubuntu)
   Status: New => Incomplete

-- 
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/1260230

Title:
  Memory leak in libcrypto.so\libssl.so

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  I've found a bug in openssl 1.0.1-4ubuntu5.10. Was trying to use
  libpq\libmysql.so to connect to database and did not specify sslmode
  so it used ssl to connect to database, when i've checked with valgrind
  i've detected some memory leak:

  ==25346== Memcheck, a memory error detector
  ==25346== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
  ==25346== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
  ==25346== Command: ./test
  ==25346==
  ==25346==
  ==25346== HEAP SUMMARY:
  ==25346== in use at exit: 81,152 bytes in 2,769 blocks
  ==25346==   total heap usage: 4,388 allocs, 1,619 frees, 281,833 bytes 
allocated
  ==25346==
  ==25346== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost 
in loss record 229 of 279
  ==25346==at 0x402BE68: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  ==25346==by 0x416E84E: nss_parse_service_list (nsswitch.c:678)
  ==25346==by 0x416EFC9: __nss_database_lookup (nsswitch.c:175)
  ==25346==by 0x4EB6168: ???
  ==25346==by 0x4EB7B5C: ???
  ==25346==by 0x4125FA6: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:256)
  ==25346==by 0x405F691: ??? (in /usr/lib/libpq.so.5.4)
  ==25346==by 0x404C6BD: ??? (in /usr/lib/libpq.so.5.4)
  ==25346==by 0x404D06A: ??? (in /usr/lib/libpq.so.5.4)
  ==25346==by 0x404EC4A: ??? (in /usr/lib/libpq.so.5.4)
  ==25346==by 0x404EF2F: ??? (in /usr/lib/libpq.so.5.4)
  ==25346==by 0x404F31E: PQconnectStart (in /usr/lib/libpq.so.5.4)
  ==25346==
  ==25346== LEAK SUMMARY:
  ==25346==definitely lost: 40 bytes in 1 blocks
  ==25346==indirectly lost: 120 bytes in 10 blocks
  ==25346==  possibly lost: 0 bytes in 0 blocks
  ==25346==still reachable: 80,992 bytes in 2,758 blocks
  ==25346== suppressed: 0 bytes in 0 blocks
  ==25346== Reachable blocks (those to which a pointer was found) are not shown.
  ==25346== To see them, rerun with: --leak-check=full --show-reachable=yes
  ==25346==
  ==25346== For counts of detected and suppressed errors, rerun with: -v
  ==25346== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


  with sslmode=disable i see this:
  ==28708== Memcheck, a memory error detector
  ==28708== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
  ==28708== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
  ==28708== Command: ./test
  ==28708==
  ==28708==
  ==28708== HEAP SUMMARY:
  ==28708== in use at exit: 160 bytes in 11 blocks
  ==28708==   total heap usage: 138 allocs, 127 frees, 46,314 bytes allocated
  ==28708==
  ==28708== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost 
in loss record 11 of 11
  ==28708==at 0x402BE68: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  ==28708==by 0x416E84E: nss_parse_service_list (nsswitch.c:678)
  ==28708==by 0x416EFC9: __nss_database_lookup (nsswitch.c:175)
  ==28708==by 0x4EB6168: ???
  ==28708==by 0x4EB7B5C: ???
  ==28708==by 0x4125FA6: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:256)
  ==28708==by 0x405F691: ??? (in /usr/lib/libpq.so.5.4)
  ==28708==by 0x404C6BD: ??? (in /usr/lib/libpq.so.5.4)
  ==28708==by 0x404D06A: ??? (in /usr/lib/libpq.so.5.4)
  ==28708==by 0x404EC4A: ??? (in /usr/lib/libpq.so.5.4)
  ==28708==by 0x404EF2F: ??? (in /usr/lib/libpq.so.5.4)
  ==28708==by 0x404F31E: PQconnectStart (in /usr/lib/libpq.so.5.4)
  ==28708==
  ==28708== LEAK SUMMARY:
  ==28708==definitely lost: 40 bytes in 1 blocks
  ==28708==indirectly lost: 120 bytes in 10 blocks
  ==28708==  possibly lost: 0 bytes in 0 blocks
  ==28708==still reachable: 0 bytes in 0 blocks
  ==28708== suppressed: 0 bytes in 0 blocks
  ==28708==
  ==28708== For counts of detected and suppressed errors, rerun with: -v
  ==28708== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

  also test openssl program(attached) have a leak 47700 bytes

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1260230/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : 

[Touch-packages] [Bug 1791559] Re: Spurious reboot notifications caused by libssl upgrades.

[Adrien Nader]

*** This bug is a duplicate of bug 1971650 ***
https://bugs.launchpad.net/bugs/1971650

I'm going to mark this as duplicate of 1971650 which is about updating
the logic for libssl upgrades since it will cover this issue too (and
we'd like to address it in the not-so-distant future).

** This bug has been marked a duplicate of bug 1971650
   wrong check for "server" in libssl3.postinst

-- 
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/1791559

Title:
  Spurious reboot notifications caused by libssl upgrades.

Status in openssl package in Ubuntu:
  New

Bug description:
  Upon installing libssl:i386 on Ubuntu LTS 18.04.1 Desktop, I am
  advised that I need to perform a reboot.

  I see a single process in my system using a no-longer-existing copy of
  libssl.so.1.0.0, but I can easily restart that process.

  Even if this were Server, I could easily just restart the sshd
  process, from its console if necessary.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1791559/+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 1420608] Re: s_client doesn't recognise XMPP STARTTLS messages with double quotes

[Adrien Nader]

I'm marking this bug as Fix Released for the openssl package too because
we've incorporated this already and I can't reproduce the issue (I used
conference.igniterealtime.org:5222 since the original testcase doesn't
resolve anymore).

** Changed in: openssl (Ubuntu)
   Status: Confirmed => Fix Released

-- 
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/1420608

Title:
  s_client doesn't recognise XMPP STARTTLS messages with double quotes

Status in OpenSSL:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  OpenSSL s_client does not recognise the XML produced by some Jabber
  servers (eg. OpenFire). The parameter values use double (") instead of
  single quotes (') and s_client is too conservative in its string-
  parsing routine.

  To demonstrate the problem I used one of the public XMPP servers
  running OpenFire 3.9.3:

  openssl s_client -connect jabber.rootbash.com:5222 -starttls xmpp -debug
  CONNECTED(0003)
  write to 0x1124c10 [0x7fffdf2d49c0] (124 bytes => 124 (0x7C))
   - 3c 73 74 72 65 61 6d 3a-73 74 72 65 61 6d 20 78   
  read from 0x1124c10 [0x1118800] (8192 bytes => 192 (0xC0))
   - 3c 3f 78 6d 6c 20 76 65-72 73 69 6f 6e 3d 27 31   http://etherx
  0050 - 2e 6a 61 62 62 65 72 2e-6f 72 67 2f 73 74 72 65   .jabber.org/stre
  0060 - 61 6d 73 22 20 78 6d 6c-6e 73 3d 22 6a 61 62 62   ams" xmlns="jabb
  0070 - 65 72 3a 63 6c 69 65 6e-74 22 20 66 72 6f 6d 3d   er:client" from=
  0080 - 22 6a 61 62 62 65 72 2e-72 6f 6f 74 62 61 73 68   "jabber.rootbash
  0090 - 2e 63 6f 6d 22 20 69 64-3d 22 61 39 64 33 30 61   .com" id="a9d30a
  00a0 - 34 32 22 20 78 6d 6c 3a-6c 61 6e 67 3d 22 65 6e   42" xml:lang="en
  00b0 - 22 20 76 65 72 73 69 6f-6e 3d 22 31 2e 30 22 3e   " version="1.0">
  read from 0x1124c10 [0x1118800] (8192 bytes => 428 (0x1AC))
   - 3c 73 74 72 65 61 6d 3a-66 65 61 74 75 72 65 73   DI
  0090 - 47 45 53 54 2d 4d 44 35-3c 2f 6d 65 63 68 61 6e   GEST-MD5P
  00b0 - 4c 41 49 4e 3c 2f 6d 65-63 68 61 6e 69 73 6d 3e   LAIN
  00c0 - 3c 6d 65 63 68 61 6e 69-73 6d 3e 41 4e 4f 4e 59   ANONY
  00d0 - 4d 4f 55 53 3c 2f 6d 65-63 68 61 6e 69 73 6d 3e   MOUS
  00e0 - 3c 6d 65 63 68 61 6e 69-73 6d 3e 43 52 41 4d 2d   CRAM-
  00f0 - 4d 44 35 3c 2f 6d 65 63-68 61 6e 69 73 6d 3e 3c   MD5<
  0100 - 2f 6d 65 63 68 61 6e 69-73 6d 73 3e 3c 63 6f 6d   /mechanisms>http://jabber.or
  0130 - 67 2f 66 65 61 74 75 72-65 73 2f 63 6f 6d 70 72   g/features/compr
  0140 - 65 73 73 22 3e 3c 6d 65-74 68 6f 64 3e 7a 6c 69   ess">zli
  0150 - 62 3c 2f 6d 65 74 68 6f-64 3e 3c 2f 63 6f 6d 70   bhttp://jabb
  0180 - 65 72 2e 6f 72 67 2f 66-65 61 74 75 72 65 73 2f   er.org/features/
  0190 - 69 71 2d 61 75 74 68 22-2f 3e 3c 2f 73 74 72 65   iq-auth"/>
  ---
  no peer certificate available
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 620 bytes and written 124 bytes
  ---
  New, (NONE), Cipher is (NONE)
  Secure Renegotiation IS NOT supported
  Compression: NONE
  Expansion: NONE
  ---

  The "no peer certificate available" is incorrect, it appears because
  s_client doesn't correctly recognise the response from the remote
  server.

  The problem comes from the hard-coded string that s_client is looking for 
during communication with the remote server here:
  
https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/apps/s_client.c#L1461
 - the utility expects only a single-quoted string, while the standard also 
allows the use of double quotes.

  There is a bug report and a series of patches for various XMPP-related
  bugs submitted in OpenSSL RT bugtracker
  https://rt.openssl.org/Ticket/Display.html?id=2860=guest=guest
  (and more specifically for this problem -
  https://rt.openssl.org/Ticket/Display.html?id=2860#txn-34620). This
  issue has been fixed  in the upstream Git repository in the master
  branch
  
(https://github.com/openssl/openssl/blob/fbf08b79ff33110c242849e836aeb494bc03a132/apps/s_client.c#L1620).

  Please consider including these patches.

  Also please update the man page for s_client, it is for a previous
  version of the utility and doesn't mention STARTTLS XMPP support at
  all.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: openssl 1.0.1f-1ubuntu2.8
  ProcVersionSignature: Ubuntu 3.13.0-45.74-generic 3.13.11-ckt13
  Uname: Linux 3.13.0-45-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.14.1-0ubuntu3.6
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Feb 10 21:59:30 2015
  InstallationDate: Installed on 2014-07-07 (218 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/1420608/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post 

[Touch-packages] [Bug 1441461] Re: openssl verify fails with "certificate signature failure"

[Adrien Nader]

I was able to reproduce your results but there aren't that many patches
being applied at the moment and that makes the failure surprising. I
didn't spot anything obvious in the certificates either but overall I
think this bug needs a reproducer which covers the generation of the
certificates because this is a very common worfklow and I'd be surprised
it was completely broken without many people noticing.

** Changed in: openssl (Ubuntu)
   Status: New => Incomplete

-- 
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/1441461

Title:
  openssl verify fails with "certificate signature failure"

Status in openssl package in Ubuntu:
  Incomplete

Bug description:
  I have a intermediate certificate signed by my own CA, which works fine on 
other systems.
  but openssl (1.0.1f-1ubuntu2.11) installed with apt-get will always fails 
with "certificate signature failure"

  but openssl binary compiled myself with the same version of code
  (1.0.1f), works.

  so i wonder if this is a bug of openssl?

  certificate details and version info is at
  https://gist.github.com/bearice/e2dd5d4245472e1b3992

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1441461/+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 2019970] Re: OpenSSL 3.0.2 crash in Ubuntu 22.04.2 LTS

[Adrien Nader]

Hi,

Thank you for taking the time to report this issue and providing a
reproducer. Unfortunately I have not succeeded in reproducing the issue.
In a fresh jammy container, using "OPENSSL_BRANCH=openssl-3.0.3
scripts/fullbuild.sh", I then ran "ln -s oqsprovider.so
_build/lib/oqsprovider2.so" which gave me the layout below:

root@jammy:~/oqs-provider# ls -l _build/lib/
total 6472
lrwxrwxrwx 1 root root  14 May 17 15:39 oqsprovider2.so -> 
oqsprovider.so
lrwxrwxrwx 1 root root  16 May 17 15:32 oqsprovider.so -> 
oqsprovider.so.1
-rwxr-xr-x 1 root root 6625696 May 17 15:32 oqsprovider.so.0.5.0-dev
lrwxrwxrwx 1 root root  24 May 17 15:32 oqsprovider.so.1 -> 
oqsprovider.so.0.5.0-dev

and then

root@jammy:~/oqs-provider# OPENSSL_MODULES=_build/lib/ 
OPENSSL_CONF=scripts/o-ca.cnf ./.local/bin/openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

which didn't crash.

-- 
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/2019970

Title:
  OpenSSL 3.0.2 crash in Ubuntu 22.04.2 LTS

Status in openssl package in Ubuntu:
  New

Bug description:
  Full bug report at https://github.com/openssl/openssl/issues/20981

  No upstream impact: OpenSSL 3.0.9-dev does not contain the problem any
  more.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2019970/+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 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

[Adrien Nader]

Gil, can you do the verification? Thanks.

-- 
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/1994165

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.

  This patch handles the SMIME_crlf_copy return code in all
  occurrences.

  Signed-off-by: Alon Bar-Lev 

  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

[Adrien Nader]

As expected, it wasn't very easy to create a reproducer since the
openssl tool couldn't be used and it required introducing errors in
lower layers. Moreover the CMS_dataFinal symbol cannot be overriden in a
meaningful way, probably either due to LTO or symbol visibility.
Fortunately it was still possible to do it through GDB even though it
couldn't locate the symbol at first (hence the message "Function
"CMS_dataFinal" not defined.")

# apt-get install -y gdb

# cat > gdb_commands << EOF
> set breakpoint pending on
break CMS_dataFinal
r
return (int) 0
c
q
EOF

# echo foo > mail.txt

# openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 
-days 30
# echo use "1234" as password and press enter for each subsequent question

# gdb --return-child-result --batch-silent --command=gdb_commands --args 
openssl cms -sign -in mail.txt -out mail.msg -signer cert.pem -inkey key.pem 
-noindef -nodetach -passin pass:1234; echo $?
Function "CMS_dataFinal" not defined.
0

# echo edit sources.list and apt install -t jammy-proposed libssl3

# # gdb --return-child-result --batch-silent --command=gdb_commands --args 
openssl cms -sign -in mail.txt -out mail.msg -signer cert.pem -inkey key.pem 
-noindef -nodetach -passin pass:1234; echo $?
Function "CMS_dataFinal" not defined.
80FBF0F7FF7F:error:1767:CMS routines:CMS_final:cms datafinal 
error:../crypto/cms/cms_smime.c:890:
3

As can be seen, after the update, the return code is non-0, indicating
the error was properly bubbled up.

-- 
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/1994165

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.

  This patch handles the SMIME_crlf_copy return code in all
  occurrences.

  Signed-off-by: Alon Bar-Lev 

  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate

[Adrien Nader]

Frank and Grgo, thanks for the verification. That was very helpful.

-- 
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/2023545

Title:
  [UBUNTU 22.04] openssl with ibmca engine configured dumps core when
  creating a new certificate

Status in Ubuntu on IBM z Systems:
  In Progress
Status in openssl package in Ubuntu:
  In Progress
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===

  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Openssl using an engine dumps core upon certificate creation; other 
operations are probably affected too. Overall, engines are likely mostly 
unusable.

  [Test plan]
  - An openssl engine is req. to test the fix.
  - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN.
  - Check with 'lszcrypt -V' the availability (online) of the hw crypto 
resources.
  - Install the needed package that allows to exploit the hw crypto resources:
    sudo apt-get install libica-utils libica? openssl-ibmca
  - And copy a working sample openssf.cnf file:
    sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample 
/etc/ssl/openssl.cnf
  - Verify if the 'openssl engine' lists an ibmca engine,
in addition to the dynamic engine:
openssl engine
      (dynamic) Dynamic engine loading support
      (ibmca) Ibmca hardware engine support  <===
  - try to create a new certificate, using this cmd-line:
    openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem 
-keyout __key.pem --subj '/CN=US'
  - The above command must not lead to a 'Segmentation fault (core dumped)',
    rather than create a proper certificate file.
    Also watch /var/log/syslog / journalctl for more details.
  - Upgrade not only the openssl package itself,
but also libssl3, before verification.
  - The issue is fixed in openssl 3.0.8 which landed in lunar.

  [Where problems could occur]
  I don't pretend to understand the lifecycle of providers in openssl3 but the 
patch is simple and has been widely tested by now, including on ubuntu. Thus, I 
see little chance an unexpected problem would occur with it.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/issues/18578

  *
  
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-
  sru-0001-Release-the-drbg-in-the-global-default-context-
  befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem
  -keyout __key.pem --subj '/CN=US'

  ---Problem Description---
  OpenSSL with ibmca engine configured dumps core when creating a new 
certificate.

  # openssl engine
  (dynamic) Dynamic engine loading support
  (ibmca) Ibmca hardware engine support
  # openssl req  -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem 
-keyout __key.pem --subj '/CN=US'
  Segmentation fault (core dumped)

  # journalctl
  Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b 
ilc:2 in libc.so.6[3ffae08+1ca000]
  Jun 07 13:06:08 SYSTEM kernel: Failing address:  TEID: 
0800
  Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user 
ASCE.
  Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024
  Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded 
Not tainted 5.15.0-73-generic #80-Ubuntu
  Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0)
  Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708
  Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 
AS:0 CC:0 PM:0 RI:0 EA:3
  Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 
 02aa3289f9d0
  Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 
 02aa328a4300
  Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 
02aa03ff 
  Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 
03ffae437c22 03ffec2fe000
  Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2  
  lgr%r11,%r2
    03ffae11c700: 
4700bc0,0
   #03ffae11c704: 
b24f00a0ear%r10,%a0
   >03ffae11c708: 
58102018l%r1,24(%r2)
    

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

[Adrien Nader]

Thanks a lot for the verification Simon!

I looked at the test results and I believe failed tests are all fine:

- diffoscope: pyhon "ModuleNotFoundError: No module named 'tests.utils'"
- dotnet*: complains that this dotnet is not tested for 24.04 (yes, 24.04); 
this system of keeping a matrix of host/targets compatibility is being removed 
upstream due to being impossible to maintain (confirmed by Dominik)
- ganeti: same failure as with the iptables SRU
- linux-*: timed out building the kernel
- ruby3.0: expired certificates in testsuite

For the following packages, I re-tried the tests and they succeeded:

- puma: retried twice and passed; at least one occurrence of the same failure
- python-bonsai: retried; passing now; there have been various errors in this 
package that disappear on re-try
- seqkit: retried; and passing I guess since it disappeared; there's a (long) 
history of this test failing
- systemd: retried; timeouts which don't really seem to be related to openssl, 
or at least I couldn't spot an error, same issues can be seen in several other 
logs

-- 
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/2033422

Title:
  openssl: backport to jammy "clear method store / query cache
  confusion"

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [ATTENTION]
  This SRU contains THREE changes which are listed in the section below.

  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.

  This SRU addresses three issues with Jammy's openssl version:
  - http://pad.lv/1994165: ignored SMIME signature errors
  - http://pad.lv/2023545: imbca engine dumps core
  - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections 
(this one)

  The SRU information has been added to the three bug reports and I am
  attaching the debdiff here only for all three.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 
implemented.

  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .

  To test, follow these steps:
  - run "time python3 main.py" # using the aforementioned main.py script
  - apt install -t jammy-proposed libssl3
  - run "time python3 main.py"
  - compare the runtimes for the two main.py runs

  You can run this on x86_64, Raspberry Pi 4 or any machine, and get a
  very large speed-up in all cases. The improvements are not
  architecture-dependant.

  Using this changeset, I get the following numbers for ten runs on my
  laptop:

  3.0.2:
  real  2m5.567s
  user  4m3.948s
  sys   2m0.233s

  this SRU:
  real  0m23.966s
  user  2m35.687s
  sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In http://pad.lv/2009544 , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. 

[Touch-packages] [Bug 2052505] Re: Can't install openssl/libssl3 debug package

[Adrien Nader]

Thanks for re-trying and reporting!

For some (possible) context: there have been some infrastructure issues
his week, especially at the beginning of the week: broken services and
delays in the pipelines. I was expecting this to be the cause of the
issue.

-- 
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/2052505

Title:
  Can't install openssl/libssl3 debug package

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  I'm building an application in docker, using
  `mcr.microsoft.com/dotnet/runtime:7.0-jammy`
  (https://github.com/dotnet/dotnet-
  docker/blob/main/src/runtime/7.0/jammy/amd64/Dockerfile) image, that
  is using `amd64/buildpack-deps:jammy-curl`(https://github.com/docker-
  library/buildpack-
  
deps/blob/93d6db0797f91ab674535553b7e0e762941a02d0/ubuntu/jammy/curl/Dockerfile)
  as base image.

  In my docker file I added ubuntu debug repositories and install debug
  packages:

  ```bash
  apt-get install -y software-properties-common
  echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe 
multiverse
  deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted 
universe multiverse | \
  deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted 
universe multiverse" | \
  tee -a /etc/apt/sources.list.d/ddebs.list
  apt install ubuntu-dbgsym-keyring
  apt-get update -y
  apt-get install -y --no-install-recommends libc6-dbg libssl3-dbgsym 
openssl-dbgsym libicu70-dbgsym libstdc++6-dbgsym 
  ```
  Yesterday I tried and the build isn'T running anymore with the error message:

  ```output
  1.884 Some packages could not be installed. This may mean that you have
  1.884 requested an impossible situation or if you are using the unstable
  1.884 distribution that some required packages have not yet been created
  1.884 or been moved out of Incoming.
  1.884 The following information may help to resolve the situation:
  1.884 
  1.887 The following packages have unmet dependencies:
  2.072  libssl3-dbgsym : Depends: libssl3 (= 3.0.2-0ubuntu1.13) but 
3.0.2-0ubuntu1.14 is to be installed
  2.075  openssl-dbgsym : Depends: openssl (= 3.0.2-0ubuntu1.13) but 
3.0.2-0ubuntu1.14 is to be installed
  2.080 E: Unable to correct problems, you have held broken packages.
  ```

  It looks like the debug symbol oackage for libssl3 and openssl should
  be updated. I waited 24h for mirror sync, but error still persist.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2052505/+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 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0

[Adrien Nader]

I'm not seeing the issue on 3.2.1. I'm preparing 3.0.13 without the AES
patch and will probably deal with it after the feature freeze at the end
of the month.

-- 
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/2030784

Title:
  Backport Intel's AVX512 patches on openssl 3.0

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  https://github.com/openssl/openssl/pull/14908

  https://github.com/openssl/openssl/pull/17239

  These should provide a nice performance bonus on recent CPUs, and the
  patches are fairly self-contained.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0

[Adrien Nader]

While preparing an update to 3.0.13 for Noble, I started encoutering
testsuite failures.

The cause is the AES patch combined with 3.0.13 (more specifically with the 
dupctx patches. The problematic combination looks something like the following:
- AES-GCM-enabled-with-AVX512-vAES-and-vPCLMULQDQ
- make-inability-to-dup-clone-ciphers-an-error
- Add-dupctx-support-to-aead-ciphers
- Fix-a-key-repointing-in-various-ciphers (this is probably only needed to 
avoid merge conflicts and not a cause of the issue)

This happens both on Intel and AMD systems which have the corresponding
CPU features.

I am going to prepare 3.0.13 _without_ the AES patch from here and I
will continue to investigate this with upstream's 3.2 (since this is a
rare CPU feature, it's possible CI tests don't exercise it).

-- 
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/2030784

Title:
  Backport Intel's AVX512 patches on openssl 3.0

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  https://github.com/openssl/openssl/pull/14908

  https://github.com/openssl/openssl/pull/17239

  These should provide a nice performance bonus on recent CPUs, and the
  patches are fairly self-contained.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0

[Adrien Nader]

I tested this patch set on a Zen 4 machine too and saw roughly similar
speedups.

And before someone asks: no, I'm not testing that on Via CPUs!

-- 
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/2030784

Title:
  Backport Intel's AVX512 patches on openssl 3.0

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  https://github.com/openssl/openssl/pull/14908

  https://github.com/openssl/openssl/pull/17239

  These should provide a nice performance bonus on recent CPUs, and the
  patches are fairly self-contained.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

[Adrien Nader]

I'm attaching an updated debdiff.

- remove left-over patches for a bug that we decided to not handle as part of 
this SRU (patches were already unlisted from d/p/series)
- added Bug-Ubuntu entries to patches

PPA is the same. New build is at
https://launchpad.net/~adrien-n/+archive/ubuntu/jammy-
openssl-2033422-sru/+sourcepub/15684316/+listing-archive-extra .

** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5737782/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff

-- 
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/2033422

Title:
  openssl: backport to jammy "clear method store / query cache
  confusion"

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [ATTENTION]
  This SRU contains THREE changes which are listed in the section below.

  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.

  This SRU addresses three issues with Jammy's openssl version:
  - http://pad.lv/1994165: ignored SMIME signature errors
  - http://pad.lv/2023545: imbca engine dumps core
  - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections 
(this one)

  The SRU information has been added to the three bug reports and I am
  attaching the debdiff here only for all three.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 
implemented.

  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .

  To test, follow these steps:
  - run "time python3 main.py" # using the aforementioned main.py script
  - apt install -t jammy-proposed libssl3
  - run "time python3 main.py"
  - compare the runtimes for the two main.py runs

  You can run this on x86_64, Raspberry Pi 4 or any machine, and get a
  very large speed-up in all cases. The improvements are not
  architecture-dependant.

  Using this changeset, I get the following numbers for ten runs on my
  laptop:

  3.0.2:
  real  2m5.567s
  user  4m3.948s
  sys   2m0.233s

  this SRU:
  real  0m23.966s
  user  2m35.687s
  sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In http://pad.lv/2009544 , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. Results on a given machine vary also very little across
  runs (less than 2% variation on runs of size 10). They are also very
  similar on a Raspberry Pi 4 (8GB).

  The benchmark uses https://www.google.com/humans.txt which takes
  around 130ms to download on my machine but I modified the script to
  download something only 20ms away. Results are so close to the ones
  using humans.txt that they are within the error margin. This is
  consistent with the high-concurrency in the benchmark which 

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

[Adrien Nader]

Here is an updated version.

I've dropped the extra patch for #1994165 and fixed the changelog where
I had swapped comments for two of the patches.

I've created a new PPA at
https://launchpad.net/~adrien-n/+archive/ubuntu/jammy-
openssl-2033422-sru because the version is unchanged (there has been no
new openssl security update).

** Patch added: "openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2033422/+attachment/5736379/+files/openssl_3.0.2-0ubuntu1.12-to-3.0.2-0ubuntu1.13.diff

-- 
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/2033422

Title:
  openssl: backport to jammy "clear method store / query cache
  confusion"

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [ATTENTION]
  This SRU contains THREE changes which are listed in the section below.

  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.

  This SRU addresses three issues with Jammy's openssl version:
  - http://pad.lv/1994165: ignored SMIME signature errors
  - http://pad.lv/2023545: imbca engine dumps core
  - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections 
(this one)

  The SRU information has been added to the three bug reports and I am
  attaching the debdiff here only for all three.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 
implemented.

  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .

  To test, follow these steps:
  - run "time python3 main.py" # using the aforementioned main.py script
  - apt install -t jammy-proposed libssl3
  - run "time python3 main.py"
  - compare the runtimes for the two main.py runs

  You can run this on x86_64, Raspberry Pi 4 or any machine, and get a
  very large speed-up in all cases. The improvements are not
  architecture-dependant.

  Using this changeset, I get the following numbers for ten runs on my
  laptop:

  3.0.2:
  real  2m5.567s
  user  4m3.948s
  sys   2m0.233s

  this SRU:
  real  0m23.966s
  user  2m35.687s
  sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In http://pad.lv/2009544 , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. Results on a given machine vary also very little across
  runs (less than 2% variation on runs of size 10). They are also very
  similar on a Raspberry Pi 4 (8GB).

  The benchmark uses https://www.google.com/humans.txt which takes
  around 130ms to download on my machine but I modified the script to
  download something only 20ms away. Results are so close to the ones
  using humans.txt that they are within the error margin. This is
  consistent with the high-concurrency in the benchmark which both
  saturates CPU, and 

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

[Adrien Nader]

Thanks for the review and upload.

I have a similar take on the patches in this series and I believe it
would be very difficult and riskier to try to skip some of the patches
in this series which has seen real-world use as a whole, starting with
openssl >= 3.0.4 (which we started shipping in lunar).

-- 
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/2033422

Title:
  openssl: backport to jammy "clear method store / query cache
  confusion"

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [ATTENTION]
  This SRU contains THREE changes which are listed in the section below.

  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.

  This SRU addresses three issues with Jammy's openssl version:
  - http://pad.lv/1994165: ignored SMIME signature errors
  - http://pad.lv/2023545: imbca engine dumps core
  - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections 
(this one)

  The SRU information has been added to the three bug reports and I am
  attaching the debdiff here only for all three.

  All the patches have been included in subsequent openssl 3.0.x
  releases which in turn have been included in subsequent Ubuntu
  releases. There has been no report of issues when updating to these
  Ubuntu releases.

  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU.
  Both matched completely (FYI, mantic's matched completely too).

  I have also pushed the code to git (without any attempt to make it
  git-ubuntu friendly).

  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru

  I asked Brian Murray about phasing speed and he concurs a slow roll-out is 
probably better for openssl. There is a small uncertainty because a security 
update could come before the phasing is over, effectively fast-forwarding the 
SRU. Still, unless there is already a current pre-advisory, this is probably 
better than a 10% phasing which is over after only a couple days anyway.
  NB: at the moment openssl doesn't phase slowly so this needs to be 
implemented.

  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.

  [Test plan]
  Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .

  To test, follow these steps:
  - run "time python3 main.py" # using the aforementioned main.py script
  - apt install -t jammy-proposed libssl3
  - run "time python3 main.py"
  - compare the runtimes for the two main.py runs

  You can run this on x86_64, Raspberry Pi 4 or any machine, and get a
  very large speed-up in all cases. The improvements are not
  architecture-dependant.

  Using this changeset, I get the following numbers for ten runs on my
  laptop:

  3.0.2:
  real  2m5.567s
  user  4m3.948s
  sys   2m0.233s

  this SRU:
  real  0m23.966s
  user  2m35.687s
  sys   0m1.920s

  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.

  In http://pad.lv/2009544 , Rafael also shared his performance numbers
  and they are relatable to these. He used slightly different versions
  (upstreams rather than patched with cherry-picks) but at least one of
  the version used does not include other performance change. He also
  used different hardware and this performance issue seems to depend on
  the number of CPUs available but also obtained a performance several
  times better. Results on a given machine vary also very little across
  runs (less than 2% variation on runs of size 10). They are also very
  similar on a Raspberry Pi 4 (8GB).

  The benchmark uses https://www.google.com/humans.txt which takes
  around 130ms to download on my machine but I modified the script to
  download something only 20ms away. Results are so close to the ones
  using humans.txt that they are within the error margin. This is
  consistent with the high-concurrency in the benchmark which both
  saturates CPU, and "hides" latencies that are relatively low.

  Finally, there are positive reports on github. Unfortunately they are
  not always completely targeted at these patches only and therefore I
  will not link directly to them but they have also been 

[Touch-packages] [Bug 2044795] Re: Please merge openssl 3.1.4-2 from debian unstable

[Adrien Nader]

Openssl's support policy means we won't be using a non-LTS version in
Ubuntu. There's a small window where we might use a non-LTS version
provided we are sure we can upgrade to an LTS version of openssl in time
for our own LTS but at the moment this situation has not happened yet.

Openssl 3.1 is not an LTS, nor is 3.2 (released a few days ago), and it
is not known if 3.3 will be. By the way, 3.3 should be released in
April, almost in time for our LTS, but again, we don't know if it will
also be an LTS release.

As a consequence, we are unfortunately most likely going with 3.0 in
24.04, and every subsequent ubuntu release until we know we will have an
LTS in time for our 26.04 (because we can't "downgrade" openssl version
for our LTS releases).

In the future it is possible that we introduce "openssl-latest" or
something like that in order to track most recent releases but without
any support guarantee. This would be a completely separate package.

In any case, I hadn't noticed that 3.1.* had been uploaded to Debian
unstable. I was assuming that the debian maintainers would stick to 3.0
for the same reasons as I outlined above. It's possible they're betting
they will have an openssl LTS release in time for trixie's release since
trixie might be out in 2025 and by that time openssl 3.0 will roughly
reach EOL, and a new openssl LTS would be needed. I guess we'll have to
discuss which openssl version to use post-24.04 but probably not before
24.04 is released.

I'm going to re-write this report as something post 24.04 since we can't
do anything before 24.04 sadly.

** Changed in: openssl (Ubuntu)
Milestone: None => later

** Summary changed:

- Please merge openssl 3.1.4-2 from debian unstable
+ Please merge openssl from debian unstable

** Changed in: openssl (Ubuntu)
   Status: New => Confirmed

-- 
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/2044795

Title:
  Please merge openssl from debian unstable

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  tracking bug

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2044795/+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 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0

[Adrien Nader]

Thanks a lot for the tests, that's very appreciated.

I ran that on my laptop (11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz)
which quite surprisingly has all these CPU features. Mostly idle,
dynamic CPU governor but no thermal throttling at all (and if there
were, it would probably slow down the AVX-512 code anyway), and tests
are long enough for CPU governors to not matter much.

* AES-128-GCM | AES-256-GCM
 - Baseline - Requires VAES and VPCMULQDQ features present on ICX or newer 
platform. This should be the most performant flow.
AES-128-GCM 855360.29k  3158479.88k  6093932.91k  8905067.37k 13336828.91k 
13788498.58k

 - Individual VAES Disabled and VPCLMULQDQ Disabled should fallback to AVX 
AESNI flow and should have equivalent performance
AES-128-GCM 785422.85k  1936140.78k  4404423.77k  6481577.18k  7732716.48k  
7873213.39k
AES-128-GCM 790775.41k  1942054.64k  4404868.20k  6484287.87k  7711803.10k  
7778795.52k

 - AESNI and VAESNI Disabled should fallback to 'C code' performance
AES-128-GCM 150183.11k   167807.25k   598198.71k   662922.19k   681574.40k  
 678182.91k

* RSA 2K/3K/4K Sign Performance
 - Baseline - Requires AVX512F, AVX512VL, AVX512DQ, and AVX512IFMA features on 
ICX or newer platform. This should be the most performant flow.
rsa 2048 bits 0.000246s 0.15s   4057.2  65278.3
rsa 3072 bits 0.000701s 0.32s   1426.4  31247.7
rsa 4096 bits 0.001434s 0.55s697.4  18052.7

 - Individual AVX512F, AVX512VL, and AVX512IFMA features should yield 
equivalent performance. This flow will use the ADOX/ADCX/MULX RSA flow.
rsa 2048 bits 0.000523s 0.15s   1910.4  65748.2
rsa 3072 bits 0.001579s 0.32s633.3  31158.1
rsa 4096 bits 0.003529s 0.55s283.4  18093.6

rsa 2048 bits 0.000524s 0.15s   1909.0  66310.8
rsa 3072 bits 0.001577s 0.32s634.1  31309.7
rsa 4096 bits 0.003568s 0.55s280.2  18120.4

rsa 2048 bits 0.000523s 0.15s   1913.3  65234.3
rsa 3072 bits 0.001583s 0.32s631.7  31094.6
rsa 4096 bits 0.003607s 0.55s277.3  18076.8

rsa 2048 bits 0.000524s 0.15s   1907.6  66299.6
rsa 3072 bits 0.001577s 0.32s634.1  31214.4
rsa 4096 bits 0.003586s 0.55s278.9  18096.1

We see the expected behavior (AFAIU, all features must be available at
the same time for the changes to have effect).

I'm not comparing everything number by number because I don't think
we're looking for specific percentages of improvements.

Overall we see up to ~2.4 performance improvement and we always see
large improvements (double digit percentages).


As a control I also ran that on lunar, therefore without the patches (I
acknowledge this is not the same openssl version and there are also
other changes but I do not think this matters here).

# AES-128-GCM | AES-256-GCM
 - Baseline - Requires VAES and VPCMULQDQ features present on ICX or newer 
platform. This should be the most performant flow.
AES-128-GCM 782474.44k  1938211.66k  4430867.84k  6402298.54k  7685819.33k  
7840186.37k

 - Individual VAES Disabled and VPCLMULQDQ Disabled should fallback to AVX 
AESNI flow and should have equivalent performance
AES-128-GCM 750028.44k  1926234.78k  4365867.67k  6383893.16k  7742842.78k  
7843146.41k
AES-128-GCM 786910.34k  1934779.33k  4421411.45k  6389114.88k  7650086.87k  
7797479.86k

 - AESNI and VAESNI Disabled should fallback to 'C code' performance
AES-128-GCM 147889.72k   167843.85k   599710.04k   663642.45k   679072.96k  
 680631.91k

# RSA 2K/3K/4K Sign Performance
 - Baseline - Requires AVX512F, AVX512VL, AVX512DQ, and AVX512IFMA features on 
ICX or newer platform. This should be the most performant flow.
rsa 2048 bits 0.000247s 0.15s   4050.8  66072.6
rsa 3072 bits 0.001596s 0.32s626.5  31144.2
rsa 4096 bits 0.003534s 0.56s282.9  18003.6

 - Individual AVX512F, AVX512VL, and AVX512IFMA features should yield 
equivalent performance. This flow will use the ADOX/ADCX/MULX RSA flow.
rsa 2048 bits 0.000528s 0.15s   1892.3  66008.3
rsa 3072 bits 0.001573s 0.32s635.6  31094.2
rsa 4096 bits 0.003534s 0.55s282.9  18073.8

rsa 2048 bits 0.000522s 0.15s   1914.7  65763.4
rsa 3072 bits 0.001575s 0.32s635.0  31237.8
rsa 4096 bits 0.003530s 0.55s283.2  18093.1

rsa 2048 bits 0.000522s 0.15s   1917.4  65826.2
rsa 3072 bits 0.001575s 0.32s635.0  31177.2
rsa 4096 bits 0.003549s 0.55s281.8  18109.9

rsa 2048 bits 0.000522s 0.15s   1915.1  65760.4
rsa 3072 bits 0.001575s 0.32s635.0  31180.2
rsa 4096 bits 0.003538s 0.55s282.6  18109.9


We can see there are no change with the CPU feature flags, except for the test 
that disables AESNI, in which case the performance is the same in lunar and 
mantic. That the CPU feature flags don't change the performance except i the 
one aforementioned case, indicate that these patches are responsible for the 
large performance increase we have seen. We can also see that they don't 
otherwise 

[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate

[Adrien Nader]

As you mention, it's difficult to test with this reproducer specifically
since it's specialized hardware and I've largely had to rely on testing
from the proxied persons who also have interests and duties in this
working well. The issue also appears without the specific hardware when
using providers for some functions but openssl 3.0 providers are recent
and not very widely used so there aren't many one that fit either and
the verification/setup is correspondingly high. On the bright side, the
potential for damage is low due to the small userbase. One last thing: I
don't know if this could work less well than right now since they get
crashes.

The "engines-1.1" is not necessarily a concern: libengine-gost-
openssl/libengine-gost-openssl1.1 was/were putting files in a similar
place without issue IIRC. I don't have a good example to show because
the package currently for jammy puts it in / directly... . In any case,
the path should be configured and the actual location isn't really an
issue. You can see the configuration on https://sysos.ru/archives/589
(russian, search for "openssl_def"; I have seen non-russian links too
but I can't find them again).

The package for the SRU is already in -proposed so it should be possible
to test already. It's (very) late here though so I'll come back to this
and the tests tomorrow. Thanks for the review, comments, and testcase.

-- 
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/2023545

Title:
  [UBUNTU 22.04] openssl with ibmca engine configured dumps core when
  creating a new certificate

Status in Ubuntu on IBM z Systems:
  In Progress
Status in openssl package in Ubuntu:
  In Progress
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Openssl using an engine dumps core upon certificate creation; other 
operations are probably affected too. Overall, engines are likely mostly 
unusable.

  [Test plan]
  An engine is needed to test the fix and I don't think we have many in the 
archive. This complicates reproducing the issue. I have been relying on user 
reports which have been very detailled and helpful.
  The issue has also been reported independently and with another engine 
(devcrypto).
  The issue is fixed in openssl 3.0.8 which landed in lunar.

  [Where problems could occur]
  I don't pretend to understand the lifecycle of providers in openssl3 but the 
patch is simple and has been widely tested by now, including on ubuntu. Thus, I 
see little chance an unexpected problem would occur with it.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/issues/18578

  *
  
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-
  sru-0001-Release-the-drbg-in-the-global-default-context-
  befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem
  -keyout __key.pem --subj '/CN=US'

  ---Problem Description---
  OpenSSL with ibmca engine configured dumps core when creating a new 
certificate.

  # openssl engine
  (dynamic) Dynamic engine loading support
  (ibmca) Ibmca hardware engine support
  # openssl req  -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem 
-keyout __key.pem --subj '/CN=US'
  Segmentation fault (core dumped)

  # journalctl
  Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b 
ilc:2 in libc.so.6[3ffae08+1ca000]
  Jun 07 13:06:08 SYSTEM kernel: Failing address:  TEID: 
0800
  Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user 
ASCE.
  Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024
  Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded 
Not tainted 5.15.0-73-generic #80-Ubuntu
  Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0)
  Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708
  Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 
AS:0 CC:0 PM:0 RI:0 EA:3
  Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 
 02aa3289f9d0
  Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 
 02aa328a4300
  Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 
02aa03ff 
  Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 
03ffae437c22 03ffec2fe000
  Jun 07 13:06:08 SYSTEM kernel: User Code: 

[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

[Adrien Nader]

Indeed, there is an "extra" change which I saw fit to include after
reviewing the change with care.

Replicating the issue directly involves using the openssl C APIs because
higher-level interfaces like the command-line ones prevent calling the
affected code in a way that will trigger the issue. This significantly
increases the effort required to write the testcase. I don't think
upstream wrote one either although that is their habit nowadays but it's
been some time and I will have to look at it again.

Removing (b) wouldn't cause a security issue and it seems (a) is enough
to fix the functional issue that has been reported. On the other hand
this is a diff from current upstream versions, it will require new tests
and the (a+b) changes have seen a lot of use worlwide by now. When
including (b), I knew that it was probably not strictly required and I'm
fine with removing it even though I would prefer to keep it for the
above reasons.

-- 
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/1994165

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.

  This patch handles the SMIME_crlf_copy return code in all
  occurrences.

  Signed-off-by: Alon Bar-Lev 

  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed

[Adrien Nader]

That looks a lot like the -fstack-clash-protection issue we've been
having recently for other packages on armhf.

dpkg 1.22.1ubuntu3 should fix this (
https://launchpad.net/ubuntu/+source/dpkg/1.22.1ubuntu3 )

The place where I've written the most details about this is
https://code.launchpad.net/~adrien-n/ubuntu/+source/dpkg/+git/dpkg/+merge/456181
. If you want I can also upload your package to my test PPA.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/2043713

Title:
  armhf autopkgtests fail due to
  TestApportValgrind.test_valgrind_min_installed

Status in apport package in Ubuntu:
  New

Bug description:
  autopkgtests are pretty reliably failing[1] on armhf due to the
  following (single) test failure:

  638s === FAILURES 
===
  638s  TestApportValgrind.test_valgrind_min_installed 

  638s 
  638s self = 
  638s 
  638s def test_valgrind_min_installed(self):
  638s """Valgrind is installed and recent enough."""
  638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"]
  638s (ret, out, err) = self._call(cmd)
  638s >   self.assertEqual(err, "")
  638s E   AssertionError: "==2474== Invalid write of size 4\n==2474[1064 
chars]= \n" != ''
  638s E   Diff is 1134 characters long. Set self.maxDiff to None to see it.
  638s 
  638s tests/integration/test_apport_valgrind.py:43: AssertionError

  This could be related to valgrind functionality being different on
  armhf, it could also be related to integer sizes internally on armhf.
  I haven't looked too deeply into it.

  [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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 2043713] Re: armhf autopkgtests fail due to TestApportValgrind.test_valgrind_min_installed

[Adrien Nader]

Thanks for looking more deeply than I did. I guess I'll upload both to
my PPA, using whichever version is in -proposed right now.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/2043713

Title:
  armhf autopkgtests fail due to
  TestApportValgrind.test_valgrind_min_installed

Status in apport package in Ubuntu:
  New

Bug description:
  autopkgtests are pretty reliably failing[1] on armhf due to the
  following (single) test failure:

  638s === FAILURES 
===
  638s  TestApportValgrind.test_valgrind_min_installed 

  638s 
  638s self = 
  638s 
  638s def test_valgrind_min_installed(self):
  638s """Valgrind is installed and recent enough."""
  638s cmd = ["valgrind", "-q", "--extra-debuginfo-path=./", "ls"]
  638s (ret, out, err) = self._call(cmd)
  638s >   self.assertEqual(err, "")
  638s E   AssertionError: "==2474== Invalid write of size 4\n==2474[1064 
chars]= \n" != ''
  638s E   Diff is 1134 characters long. Set self.maxDiff to None to see it.
  638s 
  638s tests/integration/test_apport_valgrind.py:43: AssertionError

  This could be related to valgrind functionality being different on
  armhf, it could also be related to integer sizes internally on armhf.
  I haven't looked too deeply into it.

  [1] https://autopkgtest.ubuntu.com/packages/a/apport/noble/armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2043713/+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 2044391] Re: Blowfish decryption failure because of incorrect key length

[Adrien Nader]

I'm going to mark this as duplicate of another bug which I have an
overdue answer to provide.

But one important question: what is your actual usecase that is
negatively 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/2044391

Title:
  Blowfish decryption failure because of incorrect key length

Status in openssl package in Ubuntu:
  New

Bug description:
  The version of OpenSSL in Jammy (3.0.2) is affected by this issue:
  https://github.com/openssl/openssl/issues/18359.  The upshot is that
  ciphertext created in Jammy cannot be decrypted by unaffected versions
  of OpenSSL and vice versa.  For example, here we encrypt a plaintext
  in Jammy:

  $ cat plaintext.txt 
  The quick brown fox jumps over the lazy dog
  $ openssl enc -provider legacy -bf-cfb -e -in plaintext.txt -out 
ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1
  $ cat ciphertext.asc 
  tBL52uAegjMw+DQLL1ipaXQjDnX0KK72QyqMxU1MbuSIfchivPj/JOGWUOU=
  $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K 
d5cca2db098c2ea2 -iv da5638ace83dcde1
  The quick brown fox jumps over the lazy dog

  If we then try to decrypt it in Debian Sid, we get:

  $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K 
d5cca2db098c2ea2 -iv da5638ace83dcde1
  hex string is too short, padding with zero bytes to length
  �;S��\h<�Vɦyʄ(�g`Hrm^�[��u  �"f�S�-9�u

  This has been fixed upstream here:
  
https://github.com/openssl/openssl/commit/1b8ef23e68b273bb5e59f60df62251153f24768d

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2044391/+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 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

[Adrien Nader]

Apologies for not answering earlier; I wasn't available when I first saw
your message.

FWIW, there's just been another report of the same issue with a
different scenario but that's half-way between the "streaming" case and
the "data at rest" one.

The reason this fix is difficult to integrate in a stable release is
because while we know we would introduce breakage, we do not and cannot
know how much. Imagine even 100 Jammy machines which can talk together
today; that's quite expected because they're on the same release. This
change would break that unless every machine is upgraded at once which
is not the case by default due to phasing of updates (and we want to
phase openssl updates slowly because it's a very central component).

While I really sympathetize with your issue, this is the stance of the
Ubuntu project. Both including the fix and not including the fix are
problematic unfortunately.

One additional reason to not include the fix is that we're now close to
Ubuntu 24.04. I realize you've reported this over a year ago but
analysis, preparing a new verion, and the SRU process all take time.
This is especially true for openssl which is central and which updates
have caused issues several times.

Ultimately I'd like to be able to keep Ubuntu releases updated with the
latest openssl versions (no jump from 3.x to 3.x+1 though, merely 3.x.y
to 3.x.y+1). This is not done at the moment because incompatibilities
and issues in openssl are often found late but are also very painful. In
order to do these, I will have to apply the same analysis and criteria
to every change in the openssl releases to ensure package upgrades are
safe and uneventful. Had this been in place for 22.04, this change would
likely have been integrated when it was released in June because that
was very close to the initial 22.04 release. If we want this to happen,
we need to draw the line somewhere and stick to it. Unfortunately this
change is on the other side of the line

That's not to say that we cannot do anything for tinc or for others
affected packages but rather that it won't be done in openssl.

I see two ways to improve this, tinc side.

1) Switch to another cipher. Blowfish uses a 64-bit block size which is
small and limits how much data can be safely encrypted with the same key
(
https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
). I guess this requires cooperation from the server which you might not
control but it is the best long-term solution (and would also help
performance because computing a MAC on top of BF is surprisingly
expensive, and re-keying every n GB stalls data transfers and incurs a
spike in latency).

2) Modify tinc because there's apparently a portable work-around as I've
mentioned in
https://github.com/gsliepen/tinc/issues/414#issuecomment-1741038601 . I
think there's more context on the github openssl bug tracker. My time is
scarce until the end of the year but I will gladly help with the
packaging if needed. I don't know if it could be uploaded because there
would be the same compatibility concern, this time with servers on
22.04. A PPA might be more appropriate and not too inconvenient since
tinc development has stalled while openssl gets security updates every
few months. It might also be possible to add a new ciphername/option
just for that but I don't know how much work that would be without
looking at tinc's code. Let me know if you are able to spend some time
on this.

By the way, even though a change in the C code just for tinc seems
annoying, the knowledge gained could be used for other packaes and
workloads too.

-- 
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/1990216

Title:
  backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
  1.1 with blowfish in OFB or CFB modes" to Jammy

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug was the fourth in a series of bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key 
shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead 
to decryption issues.

  [Test plan]
  On Focal, run the following and copy the output to your clipboard

  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" 
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
  tar c pouet.bf-* | xz | base64 -w 60

  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.

  On Jammy, run the 

[Touch-packages] [Bug 2044391] Re: Blowfish decryption failure because of incorrect key length

[Adrien Nader]

*** This bug is a duplicate of bug 1990216 ***
https://bugs.launchpad.net/bugs/1990216

** This bug has been marked a duplicate of bug 1990216
   backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 
with blowfish in OFB or CFB modes" to Jammy

-- 
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/2044391

Title:
  Blowfish decryption failure because of incorrect key length

Status in openssl package in Ubuntu:
  New

Bug description:
  The version of OpenSSL in Jammy (3.0.2) is affected by this issue:
  https://github.com/openssl/openssl/issues/18359.  The upshot is that
  ciphertext created in Jammy cannot be decrypted by unaffected versions
  of OpenSSL and vice versa.  For example, here we encrypt a plaintext
  in Jammy:

  $ cat plaintext.txt 
  The quick brown fox jumps over the lazy dog
  $ openssl enc -provider legacy -bf-cfb -e -in plaintext.txt -out 
ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1
  $ cat ciphertext.asc 
  tBL52uAegjMw+DQLL1ipaXQjDnX0KK72QyqMxU1MbuSIfchivPj/JOGWUOU=
  $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K 
d5cca2db098c2ea2 -iv da5638ace83dcde1
  The quick brown fox jumps over the lazy dog

  If we then try to decrypt it in Debian Sid, we get:

  $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K 
d5cca2db098c2ea2 -iv da5638ace83dcde1
  hex string is too short, padding with zero bytes to length
  �;S��\h<�Vɦyʄ(�g`Hrm^�[��u  �"f�S�-9�u

  This has been fixed upstream here:
  
https://github.com/openssl/openssl/commit/1b8ef23e68b273bb5e59f60df62251153f24768d

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2044391/+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 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

[Adrien Nader]

Sometimes I don't understand what happens when I attempt to reply by
mail...

Anyway...
The affected code is in libcrypto which I think sees fewer important security 
fixes. Therefore it's possible to build it and put it in your library search 
path. This should fix the issue without being too terrible wrt security updates.

I still think that setting the key size in the caller program is better
if possible however. It's slightly more involved upfront though (but it
could pay up in the end).

I'll prepare a PPA on tomorrow with only this change on tomorrow; I will
probably add a few things to prevent using the package directly however
since I expect the proper approach would be to 'dpkg -x' the package or
equivalent and use its libcrypto.so and LD_LIBRARY_PATH or similar
specifically when needed.

-- 
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/1990216

Title:
  backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
  1.1 with blowfish in OFB or CFB modes" to Jammy

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug was the fourth in a series of bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key 
shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead 
to decryption issues.

  [Test plan]
  On Focal, run the following and copy the output to your clipboard

  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" 
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
  tar c pouet.bf-* | xz | base64 -w 60

  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.

  On Jammy, run the following and paste your clipboard

  base64 -d | xz -d | tar x
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider 
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; 
done

  Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
  decrypted: the other two will result in garbage on screen.

  Here is the result of the enc + tar + xz + base64 on Focal (works with
  Lunar/Mantic too but you need to added ):

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
  hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
  m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
  D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
  ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
  GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
  AoBQAACjzq5WscRn+wIABFla

  Here is the same but from Jammy if you want to test encryption on
  Jammy and decryption on Lunar/Mantic:

  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
  HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
  jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
  2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
  k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
  /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
  1AABrQKAUAAABh3ynbHEZ/sCAARZWg==

  The contents are expected to be different due to the use of
  randomness. Don't try to compare the base64 outputs: I'm only using
  them to ease testing across containers.

  [Where problems could occur]
  This patch makes openssl match the documented default (see "man openssl-enc" 
and search for "Blowfish" for instance) and fixes decryption from an up-to-date 
Jammy to pretty much everything else, but it also create an issue for data 
encrypted on Jammy without this patch and Jammy with this patch.

  There are two possible cases: encrypted data being streamed across
  this boundary or data at rest being transferred or read later.

  Streaming is probably not an issue in practice because it's rather the
  current situation that has been an issue and it's easy to remedy by
  updating everything (which is relatively few machines since that's
  only Jammy and not any other OS or distribution).

  Data at rest is more annoying since updating Jammy will make it
  impossible to read the data again without updates to other pieces of
  software. That sounds like a really bad thing and it kind of is but at
  the same, the benefits are much larger than the issues. Indeed, there
  is 

[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly

[Adrien Nader]

There aren't many ways to make localtime() fail and we still don't know
how this happened in this case. We expect this happens maybe on a 32-bit
machine. You can't have a really huge value in btmp anyway because
everything is stored on 32-bit signed integers but maybe seconds are
negative or microseconds are more than a million (or negative?). It's
very difficult to tell and I think we could reproduce the issue but we
might also find several ways to get the same behavior.

I'm also wondering if the bug is really in pam _if_ the behavior is
different between 32-bit and 64-bit arches. This could be worth
investigating.

Do we have a *tmp file that exhibit the issue? I think it would be worth
diving into the binary to see if anything stands out.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250

Title:
  pam_lastlog doesn't handle localtime_r related errors properly

Status in pam package in Ubuntu:
  New
Status in pam package in Fedora:
  Fix Released

Bug description:
  The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to 
noble) are affected by
  https://bugzilla.redhat.com/show_bug.cgi?id=2012871

  Customers report a command going through PAM crashing for a given user.
  A potential follow on issue can be that no ssh remote connections to an 
affected server are possible anymore, esp. painful with headless systems (was 
reported on a different distro).

  This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
  with tm = localtime_r(...) that can be NULL and needs to be handled.

  There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
  314-  ll_time = last_login.ll_time;
  315:  if ((tm = localtime_r (_time, _buf)) != NULL) {
  316-  strftime (the_time, sizeof (the_time),
  317-  /* TRANSLATORS: "strftime options for date of last 
login" */
  --
  574-
  575-  lf_time = utuser.ut_tv.tv_sec;
  576:  tm = localtime_r (_time, _buf);
  577-  strftime (the_time, sizeof (the_time),
  578-  /* TRANSLATORS: "strftime options for date of last login" */

  Case 1 (line 315) is properly handled, but not case 2 (line 576).

  The second case got fixed by:
  
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c

  This fix should be included in Ubuntu (and Debian).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/2045250/+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 2032577] Re: xz crashed with SIGSEGV in lzma_lzma_optimum_normal

[Adrien Nader]

XZ developers have a couple questions regarding this after looking at the trace:
- is it reproducible? did it happen several times?
- does the machine use ECC memory?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xz-utils in Ubuntu.
https://bugs.launchpad.net/bugs/2032577

Title:
  xz crashed with SIGSEGV in lzma_lzma_optimum_normal

Status in xz-utils package in Ubuntu:
  New

Bug description:
  xz segfaults. More details in
  https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2032379

  From Dmesg.txt on that report

  [114838.184191] xz[431483]: segfault at 7f9a93f3701a ip
  7f9b3f780c1a sp 7f9a957baa50 error 4 in
  liblzma.so.5.2.5[7f9b3f771000+1b000]

  ProblemType: Crash
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  DistroRelease: Ubuntu 22.04
  ExecutablePath: /usr/bin/xz
  ExecutableTimestamp: 1649422298
  InstallationDate: Installed on 2021-04-09 (863 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  Package: xz-utils 5.2.5-2ubuntu1
  ProcCmdline: xz --check=crc32 --threads=0 -c /var/tmp/mkinitramfs-MAIN_E1GbD9
  ProcCwd: /
  ProcEnviron:
   LC_CTYPE=C.UTF-8
   TERM=linux
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
  ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17
  SegvAnalysis:
   Segfault happened at: 0x7f9b3f780c1a:movzbl (%rdi,%r8,1),%r10d
   PC (0x7f9b3f780c1a) ok
   source "(%rdi,%r8,1)" (0x7f9a93f3701a) in non-readable VMA region: 
0x7f9a90021000-0x7f9a9400 ---p None
   destination "%r10d" ok
   Stack memory exhausted (SP below stack segment)
  SegvReason: reading VMA None
  Signal: 11
  SourcePackage: xz-utils
  Uname: Linux 5.19.0-38-generic x86_64
  UpgradeStatus: Upgraded to jammy on 2023-01-29 (204 days ago)
  UserGroups: N/A
  StacktraceTop:
   bt_find_func (len_limit=64, pos=9137198, cur=0x7f9a943edc3d "", 
cur_match=4194304, depth=24, son=son@entry=0x7f9a8afbd010, cyclic_pos=748589, 
cyclic_size=8388609, matches=0x7f9adc0ec324, len_best=11) at 
../../../../src/liblzma/lz/lz_encoder_mf.c:483
   lzma_mf_bt4_find (mf=0x7f9a9c70, matches=0x7f9adc0ec304) at 
../../../../src/liblzma/lz/lz_encoder_mf.c:721
   lzma_mf_find (mf=mf@entry=0x7f9a9c70, 
count_ptr=count_ptr@entry=0x7f9adc0ecb94, matches=matches@entry=0x7f9adc0ec304) 
at ../../../../src/liblzma/lz/lz_encoder_mf.c:28
   lzma_lzma_optimum_normal (position=, len_res=, back_res=, mf=, coder=) at ../../../../src/liblzma/lzma/lzma_encoder_optimum_normal.c:846
   lzma_lzma_optimum_normal (position=, len_res=, back_res=, mf=, coder=) at ../../../../src/liblzma/lzma/lzma_encoder_optimum_normal.c:804

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2032577/+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 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

[Adrien Nader]

** Tags removed: verification-needed verification-needed-jammy
** Tags added: verification-done verification-done-jammy

** Tags removed: foundations-triage-discuss

-- 
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/1994165

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  Fix Committed
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of three bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.

  This patch handles the SMIME_crlf_copy return code in all
  occurrences.

  Signed-off-by: Alon Bar-Lev 

  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+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 2062167] Re: [FFe] openssl: post-3.0.13 changes from git

[Adrien Nader]

** Changed in: openssl (Ubuntu)
   Status: Triaged => New

-- 
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/2062167

Title:
  [FFe] openssl: post-3.0.13 changes from git

Status in openssl package in Ubuntu:
  New

Bug description:
  I would like to have the most recent openssl version possible in
  Noble. For that I am requesting to upload all the commits in the
  openssl-3.0 branch that follow 3.0.13 which is already in the archive.

  I would like to include 3.0.14 afterwards if feasible. Having the most
  recent commits of the 3.0 branch will make that easier.

  I went through all commits since 3.0.13 at the end of January. I
  skipped a few which touch files that are not in the 3.0.13 release
  tarball (github CI stuff mostly) and edited one that touched such a
  file.

  There are only fixes. This is not surprising considering we are past
  the 13th patch release for openssl 3.0, and almost 3 years after 3.0
  was released.

  Changes are most usually backports which is a good thing as it means
  they are also tested in the other branches, including through 3.3, for
  which the .0 release was published a few days ago after weeks in
  beta/RC.

  There are a few behaviour tweaks, and that is why I want to get as
  close as possible to what 3.0.14 will be. The bigger one is
  ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection
  of engine-provided private "classic" keys", which also states "The
  workaround has caused more problems than it solved."

  As I said, I went through all commits. All look safe to me. The
  question really boils down to whether we will include these fixes in
  Noble now or if we won't: there is only a very very small chance that
  any given change is SRU'ed afterwards.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2062167/+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 2062167] Re: [FFe] openssl: post-3.0.13 changes from git

[Adrien Nader]

Note that there is a CVE fix in there too. It's low-severity because
it's only unbounded memory growth but it's quite easy to trigger and I
think that anyone who has a webserver with TLS 1.3 will want it patched.
Therefore there should be an upload of this at least.

-- 
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/2062167

Title:
  [FFe] openssl: post-3.0.13 changes from git

Status in openssl package in Ubuntu:
  Triaged

Bug description:
  I would like to have the most recent openssl version possible in
  Noble. For that I am requesting to upload all the commits in the
  openssl-3.0 branch that follow 3.0.13 which is already in the archive.

  I would like to include 3.0.14 afterwards if feasible. Having the most
  recent commits of the 3.0 branch will make that easier.

  I went through all commits since 3.0.13 at the end of January. I
  skipped a few which touch files that are not in the 3.0.13 release
  tarball (github CI stuff mostly) and edited one that touched such a
  file.

  There are only fixes. This is not surprising considering we are past
  the 13th patch release for openssl 3.0, and almost 3 years after 3.0
  was released.

  Changes are most usually backports which is a good thing as it means
  they are also tested in the other branches, including through 3.3, for
  which the .0 release was published a few days ago after weeks in
  beta/RC.

  There are a few behaviour tweaks, and that is why I want to get as
  close as possible to what 3.0.14 will be. The bigger one is
  ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection
  of engine-provided private "classic" keys", which also states "The
  workaround has caused more problems than it solved."

  As I said, I went through all commits. All look safe to me. The
  question really boils down to whether we will include these fixes in
  Noble now or if we won't: there is only a very very small chance that
  any given change is SRU'ed afterwards.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2062167/+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 2062167] [NEW] [FFe] openssl: post-3.0.13 changes from git

[Adrien Nader]

Public bug reported:

I would like to have the most recent openssl version possible in Noble.
For that I am requesting to upload all the commits in the openssl-3.0
branch that follow 3.0.13 which is already in the archive.

I would like to include 3.0.14 afterwards if feasible. Having the most
recent commits of the 3.0 branch will make that easier.

I went through all commits since 3.0.13 at the end of January. I skipped
a few which touch files that are not in the 3.0.13 release tarball
(github CI stuff mostly) and edited one that touched such a file.

There are only fixes. This is not surprising considering we are past the
13th patch release for openssl 3.0, and almost 3 years after 3.0 was
released.

Changes are most usually backports which is a good thing as it means
they are also tested in the other branches, including through 3.3, for
which the .0 release was published a few days ago after weeks in
beta/RC.

There are a few behaviour tweaks, and that is why I want to get as close
as possible to what 3.0.14 will be. The bigger one is
ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection of
engine-provided private "classic" keys", which also states "The
workaround has caused more problems than it solved."

As I said, I went through all commits. All look safe to me. The question
really boils down to whether we will include these fixes in Noble now or
if we won't: there is only a very very small chance that any given
change is SRU'ed afterwards.

** Affects: openssl (Ubuntu)
 Importance: High
 Status: Triaged

-- 
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/2062167

Title:
  [FFe] openssl: post-3.0.13 changes from git

Status in openssl package in Ubuntu:
  Triaged

Bug description:
  I would like to have the most recent openssl version possible in
  Noble. For that I am requesting to upload all the commits in the
  openssl-3.0 branch that follow 3.0.13 which is already in the archive.

  I would like to include 3.0.14 afterwards if feasible. Having the most
  recent commits of the 3.0 branch will make that easier.

  I went through all commits since 3.0.13 at the end of January. I
  skipped a few which touch files that are not in the 3.0.13 release
  tarball (github CI stuff mostly) and edited one that touched such a
  file.

  There are only fixes. This is not surprising considering we are past
  the 13th patch release for openssl 3.0, and almost 3 years after 3.0
  was released.

  Changes are most usually backports which is a good thing as it means
  they are also tested in the other branches, including through 3.3, for
  which the .0 release was published a few days ago after weeks in
  beta/RC.

  There are a few behaviour tweaks, and that is why I want to get as
  close as possible to what 3.0.14 will be. The bigger one is
  ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6: Revert "Improved detection
  of engine-provided private "classic" keys", which also states "The
  workaround has caused more problems than it solved."

  As I said, I went through all commits. All look safe to me. The
  question really boils down to whether we will include these fixes in
  Noble now or if we won't: there is only a very very small chance that
  any given change is SRU'ed afterwards.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2062167/+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 1297025] Re: Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package

[Adrien Nader]

** Changed in: openssl (Ubuntu)
Milestone: None => ubuntu-24.10

-- 
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/1297025

Title:
  Either the changelog.gz is missing or there is an erroneous link in
  the libssl1.0.0 package

Status in openssl package in Ubuntu:
  In Progress

Bug description:
  In libssl-dev for both Precise and Saucy packages for libssl-dev, there is a 
broken link:
  # ls -l /usr/share/doc/libssl-dev/changelog.gz 
  lrwxrwxrwx 1 root root 27 Jan  8 12:48 /usr/share/doc/libssl-dev/changelog.gz 
-> ../libssl1.0.0/changelog.gz
  # ls -l /usr/share/doc/libssl1.0.0/changelog.gz 
  ls: cannot access /usr/share/doc/libssl1.0.0/changelog.gz: No such file or 
directory

  I have verified this in both releases while trying to debug a failing
  build of a 3rd party library that links against these.  Build works in
  Precise, fails in Saucy.  Was looking to see what changed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1297025/+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 2063271] Re: Illegal opcode in libssl

[Adrien Nader]

AFAIU there is no issue in the package at the moment so I'll close the
report. Thanks for investigating and trying the package reinstallation.
(Also, Alex, impressive intuition!)

** Changed in: openssl (Ubuntu)
   Status: New => Invalid

-- 
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/2063271

Title:
  Illegal opcode in libssl

Status in openssl package in Ubuntu:
  Invalid

Bug description:
  Many programs using openssl now fail, typically with messages such as

Illegal instruction (core dumped)

  This seems to be a serious error, since it affects, for example,
  update-manager. Since this makes it harder to get security updates, I
  would also consider it a security vulnerability.

  The issue seems to be that openssl seems to be an attempt to use an
  illegal opcode. A few sample entries in /var/log/syslog are:

  Apr 21 19:16:39 einstein kernel: [495465.431588] traps: 
update-manager[396881] trap invalid opcode ip:740964b8ac6b sp:7409552125b0 
error:0 in libssl.so.3[740964b7a000+5b000]
  Apr 21 19:16:55 einstein kernel: [495482.104658] traps: python3[396949] trap 
invalid opcode ip:73607be8ac6b sp:736074d8d5b0 error:0 in 
libssl.so.3[73607be7a000+5b000]
  Apr 21 19:40:05 einstein kernel: [496871.653271] traps: 
chrome-gnome-sh[397293] trap invalid opcode ip:79432ffa7c6b sp:7ffd6bc03e70 
error:0 in libssl.so.3[79432ff97000+5b000]
  Apr 22 16:23:08 einstein kernel: [501744.765118] traps: 
check-new-relea[400397] trap invalid opcode ip:797c7cc8ac6b sp:797c6cace5b0 
error:0 in libssl.so.3[797c7cc7a000+5b000]
  Apr 23 15:08:03 einstein kernel: [518701.050526] traps: wget[443588] trap 
invalid opcode ip:73a8b2eb4c6b sp:7ffc04918740 error:0 in 
libssl.so.3[73a8b2ea4000+5b000]
  Apr 23 15:12:55 einstein kernel: [518992.493020] traps: curl[443851] trap 
invalid opcode ip:7e4e3951dc6b sp:7ffc804d2ed0 error:0 in 
libssl.so.3[7e4e3950d000+5b000]
  Apr 23 15:13:32 einstein kernel: [519029.181422] traps: apport-gtk[04] 
trap invalid opcode ip:7039180f5c6b sp:703902bfaad0 error:0 in 
libssl.so.3[7039180e5000+5b000]

  This bug report itself had to be submitted manually since ubuntu-bug
  now itself fails.

  lsb_release -rd reports:

Description:Ubuntu 22.04.4 LTS
Release:22.04

  apt-cache policy openssl reports:

openssl:
  Installed: 3.0.2-0ubuntu1.15
  Candidate: 3.0.2-0ubuntu1.15
  Version table:
 *** 3.0.2-0ubuntu1.15 500
500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64 
Packages
500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 
Packages
100 /var/lib/dpkg/status
 3.0.2-0ubuntu1 500
 500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

  /proc/version for my computer gives

Linux version 6.5.0-28-generic (buildd@lcy02-amd64-098) 
(x86_64-linux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0, GNU ld (GNU 
Binutils for Ubuntu) 2.38) #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu 
Apr  4 14:39:20 UTC 2

  /proc/cpuinfo for my computer starts

  processor : 0
  vendor_id : GenuineIntel
  cpu family: 6
  model : 78
  model name: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
  stepping  : 3
  microcode : 0xf0
  cpu MHz   : 500.018
  cache size: 4096 KB
  physical id   : 0
  siblings  : 4
  core id   : 0
  cpu cores : 2
  apicid: 0
  initial apicid: 0
  fpu   : yes
  fpu_exception : yes
  cpuid level   : 22
  wp: yes
  flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 
sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust 
bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt 
xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify 
hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
  bugs  : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit srbds mmio_stale_data retbleed gds
  bogomips  : 5199.98
  clflush size  : 64
  cache_alignment   : 64
  address sizes : 39 bits physical, 48 bits virtual
  power management:
  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2063271/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : 

[Touch-packages] [Bug 2063898] Re: broken doc symlinks after t64 transition in noble

[Adrien Nader]

*** This bug is a duplicate of bug 1297025 ***
https://bugs.launchpad.net/bugs/1297025

** This bug has been marked a duplicate of bug 1297025
   Either the changelog.gz is missing or there is an erroneous link in the 
libssl1.0.0 package

-- 
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/2063898

Title:
  broken doc symlinks after t64 transition in noble

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  $ pwd
  /usr/share/doc/openssl

  $ ls -l
  total 52
  lrwxrwxrwx 1 root root30 mars  31 08:42 changelog.Debian.gz -> 
../libssl3/changelog.Debian.gz
  lrwxrwxrwx 1 root root23 mars  31 08:42 changelog.gz -> 
../libssl3/changelog.gz
  lrwxrwxrwx 1 root root20 mars  31 08:42 copyright -> ../libssl3/copyright

  libssl3 doenst exist anymore, it is now libssl3t64

  $ apt-cache policy openssl libssl3t64
  openssl:
Installed: 3.0.13-0ubuntu3
Candidate: 3.0.13-0ubuntu3
Version table:
   *** 3.0.13-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages
  100 /var/lib/dpkg/status
  libssl3t64:
Installed: 3.0.13-0ubuntu3
Candidate: 3.0.13-0ubuntu3
Version table:
   *** 3.0.13-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2063898/+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 1297025] Re: Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package

[Adrien Nader]

I plan to work on this during the OO cycle. It's an issue inherited from
Debian AFAIU.

-- 
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/1297025

Title:
  Either the changelog.gz is missing or there is an erroneous link in
  the libssl1.0.0 package

Status in openssl package in Ubuntu:
  In Progress

Bug description:
  In libssl-dev for both Precise and Saucy packages for libssl-dev, there is a 
broken link:
  # ls -l /usr/share/doc/libssl-dev/changelog.gz 
  lrwxrwxrwx 1 root root 27 Jan  8 12:48 /usr/share/doc/libssl-dev/changelog.gz 
-> ../libssl1.0.0/changelog.gz
  # ls -l /usr/share/doc/libssl1.0.0/changelog.gz 
  ls: cannot access /usr/share/doc/libssl1.0.0/changelog.gz: No such file or 
directory

  I have verified this in both releases while trying to debug a failing
  build of a 3rd party library that links against these.  Build works in
  Precise, fails in Saucy.  Was looking to see what changed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1297025/+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 2058017] Re: openssl is not LTO-safe

[Adrien Nader]

** Changed in: openssl (Ubuntu)
   Status: In Progress => Fix Committed

-- 
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/2058017

Title:
  openssl is not LTO-safe

Status in openssl package in Ubuntu:
  Fix Committed

Bug description:
  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably
  no performance gains to LTO for this package.

  Openssl is an old project and the codebase wasn't written with
  aliasing rules in mind. There are several reports of issues related to
  LTO. The openssl technical commitee says "currently we're not going to
  fix all the strict aliasing and other LTO problems" and "Fixes raised
  in pull requests will be considered."; in other words: if you find a
  violation, we'll merge your fixes but we're not going to dedicate time
  to fixing them ourselves.

  We don't have specific reports on launchpad at the moment but there
  has been at least one issue experienced by the FIPS: the compiler
  decided a 0-filled array could be removed and proceeded to do so. In
  addition to that, compilers are only pushing this further and further.
  Issues are impossible to predict and even security updates could
  trigger issues.

  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057

  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment
  and for Noble since I don't have time to investigate more changes.

  Performance shouldn't be impacted much if at all:
  - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these got miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.

  Code size increases by a few percents except for libcrypto which gets
  17% larger. The corresponding .deb file increases by 2.6% only.

  I ran "openssl speed" with a long benchmark time in order to get good
  results (there is a variation of several percents with the default
  times). I then scripted a diff which output is shown below; "."
  means the difference is within 2% which is the vast majority. Also
  note that some important ciphers are not present due to how openssl
  speed works; small aes-*-cbc are negatively impacted, up to -10% but
  that would -50% if you compared between "software" and "hardware"
  implementations, the results would be reversed at anything but the
  smallest data sizes, and the fact that you want to use hardware
  implementations as much as possible means that you also want to avoid
  places where LTO could have an effect.

  type  16  bytes   64 bytes  256  
bytes   1024   bytes  8192  bytes  16384  bytes
  md5   .   .   .  .  ..
  sha1  .   .   .  .  ..
  rmd160.   .   .  .  ..
  sha256+2.3%   .   .  .  ..
  sha512.   .   .  .  ..
  hmac(md5) .   .   .  .  ..
  des-ede3  .   .   .  .  ..
  aes-128-cbc   -10.0%  .   .  .  ..
  aes-192-cbc   -7.6%   .   .  .  ..
  aes-256-cbc   -5.2%   .   .  .  ..
  camellia-128-cbc  .   .   .  .  ..
  camellia-192-cbc  .   .   .  .  ..
  camellia-256-cbc  .   .   .  .  ..
  ghash .   .   +21.2% -27.3% +30.5%   
+39.3%
  rand  -2.8%   -2.9%   -2.9%  -2.8%  ..
  sign  verify  sign/s  verify/s
  rsa   512 bits0.31s 

[Touch-packages] [Bug 2056593] Re: [FFE] FIPS compatibility patches

[Adrien Nader]

** Changed in: openssl (Ubuntu)
   Status: Triaged => Fix Committed

-- 
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/2056593

Title:
  [FFE] FIPS compatibility patches

Status in openssl package in Ubuntu:
  Fix Committed

Bug description:
  We have an open MR with a handful of FIPS compatibilty changes we wore hoping
  to get into 24.04. The main purpose of the changes is to detect whether the
  kernel is running in FIPS mode and adjust the behavior of the library
  accordingly by loading the correct provider backend and using defaults that
  are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code
  paths and crashing.

  The proposed patches were taken from the OpenSSL version shipped in the FIPS
  archive at esm.ubuntu.com for 22.04. Having them in the regular archive will
  reduce the maintenance work significantly. None of the changes should have any
  impact on running OpenSSL in regular (non-fips) mode.

  Below is a detailed list of the changes:

  - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch:
    This adds a new internal API to determine whether the kernel has been booted
    in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE
    environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify 
an
    alternative path for the fips_enabled file and is used in tests.
    The FIPS_MODULE switch can be used to enable build of the the FIPS provider
    module specific parts which are not needed in the OpenSSL library itself.

  - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch:
    This automatically configures all library contexts to use the FIPS provider 
when
    the kernel is booted in FIPS mode by:
    - Setting "fips=yes" as the default property for algorithm fetches
    - Loading and activating the FIPS provider as the fallback provider.

    If applications load providers via a configuration either because the 
default
    configuration is modified or they override the default configuration, this
    disables loading of the fallback providers. In this case, the configuration
    must load the FIPS provider when FIPS mode is enabled, else algorithm 
fetches
    will fail

    Applications can choose to use non-FIPS approved algorithms by specifying 
the
    "-fips" or "fips=no" property for algorithm fetches and loading the default
    provider.

  - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch:
    Omit unavailable algorithms in FIPS mode

  - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch
    The -propquery argument might be used to define a preference for which 
provider
    an algorithm is fetched from. Set the query properties for the library 
context
    DRBG fetches as well so that they are fetched with the same properties.

  - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch:
    This test uses 2 library contexts - one context for creating initial test 
keys,
    and then another context (or the default context) for running tests. There 
is an
    issue that during the encoding tests, the OSSL_ENCODER_CTX is created from 
the
    created EVP_PKEYs, which are associated with the library context used to 
create
    the keys. This means that encoding tests run with the wrong library context,
    which always uses the default provider.

  These changes are now included in a larger MR with other changes in
  the same package version:
  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486

  The now-superseded MR is at
  
https://code.launchpad.net/~tobhe/ubuntu/+source/openssl/+git/openssl/+merge/460953

  Since OpenSSL just received another big update to 3.0.13 we had to rebase our 
changes
  and will have to rerun our install/upgrade tests.

  A test build is also available at
  https://launchpad.net/~tobhe/+archive/ubuntu/openssl-test/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2056593/+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 2058017] Re: openssl is not LTO-safe

[Adrien Nader]

** Description changed:

  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably no
  performance gains to LTO for this package.
  
  Openssl is an old project and the codebase wasn't written with aliasing
  rules in mind. There are several reports of issues related to LTO. The
  openssl technical commitee says "currently we're not going to fix all
  the strict aliasing and other LTO problems" and "Fixes raised in pull
  requests will be considered."; in other words: if you find a violation,
  we'll merge your fixes but we're not going to dedicate time to fixing
  them ourselves.
  
  We don't have specific reports on launchpad at the moment but there has
  been at least one issue experienced by the FIPS: the compiler decided a
  0-filled array could be removed and proceeded to do so. In addition to
  that, compilers are only pushing this further and further. Issues are
  impossible to predict and even security updates could trigger issues.
  
  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
  
  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment and
  for Noble since I don't have time to investigate more changes.
  
  Performance shouldn't be impacted much if at all:
  - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these got miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.
  
  Code size increases by a few percents except for libcrypto which gets
  17% larger. The corresponding .deb file increases by 2.6% only.
  
- I will add results of "openssl speed" soon (in a few hours).
+ I ran "openssl speed" with a long benchmark time in order to get good
+ results (there is a variation of several percents with the default
+ times). I then scripted a diff which output is shown below (hopefully it
+ will display fine...); entries within 2% are not displayed. Also note
+ that some important ciphers are not present due to how openssl speed
+ works; small aes-*-cbc are negatively impacted, up to -10% but that
+ would -50% if you compared between "software" and "hardware"
+ implementations, the results would be reversed at anything but the
+ smallest data sizes, and the fact that you want to use hardware
+ implementations as much as possible means that you also want to avoid
+ places where LTO could have an effect.
+ 
+ type  16  bytes   64 bytes  256  
bytes  1024   bytes  8192  bytes  16384  bytes
+ md5
+ sha1
+ rmd160
+ sha256+2.3%
+ sha512
+ hmac(md5)
+ des-ede3
+ aes-128-cbc   -10.0%
+ aes-192-cbc   -7.6%
+ aes-256-cbc   -5.2%
+ camellia-128-cbc
+ camellia-192-cbc
+ camellia-256-cbc
+ ghash +21.2%  -27.3%  +30.5% +39.3%
+ rand  -2.8%   -2.9%   -2.9%  -2.8%
+ sign  verify  sign/s  verify/s
+ rsa   512 bits0.31s  0.02s  -2.7%
+ rsa   1024bits0.05s
+ rsa   2048bits+2.4%  0.15s  -2.3%
+ rsa   3072bits0.32s
+ rsa   4096bits
+ rsa   7680bits30.2
+ rsa   15360   bits5.9
+ sign  verify  sign/s  verify/s
+ dsa   512 bits+4.8%  0.24s  -3.9%
+ dsa   1024bits+2.5%  -3.3%  +2.4%
+ dsa   2048bits+2.0%
+ sign  verify  sign/s  verify/s
+ 160   bitsecdsa   (secp160r1)+100.0%+100.0%  -2.2%
+ 192   bitsecdsa   (nistp192) 0.0002s0.0002s  
-3.6%  -3.3%
+ 224   bitsecdsa   (nistp224) 0.s0.0001s
+ 256   bitsecdsa   (nistp256) 0.s0.0001s
+ 384   bitsecdsa   (nistp384) +14.3% 0.0006s  -3.2%
+ 521   bitsecdsa   (nistp521) 0.0002s0.0005s
+ 163   bitsecdsa   (nistk163) 0.0002s0.0003s  
-3.2%  

[Touch-packages] [Bug 2058017] Re: openssl is not LTO-safe

[Adrien Nader]

** Description changed:

  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably no
  performance gains to LTO for this package.
  
  Openssl is an old project and the codebase wasn't written with aliasing
  rules in mind. There are several reports of issues related to LTO. The
  openssl technical commitee says "currently we're not going to fix all
  the strict aliasing and other LTO problems" and "Fixes raised in pull
  requests will be considered."; in other words: if you find a violation,
  we'll merge your fixes but we're not going to dedicate time to fixing
  them ourselves.
  
  We don't have specific reports on launchpad at the moment but there has
  been at least one issue experienced by the FIPS: the compiler decided a
  0-filled array could be removed and proceeded to do so. In addition to
  that, compilers are only pushing this further and further. Issues are
  impossible to predict and even security updates could trigger issues.
  
  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
  
  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment and
  for Noble since I don't have time to investigate more changes.
  
  Performance shouldn't be impacted much if at all:
  - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these got miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.
  
  Code size increases by a few percents except for libcrypto which gets
  17% larger. The corresponding .deb file increases by 2.6% only.
  
  I ran "openssl speed" with a long benchmark time in order to get good
  results (there is a variation of several percents with the default
- times). I then scripted a diff which output is shown below (hopefully it
- will display fine...); entries within 2% are not displayed. Also note
+ times). I then scripted a diff which output is shown below; "."
+ means the difference is within 2% which is the vast majority. Also note
  that some important ciphers are not present due to how openssl speed
  works; small aes-*-cbc are negatively impacted, up to -10% but that
  would -50% if you compared between "software" and "hardware"
  implementations, the results would be reversed at anything but the
  smallest data sizes, and the fact that you want to use hardware
  implementations as much as possible means that you also want to avoid
  places where LTO could have an effect.
  
  type  16  bytes   64 bytes  256  
bytes   1024   bytes  8192  bytes  16384  bytes
  md5   .   .   .  .  ..
  sha1  .   .   .  .  ..
  rmd160.   .   .  .  ..
  sha256+2.3%   .   .  .  ..
  sha512.   .   .  .  ..
  hmac(md5) .   .   .  .  ..
  des-ede3  .   .   .  .  ..
  aes-128-cbc   -10.0%  .   .  .  ..
  aes-192-cbc   -7.6%   .   .  .  ..
  aes-256-cbc   -5.2%   .   .  .  ..
  camellia-128-cbc  .   .   .  .  ..
  camellia-192-cbc  .   .   .  .  ..
  camellia-256-cbc  .   .   .  .  ..
  ghash .   .   +21.2% -27.3% +30.5%   
+39.3%
  rand  -2.8%   -2.9%   -2.9%  -2.8%  ..
  sign  verify  sign/s  verify/s
  rsa   512 bits0.31s  0.02s  -2.7%.
  rsa   1024bits.  0.05s  ..
  rsa   2048bits+2.4%  

[Touch-packages] [Bug 2030784] Re: Backport Intel's AVX512 patches on openssl 3.0

[Adrien Nader]

Thanks a lot for looking at this. The issue seems fixed on my machine.
There are currently several changes being prepared for openssl and I
think I'd rather batch them considering the state of the CI queue but
this will definitely go into Noble. Thanks again.

-- 
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/2030784

Title:
  Backport Intel's AVX512 patches on openssl 3.0

Status in openssl package in Ubuntu:
  Fix Released

Bug description:
  https://github.com/openssl/openssl/pull/14908

  https://github.com/openssl/openssl/pull/17239

  These should provide a nice performance bonus on recent CPUs, and the
  patches are fairly self-contained.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2030784/+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 2058017] [NEW] openssl is not LTO-safe

[Adrien Nader]

Public bug reported:

tl;dr: since it's too much work to make openssl LTO-safe, upstream
doesn't see it as a goal and doesn't test it, and there are probably no
performance gains to LTO for this package.

Openssl is an old project and the codebase wasn't written with aliasing
rules in mind. There are several reports of issues related to LTO. The
openssl technical commitee says "currently we're not going to fix all
the strict aliasing and other LTO problems" and "Fixes raised in pull
requests will be considered."; in other words: if you find a violation,
we'll merge your fixes but we're not going to dedicate time to fixing
them ourselves.

We don't have specific reports on launchpad at the moment but but we
cannot rule out that we're already experiencing miscompilations and
compilers are only pushing this further and further. This is impossible
to know in advance and even security updates could trigger issues.

Gentoo prevents usage of LTO for openssl and has some links related to this at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
- https://github.com/llvm/llvm-project/issues/55255
- https://github.com/openssl/openssl/issues/12247
- https://github.com/openssl/openssl/issues/18225
- https://github.com/openssl/openssl/issues/18663
- https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057

Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
strict-aliasing. I don't plan to do the same at least at the moment and
for Noble since I don't have time to investigate more changes.

Performance shouldn't be impacted much if at all:
- crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these can get miscompiled)
- the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
- at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
- if LTO-compliance was doable and thought to be useful by upstream, they would 
have certainly pushed that forward, especially in the wake of openssl 3.0's 
performance issues.

Code size increases by a few percents except for libcrypto which gets
17% larger. The corresponding .deb file increases by 2.6% only.

** Affects: openssl (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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/2058017

Title:
  openssl is not LTO-safe

Status in openssl package in Ubuntu:
  New

Bug description:
  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably
  no performance gains to LTO for this package.

  Openssl is an old project and the codebase wasn't written with
  aliasing rules in mind. There are several reports of issues related to
  LTO. The openssl technical commitee says "currently we're not going to
  fix all the strict aliasing and other LTO problems" and "Fixes raised
  in pull requests will be considered."; in other words: if you find a
  violation, we'll merge your fixes but we're not going to dedicate time
  to fixing them ourselves.

  We don't have specific reports on launchpad at the moment but but we
  cannot rule out that we're already experiencing miscompilations and
  compilers are only pushing this further and further. This is
  impossible to know in advance and even security updates could trigger
  issues.

  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057

  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment
  and for Noble since I don't have time to investigate more changes.

  Performance shouldn't be impacted much if at all:
  - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these can get miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.

  Code size increases by a few percents 

[Touch-packages] [Bug 2058017] Re: [FFe] openssl is not LTO-safe

[Adrien Nader]

** Description changed:

  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably no
  performance gains to LTO for this package.
  
  Openssl is an old project and the codebase wasn't written with aliasing
  rules in mind. There are several reports of issues related to LTO. The
  openssl technical commitee says "currently we're not going to fix all
  the strict aliasing and other LTO problems" and "Fixes raised in pull
  requests will be considered."; in other words: if you find a violation,
  we'll merge your fixes but we're not going to dedicate time to fixing
  them ourselves.
  
- We don't have specific reports on launchpad at the moment but but we
- cannot rule out that we're already experiencing miscompilations and
- compilers are only pushing this further and further. This is impossible
- to know in advance and even security updates could trigger issues.
+ We don't have specific reports on launchpad at the moment but there has
+ been at least one issue experienced by the FIPS: the compiler decided a
+ 0-filled array could be removed and proceeded to do so. In addition to
+ that, compilers are only pushing this further and further. Issues are
+ impossible to predict and even security updates could trigger issues.
  
  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057
  
  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment and
  for Noble since I don't have time to investigate more changes.
  
  Performance shouldn't be impacted much if at all:
- - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these can get miscompiled)
+ - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these got miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.
  
  Code size increases by a few percents except for libcrypto which gets
  17% larger. The corresponding .deb file increases by 2.6% only.
+ 
+ I will add results of "openssl speed" soon (in a few hours).

-- 
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/2058017

Title:
  openssl is not LTO-safe

Status in openssl package in Ubuntu:
  New

Bug description:
  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably
  no performance gains to LTO for this package.

  Openssl is an old project and the codebase wasn't written with
  aliasing rules in mind. There are several reports of issues related to
  LTO. The openssl technical commitee says "currently we're not going to
  fix all the strict aliasing and other LTO problems" and "Fixes raised
  in pull requests will be considered."; in other words: if you find a
  violation, we'll merge your fixes but we're not going to dedicate time
  to fixing them ourselves.

  We don't have specific reports on launchpad at the moment but there
  has been at least one issue experienced by the FIPS: the compiler
  decided a 0-filled array could be removed and proceeded to do so. In
  addition to that, compilers are only pushing this further and further.
  Issues are impossible to predict and even security updates could
  trigger issues.

  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057

  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment
  and for Noble since I don't have time to investigate more changes.

  Performance shouldn't be impacted much if at 

[Touch-packages] [Bug 2056593] Re: [FFE] FIPS compatibility patches

[Adrien Nader]

I did some additional tests too in a noble container.

With/without the env var to set the file location, including with the
file missing, with/without the env var to force FIPS mode, and using
values 0, 1, 42, -42, a.

By the way, note that access to these environment variables uses
secure_getenv().

-- 
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/2056593

Title:
  [FFE] FIPS compatibility patches

Status in openssl package in Ubuntu:
  New

Bug description:
  We have an open MR with a handful of FIPS compatibilty changes we wore hoping
  to get into 24.04. The main purpose of the changes is to detect whether the
  kernel is running in FIPS mode and adjust the behavior of the library
  accordingly by loading the correct provider backend and using defaults that
  are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code
  paths and crashing.

  The proposed patches were taken from the OpenSSL version shipped in the FIPS
  archive at esm.ubuntu.com for 22.04. Having them in the regular archive will
  reduce the maintenance work significantly. None of the changes should have any
  impact on running OpenSSL in regular (non-fips) mode.

  Below is a detailed list of the changes:

  - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch:
    This adds a new internal API to determine whether the kernel has been booted
    in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE
    environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify 
an
    alternative path for the fips_enabled file and is used in tests.
    The FIPS_MODULE switch can be used to enable build of the the FIPS provider
    module specific parts which are not needed in the OpenSSL library itself.

  - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch:
    This automatically configures all library contexts to use the FIPS provider 
when
    the kernel is booted in FIPS mode by:
    - Setting "fips=yes" as the default property for algorithm fetches
    - Loading and activating the FIPS provider as the fallback provider.

    If applications load providers via a configuration either because the 
default
    configuration is modified or they override the default configuration, this
    disables loading of the fallback providers. In this case, the configuration
    must load the FIPS provider when FIPS mode is enabled, else algorithm 
fetches
    will fail

    Applications can choose to use non-FIPS approved algorithms by specifying 
the
    "-fips" or "fips=no" property for algorithm fetches and loading the default
    provider.

  - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch:
    Omit unavailable algorithms in FIPS mode

  - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch
    The -propquery argument might be used to define a preference for which 
provider
    an algorithm is fetched from. Set the query properties for the library 
context
    DRBG fetches as well so that they are fetched with the same properties.

  - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch:
    This test uses 2 library contexts - one context for creating initial test 
keys,
    and then another context (or the default context) for running tests. There 
is an
    issue that during the encoding tests, the OSSL_ENCODER_CTX is created from 
the
    created EVP_PKEYs, which are associated with the library context used to 
create
    the keys. This means that encoding tests run with the wrong library context,
    which always uses the default provider.

  These changes are now included in a larger MR with other changes in
  the same package version:
  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486

  The now-superseded MR is at
  
https://code.launchpad.net/~tobhe/ubuntu/+source/openssl/+git/openssl/+merge/460953

  Since OpenSSL just received another big update to 3.0.13 we had to rebase our 
changes
  and will have to rerun our install/upgrade tests.

  A test build is also available at
  https://launchpad.net/~tobhe/+archive/ubuntu/openssl-test/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2056593/+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 2058017] Re: openssl is not LTO-safe

[Adrien Nader]

** Summary changed:

- [FFe] openssl is not LTO-safe
+ openssl is not LTO-safe

-- 
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/2058017

Title:
  openssl is not LTO-safe

Status in openssl package in Ubuntu:
  New

Bug description:
  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably
  no performance gains to LTO for this package.

  Openssl is an old project and the codebase wasn't written with
  aliasing rules in mind. There are several reports of issues related to
  LTO. The openssl technical commitee says "currently we're not going to
  fix all the strict aliasing and other LTO problems" and "Fixes raised
  in pull requests will be considered."; in other words: if you find a
  violation, we'll merge your fixes but we're not going to dedicate time
  to fixing them ourselves.

  We don't have specific reports on launchpad at the moment but there
  has been at least one issue experienced by the FIPS: the compiler
  decided a 0-filled array could be removed and proceeded to do so. In
  addition to that, compilers are only pushing this further and further.
  Issues are impossible to predict and even security updates could
  trigger issues.

  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057

  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment
  and for Noble since I don't have time to investigate more changes.

  Performance shouldn't be impacted much if at all:
  - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these got miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.

  Code size increases by a few percents except for libcrypto which gets
  17% larger. The corresponding .deb file increases by 2.6% only.

  I will add results of "openssl speed" soon (in a few hours).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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 2058017] Re: [FFe] openssl is not LTO-safe

[Adrien Nader]

** Summary changed:

- openssl is not LTO-safe
+ [FFe] openssl is not LTO-safe

-- 
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/2058017

Title:
  [FFe] openssl is not LTO-safe

Status in openssl package in Ubuntu:
  New

Bug description:
  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably
  no performance gains to LTO for this package.

  Openssl is an old project and the codebase wasn't written with
  aliasing rules in mind. There are several reports of issues related to
  LTO. The openssl technical commitee says "currently we're not going to
  fix all the strict aliasing and other LTO problems" and "Fixes raised
  in pull requests will be considered."; in other words: if you find a
  violation, we'll merge your fixes but we're not going to dedicate time
  to fixing them ourselves.

  We don't have specific reports on launchpad at the moment but but we
  cannot rule out that we're already experiencing miscompilations and
  compilers are only pushing this further and further. This is
  impossible to know in advance and even security updates could trigger
  issues.

  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057

  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment
  and for Noble since I don't have time to investigate more changes.

  Performance shouldn't be impacted much if at all:
  - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these can get miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.

  Code size increases by a few percents except for libcrypto which gets
  17% larger. The corresponding .deb file increases by 2.6% only.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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 2058017] Re: openssl is not LTO-safe

[Adrien Nader]

** Changed in: openssl (Ubuntu)
Milestone: None => ubuntu-24.04

** Changed in: openssl (Ubuntu)
 Assignee: (unassigned) => Adrien Nader (adrien-n)

** Changed in: openssl (Ubuntu)
   Status: New => In Progress

-- 
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/2058017

Title:
  openssl is not LTO-safe

Status in openssl package in Ubuntu:
  In Progress

Bug description:
  tl;dr: since it's too much work to make openssl LTO-safe, upstream
  doesn't see it as a goal and doesn't test it, and there are probably
  no performance gains to LTO for this package.

  Openssl is an old project and the codebase wasn't written with
  aliasing rules in mind. There are several reports of issues related to
  LTO. The openssl technical commitee says "currently we're not going to
  fix all the strict aliasing and other LTO problems" and "Fixes raised
  in pull requests will be considered."; in other words: if you find a
  violation, we'll merge your fixes but we're not going to dedicate time
  to fixing them ourselves.

  We don't have specific reports on launchpad at the moment but there
  has been at least one issue experienced by the FIPS: the compiler
  decided a 0-filled array could be removed and proceeded to do so. In
  addition to that, compilers are only pushing this further and further.
  Issues are impossible to predict and even security updates could
  trigger issues.

  Gentoo prevents usage of LTO for openssl and has some links related to this 
at 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131
 :
  - https://github.com/llvm/llvm-project/issues/55255
  - https://github.com/openssl/openssl/issues/12247
  - https://github.com/openssl/openssl/issues/18225
  - https://github.com/openssl/openssl/issues/18663
  - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057

  Gentoo also prevents usage of -fstrict-aliasing and always set -fno-
  strict-aliasing. I don't plan to do the same at least at the moment
  and for Noble since I don't have time to investigate more changes.

  Performance shouldn't be impacted much if at all:
  - crypto algorithms are implemented in ASM (funnily, using C implementations 
can trigger issues because these got miscompiled)
  - the rest of the openssl codebase probably doesn't benefit from LTO because 
source files match codepaths quite well
  - at the moment, openssl performance for servers is bad due to 
algorithmic/architectural issues, not micro-optimizations and these wouldn't be 
noticed
  - if LTO-compliance was doable and thought to be useful by upstream, they 
would have certainly pushed that forward, especially in the wake of openssl 
3.0's performance issues.

  Code size increases by a few percents except for libcrypto which gets
  17% larger. The corresponding .deb file increases by 2.6% only.

  I will add results of "openssl speed" soon (in a few hours).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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 2056593] Re: [FFE] FIPS compatibility patches

[Adrien Nader]

** Description changed:

  We have an open MR with a handful of FIPS compatibilty changes we wore hoping
  to get into 24.04. The main purpose of the changes is to detect whether the
  kernel is running in FIPS mode and adjust the behavior of the library
  accordingly by loading the correct provider backend and using defaults that
  are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code
  paths and crashing.
  
  The proposed patches were taken from the OpenSSL version shipped in the FIPS
  archive at esm.ubuntu.com for 22.04. Having them in the regular archive will
  reduce the maintenance work significantly. None of the changes should have any
  impact on running OpenSSL in regular (non-fips) mode.
  
  Below is a detailed list of the changes:
  
  - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch:
-   This adds a new internal API to determine whether the kernel has been booted
-   in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE
-   environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify 
an
-   alternative path for the fips_enabled file and is used in tests.
-   The FIPS_MODULE switch can be used to enable build of the the FIPS provider
-   module specific parts which are not needed in the OpenSSL library itself.
+   This adds a new internal API to determine whether the kernel has been booted
+   in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE
+   environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify 
an
+   alternative path for the fips_enabled file and is used in tests.
+   The FIPS_MODULE switch can be used to enable build of the the FIPS provider
+   module specific parts which are not needed in the OpenSSL library itself.
  
  - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch:
-   This automatically configures all library contexts to use the FIPS provider 
when
-   the kernel is booted in FIPS mode by:
-   - Setting "fips=yes" as the default property for algorithm fetches
-   - Loading and activating the FIPS provider as the fallback provider.
+   This automatically configures all library contexts to use the FIPS provider 
when
+   the kernel is booted in FIPS mode by:
+   - Setting "fips=yes" as the default property for algorithm fetches
+   - Loading and activating the FIPS provider as the fallback provider.
  
-   If applications load providers via a configuration either because the 
default
-   configuration is modified or they override the default configuration, this
-   disables loading of the fallback providers. In this case, the configuration
-   must load the FIPS provider when FIPS mode is enabled, else algorithm 
fetches
-   will fail
+   If applications load providers via a configuration either because the 
default
+   configuration is modified or they override the default configuration, this
+   disables loading of the fallback providers. In this case, the configuration
+   must load the FIPS provider when FIPS mode is enabled, else algorithm 
fetches
+   will fail
  
-   Applications can choose to use non-FIPS approved algorithms by specifying 
the
-   "-fips" or "fips=no" property for algorithm fetches and loading the default
-   provider.
+   Applications can choose to use non-FIPS approved algorithms by specifying 
the
+   "-fips" or "fips=no" property for algorithm fetches and loading the default
+   provider.
  
  - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch:
-   Omit unavailable algorithms in FIPS mode
+   Omit unavailable algorithms in FIPS mode
  
  - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch
-   The -propquery argument might be used to define a preference for which 
provider
-   an algorithm is fetched from. Set the query properties for the library 
context
-   DRBG fetches as well so that they are fetched with the same properties.
+   The -propquery argument might be used to define a preference for which 
provider
+   an algorithm is fetched from. Set the query properties for the library 
context
+   DRBG fetches as well so that they are fetched with the same properties.
  
  - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch:
-   This test uses 2 library contexts - one context for creating initial test 
keys,
-   and then another context (or the default context) for running tests. There 
is an
-   issue that during the encoding tests, the OSSL_ENCODER_CTX is created from 
the
-   created EVP_PKEYs, which are associated with the library context used to 
create
-   the keys. This means that encoding tests run with the wrong library context,
-   which always uses the default provider.
+   This test uses 2 library contexts - one context for creating initial test 
keys,
+   and then another context (or the default context) for running tests. There 
is an
+   issue that during the encoding tests, the OSSL_ENCODER_CTX is created from 
the
+   created EVP_PKEYs, which are 

[Touch-packages] [Bug 2056739] Re: apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config"

[Adrien Nader]

Hey,

I think everything in the gnutls/ directory should be allowed: there can
be profiles with arbitrary names (or at least alnum I guess) which
define priority/configuration strings that can be used by gnutls
applications. I'm not aware of anything else that typically goes there
but I haven't checked. I'll have another look today.

More generally, there can be the same issue for openssl which has its
own abstraction file but isn't included by default AFAIU.

A similar issue could apply to ssl_certs since some apps/libraries ship
their own cert bundle and could function despite not having access to
the system store (I'm looking at you python). I don't know what would be
a typical behavior here but I'm pretty sure that the whole range of
possible behavior exists in the wild.

I'm wondering if I understood the current rules fine because based on my
understanding, I would have expected warnings for these too.

A noteworthy change is
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/2016303 : it would
access to /etc/nss . I don't know if NSS silently ignores inaccessible
system-wide configuration or not. You might want to include it already.

I think all these libraries should probably fail on EPERM. Probably 0
change upstreams accept such a change if it's needed however. :P

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2056739

Title:
  apparmor="DENIED" operation="open" class="file" profile="virt-aa-
  helper" name="/etc/gnutls/config"

Status in apparmor package in Ubuntu:
  New
Status in chrony package in Ubuntu:
  New
Status in gnutls28 package in Ubuntu:
  New
Status in libvirt package in Ubuntu:
  New
Status in apparmor source package in Noble:
  New
Status in chrony source package in Noble:
  New
Status in gnutls28 source package in Noble:
  New
Status in libvirt source package in Noble:
  New

Bug description:
  Christian summarizes this after the great reports by Martin:

  gnutls started to ship forceful disables in pkg/import/3.8.1-4ubuntu3
  and added more later.

  Due to that anything linked against gnutls while being apparmor
  isolated now hits similar denials, preventing the desired effect of
  the config change BTW.

  I think for safety we WANT to always allow this access, otherwise
  people will subtly not have crypto control about the more important
  (those isolated) software. Because after the denial I'd expect this to
  not really disable it in the program linked to gnutls (details might
  vary depending what they really use gnutls for).

  I do not nkow of a gnutls abstraction to use, but TBH I'm afraid now
  fixing a few but leaving this open in some others not spotted.

  I'd therefore suggest, but we need to discuss, to therefore change it
  in /etc/apparmor.d/abstractions/base.

  Therefore I'm adding gnutls (and Adrien) as well as apparmor to the
  bug tasks.

  
  --- --- --- --- --- --- --- --- --- --- --- ---
  --- --- --- --- --- --- --- --- --- --- --- ---

  
  Merely booting current noble cloud image with "chrony" installed causes this:

  audit: type=1400 audit(1710152842.540:107): apparmor="DENIED"
  operation="open" class="file" profile="/usr/sbin/chronyd"
  name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r"
  denied_mask="r" fsuid=0 ouid=0

  
  --- --- --- --- --- --- --- --- --- --- --- ---
  --- --- --- --- --- --- --- --- --- --- --- ---

  
  Running any VM in libvirt causes a new AppArmor violation in current noble. 
This is a regression, this didn't happen in any previous release.

  Reproducer:

    virt-install --memory 50 --pxe --virt-type qemu --os-variant
  alpinelinux3.8 --disk none --wait 0 --name test1

  (This is the simplest way to create a test VM. But it's form or shape
  doesn't matter at all).

  Results in lots of

  audit: type=1400 audit(1710146677.570:108): apparmor="DENIED"
  operation="open" class="file" profile="virt-aa-helper"
  name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper"
  requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  libvirt-daemon 10.0.0-2ubuntu1
  apparmor 4.0.0~alpha4-0ubuntu1
  libgnutls30:amd64 3.8.3-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056739/+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 2055422] Re: Please sync xz-utils 5.6.0-0.2 from Debian experimental

[Adrien Nader]

I had forgotten about this bug. Thanks for bringing this up and let me
close this.

** Changed in: xz-utils (Ubuntu)
   Status: New => Invalid

** Description changed:

+ NOTE: THE VERSION MENTIONED HERE HAS BEEN BACKDOORED.
+ I am keeping the text below unchanged due to its possible historical 
relevance.
+ 
+ ==
+ 
  Xz-utils 5.6.0 was released last Friday. It features a much faster
  decompression code on all platforms but on x86_64 in particular, it is
  60% faster in my testing. It also aligns better current practices of
  enabling multi-threading by default (always with a default memory limit
  of 25% of the system physical memory).
  
  Sebastian Andrzej Siewior has uploaded it to experimental and after a
  few fixes for integration (due to extra output on stderr in particular),
  has uploaded xz-utils 5.6.0-0.2.
  
  I expect tests to pass now considering they almost all succeeded with the 
first upload.
  I am aware of tweaks to other packages too but I'm not sure they will 
actually be needed with this new upload and since they relate to pristine-tar 
and/or dpkg, I think it's probably better to be sure first due to the ongoing 
migrations.
  
  Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xz-utils in Ubuntu.
https://bugs.launchpad.net/bugs/2055422

Title:
  Please sync xz-utils 5.6.0-0.2 from Debian experimental

Status in xz-utils package in Ubuntu:
  Invalid

Bug description:
  NOTE: THE VERSION MENTIONED HERE HAS BEEN BACKDOORED.
  I am keeping the text below unchanged due to its possible historical 
relevance.

  ==

  Xz-utils 5.6.0 was released last Friday. It features a much faster
  decompression code on all platforms but on x86_64 in particular, it is
  60% faster in my testing. It also aligns better current practices of
  enabling multi-threading by default (always with a default memory
  limit of 25% of the system physical memory).

  Sebastian Andrzej Siewior has uploaded it to experimental and after a
  few fixes for integration (due to extra output on stderr in
  particular), has uploaded xz-utils 5.6.0-0.2.

  I expect tests to pass now considering they almost all succeeded with the 
first upload.
  I am aware of tweaks to other packages too but I'm not sure they will 
actually be needed with this new upload and since they relate to pristine-tar 
and/or dpkg, I think it's probably better to be sure first due to the ongoing 
migrations.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055422/+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 2059417] Re: Sync xz-utils 5.6.1-1 (main) from Debian unstable (main)

[Adrien Nader]

** Description changed:

+ NOTE: THIS IS AN ATTEMPT AT INCLUDING A BACKDOOR. THIS IS LEFT FOR
+ HISTORICAL PURPOSES ONLY AND MUST NOT BE DONE.
+ 
+ 
  Please sync xz-utils 5.6.1-1 (main) from Debian unstable (main)
  
  Hello! I am one of the upstream maintainers for XZ Utils. Version 5.6.1
  was recently released and uploaded to Debian as a bugfix only release.
  Notably, this fixes a bug that causes Valgrind to issue a warning on
  any application dynamically linked with liblzma. This includes a lot of
  important applications. This could break build scripts and test
  pipelines that expect specific output from Valgrind in order to pass.
  
  Additionally, this fixes a small typo for the man pages translations
  for Brazilian Portuguese, German, French, Korean, Romanian, and
  Ukrainian, and removes the need for patches applied for version
  5.6.0-0.2.
  
  The other bugfixes in this release have no impact on Ubuntu. They
  involve building with CMake or when building on a system without
  Landlock system calls defined (these are defined in Ubuntu).
  
  Changelog entries since current noble version 5.6.0-0.2:
  
  xz-utils (5.6.1-1) unstable; urgency=medium
  
    * Non-maintainer upload.
    * Import 5.6.1 (Closes: #1067708).
    * Takeover maintenance of the package.
  
   -- Sebastian Andrzej Siewior   Wed, 27 Mar
  2024 22:53:21 +0100
  
- 
  Excerpt from the NEWS entry from upstream:
  
  5.6.1 (2024-03-09)
  
- * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC)
-   with GCC. The more serious bug caused a program linked with
-   liblzma to crash on start up if the flag -fprofile-generate was
-   used to build liblzma. The second bug caused liblzma to falsely
-   report an invalid write to Valgrind when loading liblzma.
+ * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC)
+   with GCC. The more serious bug caused a program linked with
+   liblzma to crash on start up if the flag -fprofile-generate was
+   used to build liblzma. The second bug caused liblzma to falsely
+   report an invalid write to Valgrind when loading liblzma.
  
- * xz: Changed the messages for thread reduction due to memory
-   constraints to only appear under the highest verbosity level.
+ * xz: Changed the messages for thread reduction due to memory
+   constraints to only appear under the highest verbosity level.
  
- * Build:
+ * Build:
  
- - Fixed a build issue when the header file 
-   was present on the system but the Landlock system calls were
-   not defined in .
+ - Fixed a build issue when the header file 
+   was present on the system but the Landlock system calls were
+   not defined in .
  
- - The CMake build now warns and disables NLS if both gettext
-   tools and pre-created .gmo files are missing. Previously,
-   this caused the CMake build to fail.
+ - The CMake build now warns and disables NLS if both gettext
+   tools and pre-created .gmo files are missing. Previously,
+   this caused the CMake build to fail.
  
- * Minor improvements to man pages.
+ * Minor improvements to man pages.
  
- * Minor improvements to tests.
+ * Minor improvements to tests.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xz-utils in Ubuntu.
https://bugs.launchpad.net/bugs/2059417

Title:
  Sync xz-utils 5.6.1-1 (main) from Debian unstable (main)

Status in xz-utils package in Ubuntu:
  Won't Fix

Bug description:
  NOTE: THIS IS AN ATTEMPT AT INCLUDING A BACKDOOR. THIS IS LEFT FOR
  HISTORICAL PURPOSES ONLY AND MUST NOT BE DONE.

  
  Please sync xz-utils 5.6.1-1 (main) from Debian unstable (main)

  Hello! I am one of the upstream maintainers for XZ Utils. Version 5.6.1
  was recently released and uploaded to Debian as a bugfix only release.
  Notably, this fixes a bug that causes Valgrind to issue a warning on
  any application dynamically linked with liblzma. This includes a lot of
  important applications. This could break build scripts and test
  pipelines that expect specific output from Valgrind in order to pass.

  Additionally, this fixes a small typo for the man pages translations
  for Brazilian Portuguese, German, French, Korean, Romanian, and
  Ukrainian, and removes the need for patches applied for version
  5.6.0-0.2.

  The other bugfixes in this release have no impact on Ubuntu. They
  involve building with CMake or when building on a system without
  Landlock system calls defined (these are defined in Ubuntu).

  Changelog entries since current noble version 5.6.0-0.2:

  xz-utils (5.6.1-1) unstable; urgency=medium

    * Non-maintainer upload.
    * Import 5.6.1 (Closes: #1067708).
    * Takeover maintenance of the package.

   -- Sebastian Andrzej Siewior   Wed, 27 Mar
  2024 22:53:21 +0100

  Excerpt from the NEWS entry from 

[Touch-packages] [Bug 2009544] Re: OpenSSL 3 performance regression

[Adrien Nader]

Due to openssl's release schedule, 24.04 Noble Numbat will still use
3.0. It will be 3.0.13 unless a 3.0.14 is released very soon.

After Noble Numbat is released, I will work on openssl 3.3 for the
subsequent Ubuntu release. It is not yet released but will be soon so I
might start with beta/RC. The openssl release schedule dictates that
there will be another openssl LTS release by the time Ubuntu's next
release (26.04) enters development.

Unfortunately there is little way around this due to openssl's own
schedule and the need to have very long support.

-- 
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/2009544

Title:
  OpenSSL 3 performance regression

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  Hello, it sounds like there's some significant performance regressions
  in OpenSSL 3:

  https://github.com/openssl/openssl/issues/20286#issuecomment-1438826816

  Some we might be able to address with:
  https://github.com/openssl/openssl/pull/18151

  Some of the performance differences may be subject to ongoing work.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+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 2059417] Re: Sync xz-utils 5.6.1-1 (main) from Debian unstable (main)

[Adrien Nader]

I'll dive deeper into this. The timing collides with the t64 transition
so that makes me curious. Moreover, Debian reverted to 5.4.5 so the
situation where we're on 5.6.0 doesn't match Debian either.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xz-utils in Ubuntu.
https://bugs.launchpad.net/bugs/2059417

Title:
  Sync xz-utils 5.6.1-1 (main) from Debian unstable (main)

Status in xz-utils package in Ubuntu:
  Won't Fix

Bug description:
  Please sync xz-utils 5.6.1-1 (main) from Debian unstable (main)

  Hello! I am one of the upstream maintainers for XZ Utils. Version 5.6.1
  was recently released and uploaded to Debian as a bugfix only release.
  Notably, this fixes a bug that causes Valgrind to issue a warning on
  any application dynamically linked with liblzma. This includes a lot of
  important applications. This could break build scripts and test
  pipelines that expect specific output from Valgrind in order to pass.

  Additionally, this fixes a small typo for the man pages translations
  for Brazilian Portuguese, German, French, Korean, Romanian, and
  Ukrainian, and removes the need for patches applied for version
  5.6.0-0.2.

  The other bugfixes in this release have no impact on Ubuntu. They
  involve building with CMake or when building on a system without
  Landlock system calls defined (these are defined in Ubuntu).

  Changelog entries since current noble version 5.6.0-0.2:

  xz-utils (5.6.1-1) unstable; urgency=medium

    * Non-maintainer upload.
    * Import 5.6.1 (Closes: #1067708).
    * Takeover maintenance of the package.

   -- Sebastian Andrzej Siewior   Wed, 27 Mar
  2024 22:53:21 +0100

  
  Excerpt from the NEWS entry from upstream:

  5.6.1 (2024-03-09)

  * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC)
with GCC. The more serious bug caused a program linked with
liblzma to crash on start up if the flag -fprofile-generate was
used to build liblzma. The second bug caused liblzma to falsely
report an invalid write to Valgrind when loading liblzma.

  * xz: Changed the messages for thread reduction due to memory
constraints to only appear under the highest verbosity level.

  * Build:

  - Fixed a build issue when the header file 
was present on the system but the Landlock system calls were
not defined in .

  - The CMake build now warns and disables NLS if both gettext
tools and pre-created .gmo files are missing. Previously,
this caused the CMake build to fail.

  * Minor improvements to man pages.

  * Minor improvements to tests.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417/+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 2009544] Re: OpenSSL 3 performance regression

[Adrien Nader]

I'm going to target this to 24.10 as it's the first time it will be
possible to "solve" it. As far as I understand, there will probably be
performance loss with 3.3 compared to 1.1 but it's going to be a long
tail rather than a few big changes which have been included in 3.1, 3.2
and 3.3.

Btw, Antoine, are you able to test with 3.3 beta? I'd like to know where
we'll stand and if we should take additional steps. I'm also not opposed
to performance backports for 22.04 but I must make it clear that these
take time to author, test and validate, and also require calendar time
(at which point the next release might very well be out).

-- 
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/2009544

Title:
  OpenSSL 3 performance regression

Status in openssl package in Ubuntu:
  Confirmed

Bug description:
  Hello, it sounds like there's some significant performance regressions
  in OpenSSL 3:

  https://github.com/openssl/openssl/issues/20286#issuecomment-1438826816

  Some we might be able to address with:
  https://github.com/openssl/openssl/pull/18151

  Some of the performance differences may be subject to ongoing work.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+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 2009544] Re: OpenSSL 3 performance regression

[Adrien Nader]

** Also affects: openssl (Ubuntu Noble)
   Importance: Undecided
   Status: Confirmed

** Also affects: openssl (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: openssl (Ubuntu Mantic)
   Importance: Undecided
   Status: New

** Changed in: openssl (Ubuntu Mantic)
   Status: New => Won't Fix

** Changed in: openssl (Ubuntu Jammy)
   Status: New => Confirmed

-- 
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/2009544

Title:
  OpenSSL 3 performance regression

Status in openssl package in Ubuntu:
  Confirmed
Status in openssl source package in Jammy:
  Confirmed
Status in openssl source package in Mantic:
  Won't Fix
Status in openssl source package in Noble:
  Confirmed

Bug description:
  Hello, it sounds like there's some significant performance regressions
  in OpenSSL 3:

  https://github.com/openssl/openssl/issues/20286#issuecomment-1438826816

  Some we might be able to address with:
  https://github.com/openssl/openssl/pull/18151

  Some of the performance differences may be subject to ongoing work.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+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 2055304] Re: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2

[Adrien Nader]

Thanks for the report. I am reluctant to backport this as I'm not sure
it makes a lot of sense system-wide. Curl upstream didn't seem happy
with enabling this work-around even in 2021. It seems the reason to
integrate this would be to be able to ignore this despite curl not
ignoring it nor offering a way to ignore it.

I also don't like that it's the kind of configuration that will linger
on systems for years, if not decades. For the distribution, this also
means that once the patch is in, it needs to be supported for 15 years.
On the other hand, it will get in after 24.04/Noble is released since
upstream merged it...

Still, I can't make a compelling case in favor of this patch. This is
especially troublesome since a change to released versions needs exactly
that.

Which servers are you experiencing this issue with?

-- 
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/2055304

Title:
  openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2

Status in openssl package in Ubuntu:
  New

Bug description:
  I get "Closing connection 0 curl: (35) error:0A000126:SSL
  routines::unexpected eof while reading" accessing some web servers.
  AFAIS "SSL_OP_IGNORE_UNEXPECTED_EOF" can help here. With 3.2[0] it can
  be configured in openssl.cnf, whereas 3.0[1] cannot. Would you mind to
  backport the mini patch[2] to be configured with 3.0, too?

  Example:
  $ tail -n 3 /etc/ssl/openssl.cnf 
  [system_default_sect]
  CipherString = DEFAULT:@SECLEVEL=2
  Options = IgnoreUnexpectedEOF

  
  [0] https://www.openssl.org/docs/man3.2/man3/SSL_CONF_cmd.html
  [1] https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html
  [2] 
https://github.com/openssl/openssl/commit/51cf034433d528876f3c235c5150c5acfe88f24d

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2055304/+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 2055304] Re: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2

[Adrien Nader]

There are several reasons a program can skip loading the openssl
configuration unfortunately: env vars pointing to another file, apparmor
preventing loading, library initilization skipping it, ...

Is the program that ignores the openssl configuration file in the Ubuntu
archive? Or public?

-- 
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/2055304

Title:
  openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2

Status in openssl package in Ubuntu:
  New

Bug description:
  I get "Closing connection 0 curl: (35) error:0A000126:SSL
  routines::unexpected eof while reading" accessing some web servers.
  AFAIS "SSL_OP_IGNORE_UNEXPECTED_EOF" can help here. With 3.2[0] it can
  be configured in openssl.cnf, whereas 3.0[1] cannot. Would you mind to
  backport the mini patch[2] to be configured with 3.0, too?

  Example:
  $ tail -n 3 /etc/ssl/openssl.cnf 
  [system_default_sect]
  CipherString = DEFAULT:@SECLEVEL=2
  Options = IgnoreUnexpectedEOF

  
  [0] https://www.openssl.org/docs/man3.2/man3/SSL_CONF_cmd.html
  [1] https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html
  [2] 
https://github.com/openssl/openssl/commit/51cf034433d528876f3c235c5150c5acfe88f24d

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2055304/+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 2055422] Re: Please sync xz-utils 5.6.0-0.2 from Debian experimental

[Adrien Nader]

Graham pointed out that the upload was actually to unstable and
therefore autosync'ed already!

I'm going to keep the bug open until it migrates due to the possibility
of some testsuite failures.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xz-utils in Ubuntu.
https://bugs.launchpad.net/bugs/2055422

Title:
  Please sync xz-utils 5.6.0-0.2 from Debian experimental

Status in xz-utils package in Ubuntu:
  New

Bug description:
  Xz-utils 5.6.0 was released last Friday. It features a much faster
  decompression code on all platforms but on x86_64 in particular, it is
  60% faster in my testing. It also aligns better current practices of
  enabling multi-threading by default (always with a default memory
  limit of 25% of the system physical memory).

  Sebastian Andrzej Siewior has uploaded it to experimental and after a
  few fixes for integration (due to extra output on stderr in
  particular), has uploaded xz-utils 5.6.0-0.2.

  I expect tests to pass now considering they almost all succeeded with the 
first upload.
  I am aware of tweaks to other packages too but I'm not sure they will 
actually be needed with this new upload and since they relate to pristine-tar 
and/or dpkg, I think it's probably better to be sure first due to the ongoing 
migrations.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055422/+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 2055422] [NEW] Please sync xz-utils 5.6.0-0.2 from Debian experimental

[Adrien Nader]

Public bug reported:

Xz-utils 5.6.0 was released last Friday. It features a much faster
decompression code on all platforms but on x86_64 in particular, it is
60% faster in my testing. It also aligns better current practices of
enabling multi-threading by default (always with a default memory limit
of 25% of the system physical memory).

Sebastian Andrzej Siewior has uploaded it to experimental and after a
few fixes for integration (due to extra output on stderr in particular),
has uploaded xz-utils 5.6.0-0.2.

I expect tests to pass now considering they almost all succeeded with the first 
upload.
I am aware of tweaks to other packages too but I'm not sure they will actually 
be needed with this new upload and since they relate to pristine-tar and/or 
dpkg, I think it's probably better to be sure first due to the ongoing 
migrations.

Thanks.

** Affects: xz-utils (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xz-utils in Ubuntu.
https://bugs.launchpad.net/bugs/2055422

Title:
  Please sync xz-utils 5.6.0-0.2 from Debian experimental

Status in xz-utils package in Ubuntu:
  New

Bug description:
  Xz-utils 5.6.0 was released last Friday. It features a much faster
  decompression code on all platforms but on x86_64 in particular, it is
  60% faster in my testing. It also aligns better current practices of
  enabling multi-threading by default (always with a default memory
  limit of 25% of the system physical memory).

  Sebastian Andrzej Siewior has uploaded it to experimental and after a
  few fixes for integration (due to extra output on stderr in
  particular), has uploaded xz-utils 5.6.0-0.2.

  I expect tests to pass now considering they almost all succeeded with the 
first upload.
  I am aware of tweaks to other packages too but I'm not sure they will 
actually be needed with this new upload and since they relate to pristine-tar 
and/or dpkg, I think it's probably better to be sure first due to the ongoing 
migrations.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055422/+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 2055304] Re: openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2

[Adrien Nader]

Thanks for continued investigation.

A reproducer would be valuable as it would allow me to verify
independently the patch is effective, within the limits of the
understanding of the situation of course and that can be especially
time-consuming when not having access to the remote server. :/
A reproducer here can be along the lines of install ubuntu foo to get
nginx bar, configure nginx with TLS and baz and use a given curl
command.
Right now it's difficult to say if you're missing something since I
can't test by myself and compare.
A reproducer is also going to be a required proof in practice for the
change to be done in any past release.

Timeline-wise, either this change gets into 24.04 which is entering
Feature Freeze today, or it will wait for the development cycle of 24.10
when openssl is updated to >= 3.2 (probably 3.3). Then only will it be
possible to also backport this to 22.04 which I guess is the release you
are interested in.

-- 
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/2055304

Title:
  openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2

Status in openssl package in Ubuntu:
  New

Bug description:
  I get "Closing connection 0 curl: (35) error:0A000126:SSL
  routines::unexpected eof while reading" accessing some web servers.
  AFAIS "SSL_OP_IGNORE_UNEXPECTED_EOF" can help here. With 3.2[0] it can
  be configured in openssl.cnf, whereas 3.0[1] cannot. Would you mind to
  backport the mini patch[2] to be configured with 3.0, too?

  Example:
  $ tail -n 3 /etc/ssl/openssl.cnf 
  [system_default_sect]
  CipherString = DEFAULT:@SECLEVEL=2
  Options = IgnoreUnexpectedEOF

  
  [0] https://www.openssl.org/docs/man3.2/man3/SSL_CONF_cmd.html
  [1] https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html
  [2] 
https://github.com/openssl/openssl/commit/51cf034433d528876f3c235c5150c5acfe88f24d

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2055304/+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