Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 2071343 - [tr_TR] curl: (35) error:03000072:digital envelope routines::decode error with LANG=tr_TR.utf8
Summary: [tr_TR] curl: (35) error:03000072:digital envelope routines::decode error wit...
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: 36
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Dmitry Belyavskiy
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
: 2071377 (view as bug list)
Depends On:
Blocks: F36FinalBlocker 2071631
TreeView+ depends on / blocked
Reported: 2022-04-03 07:21 UTC by Jens Petersen
Modified: 2022-04-22 01:19 UTC (History)
14 users (show)

Fixed In Version: openssl-3.0.2-3.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2071631 (view as bug list)
Last Closed: 2022-04-22 01:19:38 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openssl openssl issues 18039 0 None open [3.0.2] curl: (35) error:03000072:digital envelope routines::decode error with LANG=tr_TR.utf8 2022-04-04 14:10:22 UTC
Red Hat Issue Tracker FC-420 0 None None None 2022-04-03 07:49:00 UTC

Description Jens Petersen 2022-04-03 07:21:40 UTC
Description of problem:
With openssl-3.0.0:

$ LANG=tr_TR.utf8 curl -L
Segmentation fault (core dumped)

and openssl-3.0.2 in F36+:

$ LANG=tr_TR.utf8 curl -L
curl: (35) error:03000072:digital envelope routines::decode error

This is also affecting rpm-ostree:
see the original report at

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
0. install glibc-langpack-tr if glibc-all-langpacks not installed
1. LANG=tr_TR.utf8 curl -Lv

Actual results:
*   Trying
* Connected to ( 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?

Comment 1 Onuralp Sezer 2022-04-03 13:08:20 UTC
*** Bug 2071377 has been marked as a duplicate of this bug. ***

Comment 2 Jens Petersen 2022-04-04 14:09:46 UTC
I have opened a issue upstream for this:

Comment 3 František Zatloukal 2022-04-04 14:48:15 UTC
Discussed in ticket:

The decision to classify this bug as an RejectedBlocker was made.

Proposing also as a blocker as per comments in the ticket.

Comment 4 František Zatloukal 2022-04-04 14:52:50 UTC
Ehm, for the record:

The decision to classify this bug as an AcceptedFreezeException was made.

Comment 5 Dmitry Orlov 2022-04-04 18:42:33 UTC
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

Comment 6 Dmitry Orlov 2022-04-04 18:44:06 UTC
(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

Comment 7 František Zatloukal 2022-04-04 18:53:36 UTC
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."


Comment 8 František Zatloukal 2022-04-09 18:19:35 UTC
Setting to post as there is patch upstream:

I'd have created a scratch build, but the changeset doesn't apply cleanly and I am no openssl expert, so :/

Comment 9 Dmitry Belyavskiy 2022-04-09 19:04:53 UTC
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.

Comment 10 Ben Cotton 2022-04-18 16:35:50 UTC
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.

Comment 11 Dmitry Belyavskiy 2022-04-18 17:19:05 UTC
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.

Comment 12 Ben Cotton 2022-04-18 21:02:44 UTC
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.

Comment 13 Dmitry Belyavskiy 2022-04-19 11:33:36 UTC

Do we have Fedora API/ABI obligations similar to RHEL?

Comment 14 Ben Cotton 2022-04-19 11:56:23 UTC
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:

Comment 15 Dmitry Belyavskiy 2022-04-19 12:04:57 UTC
Then it's worth waiting for one more vote here:

Comment 16 Adam Williamson 2022-04-20 00:43:39 UTC
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.

Comment 17 Dmitry Belyavskiy 2022-04-20 12:14:10 UTC
We expect 3.0.3 with several bugfixes (including this) next Tuesday.

Comment 18 Adam Williamson 2022-04-20 20:34:56 UTC
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!

Comment 19 Adam Williamson 2022-04-20 20:39:08 UTC
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.

Comment 20 Dmitry Belyavskiy 2022-04-20 20:48:33 UTC
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.

Comment 21 Adam Williamson 2022-04-20 20:55:00 UTC
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!

Comment 22 Dmitry Belyavskiy 2022-04-21 09:23:38 UTC
the build is

Do we follow the usual procedure with update/karma?

Comment 23 Fedora Update System 2022-04-21 10:20:40 UTC
FEDORA-2022-b132688ddd has been submitted as an update to Fedora 36.

Comment 24 Lukas Ruzicka 2022-04-21 10:55:50 UTC
I confirm that the reproducer is no longer valid with the latest update.

Comment 25 Jens Petersen 2022-04-21 11:59:26 UTC
LGTM too so far, thank you!

Comment 26 Adam Williamson 2022-04-21 15:31:33 UTC
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

Comment 27 Fedora Update System 2022-04-21 17:49:57 UTC
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:

See also for more information on how to test updates.

Comment 28 Fedora Update System 2022-04-22 01:19:38 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.