Re: openldap: gdb: symbol lookup error: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0
Dear Jan, Yes. gdb expects system openssl (providing this function) To workaround it, you have to provide the LD_SET_LIBRARY inside gdb, via (gdb) set environment LD_LIBRARY_PATH /home/jaruga/.local/openssl-3.0.8/lib/ On Mon, Mar 27, 2023 at 5:39 PM Jun Aruga (he / him) wrote: > > Hi, > > I opened this issue's ticket for openldap on Bugzilla. > https://bugzilla.redhat.com/show_bug.cgi?id=2181668 > > But let me ask on the devel@ mailing list too, as I want to debug a > program with gdb and the source-compiled openssl soon. > I am using Fedora 37. I built the openssl 3.0.8 from the source > downloading the source from https://www.openssl.org/source/ . > > ``` > $ ./Configure --prefix=$HOME/.local/openssl-3.0.8 --libdir=lib shared > linux-x86_64 > $ make -j4 > $ make install > ``` > > Then the gdb fails with the error below. Do you know why this error > happens? And is there a workaround to avoid this error? > > ``` > $ rpm -qf /lib64/libldap.so.2 > openldap-2.6.4-1.fc37.x86_64 > > $ rpm -q gdb > gdb-13.1-1.fc37.x86_64 > > $ ldd /bin/gdb | grep ldap > libldap.so.2 => /lib64/libldap.so.2 (0x7f147899a000) > > $ LD_LIBRARY_PATH=/home/jaruga/.local/openssl-3.0.8/lib/ gdb > gdb: symbol lookup error: /lib64/libldap.so.2: undefined symbol: > EVP_md2, version OPENSSL_3.0.0 > > $ echo $? > 127 > ``` > > Thanks! > > -- > Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic > See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for > the timezone. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: openldap: gdb: symbol lookup error: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0
Dear Jun, No, it's not a Fedora-specific issue. You try to provide a replacement to a system library, and this change may affect all the binaries built with the system area. You shouldn't replace or shadow the system library with your own one, otherwise you get PROBLEMS. On Tue, Mar 28, 2023 at 3:06 PM Jun Aruga (he / him) wrote: > > Dear Dmitry, > > Thanks! The workaround worked! > > Is this issue Fedora specific? > Can we fix the case: > `LD_LIBRARY_PATH=/home/jaruga/.local/openssl-3.0.8/lib/ gdb` to work > by modifying the gdb or openldap patches? > Which is better to fix the gdb or openldap? > > Jun > > On Mon, Mar 27, 2023 at 5:45 PM Dmitry Belyavskiy wrote: > > > > Dear Jan, > > > > Yes. gdb expects system openssl (providing this function) > > > > To workaround it, you have to provide the LD_SET_LIBRARY inside gdb, via > > (gdb) set environment LD_LIBRARY_PATH /home/jaruga/.local/openssl-3.0.8/lib/ > > > > On Mon, Mar 27, 2023 at 5:39 PM Jun Aruga (he / him) > > wrote: > > > > > > Hi, > > > > > > I opened this issue's ticket for openldap on Bugzilla. > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181668 > > > > > > But let me ask on the devel@ mailing list too, as I want to debug a > > > program with gdb and the source-compiled openssl soon. > > > I am using Fedora 37. I built the openssl 3.0.8 from the source > > > downloading the source from https://www.openssl.org/source/ . > > > > > > ``` > > > $ ./Configure --prefix=$HOME/.local/openssl-3.0.8 --libdir=lib shared > > > linux-x86_64 > > > $ make -j4 > > > $ make install > > > ``` > > > > > > Then the gdb fails with the error below. Do you know why this error > > > happens? And is there a workaround to avoid this error? > > > > > > ``` > > > $ rpm -qf /lib64/libldap.so.2 > > > openldap-2.6.4-1.fc37.x86_64 > > > > > > $ rpm -q gdb > > > gdb-13.1-1.fc37.x86_64 > > > > > > $ ldd /bin/gdb | grep ldap > > > libldap.so.2 => /lib64/libldap.so.2 (0x7f147899a000) > > > > > > $ LD_LIBRARY_PATH=/home/jaruga/.local/openssl-3.0.8/lib/ gdb > > > gdb: symbol lookup error: /lib64/libldap.so.2: undefined symbol: > > > EVP_md2, version OPENSSL_3.0.0 > > > > > > $ echo $? > > > 127 > > > ``` > > > > > > Thanks! > > > > > > -- > > > Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic > > > See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for > > > the timezone. > > > ___ > > > devel mailing list -- devel@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > Do not reply to spam, report it: > > > https://pagure.io/fedora-infrastructure/new_issue > > > > > > > > -- > > Dmitry Belyavskiy > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > > > > -- > Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic > See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for > the timezone. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
How to get a rawhide i686 VM?
Dear colleagues, What is the simplest way to get a rawhide i686 VM? I came across a nasty architecture-specific bug, and the code investigation isn't of much help. There is no obvious way to access a core dump via mock (could you please ping me if it exists?) and the VM looks like a reasonable choice. Any advice would be appreciated! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to get a rawhide i686 VM?
Dear Peter, On Mon, May 15, 2023 at 1:06 PM Peter Robinson wrote: > > On Mon, May 15, 2023 at 11:39 AM Dmitry Belyavskiy > wrote: > > > > Dear colleagues, > > > > What is the simplest way to get a rawhide i686 VM? I came across a > > nasty architecture-specific bug, and the code investigation isn't of > > much help. There is no obvious way to access a core dump via mock > > (could you please ping me if it exists?) and the VM looks like a > > reasonable choice. > > run an i686 userspace in a x86_64 is about the best option these days. Is there a guideline on how to do it? -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Managing multiple cross-dependent patches
Dear colleagues, I maintain OpenSSH that has a lot of heavy-interfering downstream patches. I’d like to reduce the burden of rebase by combining some of them. So I wonder if there is software checking for cross-dependencies between patches to see what are the natural candidates for combining? I’m aware of quilt and git-absorb but it looks like they don’t help me much. Many thanks! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Managing multiple cross-dependent patches
Dear Chris, On Fri, Jun 2, 2023 at 4:42 PM Chris Adams wrote: > > Once upon a time, Dmitry Belyavskiy said: > > I maintain OpenSSH that has a lot of heavy-interfering downstream > > patches. I’d like to reduce the burden of rebase by combining some of > > them. > > Wow that's a lot of patches. Some appear to be Fedora specific, but a > bunch seem like general fixes. Has there been an attempt to upstream > some of this? Yes. Some of them were even accepted, but, for example, gss ones were explicitly rejected. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Managing multiple cross-dependent patches
Dear Daniel, On Fri, Jun 2, 2023 at 4:57 PM Daniel P. Berrangé wrote: > > On Fri, Jun 02, 2023 at 04:27:37PM +0200, Dmitry Belyavskiy wrote: > > Dear colleagues, > > > > I maintain OpenSSH that has a lot of heavy-interfering downstream > > patches. I’d like to reduce the burden of rebase by combining some of > > them. > > Trying to reduce the burden by combining patches won't help IMHO, and > if anything make life worse, as any patch failing to apply will leave > a bigger conflict mess to resolve. I always favour a larger number of > small patches, over a small number of big patches. I can easily identify some patches that would definitely better be combined. I'd prefer to do it more or less automagically. But of course, there are also ones that should stay separate. > > So I wonder if there is software checking for cross-dependencies > > between patches to see what are the natural candidates for combining? > > > > I’m aware of quilt and git-absorb but it looks like they don’t help me much. > > Are you primarily using dist-git and managing the patches manually ? > It looks like it, since the paches I see in openssh.git aren't git > commit exports. > > If so, I'd highly recommend switching to using a src-git model instead, > where you manage a Fedora branch of commits directly against the upstream > git repo. This lets you exploit the full power of git for rebasing and > cherry-picking patches and resolving conflicts. dist-git largely becomes > an export of patches from the src-git branch which is largely automatable. > I'm not saying src-git is a magic bullet, just that it is much less painful > that directly working on dist-git. I consider it as an option for future. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes to build environment
Dear Steve, I usually use smth like RPM_ARCH=1 RPM_PACKAGE_RELEASE=2 RPM_PACKAGE_VERSION=3 RPM_PACKAGE_NAME=4 make in this situation and have never got any problem yet. On Thu, Jun 22, 2023 at 7:58 PM Steve Grubb wrote: > > Hello, > > I have switched to F38 and find a couple items annoying. I have a workflow > that > checks things I develop out of github, rolls it up into an rpm, builds it, > and runs the results through annocheck. > > If there is a warning I'd like to investigate, I cd into the build directory. > But oops, now its gone (problem #1). OK, I use rpmbuild -bc to rebuild it. I > cd into the build directory make a change and run make. > > gcc: fatal error: environment variable 'RPM_ARCH' not defined > > (problem #2) > > How do I fix these things? > > -Steve > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenSSH: hardening hostkeys permissions
Dear colleagues, Many years ago we implemented the patch https://src.fedoraproject.org/rpms/openssh/c/1ddd0ee5 Unfortunately, as it was 11 years ago, we can't find the exact explanation where the requirement came from. We think that we intended to increase security, but it probably caused more confusion than gain of the security over the years. The patch allows more relaxed permissions for the private keys than upstream OpenSSH permits - 0640 instead of 0600, and the key file must belong to the ssh_keys group. The ssh_keysign utility was simultaneously changed from suid root to sgid ssh_keys. The side effect of this solution is that ssh with host based auth (HBA) started to fail after changing group ID ( with newgrp, etc.). In the case of HBA ssh invokes ssh-keysign that does a lot of sanity checks including group checks. The workaround is returning setuid bit instead of sgid, and we recommend it to our clients. Some more information is available in https://bugzilla.redhat.com/show_bug.cgi?id=1498845 As this problem affects several clients, and it is a deviation from upstream (the similar patch was rejected by upstream), we want to drop this downstream patch in Fedora. We also can get rid of a designated ssh_keys group The problem we expect is that after reverting the patch we can lose the remote access to the hosts because sshd will reject starting because of group reading permissions. This should be covered by the upgrade scriptlet, though we still may come across some issues, especially if you use host keys in non-standard locations. How do we properly implement this feature to avoid customers' negative feedback? Current upgrade scriptlet covers standard key locations/names and works well enough at the 1st glance. The proposed changes are available https://src.fedoraproject.org/rpms/openssh/pull-request/37 A separate question is whether we want to publish this announcement as a Fedora change and at what level. For me it looks like a self-contained change. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenSSH: hardening hostkeys permissions
Dear Daniel, Thanks for your feedback! On Wed, Dec 7, 2022 at 2:55 PM Daniel P. Berrangé wrote: > On Wed, Dec 07, 2022 at 01:48:48PM +0100, Dmitry Belyavskiy wrote: > > The problem we expect is that after reverting the patch we can lose the > > remote access to the hosts because sshd will reject starting because of > > group reading permissions. This should be covered by the upgrade > scriptlet, > > though we still may come across some issues, especially if you use host > > keys in non-standard locations. How do we properly implement this feature > > to avoid customers' negative feedback? Current upgrade scriptlet covers > > standard key locations/names and works well enough at the 1st glance. > > In terms of upgrade impact the upgrade scriptlet may not be sufficient > to mitigate the compat risk. It is possible that there are puppet/ansible > recipes that will be setting file ownership/permissions on the keys, > which might be liable to undo the effect of any RPM upgrade scriptlet. > > > The proposed changes are available > > https://src.fedoraproject.org/rpms/openssh/pull-request/37 > > > > A separate question is whether we want to publish this announcement as a > > Fedora change and at what level. For me it looks like a self-contained > > change. > > Publishing a Fedora change looks like a wise idea, given the upgrade > risk and its possible ripple effect to OS config mgmt tools like puppet > and ansible. > Drafted here, to be published: https://fedoraproject.org/wiki/Changes/SSHKeySignSuidBit -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenSSH: hardening hostkeys permissions
On Thu, Dec 8, 2022 at 3:51 PM Daniel P. Berrangé wrote: > On Thu, Dec 08, 2022 at 03:41:32PM +0100, Dmitry Belyavskiy wrote: > > Dear Daniel, > > Thanks for your feedback! > > > > On Wed, Dec 7, 2022 at 2:55 PM Daniel P. Berrangé > > wrote: > > > > > On Wed, Dec 07, 2022 at 01:48:48PM +0100, Dmitry Belyavskiy wrote: > > > > The problem we expect is that after reverting the patch we can lose > the > > > > remote access to the hosts because sshd will reject starting because > of > > > > group reading permissions. This should be covered by the upgrade > > > scriptlet, > > > > though we still may come across some issues, especially if you use > host > > > > keys in non-standard locations. How do we properly implement this > feature > > > > to avoid customers' negative feedback? Current upgrade scriptlet > covers > > > > standard key locations/names and works well enough at the 1st glance. > > > > > > In terms of upgrade impact the upgrade scriptlet may not be sufficient > > > to mitigate the compat risk. It is possible that there are > puppet/ansible > > > recipes that will be setting file ownership/permissions on the keys, > > > which might be liable to undo the effect of any RPM upgrade scriptlet. > > > > > > > The proposed changes are available > > > > https://src.fedoraproject.org/rpms/openssh/pull-request/37 > > > > > > > > A separate question is whether we want to publish this announcement > as a > > > > Fedora change and at what level. For me it looks like a > self-contained > > > > change. > > > > > > Publishing a Fedora change looks like a wise idea, given the upgrade > > > risk and its possible ripple effect to OS config mgmt tools like puppet > > > and ansible. > > > > > > > Drafted here, to be published: > > https://fedoraproject.org/wiki/Changes/SSHKeySignSuidBit > > I think the "Upgrade/compatibility impact" section ought to call out the > possible risk with config mgmt tools like puppet/ansible, that might be > managing SSH host keys and their permissions/ownership > Done, thanks! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: new OpenSSL build changes
Dear colleagues, I've just pushed a new OpenSSL build to rawhide. The change compared to the previous one is incorporating the patch from https://github.com/openssl/openssl/pull/13817. Some more details can be found here: https://github.com/openssl/openssl/issues/13421 Citing the change description, We added and enabled by default implicit rejection in RSA PKCS#1 v1.5 decryption as a protection against Bleichenbacher-like attacks. The RSA decryption API will now return a randomly generated deterministic message instead of an error in case it detects an error when checking padding during PKCS#1 v1.5 decryption. This is a general protection against issues like CVE-2020-25659 and CVE-2020-25657. This protection can be disabled by calling `EVP_PKEY_CTX_ctrl_str(ctx, "rsa_pkcs1_implicit_rejection". "0")` in the RSA decryption context. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: OpenSSL update
Dear colleagues, I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37. I will also push to f38 and rawhide later today. This is a security release, it fixes 8 MODERATE CVEs (https://www.openssl.org/news/secadv/20230207.txt) I kindly ask you to test the version so it could be rolled up earlier. Many thanks in advance! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: OpenSSL update
Dear Paul On Thu, Feb 9, 2023 at 6:56 PM Paul Wouters wrote: > > On Thu, 9 Feb 2023, Dmitry Belyavskiy wrote: > > > I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37. > > I will also push to f38 and rawhide later today. > > Why is f36/f37 the playground for f38/rawhide? Shouldn't this be done > in the reverse order? In fact all the updates landed simultaneously. > > This is a security release, it fixes 8 MODERATE CVEs > > (https://www.openssl.org/news/secadv/20230207.txt) > > > > I kindly ask you to test the version so it could be rolled up earlier. > > I really would hope that testing happens in rawhide before it is pushed > into f36/f37 :( As there are many vulnerabilities, I preferred to push the releases ASAP. Previously I was blamed for pushing only CVE fixes instead of updating. I don't expect any regressions, speaking frankly. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: OpenSSL update
Dear Michel, In RHEL/CentOS we currently provide a double versioning for OPENSSL_strcasecmp and OPENSSL_strncasecmp functions. They were added in 3.0.1 downstream and 3.0.3 upstream. 0056-strcasecmp.patch in CentOS stream fixes the test in question. On Thu, Feb 9, 2023 at 9:47 PM Michel Alexandre Salim wrote: > > Hi Dmitry, > > On Thu, 2023-02-09 at 18:02 +0100, Dmitry Belyavskiy wrote: > > Dear colleagues, > > > > I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37. > > I will also push to f38 and rawhide later today. > > > > This is a security release, it fixes 8 MODERATE CVEs > > (https://www.openssl.org/news/secadv/20230207.txt) > > > > I kindly ask you to test the version so it could be rolled up > > earlier. > > > Would you happen to have any insight into why some tests are failing > when rebuilt on EPEL 8? > > This is with a scratch build of EPEL 8's openssl3 (which is just a > rebuild of openssl but renamed and with some subpackages removed) > https://koji.fedoraproject.org/koji/taskinfo?taskID=97314920 > > The errors are all identical, so to be doubly sure I rebuilt the centos > 9 srpm (only on x86_64), just slightly modified to change the g++ BR to > gcc-c++, and it failed identically > https://koji.fedoraproject.org/koji/taskinfo?taskID=97318473 > > # The following symbols are missing in libcrypto.so.3: > # OPENSSL_strcasecmp > # OPENSSL_strncasecmp > # The following symbols are extra in libcrypto.so.3: > # BIO_dgram_is_sctp > # BIO_dgram_sctp_msg_waiting > # BIO_dgram_sctp_notification_cb > # BIO_dgram_sctp_wait_for_dry > # BIO_new_dgram_sctp > # BIO_s_datagram_sctp > not ok 2 - check that there are no missing symbols in libcrypto.so.3 > # - > -03-test_internal_modes.t ... ok > 03-test_internal_namemap.t . ok > 03-test_internal_curve448.t ok > 03-test_internal_poly1305.t ok > # Looks like you failed 1 test of 4.01-test_symbol_presence.t > .. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/4 subtests > 02-test_lhash.t ... > > Thanks, > > -- > Michel Alexandre Salim > identities: > https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: OpenSSL update
Dear Michel, On Fri, Feb 10, 2023 at 7:06 PM Michel Alexandre Salim wrote: > > Dear Dmitry, > > On Fri, 2023-02-10 at 09:55 +0100, Dmitry Belyavskiy wrote: > > Dear Michel, > > > > In RHEL/CentOS we currently provide a double versioning for > > OPENSSL_strcasecmp and OPENSSL_strncasecmp functions. > > They were added in 3.0.1 downstream and 3.0.3 upstream. > > > > 0056-strcasecmp.patch in CentOS stream fixes the test in question. > > > Ah, interesting. I took a look at the history of that patch, and > narrowed down the issue: > > - with f2a49ef424f831aac988356fc8b2b910e443dc42 from Nov 25, rebuilding > in EPEL 8 fails: > - > https://gitlab.com/redhat/centos-stream/rpms/openssl/-/commit/f2a49ef424f831aac988356fc8b2b910e443dc42 > https://koji.fedoraproject.org/koji/taskinfo?taskID=97348528 > > - with that patch backed out, building 3.0.7-2 succeeds: > https://koji.fedoraproject.org/koji/taskinfo?taskID=97348707 > > Note that these are the exact openssl package from c9s, just rebuilt > with the g++ dependency replaced by gcc-c++. > > I suppose the easiest resolution here is for me to build openssl3 (for > EPEL 8) with that commit backed out, but I'm a bit puzzled as to why > this happens. Any idea there? No idea. It is probably worth adding some diagnostic output to the test in question. Maybe g++ uses a different naming schema in case of multiversioned functions. > Thanks, > > Michel > > > On Thu, Feb 9, 2023 at 9:47 PM Michel Alexandre Salim > > wrote: > > > > > > Hi Dmitry, > > > > > > On Thu, 2023-02-09 at 18:02 +0100, Dmitry Belyavskiy wrote: > > > > Dear colleagues, > > > > > > > > I've just pushed updates of OpenSSL to the 3.0.8 version to > > > > f36/37. > > > > I will also push to f38 and rawhide later today. > > > > > > > > This is a security release, it fixes 8 MODERATE CVEs > > > > (https://www.openssl.org/news/secadv/20230207.txt) > > > > > > > > I kindly ask you to test the version so it could be rolled up > > > > earlier. > > > > > > > Would you happen to have any insight into why some tests are > > > failing > > > when rebuilt on EPEL 8? > > > > > > This is with a scratch build of EPEL 8's openssl3 (which is just a > > > rebuild of openssl but renamed and with some subpackages removed) > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=97314920 > > > > > > The errors are all identical, so to be doubly sure I rebuilt the > > > centos > > > 9 srpm (only on x86_64), just slightly modified to change the g++ > > > BR to > > > gcc-c++, and it failed identically > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=97318473 > > > > > > # The following symbols are missing in libcrypto.so.3: > > > # OPENSSL_strcasecmp > > > # OPENSSL_strncasecmp > > > # The following symbols are extra in libcrypto.so.3: > > > # BIO_dgram_is_sctp > > > # BIO_dgram_sctp_msg_waiting > > > # BIO_dgram_sctp_notification_cb > > > # BIO_dgram_sctp_wait_for_dry > > > # BIO_new_dgram_sctp > > > # BIO_s_datagram_sctp > > > not ok 2 - check that there are no missing symbols in > > > libcrypto.so.3 > > > # - > > > > > > -03-test_internal_modes.t ... ok > > > 03-test_internal_namemap.t . ok > > > 03-test_internal_curve448.t ok > > > 03-test_internal_poly1305.t ok > > > # Looks like you failed 1 test of 4.01-test_symbol_presence.t > > > .. > > > Dubious, test returned 1 (wstat 256, 0x100) > > > Failed 1/4 subtests > > > 02-test_lhash.t ... > > > > > > Thanks, > > > > > > -- > > > Michel Alexandre Salim > > > identities: > > > https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > > > ___ > > > devel mailing list -- devel@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/
Adding liboqs to Rawhide
Dear colleagues, I'm currently working on bringing liboqs [1] to rawhide. According to [2], I've added the following line to the spec file: License: MIT and Apache 2.0 and BSD 3-Clause and CC0-1.0 and Unlicense I doubt about 2 licenses that are enumerated: [3] (BSD-like) and [4]. What am I to do with them? They look quite permissive but I need someone's evaluation. [1] https://github.com/open-quantum-safe/liboqs/ [2] https://github.com/open-quantum-safe/liboqs/blob/main/README.md#license [3] https://www.openssl.org/~appro/cryptogams/ [4] https://github.com/open-quantum-safe/liboqs/blob/40b01fdbb270f8614fde30e65d30e9da18c02393/src/common/rand/rand_nist.c#L1-L15 What is the proper line for the spec file and what are my next steps to evaluate the licenses, if necessary? Many thanks in advance! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide (to be f41) and openssl engines
Dear colleagues, as the changes described in https://fedoraproject.org/wiki/Changes/OpensslDeprecateEngine were approved and implemented and a week or two has passed, we can summarize the consequences. Lack of openssl/engine.h file moved to a separate package is not processed correctly by packages and requires changes in specs which also comes with a cost. OpenSSL ABI is kept. On the other hand, CentOS stream uses a different approach when openssl keeps ABI, doesn't ship openssl/engine.h, and defines OPENSSL_NO_ENGINE explicitly, so old applications keep working and at the same time new application can mostly be rebuilt without significant problems. I understand that Fedora has much more packages but there are much less complaints from CentOS/RHEL than from Fedora. So I wonder if it's worth changing the engine deprecation mechanism in Fedora to the one we have in CentOS and if yes, what is the mechanism for such a change. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora rawhide (to be f41) and openssl engines
Dear Zbyszek, On Mon, Jul 22, 2024 at 2:57 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jul 22, 2024 at 01:34:39PM +0200, Dmitry Belyavskiy wrote: > > So I wonder if it's worth changing the engine deprecation mechanism in > > Fedora to the one we have in CentOS and if yes, what is the mechanism > > for such a change. > > Does is make sense at this point? The mass rebuild is (almost?) finished > and I would expect that packages that needed to be updated for this > already were. > > Do you have any statistics about how many packages still fail to > build because of the lacking header file? I've seen 10-15 email/Slack threads related to the change. Most of them were resolved via explicit CFLAGS += -DOPENSSL_NO_ENGINE -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora rawhide (to be f41) and openssl engines
Dear Neal, On Mon, Jul 22, 2024 at 3:05 PM Neal Gompa wrote: > The CentOS approach isn't a deprecation, it's flat out removal. It's a > completely different change. > > Is anyone helping to migrate users of the engine API to newer APIs? If > that's not happening, then there's no way to support removing the > engine API from Fedora's OpenSSL. I didn't see such requests in Fedora, most people are just interested in making their software compiling. In CentOS there were 2-3 cases when people were interested in replacing the functionality with the new one. I'm ready to help if necessary, and Clemens made a great job explaining people what's going on while I was on PTO -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenSSL performance tuning Webinar
Dear colleagues, OpenSSL has announced the performance tuning webinar on August 1 https://openssl.org/blog/blog/2024/07/18/August-Webinar/ Feel free to register and join -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to contact Fedora Security Team
If you want to discuss smth not having security implications (e.g. CVEs) but crypto policies, this ML seems a proper place for it On Sun, Aug 18, 2024 at 2:16 PM Andrew Bauer wrote: > > I've got a question regarding a new crypto library that falls under this > policy: > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/ > > Per the documentation, I should contact the Fedora Security Team, but > unfortunately the link provided in the documentation is no good: > https://lists.fedoraproject.org/mailman/listinfo/security > > This points to a list that no longer exists. What is a good way to ping this > team? Thank you. > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: post-quantum libs landed in Fedora rawhide
Dear colleagues, Yesterday we added liboqs and oqsprovider packages to Fedora rawhide. It's a part of our efforts to provide implementation of post-quantum algorithms in Fedora and later in RHEL. liboqs is an implementation of NIST-approved PQ algorithms (Kyber, Dilithium, Falcon, and Sphincs). oqsprovider is an OpenSSL provider making PQ algorithms available though OpenSSL including some basic operations (keys/certification generation, signatures, CMS support, limited TLS support etc). We expect that file formats are preliminary and are a subject to change but it's enough for basic experiments. We expect better support of the TLS protocol later when OpenSSL publishes its 3.2 release (presumably this autumn). We would like to strongly encourage package maintainers and end users to do some experiments with the PQ libraries to find the limitations and either fix the issues or at least raise bugs upstream. We also expect that there are both applications and protocol specifications that are not capable of dealing with the keys that are neither RSA nor EC/EdDDSA and also would like the issues to be raised. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dropping of sshd.socket unit
Dear colleagues, I've pushed a fresh build of OpenSSH to rawhide. We decided to drop the sshd.socket unit from rawhide. We don't think it's worth going through the changes process, but would like to provide a heads-up. See the details in https://bugzilla.redhat.com/show_bug.cgi?id=2025716. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
Dear Lennart,
I'm sorry, I don't get.
Quoting the
https://www.freedesktop.org/software/systemd/man/systemd.socket.html#TriggerLimitIntervalSec=
Configures a limit on how often this socket unit may be activated
within a specific time interval. The TriggerLimitIntervalSec= may be
used to configure the length of the time interval in the usual time
units "us", "ms", "s", "min", "h", … and defaults to 2s (See
systemd.time(7) for details on the various time units understood). The
TriggerLimitBurst= setting takes a positive integer value and
specifies the number of permitted activations per time interval, and
defaults to 200 for Accept=yes sockets (thus by default permitting 200
activations per 2s), and 20 otherwise (20 activations per 2s). Set
either to 0 to disable any form of trigger rate limiting. If the limit
is hit, the socket unit is placed into a failure mode, and will not be
connectible anymore until restarted. Note that this limit is enforced
before the service activation is enqueued.
But this behavior (the last sentence) exactly matches the DoS
described here: https://bugs.archlinux.org/task/62248
Too many connections to an sshd server, configured using socket
activation can cause the socket to be disabled permanently
("sshd.socket: Trigger limit hit, refusing further activation.").
On Mon, Aug 7, 2023 at 11:48 AM Lennart Poettering wrote:
>
> On Do, 03.08.23 11:29, Dmitry Belyavskiy (dbely...@redhat.com) wrote:
>
> > Dear colleagues,
> >
> > I've pushed a fresh build of OpenSSH to rawhide.
> > We decided to drop the sshd.socket unit from rawhide. We don't think
> > it's worth going through the changes process, but would like to
> > provide a heads-up.
>
> Hmm, why drop it? For many setups, it makes not sense to continously
> run sshd, so socket activation should be fine.
>
> I don't understand the reasoning behind this change. You claim a
> DoS. Which DoS is that supposed to be? That we enforce a trigger time
> limit on socket units by default? If you don't want this, turn it off,
> that's what TriggerLimitIntervalSec=/TriggerLimitBurst= is for, see
> docs.
>
> The discussion makes this sound as if there was a bug in systemd or
> so, but there really isn't, it's literally a safety feature you ran
> into. It might not make sense to have the trigger rate limit in place
> for all usecases, ssh might be one where it is not advisable, but then
> the right approach is to just turn that part off, as documented, via
> the aforementioned options.
>
> See for details:
>
> https://www.freedesktop.org/software/systemd/man/systemd.socket.html#TriggerLimitIntervalSec=
>
> I don't care too much whether you make ssh socket-activated by default
> or not. But at least the option should exist, already for compat with
> existing setups.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
Dmitry Belyavskiy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: status openssl1.1
On Mon, Oct 16, 2023 at 10:21 AM Petr Pisar wrote: > > V Mon, Oct 16, 2023 at 08:55:12AM +0200, josef radinger via devel napsal(a): > > Hi > > > > openssl1.1 reached EOS on recently (11th September 2023 I assume) > > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > > > > according to > > https://www.openssl.org/source/: > > ... > > The previous LTS version (the 1.1.1 series) is also available but has > > recently gone out of support. > > ... > > > > paid extended support for 1.1.1 would be available, but is maybe not the way > > to go for fedora. > > > > we have > > https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat#Upgrade/compatibility_impact > > with no changes since 2022 > > and a closed tracker bug at > > https://bugzilla.redhat.com/show_bug.cgi?id=2108694 > > > > maybe we should start deprecating that package? > > > The package is already deprecated: > > # dnf5 repoquery --provides openssl1.1 | grep deprecated > deprecated() > > Maybe you wanted to say start removing? I rough estimation of an impact of the > removal are these 3 components: > > gloo-0.5.0^git20230824.01a0c81-6.fc40.src.rpm > opensmtpd-6.8.0p2-12.fc39.src.rpm > python3.6-3.6.15-20.fc39.src.rpm I'm afraid it's too late for removing the compat package in F40. If not, I can raise the change proposal, otherwise it will be delayed until F41 starts -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status openssl1.1
Dear Peter, On Mon, Oct 16, 2023 at 1:43 PM Peter Robinson wrote: > > On Mon, Oct 16, 2023 at 10:05 AM Dmitry Belyavskiy > wrote: > > > > On Mon, Oct 16, 2023 at 10:21 AM Petr Pisar wrote: > > > > > > V Mon, Oct 16, 2023 at 08:55:12AM +0200, josef radinger via devel > > > napsal(a): > > > > Hi > > > > > > > > openssl1.1 reached EOS on recently (11th September 2023 I assume) > > > > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > > > > > > > > according to > > > > https://www.openssl.org/source/: > > > > ... > > > > The previous LTS version (the 1.1.1 series) is also available but has > > > > recently gone out of support. > > > > ... > > > > > > > > paid extended support for 1.1.1 would be available, but is maybe not > > > > the way > > > > to go for fedora. > > > > > > > > we have > > > > https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat#Upgrade/compatibility_impact > > > > with no changes since 2022 > > > > and a closed tracker bug at > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2108694 > > > > > > > > maybe we should start deprecating that package? > > > > > > > The package is already deprecated: > > > > > > # dnf5 repoquery --provides openssl1.1 | grep deprecated > > > deprecated() > > > > > > Maybe you wanted to say start removing? I rough estimation of an impact > > > of the > > > removal are these 3 components: > > > > > > gloo-0.5.0^git20230824.01a0c81-6.fc40.src.rpm > > > opensmtpd-6.8.0p2-12.fc39.src.rpm > > > python3.6-3.6.15-20.fc39.src.rpm > > > > I'm afraid it's too late for removing the compat package in F40. If > > not, I can raise the change proposal, otherwise it will be delayed > > until F41 starts > > Why is it too late for F-40? Do you mean F-39? Thanks! https://fedoraproject.org/wiki/Changes/RemoveOpensslCompat -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status openssl1.1
Dear Miro, On Tue, Oct 17, 2023 at 10:33 PM Miro Hrončok wrote: > > On 16. 10. 23 14:19, Dmitry Belyavskiy wrote: > >> Why is it too late for F-40? Do you mean F-39? > > > > Thanks! > > https://fedoraproject.org/wiki/Changes/RemoveOpensslCompat > > Could you please update the contingency plan section? > > "Package owners should update their packages to remove the dependency" is not > a > contingency mechanism. I think we don't have a reason to maintain openssl1.1 anymore. Formally I can suggest turning openssl1.1 back to distro as a contingency plan, but it doesn't look reasonable to me. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenSSL 3.2.1 available in rawhide
Dear Yaakov, On Fri, Feb 9, 2024 at 4:51 AM Yaakov Selkowitz wrote: > On Thu, 2024-02-08 at 20:37 +0100, Sahana Prasad wrote: > > Hello everyone, > > OpenSSL 3.2.1 is now available in rawhide [1]. > > There are no API/ABI changes in comparison with the last version in > > rawhide > > (3.1.4). > > This version (3.2.0 onwards) supports PQ algorithms that can be > > loaded > > through > > the OQS provider. > > A few tests that needed some downstream tweaks have been disabled and > > being > > worked on. > > Other than this issue [2] upstream, we did not see any new > > failures/breakages. > > > > If you observe any new issues with this new version, kindly report a > > bug. > > Would this be related to openssl 3.2.1? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=113198856 > > The tests pass locally in mock with openssl 3.1.4. I can imagine the situation where upgrading to 3.2 could cause this failure but the logs are too vague. Could you please provide more details (e.g. openssl low-level diagnostics) or even better a minimal reproducer for diagnostics? As for now we don't see any significant regressions in our downstream tests. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: OpenSSL sync with RHEL
Dear colleagues, I'm going to push the updated version of OpenSSL to rawhide. This version incorporates FIPS-related changes from RHEL 9. A major change that may affect your applications in FIPS mode is limiting the RSA encryption. There are also minor tweaks limiting explicit curves support in a similar way as it is done in RHEL. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Karma for OpenSSL needed
Dear colleagues, I've just pushed the updates for OpenSSL fixing 2 CVEs evaluated as HIGH. Could you please check the freshly pushed builds to get necessary karma ASAP? Many thanks! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Karma for OpenSSL needed
Dear Peter, On Tue, Nov 1, 2022 at 6:44 PM Peter Robinson wrote: > Hi Dmitry, > > > I've just pushed the updates for OpenSSL fixing 2 CVEs evaluated as > HIGH. Could you please check the freshly pushed builds to get necessary > karma ASAP? > > Is there a reason we're note rebasing to 3.0.7 or generally updating > in Fedora with 3.x? It looks like 3.0.6 had CVE-2022-3358 which hasn't > been addressed because we're still on .5 > Applying a separate patch takes several minutes, and rebasing is some process, usually much longer. The rebase is going to happen as time permits. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Hi!
On Wed, Mar 20, 2024 at 9:50 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> >
> > This is a proposed Change for Fedora Linux.
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > We disable support of engines in OpenSSL
> >
> > == Owner ==
> > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > * Email: dbely...@redhat.com
> >
> > == Detailed Description ==
> > We are going to build OpenSSL without engine support. Engines are not
> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
> > The engine functionality we are aware of (PKCS#11, TPM) is either
> > covered by providers or will be covered soon.
> >
> > == Feedback ==
> >
> >
> > == Benefit to Fedora ==
> > We get rid of deprecated functionality and enforce using up-to-date
> > API. Engine support is deprecated in OpenSSL upstream, and after
> > provider migration caused some deficiencies with engine support. No
> > new features will be added to the engine. So we reduce the maintenance
> > burden and potentially attack surface.
>
> Hi,
>
> In systemd, we recently added support for engines in various tools:
> - systemd-{repart,measure} have --private-key-source=file|engine|provider
> (this is C code).
>
As `provider` is a possible source, you will have to replace `engine` with
a particular provider.
tpm2 provider is on the way to rawhide, and pkcs11 provider has already
landed, so TPMs and Yubikeys
> - ukify has --signing-engine.
> This is Python code that calls sbsign or pesign to do parts of the
> heavy lifting, and those binaries do not support providers. (At least
> the docs are silent on this, please correct it they do.)
>
Have no idea but it means we have to change this code
>
> So it seems we'd lose support for signing with keys stored on yubikeys
> and tpms and other fancy approaches if the proposed change goes through.
>
We don't lose this support but we still have to adjust configurations.
> --
>
> Also, what is the impact on:
> - kernel module signing in the build system
> - signing of shim, grub2, fwupd, and the kernel in the build system
> - mokutil
>
Does any kernel module rely on OpenSSL?
>
> Thanks,
> Zbyszek
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
Dmitry Belyavskiy
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Dear Daniel, On Wed, Mar 20, 2024 at 1:44 PM Daniel P. Berrangé wrote: > On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote: > > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine > > > > This is a proposed Change for Fedora Linux. > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > == Summary == > > We disable support of engines in OpenSSL > > > > == Owner == > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] > > * Email: dbely...@redhat.com > > > > == Detailed Description == > > We are going to build OpenSSL without engine support. Engines are not > > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. > > The engine functionality we are aware of (PKCS#11, TPM) is either > > covered by providers or will be covered soon. > > "will be covered soon" > > ... so lets wait until that work is actually complete before > removing this from openssl, otherwise there's a window of > brokenness in Fedora where the old feature is removed and > the new feature is not ready. > I am not going to land this change until the tpm2 provider is landed in Fedora. But the affected packages must start prepare to this change as early as possible. > > > == Benefit to Fedora == > > We get rid of deprecated functionality and enforce using up-to-date > > API. Engine support is deprecated in OpenSSL upstream, and after > > provider migration caused some deficiencies with engine support. No > > new features will be added to the engine. So we reduce the maintenance > > burden and potentially attack surface. > > What is upstream's intention with the 'engine' feature deprecation ? > > Are they going actively remove this functionality after some > period of deprecation ? If so what's upstream timeframe, and > should Fedora just wait for that, rather than jumping the > gun ? > As I understand, upstream is going to remove engines but it wouldn't happen before OpenSSL 4.0 I don't think Fedora should wait for that. We definitely want to land no-engine in RHEL10 so Fedora should be ready for that. > > > > == Upgrade/compatibility impact == > > OpenSSL engines will no longer be supported. Engines will not be > > supported in openssl configuration files (presumably silently > > ignored). Users will have to reconfigure systems to providers if they > > use engines. > > > > > > == How To Test == > > OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines). > > Application is normally built. > > Removing symbols is an ABI break, so would imply the need for > an SONAME version bump. This is not normally something that > downstreams should ever touch though - it is an upstream > decision when to bump their SONAME version. > > Should we not preserve the ENGINE_* symbols, but turn > their impl into either a no-op, or reporting a runtime > error, as appropriate for each API. > All 100+ symbols? I don't think providing non-working stubs would be a good idea... -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Dear Fabio, On Wed, Mar 20, 2024 at 3:18 PM Fabio Valentini wrote: > On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé > wrote: > > > > On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote: > > (...) > > > > As I understand, upstream is going to remove engines but it wouldn't > happen > > > before OpenSSL 4.0 > > > > That makes sense, as it solves the ELF ABI / SONAME change > > issue with removing the APIs. > > > > > I don't think Fedora should wait for that. We definitely want to land > > > no-engine in RHEL10 so Fedora should be ready for that. > > > > Fedora shouldn't neccessarily be rushed into something just because > > RHEL wants to do it prematurely due to RHEL's long lifecycle. > > I fully agree here. Just because something is desirable for RHEL x+1 > doesn't mean that it's desirable for Fedora y+1. > Also, hasn't CentOS Stream 10 already been branched off of > ELN-is-Fedora-40, meaning it would be too late if done in Fedora 41 > anyway? > I agree that it's not strictly necessary for F41. I'm pretty sure that if we want it in F42 we have to start now. At least the feedback is valuable and we can take it into account earlier. Or is this just about OpenSSL maintainers not wanting to have to keep > maintaining Engine support in Fedora while it will be phased out in > RHEL sooner? > Yes. We already have quite bad experience of maintaining slightly different versions of OpenSSL and I'd like to keep the versions as close as possible. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Dear Daniel, On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé wrote: > On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote: > > Dear Daniel, > > > > On Wed, Mar 20, 2024 at 1:44 PM Daniel P. Berrangé > > wrote: > > > > > On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote: > > > > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine > > > > > > > > This is a proposed Change for Fedora Linux. > > > > This document represents a proposed Change. As part of the Changes > > > > process, proposals are publicly announced in order to receive > > > > community feedback. This proposal will only be implemented if > approved > > > > by the Fedora Engineering Steering Committee. > > > > > > > > == Summary == > > > > We disable support of engines in OpenSSL > > > > > > > > == Owner == > > > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] > > > > * Email: dbely...@redhat.com > > > > > > > > == Detailed Description == > > > > We are going to build OpenSSL without engine support. Engines are not > > > > FIPS compatible and corresponding API is deprecated since OpenSSL > 3.0. > > > > The engine functionality we are aware of (PKCS#11, TPM) is either > > > > covered by providers or will be covered soon. > > > > > > "will be covered soon" > > > > > > ... so lets wait until that work is actually complete before > > > removing this from openssl, otherwise there's a window of > > > brokenness in Fedora where the old feature is removed and > > > the new feature is not ready. > > > > > > > I am not going to land this change until the tpm2 provider is landed in > > Fedora. > > Lets explicitly note that as a blocking / pre-requisite dependency > for landing this change then. > Fair point, will do. > > > Removing symbols is an ABI break, so would imply the need for > > > an SONAME version bump. This is not normally something that > > > downstreams should ever touch though - it is an upstream > > > decision when to bump their SONAME version. > > > > > > Should we not preserve the ENGINE_* symbols, but turn > > > their impl into either a no-op, or reporting a runtime > > > error, as appropriate for each API. > > > > > > > All 100+ symbols? I don't think providing non-working stubs would be a > good > > idea... > > Intentionally forking the upstream ABI is worse IMHO. > > Consider you've built your own app on Fedora 39 that uses these > symbols, and now upgrade to F40. RPM will consider the dependency > still satisfied, as the SONAME hasn't changed on libcrypto. The > app throws linker errors at some point due to the missing symbols. > > Another alternative is to continue providing fully functional engine > symbols, but remove the header files so in practice you can't compile > something new that uses it. This is still forking the API, but at least > has not forked the ELF ABI, so the upgrade doesn't explode. > I agree that this option is on the table. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Dear Jun, On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him) wrote: > On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy > wrote: > > > ... > >> > == Detailed Description == > >> > We are going to build OpenSSL without engine support. Engines are not > >> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. > >> > The engine functionality we are aware of (PKCS#11, TPM) is either > >> > covered by providers or will be covered soon. > >> > >> "will be covered soon" > >> > >> ... so lets wait until that work is actually complete before > >> removing this from openssl, otherwise there's a window of > >> brokenness in Fedora where the old feature is removed and > >> the new feature is not ready. > > > > > > I am not going to land this change until the tpm2 provider is landed in > Fedora. > > But the affected packages must start prepare to this change as early as > possible. > > Hi Dmitry, > Could you provide the upstream OpenSSL project's issue ticket(s) or > pull-request(s) about the feature adding or updating the providers to > cover all the functionalities that engines have? > I would like to track the progress of the work. > I'm quite surprised. I'm pretty sure that providers cover all the functionalities that engines have. (It doesn't mean that for each an every engine exists a 1:1 replacing provider, but it's a question to the authors of these engines) If you are aware of any deficiencies, could you please let upstream or me know? -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Dear Zbyszek, On Thu, Mar 21, 2024 at 12:41 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Thu, Mar 21, 2024 at 12:15:43PM +0100, Dmitry Belyavskiy wrote: > > > > Hi Dmitry, > > > Could you provide the upstream OpenSSL project's issue ticket(s) or > > > pull-request(s) about the feature adding or updating the providers to > > > cover all the functionalities that engines have? > > > I would like to track the progress of the work. > > > > > > > I'm quite surprised. > > I'm pretty sure that providers cover all the functionalities that engines > > have. > > (It doesn't mean that for each an every engine exists a 1:1 replacing > > provider, but it's a question to the authors of these engines) > > > > If you are aware of any deficiencies, could you please let upstream or me > > know? > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MUFNAZT3IIVWPAYVNHP72SRL4XTKJRTY/ > ? > Unfortunately I don't agree. It doesn't contain any details: what was tested and what has failed -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Dear Jun, On Thu, Mar 21, 2024 at 2:29 PM Jun Aruga (he / him) wrote: > On Thu, Mar 21, 2024 at 12:16 PM Dmitry Belyavskiy > wrote: > > > > Dear Jun, > > > > > > > > On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him) > wrote: > >> > >> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy > wrote: > >> > > >> ... > >> >> > == Detailed Description == > >> >> > We are going to build OpenSSL without engine support. Engines are > not > >> >> > FIPS compatible and corresponding API is deprecated since OpenSSL > 3.0. > >> >> > The engine functionality we are aware of (PKCS#11, TPM) is either > >> >> > covered by providers or will be covered soon. > >> >> > >> >> "will be covered soon" > >> >> > >> >> ... so lets wait until that work is actually complete before > >> >> removing this from openssl, otherwise there's a window of > >> >> brokenness in Fedora where the old feature is removed and > >> >> the new feature is not ready. > >> > > >> > > >> > I am not going to land this change until the tpm2 provider is landed > in Fedora. > >> > But the affected packages must start prepare to this change as early > as possible. > >> > >> Hi Dmitry, > >> Could you provide the upstream OpenSSL project's issue ticket(s) or > >> pull-request(s) about the feature adding or updating the providers to > >> cover all the functionalities that engines have? > >> I would like to track the progress of the work. > > > > > > I'm quite surprised. > > I'm pretty sure that providers cover all the functionalities that > engines have. > > (It doesn't mean that for each an every engine exists a 1:1 replacing > provider, but it's a question to the authors of these engines) > > > > If you are aware of any deficiencies, could you please let upstream or > me know? > > Hi Dmitry, > Sorry. Maybe I used the terminology "functionality" incorrectly. > I am talking about some features that engines provided are missing in > providers. I see the following issue tickets. > > * https://github.com/ruby/openssl/issues/722 > > The Engine API was deprecated in OpenSSL 3 and there seems to be > no alternatives for it at the moment using Provider API. The providers > can only be loaded, but there seems to be no way to load keys using an > uri (for ex. pkcs11 uri scheme) > I believe the pkcs11-provider is already capable of it. > * https://github.com/ruby/openssl/issues/723 > > GOST engine > I can say a lot about it in private. TL;DR - it's almost abandoned for many reasons. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
There is a chance Fedora is not affected according to the following analysis: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 Quoting: = If those conditions check, the payload is injected into the source tree. We have not analyzed this payload in detail. Here are the main things we know: The payload only activates if the running program has the process name /usr/bin/sshd. This means that systems that put sshd in /usr/sbin or another folder are not vulnerable. This further suspects targeting systemd systems due to their usrmerge initiative putting all binaries in /usr/bin. = We have the patch from https://github.com/openssh/openssh-portable/pull/375 applied, BTW. On Fri, Mar 29, 2024 at 10:59 PM Richard W.M. Jones wrote: > On Fri, Mar 29, 2024 at 04:46:54PM -0500, Michael Catanzaro wrote: > > On Fri, Mar 29 2024 at 04:10:53 PM -05:00:00, Michael Catanzaro > > wrote: > > >OK, I am going to ask Product Security to edit their blog post to > > >remove the incorrect information. I will CC you on that request. > > > > Or maybe I should rephrase this as a "request for clarification," > > because maybe they know something that we don't. E.g. the Ars > > article [1] says > > > > "The build environment on Fedora 40, for example, contains > > incompatibilities that prevent the injection from correctly > > occurring. Fedora 40 has now reverted to the 5.4.x versions of xz > > Utils." > > > > [1] > https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/ > > Yeah that's just a confused report. This is how it actually happened: > > (1) We built 5.6.0 for Fedora 40 & 41. Jia Tan was very insistent in > emails that we should update. > > (2) We got reports later of a valgrind test failure. I also saw it > myself in my own projects that use liblzma. We notified Jia Tan of > this. > > (3) Since the valgrind failure pointed to something with ifuncs, using > './configure --disable-ifuncs' was used to fix this in F40 & F41. > > (4) xz 5.6.1 was released with a fix for the valgrind failure. > > (5) Fedora 40 was now in beta so we kept 5.6.0 + --disable-ifuncs. > Fedora 41 was updated to 5.6.1 (enabling ifuncs again). > > And now with the benefit of hindsight ... > > In step (1) we worked in good faith with upstream. Given how > obfuscated the injection is, it's very unlikely we would have found > the problem even if we'd spent days inspecting the tarball. (And the > initial step of injection is *not* in git, so forget about reviewing > git commits.) > > The valgrind failure (2) was caused by a bug in the back door. > > Disabling ifuncs in (3) disabled the back door, because I think it > relies on ifuncs to do its malware, but in any case the obfuscated > injection script explicitly skips injection if ifuncs are disabled. > > Step (4) fixed the back door valgrind failure. > > The Fedora 40 beta freeze in (5) meant we got lucky for F40, not so > much for F41. > > Rich. > > > Now, that's a secondary source, and I'm not confident if it is true, > > but perhaps Product Security had time to analyze the build logs > > before publishing and found something that we don't know about. > > Richard, what do you think? > > > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > nbdkit - Flexible, fast NBD server with plugins > https://gitlab.com/nbdkit/nbdkit > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 1:07 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > > Before making each of these safer we should make sshd not link with so > > many things in the first place. > > Indeed. E.g., Arch Linux does not transitively link sshd against liblzma. > Fedora does because of this innocuous-looking patch: > > https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch > which is what ultimately allowed this to happen. This drags in libsystemd > for sd_notify, and libsystemd is linked to way too much stuff including > liblzma. Either we need a split libsdnotify that contains only sd_notify, > or > we should just stop using sd_notify at all. It increases the attack > surface > of daemons a lot just to allow the service to be "Type=notify" rather than > one of the other available approaches. Arch Linux is also systemd-based > nowadays, but still does not link OpenSSH against libsystemd. We have an upstream-adjusted version of this patch, see https://bugzilla.mindrot.org/show_bug.cgi?id=2641 I'm OK to bring the updated version of this script to Fedora as soon as it is finalized. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Dear Kevin, On Sat, Mar 30, 2024 at 8:12 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Miroslav Suchý wrote: > > 4) Fetch build artifacts before executing tests > > > > https://github.com/rpm-software-management/mock/issues/1352 > > Or better: Do not execute tests to begin with! rm -rf test in %prep and > NEVER run tests during builds. Even when the tests are all legitimate, all > it does is slow down the build (e.g., compare glibc build times without > and > with tests) and every so often break it because the test, not the > software, > is broken. And a claimed "test file" is what allowed the payload to be > snuck > in here. > It's a terrible idea. Sorry. > Unit tests are something for upstream developers. They should NEVER be run > in a distribution build. > The first thesis is completely wrong. Having, say, a 30+ downstream patches and declining to run upstream tests is the most effective way to break a gazillion use-cases. But the fuzzing tests look quite dangerous to me here and now. No one can review a corpse of binary files :( -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Hi Zbigniew! On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Tue, Apr 02, 2024 at 10:45:32AM +0100, Aoife Moloney wrote: > > == Summary == > > We disable building the packages using ENGINE API in OpenSSL without > > breaking ABI. > > "Without breaking ABI" is a improvement. > Everything else — not so much. > > > == Detailed Description == > > We are going to deprecate OpenSSL engine support. Engines are not FIPS > > compatible and corresponding API is deprecated since OpenSSL 3.0. The > > engine functionality we are aware of (PKCS#11, TPM) is either covered > > by providers or will be covered soon. > > This doesn't really answer the problems that were raised in the previous > round of discussion. Even if the plan is that some functionality will > be provided "soon", dropping engine support _right now_ will cause problems > for developers and for users: first the providers need to become available > and have the complete feature set, then the upstreams have add the relevant > provider code and document things so that users know how to adapt, > and then we need to integrate all of that downstream in packaging. > > If we start be ripping out the engine functionality, we'll have a > window, of unpredictable length, where the functionality will not be > available. This is bad for users, but also breaks the promise that > Fedora is the best environment for upstream development. > Thanks. In the period between the proposal was written and published the TPM2 provider has landed in Fedora. PKCS#11 provider is already here for a while. Should I update the Wiki page to adjust this point? > We don't plan to remove the API from libcrypto.so. We are going to > > prevent creating the new packages dependent on OpenSSL ENGINE API and > > remove ENGINE dependencies from the existing packages. > > IIUC, this is implemented by dropping the header files. This is > not acceptable: it would break package rebuilds. > It's our goal - to eliminate the engine dependency. While a package can be built, it gets lower priority. > == Benefit to Fedora == > > We get rid of deprecated functionality and enforce using up-to-date > > API. Engine support is deprecated in OpenSSL upstream, and after > > provider migration caused some deficiencies with engine support. No > > new features will be added to engine. So we reduce maintenance burden > > and potentially attack surface. > > > > It follows approach planned for CentOS 10. > > Such things are always a tradeoff. The benefit of removing the deprecated > code obviously reduced the maintanance burder a bit. But is is really > that much? OTOH, it disables features that are being used or developed > in a bunch of important projects. It seems very premature to take this > step for F41, i.e. sometime within the next two—three months. It seems > that the ecosystem isn't ready. > I want to encourage the ecosystem to move to a viable target. > > The tradeoff for CentOS 10 is different: the first release is still > a while away and most people will not jump onto the 10.0 release anyway. > By the time CentOS is used in anger, the ecosystem might be ready. > This is one of the cases where using Fedora as a pre-release for CentOS > as a pre-release for RHEL is detrimental to Fedora. > I agree. > == How To Test == > > OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40. > > Applications relying on the ENGINE API can't be built but still work. > > That's incompatible with package rebuilds… > > An acceptable approach would be to split out the headers to a separate > -devel file, e.g. openssl-engine-devel, mark it as Provides: deprecated(). > Existing packages which need the engine headers can adjust to use the > new header and new packages are prevented by the Packaging Guidelines > from adding a dependency on deprecated packages. > Thanks! I like this idea and can update the Wiki page accordingly. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Dear Luca On Tue, Apr 2, 2024 at 4:32 PM Luca Boccassi wrote: > > Hi Zbigniew! > > > > On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek < > > zbyszek(a)in.waw.pl> wrote: > > > > > > Thanks. In the period between the proposal was written and published the > > TPM2 provider has landed in Fedora. > > PKCS#11 provider is already here for a while. > > The fact that such packages are physically present is not enough - they > need to implement all the needed features, and they need to be mature > enough to just work out of the box. Neither of these are true today, and > providers just do not work for very simple use cases like signing a UKI > with a yubikey. At the very least a couple more years of development and > testing is needed before they are anywhere near ready to drop support for > engines, that actually do work out of the box. Not to mention third party > engines that are specific to internal/private build systems - if any such > system runs Fedora as the build host, they'd have to migrate to > Debian/Ubuntu to keep working. > The TPM2 package is suitable for all required operations, AFAIK. I'm also sure about the PKCS11 provider which I follow close enough. Please raise detailed issues if you have something particular. I remember that you mentioned a particular issue about PKCS#11, could you please try the current version? My colleagues working on PKCS#11 are not aware of any Yubikey issues, BTW. Third-party engines may be a problem but as we don't break ABI, it's not a problem of the moment. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Dear Gary, On Tue, Apr 2, 2024 at 5:39 PM Gary Buhrmaster wrote: > On Tue, Apr 2, 2024 at 3:12 PM Dmitry Belyavskiy > wrote: > > > Third-party engines may be a problem but as we don't break ABI, it's not > a problem of the moment. > > The fact you are removing the headers means it is > a problem for 3rd party engines who build from > source (and everyone should at least occasionally > be building from source as part of their CI). > > I consider removing the headers as breaking > the API, as the headers define the API. > I agree with moving the engine header package to a separate devel package instead of removing it. > The headers already mark the engine APIs > as deprecated. Orgs with resources should > be starting their migration, although some > will defer it to the next quarter (and the > next) > Yes. That's why I think the pressure in this direction is worth the effort. I believe this should be part of OpenSSL 4.0. > It will be a clear change. There is no > compelling reason for this to happen > today via the headers. Instead this should > be a marketing campaign by OpenSSL > to remind everyone that engines are > going away with OpenSSL 4.0 with every > new set of release notes (first item, > in double bold), and that orgs need to > start their migration. And then do it again. > And then do it again. And when OpenSSL > 4.0 is released, you can remind everyone > you warned them. I agree that removing the engine stuff is clearly 4.0 stuff (or earlier version if .so version changes). But there are steps that will indicate our moving in this direction and will allow reducing the number of packages to be changed. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Dear Zbyszek, Thanks, I updated the Wiki page correspondingly. On Wed, Apr 3, 2024 at 5:56 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > [Replying to two mails at once to conserve some electrons.] > > On Tue, Apr 02, 2024 at 04:03:31PM +0200, Dmitry Belyavskiy wrote: > > Thanks. In the period between the proposal was written and published the > > TPM2 provider has landed in Fedora. > > PKCS#11 provider is already here for a while. > > > > Should I update the Wiki page to adjust this point? > > Please do. > > > > == How To Test == > > > > OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40. > > > > Applications relying on the ENGINE API can't be built but still work. > > > > > > That's incompatible with package rebuilds… > > > > > > An acceptable approach would be to split out the headers to a separate > > > -devel file, e.g. openssl-engine-devel, mark it as Provides: > deprecated(). > > > Existing packages which need the engine headers can adjust to use the > > > new header and new packages are prevented by the Packaging Guidelines > > > from adding a dependency on deprecated packages. > > > > Thanks! I like this idea and can update the Wiki page accordingly. > > Thanks! > > On Tue, Apr 02, 2024 at 05:12:20PM +0200, Dmitry Belyavskiy wrote: > > On Tue, Apr 2, 2024 at 4:32 PM Luca Boccassi wrote: > > [...] > > The TPM2 package is suitable for all required operations, AFAIK. > > I'm also sure about the PKCS11 provider which I follow close enough. > > > > Please raise detailed issues if you have something particular. > > I remember that you mentioned a particular issue about PKCS#11, could you > > please try the current version? > > My colleagues working on PKCS#11 are not aware of any Yubikey issues, > BTW. > > > > Third-party engines may be a problem but as we don't break ABI, it's not > a > > problem of the moment. > > On Wed, Apr 03, 2024 at 09:50:27AM +0200, Clemens Lang wrote: > > I did try using the current pkcs11-provider with my Yubikey to > > create a signature using openssl dgst -sign > > 'pkcs11:serial=18c9662a9c930e9e;id=%02;type=private'. It worked just > > fine for me, including prompting for the PIN, twice. > > > > I did have to enable the PKCS11 provider in my openssl.cnf, but that > > could also be done programmatically at runtime by applications> > > should they choose to do so. > > > > I was not able to reproduce the problems you faced in the systemd > > upstream ticket you referred to earlier. It is possible that they > > have been fixed upstream in the meantime. > > Thank you both, it sounds like this should work. In systemd, we'll > need to adjust the code to use providers, but that should be doable. > > OK, so with discussed changes, I'm +1. > > Zbyszek > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Dear Kevin On Wed, Apr 3, 2024 at 8:13 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Joe Orton wrote: > > Given that the ENGINE API is deprecated upstream since OpenSSL 3.0, the > > API is optional upstream, and its use has produced compiler warnings > > since it was introduced in Fedora 36, it seems perfectly reasonable to > > disable this API in Fedora 41. > > I disagree. Disabling an API that is still widely used and for which there > is still no complete replacement (several replies have pointed out issues > still preventing "providers" from working in all use cases in which > "engines" work) is NOT reasonable. > You are 100% correct. That's why disabling this API is not on the table for now anymore. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Dear Björn, On Sun, Jun 9, 2024 at 12:39 AM Björn Persson wrote: > > == Summary == > > OpenSSL will no longer trust cryptographic signatures using SHA-1 by > > default, starting from Fedora 41. > > Validating DNS resolvers are still required to be able to validate > signatures made with SHA-1. RFC 8624 is still current as far as I can > tell: > > https://www.rfc-editor.org/rfc/rfc8624#section-3.1 > https://www.rfc-editor.org/rfc/rfc8624#section-3.3 > > There have been reports of SHA-1 disablement causing name resolution > problems. Here's one example: > > https://lists.isc.org/pipermail/bind-users/2023-December/108182.html > > Here's a crappy program that can show some statistics but won't let me > link directly to the relevant table: > > https://stats.dnssec-tools.org/ > > It shows about 14 SHA-1-signed domains. That's only 6‰ of the signed > domains, but still a rather large absolute number. > I don't think that 14 of something world-wide (22 mln of DNSSec signed domains) should be considered a large amount. > Before voting on this proposal, Fesco should be informed of what will > happen in Bind, Unbound and SystemD-ResolveD when users try to look up a > domain that is signed with SHA-1. > I agree that the maintainers of the DNSSec software have to consider the behavior of their software. But it doesn't mean that SHA1 for crypto purposes is of any security. > Will DNSsec validation be skipped whenever an algorithm number for SHA-1 > is encountered? That will make the resolver vulnerable to downgrade > attacks. An attacker can then disable DNSsec by sending manipulated > responses indicating for example RSA/SHA-1 for records that are actually > signed with RSA/SHA-256. > If an attacker can manipulate DNSSec so easily, it means it's completely broken. It seems to me that the following would be the best way to distrust > SHA-1 in DNSsec: > > 1: If a valid chain of trust can be established where strong algorithms > are used throughout, then return the records to the client with the AD > bit set, per the standard, indicating that the data are authentic. > > 2: If there should be signatures, but no valid chain of trust can be > established because records are missing or signatures fail to verify, > then assume it's an attack and return SERVFAIL per the standard. > > 3: If one or more valid chains of trust are found, but they all involve > SHA-1 somewhere, then return the records to the client with the AD bit > zeroed, indicating that no attack was detected but the data should not > be trusted any more than an unsigned domain. > > To be able to distinguish between cases 2 and 3, the resolver must > remain able to verify SHA-1 signatures. > Looks reasonable to me. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > In https://fedoraproject.org/wiki/SHA1SignaturesGuidance: > > At the moment, we don't provide a public API to enable SHA-1 signature > > support in OpenSSL programmatically. We ask you to respect the system > > administrator's configuration choice on this. We're planning to work > > with OpenSSL upstream to introduce a more suitable API in the future > > Any news on this? Being able to make this policy configurable at > application > level would make things _much_ easier. > We don't plan to provide such an API, sorry. SHA1 is insecure. It should be eliminated from the crypto contexts _before_ a second-preimage attack starts to cost $0.02 -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Dear Roberto On Sun, Jun 9, 2024 at 1:16 PM Roberto Ragusa wrote: > On 6/9/24 11:27, Dmitry Belyavskiy wrote: > > > > On Sun, Jun 9, 2024 at 11:22 AM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl <mailto:zbys...@in.waw.pl>> wrote: > > > > In https://fedoraproject.org/wiki/SHA1SignaturesGuidance < > https://fedoraproject.org/wiki/SHA1SignaturesGuidance>: > > > At the moment, we don't provide a public API to enable SHA-1 > signature > > > support in OpenSSL programmatically. We ask you to respect the > system > > > administrator's configuration choice on this. We're planning to > work > > > with OpenSSL upstream to introduce a more suitable API in the > future > > > > Any news on this? Being able to make this policy configurable at > application > > level would make things _much_ easier. > > > > > > We don't plan to provide such an API, sorry. SHA1 is insecure. It should > be eliminated from the crypto contexts _before_ a second-preimage attack > starts to cost $0.02 > > > Is it the library's job to decide policies about security levels? > Each time algorithms are "distrusted" people get problems mostly with > things > where security is not really critical at all, like connecting to their > local > hypervisor, their arduino boards, their home thermostat, etc. etc. etc. > Let's hope at least the policies will be tweakable enough, I've seen cases > where people were proposing removal of algorithms from the code, which is > crazy > (why should a library refuse to do an RC4 calculation for me?). > You still are able to use SHA1 and RC4 using openssl. The distribution should provide a necessary level of security defaults.Those who understand why they don't need enough security, can relax any limitations. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Dear colleagues, Let me try to summarize the pros and cons of this discussion. Our intention is making the software and its settings as secure as possible by default. That's why we have crypto policies. The proposed change is aligned with the setting we have implemented in RHEL9 for 2-3 years, and there were only several use cases affected by this tightening, mostly SSH. I understand that not all old systems are upgradeable (though many of them can be turned to smth using better algorithms - e.g. EC SSH keys are available on RHEL 7). So for these use cases we would like to propose either use runcp utility (which doesn't undermine the default settings) or, worst case, use a jump container. Any of this solution doesn't undermine the whole system's security. I believe that now we could move this change forward, having a workaround for some use cases, probing to detect the legacy algorithm when it was missing, and higher security standards. On Tue, Jun 11, 2024 at 12:02 PM Clemens Lang wrote: > Hi Peter, > > > On 11. Jun 2024, at 07:01, Peter Boy wrote: > > > >> Am 10.06.2024 um 20:16 schrieb Richard W.M. Jones : > >> > >> On Mon, Jun 10, 2024 at 01:43:57PM +0200, Vít Ondruch wrote: > >>> I wish this proposal included some examples of what might get broken > >>> and what will keep working. I guess I am not the only one who have > >>> very vague understanding what is difference between "signatures" and > >>> "hashing" or other purposes SHA1 can be used for. > >> > >> SSH and HTTPS to old machines (even old versions of Fedora & RHEL) and > >> to old network equipment and the like will not be possible. > >> > >> I'm annoyed that this is not just put behind the LEGACY policy, since > >> if that's not what "legacy" is for, what _is_ it for? > >> > >> As an aside, it'd be very nice if policies could be set per-process. > >> That would greatly enhance security by allowing specific programs to > >> connect to the legacy machines, while maintaining general system > >> security. > >> > >> Anyway, -1 from me. > >> > >> Rich. > > > > Anyway, -1 from me, too > > > > For exactly that reason. > > Can you elaborate what you would need, in addition to the LEGACY policy > (which still allows these connections) and the runcp utility? > > > -- > Clemens Lang > RHEL Crypto Team > Red Hat > > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: openssl engine-related FTBFS and Boost
Dear colleagues, On Tue, Jul 2, 2024 at 1:35 PM Iñaki Ucar wrote: > Hi, > > This recent commit [1] in rawhide moves the engine API to a > openssl-devel-engine subpackage following [2] (BTW this change announced > that it would be openssl-engine-devel instead, but that's not the point). > I'm surprised that FESCo approved this change without any analysis of the > impact and the packages that required adaptation and how. Also, change > owners are now allowed to commit and just let things break? > > One major concern is that I see this in a package that does **not** use > the engine API: > > /usr/include/boost/asio/ssl/detail/openssl_types.hpp:26:11: fatal error: > openssl/engine.h: No such file or directory >26 | # include > | ^~ > compilation terminated. > > What are we supposed to do here? Aren't we allowed to add new packages to > Fedora that require Boost ASIO because we would need to add a deprecated > package to BR, even if the package itself doesn't use that API? > In the long-term it would be better to provide a patch fixing build of the package. Probably adding -DOPENSSL_NO_ENGINE to build flags will work. Engines are deprecated. You should not use engines and should migrate to providers. The implemented solution is an attempt to find balance between removing engines at all (not possible as of now) and delaying the migration to providers. I'd recommend consider it as a gentle reminder about future engine deprecation -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Pavel Odintsov
Dear Pavel, Nice to see you here :) On Sat, May 28, 2022 at 3:33 PM Pavel Odintsov wrote: > Hello, Fedora developer community! > > My name is Pavel Odintsov and I'm a software engineer with a passion for > computer networks. I'm author of FastNetMon Community, a tool for lightning > fast volumetric DDoS attack detection. > > My software engineering skills are most solid around C++ with a deep > understanding of Go accompanied by Perl for text processing. > > My area of interest includes basic network protocols such as Ethernet, > IPv4, IPv6, TCP, UDP, BGP, Netflow, IPFIX, sFlow, > > I have experience in high speed network traffic processing as it's a > crucial part of FastNetMon's traffic processing core. > > I'm very open for communications and I use plenty of channels and you can > contact me using email or LinkedIN: https://www.linkedin.com/in/podintsov/ > > I would like to add FastNetMon to official Fedora packages to move the > experience of using our tool to the next level. > > Thank you! > > -- > Sincerely yours, Pavel Odintsov > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Can't login into Wiki
Dear colleagues, I can't login into Fedora Wiki. I get an error "You have made too many recent login attempts. Please wait 2 days before trying again." First, I didn't. Second, is there any relevant person who could reset this timer taking into account the perspective of Fedora System-wide proposals deadline? Many thanks in advance! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok wrote: > On 22. 06. 22 21:05, Vipul Siddharth wrote: > > We are going to deprecate openssl1.1 package, stop shipping the > > corresponding devel package, and stop respecting crypto policies in > > openssl1.1 package itself. > > +1 to deprecating it > Great! -1 to stop shipping the devel package, this would mean we cannot build at > least: > > - Python 2.7 >despite our long term efforts, many things still need that, e.g. gimp, > firefox (some builds do, then some don't), thunderbird etc., see > https://fedora.portingdb.xyz/ > > Or Python 3.6 (shipped for developers targeting RHEL 7/8). > > As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please > leave the > devel package? > I'm not sure that if we don't remove the devel package, we will provide strong enough motivation to get rid of the deprecating packages. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
On Fri, Jun 24, 2022 at 11:20 AM Daniel P. Berrangé wrote: > On Fri, Jun 24, 2022 at 11:13:13AM +0200, Dmitry Belyavskiy wrote: > > On Wed, Jun 22, 2022 at 11:02 PM Miro Hrončok > wrote: > > > > > On 22. 06. 22 21:05, Vipul Siddharth wrote: > > > > We are going to deprecate openssl1.1 package, stop shipping the > > > > corresponding devel package, and stop respecting crypto policies in > > > > openssl1.1 package itself. > > > > > > +1 to deprecating it > > > > > > > Great! > > > > -1 to stop shipping the devel package, this would mean we cannot build at > > > least: > > > > > > - Python 2.7 > > >despite our long term efforts, many things still need that, e.g. > gimp, > > > firefox (some builds do, then some don't), thunderbird etc., see > > > https://fedora.portingdb.xyz/ > > > > > > Or Python 3.6 (shipped for developers targeting RHEL 7/8). > > > > > > As long as OpenSSL 1.1 gets security fixes in RHEL 8, could we please > > > leave the > > > devel package? > > > > > > > I'm not sure that if we don't remove the devel package, we will provide > > strong enough motivation to get rid of the deprecating packages. > > If the openssl maintainers really strongly want to remove the > devel pacakge, then don't call this deprecation because that > is misleading. Call this purging openssl1.1 from the entire > distro, such that it can only be used by 3rd party apps who > have previously compiled against older Fedora openssl-devel. > Be open about fact that this will cause FTBFS for any Fedora > packages that stil uses openssl1 and their removal from the > distro if they can't port to openssl3 very quickly. > > Do I correctly understand that the situation with Python is the most problematic? Are we able to solve it somehow? What I'm afraid of is that if we just declare the deprecation, we will stay with this package forever. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
=== > ERROR: test_protocol_tlsv1 (test.test_ssl.ThreadedTests) > Connecting to a TLSv1 server with various client options > -- > Traceback (most recent call last): > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2452, in > test_protocol_tlsv1 > try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_TLSv1, 'TLSv1') > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2136, in > try_protocol_combo > chatty=False, connectionchatty=False) > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2064, in > server_params_test > s.connect((HOST, server.port)) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 864, in connect > self._real_connect(addr, False) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 855, in _real_connect > self.do_handshake() > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 828, in do_handshake > self._sslobj.do_handshake() > SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:727) > > == > ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests) > Connecting to a TLSv1.1 server with various client options. > -- > Traceback (most recent call last): > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 190, in f > return func(*args, **kwargs) > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2471, in > test_protocol_tlsv1_1 > try_protocol_combo(ssl.PROTOCOL_TLSv1_1, ssl.PROTOCOL_TLSv1_1, > 'TLSv1.1') > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2136, in > try_protocol_combo > chatty=False, connectionchatty=False) > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2064, in > server_params_test > s.connect((HOST, server.port)) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 864, in connect > self._real_connect(addr, False) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 855, in _real_connect > self.do_handshake() > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 828, in do_handshake > self._sslobj.do_handshake() > SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:727) > > == > ERROR: test_recv_send (test.test_ssl.ThreadedTests) > Test recv(), send() and friends. > -- > Traceback (most recent call last): > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2639, in > test_recv_send > s.connect((HOST, server.port)) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 864, in connect > self._real_connect(addr, False) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 855, in _real_connect > self.do_handshake() > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 828, in do_handshake > self._sslobj.do_handshake() > SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:727) > > == > ERROR: test_selected_alpn_protocol (test.test_ssl.ThreadedTests) > -- > Traceback (most recent call last): > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 3033, in > test_selected_alpn_protocol > chatty=True, connectionchatty=True) > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 2064, in > server_params_test > s.connect((HOST, server.port)) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 864, in connect > self._real_connect(addr, False) > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 855, in _real_connect > self.do_handshake() > File "/home/rjones/d/cpython-2.7/Lib/ssl.py", line 828, in do_handshake > self._sslobj.do_handshake() > SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:727) > > == > ERROR: test_selected_alpn_protocol_if_server_uses_alpn > (test.test_ssl.ThreadedTests) > -- > Traceback (most recent call last): > File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 3045, in > test_selected_alpn_pro
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Dear colleagues,
If I correctly follow the discussion, the biggest show-stopper is Python
2.*, which has some incomplete patches to deal with OpenSSL 3.0.
If we assist you in moving these patches forward, can we get rid of the
devel package and leave the compat package only for 3rd-party packages?
I don't think that the community really requires support for this package
for 7 years after its upstream sunset.
Many thanks!
On Tue, Jun 28, 2022 at 4:06 PM Miro Hrončok wrote:
> On 27. 06. 22 13:27, Richard W.M. Jones wrote:
> > ==
> > FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
> > --
> > Traceback (most recent call last):
> >File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 382, in
> test_openssl_version
> > (s, t))
> > AssertionError: ('OpenSSL 3.0.3 3 May 2022', (3, 0, 0, 3, 0))
>
> Might be https://github.com/python/cpython/issues/90272
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
--
Dmitry Belyavskiy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Dear Miro, On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok wrote: > On 29. 06. 22 17:11, Dmitry Belyavskiy wrote: > > Dear colleagues, > > > > If I correctly follow the discussion, the biggest show-stopper is Python > 2.*, > > which has some incomplete patches to deal with OpenSSL 3.0. > > We would also need it in for Python 3.6 and pypys. > Are RHEL 9 patches for Python 3 series relevant in this case? > If we assist you in moving these patches forward, can we get rid of the > devel > > package and leave the compat package only for 3rd-party packages? > > Please don't remove the devel package if you aim for deprecation. As other > have > said, removing the devel package is essentially retirement, not > deprecation. > OK, it's not a problem to deprecate the package in the sense of https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ But we still want to get rid of it. > I don't think that the community really requires support for this package > for 7 > > years after its upstream sunset. > > OpenSSL 3 was introduced in Fedora 36, that has *just* been released this > year. > This is a change proposal for Fedora 37, that is half a year after, not 7 > years :/ > Well, speaking about 7 years, I mean the idea to support the compat package synchronously with RHEL 8. I'd like to retire this package not later than, well, a release after OpenSSL 1.1.1 EOL. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam
Dear Ankur, Your solution looks like not a workaround but a recommended solution. You can find more information in Clemens Lang's blog post here: https://www.redhat.com/en/blog/legacy-cryptography-fedora-36-and-red-hat-enterprise-linux-9 This blog post also contains links to two relevant bugs. Hope this helps. On Thu, Jun 30, 2022 at 9:59 AM Ankur Sinha wrote: > Hi folks, > > Could someone with sufficient OpenSSL knowledge please take a look at > this post? > > > https://ask.fedoraproject.org/t/cannot-connect-to-eduroam-on-f36-due-to-openssl-error/23909 > > I'd managed to debug another one related to Eduroam and come up with a > workaround, but this is a new one that I'm not going to be able to > figure out any time soon: > > > https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-eduroam-on-fedora-36/20288 > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kTLS related failures on rawhide in OpenSSL 3.0.1
Dear colleagues, The error is specific to armv7hl architecture. Could somebody please assist us with investigation of this problem? On Wed, Jan 19, 2022 at 1:24 PM Sahana Prasad wrote: > Hello everyone, > Could anyone kindly help with investigating the kTLS related failures in > [1] > They could be infrastructure related issues, the right kernel versions > that support kTLS. > > [1] https://src.fedoraproject.org/rpms/openssl/pull-request/19 > > Thank you, > Regards, > Sahana Prasad > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kTLS related failures on rawhide in OpenSSL 3.0.1
On Thu, Jan 20, 2022 at 6:49 PM Richard W.M. Jones wrote: > On Wed, Jan 19, 2022 at 01:30:54PM +0100, Dmitry Belyavskiy wrote: > > On Wed, Jan 19, 2022 at 1:24 PM Sahana Prasad wrote: > > > > Hello everyone, > > > > Could anyone kindly help with investigating the kTLS related > > failures in [1] They could be infrastructure related issues, the > > right kernel versions that support kTLS. > > > > [1] https://src.fedoraproject.org/rpms/openssl/pull-request/19 > > > > The error is specific to armv7hl architecture. Could somebody please > > assist us with investigation of this problem? > > I could reproduce the patch locally by building openssl + > the patch in the link on > Linux armv7 5.11.12-300.fc34.armv7hl+lpae #1 SMP Wed Apr 7 16:13:08 UTC > 2021 armv7l armv7l armv7l GNU/Linux > > There's no extra output from dmesg (which I assume one would see if > kTLS was failing?). Is there anything in particular you want to know? > Could you please execute `sudo modprobe tls` and re-run the test? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
Dear Kamil, On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka wrote: > On Tuesday, February 22, 2022 10:50:06 PM CET Chris Adams wrote: > > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > > > > Yes. But how many domains using idn are there? I worked on idn support > > > in systemd, but when preparing the description of this change I > realized > > > that I have _never_ once used an idn domain outside of testing. > > > > > > And note that this is not about user-facing programs like firefox. > > > I assume that there might be _some_ use of idn in firefox. But for > > > command-line tools like curl this seems even less likely. > > > > > > I'm pretty sure use of IDN domains is a regional thing. I live in the > > US and don't see IDN domains in my normal use. But dropping support for > > them from a core utility would be bad for those that live in regions > > where IDN domains may be more common. > > > > -- > > Chris Adams > > If this appears to be a real problem, it is easy for us to re-enable IDN > in libcurl-minimal, even in an update of a stable Fedora release. So I do > not think we need to enable it proactively. > > Being from Russia and having several years of interacting with Universal Acceptance, I'd say IDN is a must nowadays. -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
OpenSSH 8.7p1 in rawhide
Dear colleagues, I recently added OpenSSH 8.7p1 to rawhide. This version includes implementation of the SFTP protocol as the main transfer protocol for the scp utility. In upstream, the SCP protocol is used by default in the scp utility. The upcoming versions 8.9p1+ (version 8.8p1 is mostly a security release) are expected to use SFTP protocol by default. This behavior (SFTP as a default transfer protocol for scp utility) is backported to rawhide. The same approach is planned for RHEL 9 GA, Please let me know if you have any questions/problems. Many thanks in advance! -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: OpenSSH 8.7p1 in rawhide
Dear Richard, On Mon, Oct 4, 2021 at 10:23 AM Richard W.M. Jones wrote: > On Wed, Sep 29, 2021 at 04:48:43PM +0200, Dmitry Belyavskiy wrote: > > Dear colleagues, > > > > I recently added OpenSSH 8.7p1 to rawhide. > > This version includes implementation of the SFTP protocol as the main > transfer > > protocol for the scp utility. In upstream, the SCP protocol is used by > default > > in the scp utility. The upcoming versions 8.9p1+ (version 8.8p1 is > mostly a > > security release) are expected to use SFTP protocol by default. This > behavior > > (SFTP as a default transfer protocol for scp utility) is backported to > rawhide. > > > > The same approach is planned for RHEL 9 GA, > > > > Please let me know if you have any questions/problems. > > Does this change the quoting of scp paths with spaces etc? The > quoting of scp is insane but at least it's a known quantity, and we > baked it into virt-p2v. > Yes. There are changes in the quoting, documented in https://www.openssh.com/txt/release-8.7 and https://www.openssh.com/txt/release-8.8 If you still need an old quoting, AFAIK, you should explicitly specify the scp protocol via -O command-line option. > > -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
At least RHEL 6 issues can be fixed server-side generating an ecdsa key... On Wed, Mar 9, 2022 at 2:47 PM Richard W.M. Jones wrote: > Previous tightening of crypto defaults caused problems with us > connecting to older ssh servers. > > I am particularly interested / worried about sshd from RHEL 5, 6 & 7 > for virt-p2v and virt-v2v conversions. This broke before, requiring > us to advise users to set the global policy for the machine to LEGACY > (thus ironically weakening crypto for everything). > > Also I have some ancient network equipment that cannot be upgraded but > needs older ssh protocols. I can't connect to it from Fedora unless I > set the crypto policy to LEGACY. > > Anyway I'm wondering if the SHA-1 change will impact ssh further? > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openssl maintainerships?
Dear Peter, dear Miro, The immediate reason for the lack of update of OpenSSL in Fedora was a problem with kTLS in avmv7. We tried to get some feedback but didn't succeed and are going to disable kTLS in armv7. Now we are going to upgrade both F36 and rawhide to 3.0.2, I start working on this. Sorry for any possible inconvenience. On Wed, Mar 16, 2022 at 12:41 AM Miro Hrončok wrote: > On 15. 03. 22 22:27, Peter Robinson wrote: > > Hi Dmitry. > > > > It seems since the openssl 3 GA release back in September there's not > > been a single successful openssl build[1], and a number of bugs [2], > > and even more CVEs [3][4]. Why aren't these being dealt with in a semi > > reasonable fashion? The last actual successful build is now over 6 > > months ago. > > I am also curious why the OpenSSL version in CentOS Stream 9 is once again > higher than in Fedora. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openssl maintainerships?
Dear Peter, We have created a bug https://bugzilla.redhat.com/show_bug.cgi?id=2047295 It doesn't look like an upstream OpenSSL bug for me. Personally I don't expect much effort in this direction because armv7 architecture looks to be deprecating. On Wed, Mar 16, 2022 at 11:11 AM Peter Robinson wrote: > On Wed, Mar 16, 2022 at 10:04 AM Dmitry Belyavskiy > wrote: > > > > Dear Peter, dear Miro, > > > > The immediate reason for the lack of update of OpenSSL in Fedora was a > problem with kTLS in avmv7. > > We tried to get some feedback but didn't succeed and are going to > disable kTLS in armv7. > > Is there a bug for this against openssl and linked to the arm > tracker[1], or did you post it to an upstream, either kernel or > openssl, to request assistance? If the later there should be a Fedora > bug with links to those so people can follow up. If there's bugs we > can get Arm to assist in solving arm specific problems but with out a > public bug we can't engage them. Even with disabling this please > outline the details and file a Fedora bug if you've not done so > already. > > > Now we are going to upgrade both F36 and rawhide to 3.0.2, I start > working on this. > > Great. > > > Sorry for any possible inconvenience. > > Please don't just let things sit because of one problem, things may > well get lost in people's inboxes if you do a single message to a > single person. It's generally not the way to get assistance. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=245418 > > > On Wed, Mar 16, 2022 at 12:41 AM Miro Hrončok > wrote: > >> > >> On 15. 03. 22 22:27, Peter Robinson wrote: > >> > Hi Dmitry. > >> > > >> > It seems since the openssl 3 GA release back in September there's not > >> > been a single successful openssl build[1], and a number of bugs [2], > >> > and even more CVEs [3][4]. Why aren't these being dealt with in a semi > >> > reasonable fashion? The last actual successful build is now over 6 > >> > months ago. > >> > >> I am also curious why the OpenSSL version in CentOS Stream 9 is once > again > >> higher than in Fedora. > >> > >> -- > >> Miro Hrončok > >> -- > >> Phone: +420777974800 > >> IRC: mhroncok > >> > > > > > > -- > > Dmitry Belyavskiy > > -- Dmitry Belyavskiy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora rawhide (to be f41) and openssl engines
Dear colleagues, On Tue, Sep 17, 2024 at 10:05 PM Jonathan Wakely wrote: > It's fixed in rawhide now, but are we still against fixing it for F41? > Affected Fedora packages might have been fixed, but people build other > software on Fedora that isn't already packaged and built in koji. I'm ok with porting this to F41 -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora rawhide (to be f41) and openssl engines
It was recently merged to f41 On Mon, Sep 23, 2024 at 11:37 AM Iñaki Ucar wrote: > > > > On Wed, 18 Sept 2024 at 15:36, Dmitry Belyavskiy wrote: >> >> Dear colleagues, >> >> On Tue, Sep 17, 2024 at 10:05 PM Jonathan Wakely wrote: >> >> > It's fixed in rawhide now, but are we still against fixing it for F41? >> > Affected Fedora packages might have been fixed, but people build other >> > software on Fedora that isn't already packaged and built in koji. >> >> I'm ok with porting this to F41 > > > It's just a matter of merging [1] into F41, right? Any blockers? > > [1] > https://src.fedoraproject.org/rpms/openssl/c/13b583a535e62d12521cfeb5088a68e5811eb6e6?branch=rawhide > > Iñaki > >> >> >> -- >> Dmitry Belyavskiy >> >> -- >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue > > > > -- > Iñaki Úcar > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: pkcs11-provider update breaks eduroam
On Wed, Nov 20, 2024 at 11:38 AM Davide Caratti wrote: > hi, > > On Wed, Nov 20, 2024 at 11:09 AM Clemens Lang wrote: > > > > Hi, > > > > > On 19. Nov 2024, at 17:47, Arthur Bols wrote: > > > > > > A few days ago pkcs11-provider-0.5-3.fc41 update was pushed to Fedora > 41. Unfortunately, this update breaks eduroam and possibly many other > WPA2-Enterprise wifi networks. There are multiple threads on Fedora > Discussion, mainly [0], and a bug report [1]. > > > > > > I understand that the maintainers implemented this change with the > best intentions, however, could someone clarify why this provider was > enabled so abruptly in this update? Wouldn’t such a change typically > require a change proposal? Given how many users are affected, would it make > sense to consider rolling back the update until there’s a fix? > > > > I think the bug can be fixed in wpa_supplicant, but until that happens, > users should just uninstall pkcs11-provider. > > > > The idea here was to auto-enable pkcs11-provider when it is installed, > which still makes sense to me. The issue here I think is that many people > ended up with pkcs11-provider installed because of a recommendation. We > should remove that recommendation, most users don’t need pcks11-provider > installed. > > I'm trying a setup right now, to understand what's happening. > wpa_supplicant does not need pkcs11-provider *at the moment*, because > it uses engine API for pkcs11 (and that is going to be a problem in > the future for EAP-TLS with pkcs11, if engine disappears from > openssl). However, it loads the legacy provider at startup, because > it's needed for MSCHAPv2 in the inner authentication. > Do you also load the default provider and/or set default fetching properties? -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: pkcs11-provider update breaks eduroam
Dear Davide,
On Thu, Nov 21, 2024 at 1:07 PM Davide Caratti wrote:
> hello,
>
> On Wed, Nov 20, 2024 at 12:48 PM Dmitry Belyavskiy
> wrote:
> >
>
> [...]
> >> > The idea here was to auto-enable pkcs11-provider when it is
> installed, which still makes sense to me. The issue here I think is that
> many people ended up with pkcs11-provider installed because of a
> recommendation. We should remove that recommendation, most users don’t need
> pcks11-provider installed.
> >>
> >> I'm trying a setup right now, to understand what's happening.
> >> wpa_supplicant does not need pkcs11-provider *at the moment*, because
> >> it uses engine API for pkcs11 (and that is going to be a problem in
> >> the future for EAP-TLS with pkcs11, if engine disappears from
> >> openssl). However, it loads the legacy provider at startup, because
> >> it's needed for MSCHAPv2 in the inner authentication.
> >
> >
> > Do you also load the default provider and/or set default fetching
> properties?
>
> yes. The problem is in md4_vector() [1], the legacy provider has a
> non-NULL pointer and EVP_md4() fetches correctly. However, when
> pkcs11-provider is installed,
> EVP_DigestInit_ex() fails. I tried this patch [2] on upstream
> wpa_supplicant, and it seem to fix at least my local test. The patch
> loads the default provider after loading the legacy provider (and
> unloads it before exiting), and took inspiration from [3] and [4].
>
> @Dmitry Belyavskiy , does it make sense for you? if so I could submit
> it to upstream wpa_supplicant. Or maybe it deserves a test in eduroam
> first.
>
> --- a/src/crypto/crypto_openssl.c
> +++ b/src/crypto/crypto_openssl.c
> @@ -188,15 +188,21 @@ static int EC_GROUP_get_curve(const EC_GROUP
> *group, BIGNUM *p, BIGNUM *a,
>
> #if OPENSSL_VERSION_NUMBER >= 0x3000L
> static OSSL_PROVIDER *openssl_legacy_provider = NULL;
> +static OSSL_PROVIDER *openssl_default_provider = NULL;
> +
> #endif /* OpenSSL version >= 3.0 */
>
> void openssl_load_legacy_provider(void)
> {
> #if OPENSSL_VERSION_NUMBER >= 0x3000L
> if (openssl_legacy_provider)
> - return;
> + goto load_default_provider;
>
> openssl_legacy_provider = OSSL_PROVIDER_try_load(NULL,
> "legacy", 1);
> +load_default_provider:
> + if (openssl_default_provider)
> + return;
> + openssl_default_provider = OSSL_PROVIDER_try_load(NULL,
> "default", 1);
> #endif /* OpenSSL version >= 3.0 */
> }
>
> @@ -208,6 +214,10 @@ static void openssl_unload_legacy_provider(void)
> OSSL_PROVIDER_unload(openssl_legacy_provider);
> openssl_legacy_provider = NULL;
> }
> + if (openssl_default_provider) {
> + OSSL_PROVIDER_unload(openssl_default_provider);
> + openssl_default_provider = NULL;
> + }
> #endif /* OpenSSL version >= 3.0 */
> }
>
> thanks,
> --
> davide
>
> [1] https://w1.fi/cgit/hostap/tree/src/crypto/crypto_openssl.c#n325
> [2] https://w1.fi/cgit/hostap/tree/src/crypto/crypto_openssl.c#n293
> [3]
> https://lore.kernel.org/lkml/10c0539a6103f4da2eb19765c83800594ebe2dff.1720728319.git.jstan...@redhat.com/
> [4]
> https://docs.openssl.org/3.2/man7/ossl-guide-libcrypto-introduction/#fetching-examples1
Yes, it looks reasonable (but I'm not sure you need to free the providers
explicitly, it's up to you).
--
Dmitry Belyavskiy
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Orphaning openssl-gost-engine
Dear colleagues, I orphan openssl-gost-engine for personal reasons -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning openssl-gost-engine
Hi Carlos, Thank you for your email! I'd like to have a talk about it if possible On Sat, Jan 25, 2025 at 3:30 PM Carlos Rodriguez-Fernandez < carlosrodrifernan...@gmail.com> wrote: > I'll take it. Thank you Dmitry. > > > On 1/23/25 10:38 AM, Dmitry Belyavskiy wrote: > > Dear colleagues, > > I orphan openssl-gost-engine for personal reasons > > -- > Dmitry Belyavskiy > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
PQ algorithms in Fedora 41 - improvements
Dear colleagues, I'd like to encourage you to test and upvote the following updates to Fedora 41: https://bodhi.fedoraproject.org/updates/FEDORA-2025-cc4e64ede9 This update adds the latest version of liboqs/oqsprovider packages and GnuTLS. This update provides the final NIST-approved versions of the post-quantum algorithms ML-KEM and ML-DSA (instead of preliminary versions, Dilithium and Kyber that are basically out of use now). https://bodhi.fedoraproject.org/updates/FEDORA-2025-800d4e4a95 This update updates OpenSSH to version 9.9p1 that brings a PQ-safe key exchange based on ML-KEM. Many thanks! -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Problems pushing OpenSSH to f42
Dear colleagues, I've built openssh for f42 fixing the latest CVEs a month ago [1]. The build has passed the gating tests and has positive karma. But it can't be pushed for a while with diagnostics FEDORA-2025-1e92156b24 ejected from the push because "Cannot find relevant tag for openssh-9.9p1-9.fc42. None of ['f42-updates-candidate', 'f42-updates-testing-pending', 'f42-updates-pending'] are in ['epel9-next-testing', 'epel10.1-testing', 'eln-updates-testing', 'epel8-testing', 'epel9-testing', 'f40-container-updates-testing', 'f41-container-updates-testing', 'f41-updates-testing', 'f42-updates-testing', 'f40-flatpak-updates-testing', 'f40-updates-testing', 'f42-container-updates-testing', 'f42-flatpak-updates-testing', 'f41-flatpak-updates-testing', 'f43-container-updates-testing', 'epel10.0-testing', 'f43-flatpak-updates-testing', 'f43-updates-testing']." Could anybody please resolve this situation? [1] https://bodhi.fedoraproject.org/updates/FEDORA-2025-1e92156b24 -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal: Package builds are expected to be reproducible (system-wide)
Hello, > We are aware of some issues that cannot be fixed easily: > * Haskell packages are not reproducible when compiled with more than > one thread. Upstream is > [https://gitlab.haskell.org/ghc/ghc/-/issues/12935 working on the > issue], the next release of ghc may resolve the issue completely. > > Does this issue affect only Haskell packages? E.g. openssl is also built with -j8 and switching back to single thread will significantly increase compilation time -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Problems pushing OpenSSH to f42
Thank you very much, looks like now it is pushed to stable On Wed, Mar 19, 2025 at 6:35 PM Kevin Fenzi wrote: > On Wed, Mar 19, 2025 at 10:26:33AM +0100, Dmitry Belyavskiy wrote: > > Dear Petr, > > Thank you for the investigation! > > I think it happened because the build happened during the freeze. > > It happened right at the time updates-testing was enabled for > f42/branched. > > So, when the build/update was automatically created it was acting like a > rawhide update. But it failed gating, then when it passed a few hours > later it was in the wrong 'flow' to go to updates-testing. > > If maintainers see this issue, probibly the easiest/quickest fix is to > just tag the build into the fN-updates-candidate tag (ie, > f42-updates-candidate), > which any maintainer can do with a 'koji tag-build f42-updates-candidate > NVR). > > kevin > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora gating tests to openssh
On Fri, Mar 7, 2025 at 12:04 PM František Šumšal wrote: > Hey, > > On 3/6/25 19:02, Dmitry Belyavskiy wrote: > > Dear colleagues, > > > > I see that Fedora gating tests for OpenSSH fail because of, among > others, ownership/permission tests failure [1]. > > > > We have a ssh-keysign binary, that has sgid permissions deviating from > upstream, we changed it in F38 [2] (and rolled back the corresponding > patch) but the checks still expect sgid bits. > > > > I believe that I asked some people how to update the data to make the > checks relevant, and I got a response that I should submit a PR to some > repo, and probably I even submitted the PR to the repo - but I > unfortunately don't remember the details at all (and looks like the PR was > not processed). Could anybody please remind me the proper procedure? > > I believe the PR you mentioned is > https://github.com/rpminspect/rpminspect-data-fedora/pull/57 and I > _think_ the reason for the fail is that there's no "fileinfo" file for F43 > (yet), so it's not picking up the changes from the PR. If I run rpminspect > locally, the permission check fails with --release=f43, but passes with > --release=f42, which would confirm this theory: > > $ rpminspect-fedora --keep --debug --keep --workdir . --arches x86_64 > --tests=permissions --verbose --release=fc43 --profile=rawhide > openssh-9.9p1.tbOmLI > ... > permissions: > > 1) /usr/libexec/openssh/ssh-keysign in openssh-keysign on x86_64 carries > insecure mode 4555, Security Team review may be required > > Result: BAD > Waiver Authorization: Security > > > 2) /usr/libexec/openssh/ssh-keysign in openssh-keysign on x86_64 carries > insecure mode 4555, Security Team review may be required > > Result: BAD > Waiver Authorization: Security > > > $ rpminspect-fedora --keep --debug --keep --workdir . --arches x86_64 > --tests=permissions --verbose --release=fc42 --profile=rawhide > openssh-9.9p1.tbOmLI > ... > permissions: > > 1) /usr/libexec/openssh/ssh-keysign in openssh-keysign on x86_64 carries > expected mode 4555 > > Result: INFO > Waiver Authorization: Not Waivable > > > 2) /usr/libexec/openssh/ssh-keysign in openssh-keysign on x86_64 carries > expected mode 4555 > > Result: INFO > Waiver Authorization: Not Waivable > > > > > Thank you! > > > > [1] > https://artifacts.dev.testing-farm.io/7a6fef07-41f3-40a2-8ee8-c327934eddcd/ > < > https://artifacts.dev.testing-farm.io/7a6fef07-41f3-40a2-8ee8-c327934eddcd/ > > > > [2] https://fedoraproject.org/wiki/Changes/SSHKeySignSuidBit < > https://fedoraproject.org/wiki/Changes/SSHKeySignSuidBit> > Thank you very much, it explains a lot -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora gating tests to openssh
Dear colleagues, I see that Fedora gating tests for OpenSSH fail because of, among others, ownership/permission tests failure [1]. We have a ssh-keysign binary, that has sgid permissions deviating from upstream, we changed it in F38 [2] (and rolled back the corresponding patch) but the checks still expect sgid bits. I believe that I asked some people how to update the data to make the checks relevant, and I got a response that I should submit a PR to some repo, and probably I even submitted the PR to the repo - but I unfortunately don't remember the details at all (and looks like the PR was not processed). Could anybody please remind me the proper procedure? Thank you! [1] https://artifacts.dev.testing-farm.io/7a6fef07-41f3-40a2-8ee8-c327934eddcd/ [2] https://fedoraproject.org/wiki/Changes/SSHKeySignSuidBit -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)
On Tue, Feb 25, 2025 at 8:50 AM Petr Pisar wrote: > V Mon, Feb 24, 2025 at 05:53:46PM +, Aoife Moloney via devel-announce > napsal(a): > > == Detailed Description == > > We are going to build OpenSSL without engine support. Engines are not > > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. > > The engine functionality we are aware of (PKCS#11, TPM) is covered by > > providers. > > Are providers FIPS compatible? > Some of them - yes. We have a dedicated FIPS provider, and also AFAIK PKCS#11 provider is FIPS-compatible to some extent. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)
On Tue, Feb 25, 2025 at 9:13 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 24/02/2025 18:53, Aoife Moloney via devel-announce wrote: > > We disable support of building engines in OpenSSL and remove the > > deprecated openssl-devel-engine subpackage. > > What happens if a third-party application (such as Steam) tries to > import and use ENGINE_ symbols from the shared library provided by > Fedora? Will it crash? > No. The symbols are kept in the library and the application should still be usable. This step prevents _building_ applications wit engine support. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Allow all packagers to push empty commits to any package
Hello, On Thu, Feb 20, 2025 at 2:27 PM Miro Hrončok wrote: > On 20. 02. 25 14:08, Dmitry Belyavskiy wrote: > > > > > > On Thu, Feb 20, 2025 at 1:17 PM Miro Hrončok > <mailto:mhron...@redhat.com>> wrote: > > > > > > What if we allowed all packagers to push empty commit to any > package? That > > should eliminate *some* need for provenpackager access. We would also > > communicate in our policies that such bumps do not require prior > agreement > > with > > the maintainers to avoid confusion about "what are we allowed to do". > > > > I don't like this idea. It will cause stupid rebases that are completely > missed > > until you suddenly have to push smth urgently and see that they can't > just merge. > > I have no idea what you mean by "stupid rebases" or "can't just merge". > > The commits are empty. Rebases are trivial. > Yes. If I forgot git pull before branching and I found it on fedpkg build stage, it distracts me on the main task. I agree that merge is trivial, BTW -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Allow all packagers to push empty commits to any package
On Thu, Feb 20, 2025 at 1:17 PM Miro Hrončok wrote: > > What if we allowed all packagers to push empty commit to any package? That > should eliminate *some* need for provenpackager access. We would also > communicate in our policies that such bumps do not require prior agreement > with > the maintainers to avoid confusion about "what are we allowed to do". > I don't like this idea. It will cause stupid rebases that are completely missed until you suddenly have to push smth urgently and see that they can't just merge. It's not a big deal for rawhide itself but if you use rawhide as a starting point to cherry-pick downwards, it's more problematic. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)
Dear Gary, On Wed, Feb 26, 2025 at 4:07 PM Gary Buhrmaster wrote: > On Wed, Feb 26, 2025 at 9:35 AM Daniel P. Berrangé > wrote: > > > Those are some high profile and/or important pieces of Fedora > functionality > > that seemingly depend on OpenSSL engines, and would (possibly[1]) need > fixing > > unless OpenSSL 3 is going to be kept in Fedora as a compat package in > parallel > > with OpenSSL 4 from F44 onwards ? > > While history may be different this time around, > openssl 1.x was kept around as a compat package > for around three years after openssl 3.x was > released (until after the major upstream dependent > packages had completed their migrations). AFAIK > no one has gone through and checked all the > current users of openssl 3.x in Fedora to see if > they are using deprecated functions, and have > opened PRs upstream to help those upstreams > remove those deprecated features, so the > transition could happen sooner than a few years. > Of course, your mileage will vary. > You are correct. But I would strictly separate deprecated functions and deprecated functions :) I'd expect that ENGINE will eventually be removed relatively soon (in 4.0), I'm not so sure about other deprecated API. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)
Richard, Many thanks for providing this list, I added it to the proposal On Tue, Feb 25, 2025 at 4:49 PM Richard W.M. Jones wrote: > On Tue, Feb 25, 2025 at 01:55:35PM +, Zbigniew Jędrzejewski-Szmek > wrote: > > 'fedrq wr -b rawhide openssl-devel-engine | wc -l' says 62. > > That list should have been in the proposal! Here it is anyway ... > > bind-32:9.18.33-1.fc43.src > boinc-client-8.0.2-2.fc42.src > cpprest-2.10.19-6.fc42.src > curl-8.12.1-1.fc43.src > dotnet8.0-8.0.113-1.fc43.src > erlang-26.2.5.9-1.fc43.src > fsverity-utils-1.6-2.fc42.src > fuse-encfs-1.9.5-24.fc42.src > gambas3-3.20.1-2.fc43.src > gdal-3.10.2-3.fc43.src > grpc-1.48.4-46.fc43.src > hitch-1.8.0-7.fc42.src > httping-3.6-2.fc42.src > kea-2.6.1-8.fc43.src > libcoap-4.3.5-7.fc42.src > minizip-ng-4.0.8-3.fc42.src > mosquitto-2.0.20-5.fc43.src > mstflint-4.25.0-8.fc42.src > myproxy-6.2.16-8.fc42.src > mysql8.0-8.0.40-3.fc42.src > nbdkit-1.42.0-2.fc43.src# I fixed this one yesterday > nextcloud-client-3.15.3-2.fc42.src > nrpe-4.1.3-2.fc42.src > ocspd-1.9.0-34.fc43.src > openssl-gost-engine-3.0.3-6.fc42.src > openssl-pkcs11-0.4.13-2.fc42.src > osslsigncode-2.9-3.fc42.src > pdns-4.9.3-1.fc42.src > pdns-recursor-5.2.0-2.fc42.src > poedit-3.5.2-3.fc42.src > proxygen-2025.02.03.00-1.fc43.src > pypy3.10-7.3.17-5.3.10.fc42.src > pypy3.9-7.3.16-4.3.9.fc42.src > pypy-7.3.17-2.fc42.src > qbittorrent-1:5.0.3-2.fc42.src > R-AsioHeaders-devel-1.22.1.2-2.fc42.noarch > rb_libtorrent-2.0.11-1.fc42.src > root-6.34.04-2.fc43.src > R-openssl-2.2.0-2.fc42.src > s2n-tls-1.5.10-2.fc42.src > sbsigntools-0.9.5-8.fc42.src > sendmail-8.18.1-5.fc42.src > sslsplit-0.5.5-16.fc42.src > strongswan-5.9.14-5.fc41.src > stunnel-5.74-2.fc42.src > systemd-257.3-7.fc43.src > tinc-1.0.36-15.fc42.src > tor-0.4.8.13-2.fc42.src > tpm2-tss-engine-1.2.0-7.fc42.src > trafficserver-9.2.6-1.fc42.src > trojan-1.16.0-27.fc42.src > uboot-tools-1:2025.04-0.4.rc2.fc43.src > ufdbGuard-1.35.8-5.fc43.src > uperf-1.0.8-6.fc42.src > websocketpp-0.8.2-17.fc42.src > wesnoth-1.19.9-1.fc43.src > workflow-0.11.7-2.fc42.src > wpa_supplicant-1:2.11-4.fc42.src > xca-2.7.0-2.fc42.src > xmms2-0.9.4-3.fc42.src > yadifa-2.6.7-2.fc42.src > znc-1.9.1-6.fc42.src > > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)
On Tue, Feb 25, 2025 at 12:04 PM Peter Boy Uni wrote: > > > > Am 25.02.2025 um 09:09 schrieb Alexander Bokovoy : > >> ... > >> == Detailed Description == > >> We are going to build OpenSSL without engine support. Engines are not > >> FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. > >> The engine functionality we are aware of (PKCS#11, TPM) is covered by > >> providers. The package necessary to build engines > >> (openssl-devel-engine) is already declared as deprecated and will be > >> removed. For the applications that still unconditionally refer to > >> openssl/engine.h we will provide a dummy engine.h file > > > > The side effect is that FreeIPA will lose support for DNSSEC until we > > are able to migrate to bind 9.19+ for bind-dyndb-ldap. > > > > ... In Fedora, however, > > this means we'd have to disable DNSSEC completely, even for existing > > deployments. > > From the point of view of the Fedora Server Edition Working Group, this is > a no-go! And what is the reason to not move forward to bind 9.19+? Let me repeat. OpenSSL 4.0 without engine support will be here in, I'd say, F44, and compat package will not help you to _build_ the packages depending on engines. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Problems pushing OpenSSH to f42
Dear Petr, Thank you for the investigation! I think it happened because the build happened during the freeze. On Wed, Mar 19, 2025 at 9:24 AM Petr Pisar wrote: > V Wed, Mar 19, 2025 at 08:37:44AM +0100, Dmitry Belyavskiy napsal(a): > > Dear colleagues, > > > > I've built openssh for f42 fixing the latest CVEs a month ago [1]. > > > > The build has passed the gating tests and has positive karma. But it > can't > > be pushed for a while with diagnostics > > > > FEDORA-2025-1e92156b24 ejected from the push because "Cannot find > relevant > > tag for openssh-9.9p1-9.fc42. None of ['f42-updates-candidate', > > 'f42-updates-testing-pending', 'f42-updates-pending'] are in > > ['epel9-next-testing', 'epel10.1-testing', 'eln-updates-testing', > > 'epel8-testing', 'epel9-testing', 'f40-container-updates-testing', > > 'f41-container-updates-testing', 'f41-updates-testing', > > 'f42-updates-testing', 'f40-flatpak-updates-testing', > > 'f40-updates-testing', 'f42-container-updates-testing', > > 'f42-flatpak-updates-testing', 'f41-flatpak-updates-testing', > > 'f43-container-updates-testing', 'epel10.0-testing', > > 'f43-flatpak-updates-testing', 'f43-updates-testing']." > > > > Could anybody please resolve this situation? > > > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2025-1e92156b24 > > > That build was never in testing (f42-updates-testing): > > $ koji list-history --build openssh-9.9p1-9.fc42 > Tue Feb 18 15:34:51 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-candidate by dbelyavs [still active] > Tue Feb 18 15:35:54 2025 openssh-9.9p1-9.fc42 tagged into > f42-signing-pending by bodhi > Tue Feb 18 15:36:49 2025 openssh-9.9p1-9.fc42 untagged from > f42-signing-pending by autosign/autosign02.iad2.fedoraproject.org > Tue Feb 18 15:36:49 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-testing-pending by autosign/autosign02.iad2.fedoraproject.org > [still active] > Wed Feb 19 10:45:06 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-pending by bodhi > Sat Mar 15 01:15:22 2025 openssh-9.9p1-9.fc42 untagged from > f42-updates-pending by bodhi > Sat Mar 15 01:24:07 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-pending by bodhi > Sun Mar 16 01:14:11 2025 openssh-9.9p1-9.fc42 untagged from > f42-updates-pending by bodhi > Sun Mar 16 01:18:29 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-pending by bodhi > Mon Mar 17 01:14:10 2025 openssh-9.9p1-9.fc42 untagged from > f42-updates-pending by bodhi > Mon Mar 17 01:15:27 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-pending by bodhi > Tue Mar 18 01:14:14 2025 openssh-9.9p1-9.fc42 untagged from > f42-updates-pending by bodhi > Tue Mar 18 01:17:59 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-pending by bodhi > Wed Mar 19 01:14:13 2025 openssh-9.9p1-9.fc42 untagged from > f42-updates-pending by bodhi > Wed Mar 19 01:18:21 2025 openssh-9.9p1-9.fc42 tagged into > f42-updates-pending by bodhi [still active] > > Which is what bodhi complains. Bodhi history indicates that the build was > auto-pushed to stable just after receving first karma point: > > Comments: bodhi - 2025-02-18 14:34:51 (karma 0) > This update was automatically created > bodhi - 2025-02-18 14:34:53 (karma 0) > This update's test gating status has been changed to 'waiting'. > bodhi - 2025-02-18 15:20:55 (karma 0) > This update's test gating status has been changed to 'failed'. > bodhi - 2025-02-18 16:28:03 (karma 0) > This update's test gating status has been changed to 'waiting'. > bodhi - 2025-02-18 16:50:04 (karma 0) > This update's test gating status has been changed to 'passed'. > pbrobinson - 2025-02-19 09:44:32 (karma 1) > Works fine > bodhi - 2025-02-19 09:44:42 (karma 0) > This update has been submitted for stable by bodhi. There is an > ongoing freeze; this will be pushed to stable after the freeze is > over. > > Web interface reads: > > Autopush Settings > Stable by Karma disabled > > Thresholds > Minimum Karma +1 > Minimum Testing 3 days > > So Bodhi violated its own rules. > > Try retracting the push request for stable and request a push to testing > instead > and after tagging it into f42-updates-testing, try requesting to stable > again. > Alternatively, raise a ticket for relengs to tag the build manually. Pushed to testing, thanks -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
