All autopackage tests succeeded after multiple trials. Canonical
customer with golang client against openssl server, where bug was first
noticed, will be testing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Several of the autopkgtest failures are due to response issues
(e.g.curl: (7) Failed to connect to launchpad.net port 443: Connection
timed out) so I'm going to ask that they be run again.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Thank you to all involved in the discussion and analysis for carefully
considering the regression risk there. Regardless of the final decision,
I think the thoughtful consideration makes this an exemplary SRU.
I confirmed that the new upload is simply a straightforward review on
top of the
** Changed in: openssl (Ubuntu)
Assignee: Nicolas Bock (nicolasbock) => (unassigned)
** Changed in: openssl (Ubuntu Bionic)
Assignee: Nicolas Bock (nicolasbock) => Bruce Elrick (virtuous-sloth)
** Changed in: openssl (Ubuntu Bionic)
Status: Fix Committed => In Progress
** Tags
Please note the manual testing using the trace option shows the same
results.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request in a
Attach debdiff relative to 18.04.17:
openssl (1.1.1-1ubuntu2.1~18.04.17ubuntu1) bionic; urgency=medium
* Backport pr9780:
- d/p/pr9780_0001-Don-t-send-a-status_request-extension-in-a-Certifica.patch
- d/p/pr9780_0002-Teach-TLSProxy-how-to-parse-CertificateRequest-messa.patch
-- Bruce
Thanks for the update, Marc. I will work on producing the dsc against
1.1.1-1ubuntu2.1~18.04.17.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty
Unfortunately the package in bionic-proposed got superseded by a
security update and will need to be re-uploaded.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can
I re-ran the test as follows to actually test the server side with only
the packaged executables.
I used this command for the server side:
/usr/bin/openssl s_server -key key.pem -cert cert.pem -status_file
openssl-1.1.1/test/recipes/ocsp-response.der -Verify 5
with ldd showing it loading its
The user who discovered this bug using the golang TLS implementation
will be testing the proposed package within the week.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL
I should add, the results in comment 22 indicate that the fix is active
and working.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request
I pulled the proposed source:
$ pull-lp-source openssl bionic
built with tracing enabled:
$ cd openssl-1.1.1
$ sed -i -e '/^CONFARGS =/a CONFARGS += enable-ssl-trace' debian/rules
$ debuild -us -uc -b 2>&1 | tee ../debuild.log
$ cd ..
installed:
$ sudo dpkg -i
Per comments from Marc, let's proceed without making this fix optional.
Let's just keep our eyes and ears open for any possible regressions
caused by this change landing in bionic.
** Changed in: openssl (Ubuntu Bionic)
Status: New => Fix Committed
** Tags added: verification-needed
Marc, I lean your way in terms of my feel for the likelihood that
someone is relying on incorrect behaviour in bionic/openssl-1.1.1.
I can say that while the lp1940141* patches rely on the pr9780 ones, the
reverse is absolutely not the case and thus the lp1940141 ones could be
dropped as a whole
Good point, Dan. A caveat to my work here on this patch: I did some C
programming and played with the Perl test harness in the early 90s which
gave me enough abililty to develop this patch set but I would benefit
from any deeper knowledge someone else may have, especially anyone with
openssl
uploaded to bionic queue, thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request in a
CertificateRequest
To manage notifications
If you'd rather remove the opt-in part, that's fine with me; I can
sponsor the debdiff then with the opt-in parts left out, if that works
for you Bruce and Nicolas.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ACK on the two PR9780* patches, but I must say I'm a bit uncomfortable
making a bug fix optional (which is what is done in the lp1940141*
patches).
While it does change what is returned to the client, that part shouldn't
be there in the first place. While it's nice to be overly cautious, we
don't
@ubuntu-security since this is openssl, could you give the debdiff a
review? I can sponsor it as a normal SRU if you have no objections (and
the changes look ok to you), as it doesn't really seem like it would
specifically need to go to the -security pocket.
--
You received this bug notification
> It's not needed for actual functionality of the backport but that
assumes that any future backports or fixes don't break this backport
yes i get that, my comment is about whether or not the patch changes any
code *outside* of the self-tests, e.g. the TLSProxy perl code changes.
If that's *only*
It's not needed for actual functionality of the backport but that
assumes that any future backports or fixes don't break this backport. By
adding the tests (and wrapping the one test that fails when the
backport-enabling environment variable is not set with the enabling of
that environmetn
"variable, we" -> "variable) we"
"and future" -> "any future"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request in a
The 2nd upstream patch appears to add new functionality, for actually
parsing a certificate request; is that actually needed (outside of the
self-tests)? If not, it shouldn't be included in the backport.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Hey Dan Streetman (ddstreet), I believe the above patch satisfies your
valid concerns about backporting. Would you please analyse for
acceptance?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
openssl (1.1.1-1ubuntu2.1~18.04.15ubuntu1) bionic; urgency=medium
* Backport pr9780 but make it optional:
- d/p/pr9780_0002-Teach-TLSProxy-how-to-parse-CertificateRequest-messa.patch
- d/p/pr9780_0001-Don-t-send-a-status_request-extension-in-a-Certifica.patch
-
For posterity, here is an example of the relevant part of the client
trace output when the bug is active, i.e. data is sent with the
ClientRequest:
$ grep -B1 -A4 CertificateRequest s_client.log
Inner Content Type = Handshake (22)
CertificateRequest, Length=1570
request_context
> the additional information contains valid data.
then I think SRU'ing this would cause a behavior change that could
possibly break someone, which isn't something we should do.
I'd suggest putting the fix behind some opt-in mechanism, so anyone who
is affected can opt-in to the fixed behavior,
Hi Dan,
Before the upstream openssl fix [1] the behavior was to send a proper
CertificateStatus if the client requested the status_request extension
from the server in a CertificateRequest. In other words, the additional
information contains valid data.
[1]
for later reference, i'd discussed this with nick and asked him to check
if the 'status_request' reply contained any kind of valid data in the
specific cases where this patch will disable it; my concern is if there
is valid data in it, it's possible there are applications out there that
might
** Description changed:
[Impact]
openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
CertificateRequest message to the client with a non-empty
status_request extension.
This issue was fixed in openssl-1.1.1d and is included in Focal
onward.
Upstream issue is
** Description changed:
[Impact]
openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
CertificateRequest message to the client with a non-empty
status_request extension.
This issue was fixed in openssl-1.1.1d and is included in Focal
onward.
Upstream issue is
** Changed in: openssl (Ubuntu)
Importance: Undecided => Medium
** Changed in: openssl (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: openssl (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
The attachment "bionic.debdiff" seems to be a debdiff. The ubuntu-
sponsors team has been subscribed to the bug report so that they can
review and hopefully sponsor the debdiff. If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if
Test package at
https://launchpad.net/~nicolasbock/+archive/ubuntu/sf00317240
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request in a
** Patch added: "bionic.debdiff"
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+attachment/5518220/+files/bionic.debdiff
** Changed in: openssl (Ubuntu)
Assignee: (unassigned) => Nicolas Bock (nicolasbock)
** Changed in: openssl (Ubuntu Bionic)
Assignee:
35 matches
Mail list logo
