Bug 2071343

*** 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.