That's awesome! I figure post-quantum cryptography will feel like
something for years in the future until the week when we all realize we
should have moved years earlier. Capture-and-store has to be going on
right now, on the assumptions that someone will bring a reliable quantum
machine to
Thanks very much for this complete answer and apologies for using the
term "bug completeness": I meant "feature stability" (with bugs being on
the arguably negative side of that term -- and this discussion being one
regarding a bug).
Clearly there's more users (valuing stability) than developers
It's less about bug completeness and more about the risks of breaking
users. The general rule for the whole distribution is backporting
specific fixes for specific bugs; however, there's a handful of packages
where that's not feasible, desired, etc.
Firefox and Chromium are the most obvious cases
Thanks for this explanation, Seth. Very good to know--from a security
perspective. A bit less satisfying from a functionality perspective,
particularly given the assurance by Matt from the OpenSSL team above.
I do understand though that you're aiming for "bug completeness" to
support those that
Michael, Ubuntu backports specific fixes as they are identified; you can
check the status of our OpenSSL packages on our website:
All OpenSSL issues:
https://ubuntu.com/security/cves?q==openssl===
OpenSSL issues, restricted to just Jammy:
https://ubuntu.com/security/cves?q==openssl==jammy=
> if it's time to re-visit that practice of not updating through minor
openssl versions; it's risky to try.
As an upstream OpenSSL maintainer we try very hard to ensure that stable
releases remain stable across patch releases. We only allow bug fixes
(no new features etc) into our patch releases
Fine for me -- I'm working around this (not using Ubuntu for CI any more
and/or using/building less buggy OpenSSL releases for CI).
> if it's time to re-visit that practice of not updating through minor
openssl versions; it's risky to try.
What risks do you see? I find it much more risky _not_
** 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/2019970
Title:
OpenSSL 3.0.2 crash in Ubuntu 22.04.2 LTS
OK, thanks. I had to edit the config file which I had used almost
blindly.
I'm not getting a crash however:
ubuntu@jammy:~/openssl-provider/oqs-provider$
OPENSSL_MODULES=$(pwd)/_build/lib/ OPENSSL_CONF=$(pwd)/scripts/o-ca.cnf
./.local/bin/openssl list -providers
Providers:
default
name:
Thanks for trying to reproduce this. A crash can only be triggered with
two providers active. Your command "OPENSSL_MODULES=_build/lib/
OPENSSL_CONF=scripts/o-ca.cnf ./.local/bin/openssl version" is not quite
conclusive: The config file "o-ca.cnf" doesn't look right. Please verify
that your setup
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
11 matches
Mail list logo
