Hide Forgot
Description of problem: With openssl-3.0.0: $ LANG=tr_TR.utf8 curl -L https://google.com Segmentation fault (core dumped) and openssl-3.0.2 in F36+: $ LANG=tr_TR.utf8 curl -L https://google.com curl: (35) error:03000072:digital envelope routines::decode error This is also affecting rpm-ostree: see the original report at https://github.com/fedora-silverblue/issue-tracker/issues/241 Version-Release number of selected component (if applicable): openssl-libs-3.0.2-1.fc36.x86_64 How reproducible: 100% Steps to Reproduce: 0. install glibc-langpack-tr if glibc-all-langpacks not installed 1. LANG=tr_TR.utf8 curl -Lv https://google.com Actual results: * Trying 142.251.12.100:443... * Connected to google.com (142.251.12.100) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/pki/tls/certs/ca-bundle.crt * CApath: none * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS header, Finished (20): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS header, Unknown (21): * TLSv1.3 (OUT), TLS alert, bad certificate (554): * error:03000072:digital envelope routines::decode error * Closing connection 0 curl: (35) error:03000072:digital envelope routines::decode error or a segfault with 3.0.0. Expected results: No error, as with other locales. Additional info: My naive guess is that maybe some glibc char function might be being misused, which is only triggered by some particular locale(s) like Turkish?
*** Bug 2071377 has been marked as a duplicate of this bug. ***
I have opened a issue upstream for this: https://github.com/openssl/openssl/issues/18039
Discussed in ticket: https://pagure.io/fedora-qa/blocker-review/issue/712 The decision to classify this bug as an RejectedBlocker was made. Proposing also as a blocker as per comments in the ticket.
Ehm, for the record: The decision to classify this bug as an AcceptedFreezeException was made.
I have a similar problem. When using webpack, an error occurs "error:0308010C:digital envelope routines::unsupported". It seems to me that this is due to the new version of opensl. Fedora 26, NodeJS 16.14.1, openssl 3.0.2
(In reply to Dmitry Orlov from comment #5) > I have a similar problem. When using webpack, an error occurs > "error:0308010C:digital envelope routines::unsupported". It seems to me that > this is due to the new version of openssl. > > Fedora 26, NodeJS 16.14.1, openssl 3.0.2 Typo))) Fedora 36
Discussed during the 2022-04-04 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made: "This bug impacts an IoT users ability to interact with ostree using “rpm-ostree” and is thus a violation of the IoT Edition rpm-ostree requirements. We grant this bug blocker status." [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-04/f36-blocker-review.2022-04-04-16.00.log.html
Setting to post as there is patch upstream: https://github.com/openssl/openssl/pull/18069 I'd have created a scratch build, but the changeset doesn't apply cleanly and I am no openssl expert, so :/
It's my patch for master :) It basically consists of 2 parts: s/str[n]casecmp/ossl_str[n]casecmp/ and changes to crypto/core_namemap.c, crypto/ctype.c, crypto/init.c, crypto/provider_core.c, include/crypto/ctype.h, include/internal/core.h, include/internal/common.h, include/internal/e_os.h (AFAIR, was in different location in 3.0), include/openssl/core_dispatch.h, providers/fips/fipsprov.c, util/libcrypto.num that really ensure the comparison according the C locale.
Dmitry, it seems like the upstream PR is stalled. Is this something we can carry locally for the time being or is it too disruptive in the current state? Knowing the answer to this question will be very important to the F36 Go/No-Go meeting.
Upstream also has Easter holidays as we do. I expect a decision this week, and will do my best to enforce it. The current patch looks being in a reasonable state.
Thanks! Ideally we'd have a build in tomorrow (19 Apr) as the go/no-go meeting for target date #1 is Thursday 21 April. That said, I'm not convinced we'll have all of the other blockers sorted by tomorrow in order to build an RC. https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
Ben, Do we have Fedora API/ABI obligations similar to RHEL?
I don't know what RHEL's ABI policy is exactly, but in Fedora we strongly discourage ABI changes once a release has gone stable: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
Then it's worth waiting for one more vote here: https://github.com/openssl/technical-policies/issues/44
For the record, we are now basically guaranteed to slip another week, which means there's a bit more breathing room for whatever decisions are being made here. But it'd still be nice to have a build ASAP, by the end of the week especially would be great.
We expect 3.0.3 with several bugfixes (including this) next Tuesday.
Next Tuesday would be too late, unfortunately. The Go/No-Go meeting is on Thursday, and it takes several hours to run a compose, so if we are getting fixes on Tuesday, we're not getting a compose with the fixes until Tuesday night or Wednesday morning, then we have at best a day and a half to complete all validation testing, which is not enough. Can we get the fix here backported to Fedora sooner than that? Ideally by end of this week? Thanks!
Note, I'm a proven packager and could theoretically backport it myself, but I try to exercise restraint with touching something like openssl that's critical to many other apps, and which is security-sensitive, it'd be better for a dedicated openssl packager to do it if possible. If push comes to shove and all other blockers are addressed and we are ready to compose but this has not yet been addressed, though, I may have to do that.
I'll try to build it till the end of the week, but we anyway will have to rebuild when 3.0.3 is out.
Sure, that shouldn't be a problem (except it would cause problems for the release process if the 3.0.3 build replaced the one with the backported fix, so if you could make sure it's submitted as a separate update, that'd be great). Thanks a lot!
Adam, the build is https://koji.fedoraproject.org/koji/taskinfo?taskID=86017542 Do we follow the usual procedure with update/karma?
FEDORA-2022-b132688ddd has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-b132688ddd
I confirm that the reproducer is no longer valid with the latest update.
LGTM too so far, thank you!
Dmitry: thanks a lot! Yes, creating an update as normal is fine. The thing I wanted you to take special care of is this: if you do make a 3.0.3 build before the above update is pushed stable, and you want to submit it as an update, *do not* edit the FEDORA-2022-b132688ddd update and put the 3.0.3 build in it - just create a new update instead. I'll try and get the backport update pushed stable quickly so we don't have to worry about it, though. :D
FEDORA-2022-b132688ddd has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-b132688ddd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b132688ddd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-b132688ddd has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.