Re: Unorphan dovecot-fts-xapian
Hi Ed, > On 27. Sep 2024, at 18:49, Ed Marshall wrote: > > Oh look, that's my copr. No complaints here! :) > > (I'd have taken it myself, but didn't know if I'd have time to commit to it > if it broke.) That’s why you were on Cc. Actually, now that you replied already… would you mind doing a package review for it at https://bugzilla.redhat.com/show_bug.cgi?id=2315641? I just learned that that’s required since the package has been orphaned for more than 8 weeks. -- 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
Unorphan dovecot-fts-xapian
Hi, I’m planning to unorphan dovecot-fts-xapian. Upstream seems to be maintained, I have the latest version building locally, and I’m also apparently not the only person interested given there’s a recent COPR [1] for it. Unless somebody complains, I’ll build new versions later today. [1]: https://copr.fedorainfracloud.org/coprs/logic/dovecot-fts-xapian/package/dovecot-fts-xapian/ -- 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
Re: Anyone with powers to bump/rebuild nss?
Hi Bojan, > On 7. Aug 2024, at 21:07, Bojan Smojver via devel > wrote: > > Hi folks, > > Looks like regular nss maintainer may be away and new Firefox requires a > higher nss version than currently built. There is a pull request lined up, so > one just needs to merge, build and create the update in bodhi. > > Anyone with sufficient powers around to do this? What made you come to the conclusion that the regular NSS maintainer is away? NSS in Fedora is maintained by the RHEL crypto team, and both Bob and Frantisek who work on NSS are currently very much in the middle of doing the required NSS rebase in Fedora, CentOS Stream, and RHEL. -- 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
Re: Fedora rawhide (to be f41) and openssl engines
Hi, > On 23. Jul 2024, at 16:36, Gary Buhrmaster wrote: > > On Tue, Jul 23, 2024 at 8:55 AM Clemens Lang wrote: > >> However, we should still consider the effect this will have on developers >> that build software on Fedora — they will also have to specify >> -DOPENSSL_NO_ENGINE now or see failing builds, and we don’t really see that >> impact until 41 releases. > > Or, perhaps, if they build locally, just > `dnf install openssl-devel-engine` > once and not have to worry about > changing their build recipes until > OpenSSL 4.0 (or later). > > That is certainly going to be a choice > some will make, and you should > always offer that as a possible > solution even if you wish it was not > used. Sure, people can do that, but they will just see an error saying that openssl/engine.h could not be found and start hunting for solutions. Let’s hope that until that happens, enough people have blogged about this (or Google has indexed this thread) to point them to potential solutions, because otherwise this will be a situation of “works on Ubuntu and everything else, but is just bad developer experience on Fedora”. We already saw a number of threads on the mailing list and a ticket reporting this precise situation. I guess from this thread it is pretty clear that there is no consensus on improving this for F41, so I’ll stop now. -- 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
Re: Fedora rawhide (to be f41) and openssl engines
Hi, > On 22. Jul 2024, at 20:42, Zbigniew Jędrzejewski-Szmek > wrote: > > At this point, this sounds like the best approach. > The problem is well understood and the build failures are trivially > resolved by adding a single BuildRequires line or a single define. > > If we start changing things again, some packages will already adapted > will need to adapt again, and overall there'll much more confusion. I won’t object to this, it’s overall less work for Dmitry and me. However, we should still consider the effect this will have on developers that build software on Fedora — they will also have to specify -DOPENSSL_NO_ENGINE now or see failing builds, and we don’t really see that impact until 41 releases. -- 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
Re: Fedora rawhide (to be f41) and openssl engines
Hi, > On 22. Jul 2024, at 16:32, Fabio Valentini wrote: > > On Mon, Jul 22, 2024 at 4:28 PM Clemens Lang wrote: >> >> Hi Neal, >> >> >>> On 22. Jul 2024, at 15:01, Neal Gompa wrote: >>> >>> The CentOS approach isn't a deprecation, it's flat out removal. It's a >>> completely different change. >> >> This isn’t correct. The headers are removed, but the ABI is still present in >> CentOS Stream, so it is not flat out removal. > > This is arguing about semantics, but probably the difference is that > packages in Fedora really MUST be kept in a state where they can be > rebuilt at any time, and removing the headers breaks that. It doesn't > break existing packages, but as soon as any changes need to be made to > any package that depends on those headers (or just a plain rebuild for > some other change in the distribution, or a mass rebuild), it *is* > equivalent to a removal. There are three cases: (1) packages that are broken now because they don’t yet depend on openssl-devel-engine and do not set OPENSSL_NO_ENGINE. (2) packages that have been fixed by adding -DOPENSSL_NO_ENGINE to CPPFLAGS (3) packages that have been fixed by adding a dependency on openssl-devel-engine If we change OpenSSL to define OPENSSL_NO_ENGINE by default, with an override available, that affects these three cases as follows: (1) now (hopefully, unless it’s an upstream bug) automatically don’t use ENGINEs, build should be fixed (2) no change, continues to build (3) continues to build, but stops using ENGINEs (but the maintainer would get a bug ticket about that from me, and then can set -DFEDORA_OPENSSL_STILL_USE_ENGINES) At no point would a package move to a state where it doesn’t build. (1) and (2) improve the situation for package maintainers. (3) is some extra work, but it’s also not fail-silent due to the ticket. The alternative is doing nothing, which means packages in (1) stay broken and need to be fixed by somebody, and everybody else gets to keep the -DOPENSSL_NO_ENGINE define or dependency on openssl-devel-engine in their specfiles. I think this would be a net improvement over what we currently have, but if others don’t agree, we can also just keep the current state and take it out on the backs of the maintainers that now have to deal with the -DOPENSSL_NO_ENGINE thing. -- 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
Re: Fedora rawhide (to be f41) and openssl engines
Hi Neal, > On 22. Jul 2024, at 15:01, Neal Gompa wrote: > > The CentOS approach isn't a deprecation, it's flat out removal. It's a > completely different change. This isn’t correct. The headers are removed, but the ABI is still present in CentOS Stream, so it is not flat out removal. For Fedora, we could change this to keep the headers and the binary support present, but define `OPENSSL_NO_ENGINE` unless a special preprocessor define overrides it. > 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. We’re happy to help maintainers that want to do this. We may do it ourselves for selected components. We will not fix every single use ourselves. -- 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
Re: Fedora rawhide (to be f41) and openssl engines
Hi Dima, > On 22. Jul 2024, at 13:34, Dmitry Belyavskiy wrote: > > 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. I believe the answer is yes. I’m working on making sure we catch all users of the ENGINE API and tell them about this change in https://bugzilla.redhat.com/show_bug.cgi?id=2296114. I’ve recently been pointed to https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes/, which explains the process to follow when mass-filing bugs. I don’t know whether there would be any specific other Fedora process we would have to follow — maybe others can chime in on this. -- 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
Re: nbdkit -> openssl-devel-engine build dependency
Hi Jonathan, > On 19. Jul 2024, at 18:13, Jonathan Wakely wrote: > > It's possible to find all packages in F40 (before openssl-devel-engine > was introduced) that depend on the ENGINE_cleanup symbol (or some > other symbol if there's a better one to check for), which will tell us > all the packages that were affected by this change. Then bugs can be > filed and each package can decide whether to add BuildRequires: > openssl-devel-engine to its spec or not. Once that's step is done, all > existing packages will be correct: they either don't use engines, > because they never needed them, or they opt-in to using them. Then > there will be no silent failures. Anything that isn't using them is > doing so intentionally, so not a "failure". > > For new packages that want to use engines, presumably somebody will > check that engine support is enabled when testing the functionality of > the new package. If they mess that up, that's a packaging bug and can > be fixed. > > So I really do think the way to fix this is to default to > OPENSSL_NO_ENGINE and simultaneously file bugs for all packages using > ENGINE_cleanup and tell them to decide whether to BuildRequires: > openssl-devel-engine. Correct, I just didn’t have the time to work on this yet. See https://bugzilla.redhat.com/show_bug.cgi?id=2296114 for some progress towards this. If anybody has automated tooling to mass-file Fedora tickets that I could re-use, pointers very welcome. -- 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
Re: nbdkit -> openssl-devel-engine build dependency
Hi Rich, > On 19. Jul 2024, at 16:42, Richard W.M. Jones wrote: > > Make sense! (I still have no idea what these "engines" are) ENGINEs are an API for OpenSSL to delegate certain operations (random number generation or cryptographic operations) to third-party modules. They have historically been used to implement PKCS#11 smartcard support (using the openssl-pkcs11 package) or hardware-accelerated cryptography (e.g., Intel QAT in the qatlib package). OpenSSL 3.0 has deprecated ENGINEs and introduced the concept of a provider instead. Simo Sorce and the RHEL crypto team have developed pkcs11-provider (same name in Fedora) for continued support of PKCS#11 smartcards, and others have been working on porting their use cases over. The advantage of providers over ENGINEs is that applications had to explicitly support ENGINEs for them to work. With providers, applications can be written in a way that they don’t care whether the private key is in a file or a smartcard. ENGINEs also use various differing code paths inside of OpenSSL, which often trigger subtle bugs and weird behavior. HTH, Clemens -- 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
Re: nbdkit -> openssl-devel-engine build dependency
Hi Jonathan,
> On 19. Jul 2024, at 16:28, Jonathan Wakely wrote:
>
> On Fri, 19 Jul 2024 at 15:21, Jonathan Wakely wrote:
>>
>> Agreed. Boost Asio will use openssl engine if the user wants it to,
>> and it will not use it if the user doesn't want it to. So Boost Asio
>> does *not* depend on openssl-engine. It leaves the decision up to the
>> users of asio headers.
>>
>> We should not force all users of boost-devel to install a deprecated package.
>
> It seems like the problem is that openssl assumes you want to use
> engines *unless* you explicitly define OPENSSL_NO_ENGINE. But the
> default is to assume you want them. Which is a problem when the
> headers and libs aren't installed by default.
>
> We can patch Boost.Asio like so:
>
> --- /usr/include/boost/asio/ssl/detail/openssl_types.hpp
> 2024-06-07 01:00:00.0 +0100
> +++ /tmp/openssl_types.hpp 2024-07-19 15:25:40.110115742 +0100
> @@ -22,7 +22,7 @@
> #endif // defined(BOOST_ASIO_USE_WOLFSSL)
> #include
> #include
> -#if !defined(OPENSSL_NO_ENGINE)
> +#if !defined(OPENSSL_NO_ENGINE) && __has_include()
> # include
> #endif // !defined(OPENSSL_NO_ENGINE)
> #include
>
> (and similarly in the other Asio ehaders that check OPENSSL_NO_ENGINE)
>
> This would mean that you can define OPENSSL_NO_ENGINE to disable
> engines, but they're automatically disabled if you don't have the
> header installed.
This has the problem of making this fail-silent.
Let’s consider this from the point of view of a package maintainer that wants
to continue supporting ENGINEs (e.g., because you want to support PKCS#11
tokens and cannot yet use the PKCS#11 provider, or want to use a different
OpenSSL ENGINE that has not yet been ported to the new provider model). If
Boost applies this patch, your package will silently stop supporting ENGINEs
until you declare a new dependency. Even worse, the package will now build with
engine support or without engine support depending on the build environment.
If this is what we want, we could have just declared `OPENSSL_NO_ENGINE` in the
OpenSSL headers.
See also https://bugzilla.redhat.com/show_bug.cgi?id=2296114, which is about
this problem and documents the situation nicely.
I still plan on looking into how to improve this situation, possibly by
scanning the entirety of Fedora rawhide for use of OpenSSL ENGINE symbols and
mass-filing tickets for these packages telling them I’ve silently disabled
ENGINE support and they need to add a pre-processor define if they want them
back, along with a change that defines OPENSSL_NO_ENGINE by default in the
OpenSSL headers.
> Even better would be for openssl/conf.h to do it:
>
> --- /usr/include/openssl/conf.h 2023-08-31 01:00:00.0 +0100
> +++ /tmp/conf.h 2024-07-19 15:27:57.513979007 +0100
> @@ -31,6 +31,10 @@
> # include
> # endif
>
> +#if ! __has_include()
> +# define OPENSSL_NO_ENGINE
> +#endif
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
That’s one potential way, thanks for the patch – however, it has the same
fail-silent problem.
--
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
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Hello Daniel, > On 5. Jul 2024, at 15:33, Daniel P. Berrangé wrote: > > It isn't listed there, but it certainly should be, as we've not > been considering it FIPS compliant, for precisely this reason. OK. I’ve asked our docs team to add it to the list. Thank you for bringing this to my attention. > FYI, disabling FIPS was done by the upstream maintainer, it isn't a > downstream change. We can’t force upstream to care about FIPS, but as RHEL downstream we should. This may occasionally mean shipping downstream changes or submitting patches to make such things configurable. -- 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
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Hi, > On 5. Jul 2024, at 14:49, Daniel P. Berrangé wrote: > > On Fri, Jul 05, 2024 at 02:37:41PM +0200, Clemens Lang wrote: >> >> >> Please start addressing this with whoever maintains the TPM specification. > > The TPM spec is maintained by the Trusted Computing Group, and I have > no influence there. You could try to bring it up with them, on a mailing list, for example. Have you tried? >> SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this >> change is already broken in FIPS mode, and the deprecation of SHA-1 will >> only continue to cause more and more problems. > > swtpm works around that be unconditionally disabling FIPS mode in openssl > already. > > This is fine, because the guest OS can put itself in FIPS mode, which > will prevent it from using the undesirable algorithms, even if the TPM > exposes them. No, this is a misconception. FIPS mode does not just disable algorithms, it also enables additional selftests and code paths, and changes the behavior of random number generators and key generation. If your guest OS is in FIPS mode and uses cryptography from swtpm, that cryptography is still not FIPS compliant, and you should not misrepresent it to be. In fact, we should probably add it to the list of packages that do not use FIPS compliant cryptography in RHEL at [1, 2] if it isn’t on there yet. Please don’t make such decisions (for RHEL) without talking to the crypto team. On Fedora, we don’t make any claims as to FIPS-ness of the operating system, so it’s fine there, but probably also not a great idea. >> An alternative is to run swtpm with OPENSSL_CONF in the environment >> pointing to an alternative openssl configuration file that re-enables >> SHA-1. You could maintain this configuration file together with swtpm. > > Can custom openssl config files "inherit" from the primary one. > ie can we have a config file that just references the primary, > while toggling only the sha1 setting, so we're not overriding > all the openssl config settings ? The OpenSSL configuration file format has an include directive, so you may be able to set this up. [1]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#ref_list-of-rhel-applications-using-cryptography-that-is-not-compliant-with-fips-140-2_using-the-system-wide-cryptographic-policies [2]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#ref_list-of-rhel-applications-using-cryptography-that-is-not-compliant-with-fips-140-3_using-the-system-wide-cryptographic-policies -- 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
Re: HEADS UP: openssl engine-related FTBFS and Boost
Hi, > On 5. Jul 2024, at 14:24, Peter Pentchev wrote: > > I wonder if it would be possible (of course it is technically possible, > more like how hard it would be) to make the OpenSSL devel package > conditionally define OPENSSL_NO_ENGINE if another package is > not installed. I can think of at least two ways to do that: > - alternatives (but maybe that's my Debian background talking) > - #include_next games That’s just -DOPENSSL_NO_ENGINE_BUT_ACTUALLY_I_REALLY_STILL_WANT_TO_USE_THIS_DEPRECATED_FUNCTIONALITY but with extra magic so package maintainers only have to add BuildRequires: openssl-devel-engine instead of adding a preprocessor define. It also has the same downside of silently disabling engines if the maintainer doesn’t check. -- 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
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Hi, > On 5. Jul 2024, at 12:38, Daniel P. Berrangé wrote: > > I've (re-)discovered that this change is going to impact on swtpm that is > used with QEMU to provide a virtual TPM to guests. > > The TPM2 specification has fully crypto agility, however, the sha1 > algorithm is one of the few that is declared mandatory to implement. > Though it is documented as deprecated by the spec, we need to provide > it to be compliant. Please start addressing this with whoever maintains the TPM specification. SHA-1 already doesn’t work in FIPS mode, so anything that breaks with this change is already broken in FIPS mode, and the deprecation of SHA-1 will only continue to cause more and more problems. See also https://fedoraproject.org/wiki/SHA1SignaturesGuidance#Cryptographic_immobility_or_outdated_standards. > The 'runcp' command is really particularly nice as a solution though. > Using that in a non-interactive scenario will require modifying the > software that launches swtpm to wrap its execution. Or we have to > replace the swtpm binary with a shell script that invokes the real > binary indirectly, which isn't especially nice either, as wrapper > shell scripts often require then changing the selinux policy to > allow their use. An alternative is to run swtpm with OPENSSL_CONF in the environment pointing to an alternative openssl configuration file that re-enables SHA-1. You could maintain this configuration file together with swtpm. > The change proposal talks about an API being added to openssl to > allow this to be changed programmatically, which is really what > I would like to see, so that swtpm can just request SHA1, as this > has the lowest impact. The upstream work on this is stalled, both due to my lack of time and upstream’s requests to change it fundamentally twice after I had working implementations. I wouldn’t rely on this showing up any time soon. I still want to eventually finish it, but until that happens and then gets released in a new OpenSSL version, this doesn’t exist. > Until that exists, however, I'm inclined > to just set OPENSSL_ENABLE_SHA1_SIGNATURES in swtpm startup, > despite the warnings not to do this. As announced, we’re going to break that without regard for whether you used it, and it won’t make a difference in FIPS mode. You should really use a separate openssl configuration file using OPENSSL_CONF instead, and start a discussion to get the TPM standard updated. -- 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
Re: HEADS UP: openssl engine-related FTBFS and Boost
Hi, > On 5. Jul 2024, at 12:10, Joe Orton wrote: > > On Tue, Jul 02, 2024 at 02:05:38PM +0200, Dmitry Belyavskiy wrote: >> 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. > > I really think this is silly. Looking at the Boost headers they already > conditionalize support for ENGINE *in the way that OpenSSL upstream > intended*. > https://www.boost.org/doc/libs/1_74_0/boost/asio/ssl/detail/openssl_types.hpp > > #if !defined(OPENSSL_NO_ENGINE) > # include > #endif // !defined(OPENSSL_NO_ENGINE) > > So, no, Boost should not be "fixed". should > simply "#define OPENSSL_NO_ENGINE" if you want Fedora packages to drop > ENGINE support. We have broken the way Fedora packages consume the > OpenSSL API - it should be reverted, we're just heaping unnecessary work > on other package maintainers. I’m sure Dmitry would be happy to do that if we as a community could agree to no longer support OpenSSL ENGINEs, but it doesn’t seem that this consensus exists in Fedora. This leaves us with deprecating ENGINEs to give package maintainers a transition period. Should we instead cook up a patch that requires packages that still want to continue use of engines to set an additional preprocessor flag? With a patched openssl/engine.h we could probably make a -DOPENSSL_NO_ENGINE_BUT_ACTUALLY_I_REALLY_STILL_WANT_TO_USE_THIS_DEPRECATED_FUNCTIONALITY work. Personally, as the maintainer of stunnel, I also didn’t enjoy the extra busy work this change forced my to do for a package that did already correctly respect OPENSSL_NO_ENGINE. However, the above alternative would have silently disabled engine support, and other package maintainers might not be a fan of that, either. One alternative is fail-loudly with work for maintainers that just want to follow the decision, the other is fail-silent with work for maintainers that want to continue using engines. Which ones is better? -- 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
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
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
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Hi, > On 10. Jun 2024, at 20:16, Richard W.M. Jones wrote: > > 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? I’m pretty sure Alex was planning to keep SHA-1 signatures working in the LEGACY policy, or even DEFAULT:SHA-1 (as it currently is on RHEL 9). It isn’t explicitly spelled out in the proposal. What the proposal does say, though, is that you can use FEDORA40 as policy. > 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. See this text in the proposal (emphasis mine): Users that need the previous behaviour and don't mind the security implications will be able to revert to the old behavior system-wide (update-crypto-policies --set FEDORA40) or ***per-process (runcp FEDORA40 command args, requires a copr-packaged tool)***. -- 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
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Hi Björn, > On 9. Jun 2024, at 00:37, Björn Persson wrote: > > 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 That’s correct. There is some movement at the IETF, though. See [1] and thread. I’d also like to specifically point to [2], which I think sums up the discussion nicely. DNSSEC is a holdout, it feels like almost everybody else has moved by now to address the insecurity of SHA-1 in signatures. As you’ll also notice from the thread, there are a few voices that feel like we should not yet deprecate SHA-1 while it has not been completely broken. There have been publications that say that DNSSEC is actually affected today if control over a zone is (even just partially) shared, see [3]. Personally, I don’t believe in waiting until the cat’s out of the bag if it will be in the foreseeable future. I’m quoting Leurent and Peyrin, who wrote the SHA-1 is a Shambles paper [4] in 2020: "Since our attack on SHA-1 has pratical [sic] implications, in order to make sure proper countermeasures have been pushed we will wait for some time before releasing source code that allows to generate SHA-1 chosen-prefix collisions.” [5] I believe hoping that Leurent and Peyrin will continue to sit on their code for another 5 years isn’t a good strategy (remember, the paper is from 2020(!)). I’m hoping the DNSSEC community will realize this soon. [1]: https://mailarchive.ietf.org/arch/msg/dnsop/gp7caSkWA9ureUStNuXtCpGmGss/ [2]: https://mailarchive.ietf.org/arch/msg/dnsop/XopFnthm0nFWrJ_z1tJYUoBwxrU/ [3]: https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/ [4]: https://eprint.iacr.org/2020/014.pdf [5]: https://sha-mbles.github.io/ > 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 > > […] > > 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. To my knowledge, DNS resolvers in RHEL and their upstreams have been adjusted to handle this, since RHEL 9 shipped with this configuration. Are there DNS resolvers in Fedora that aren’t in RHEL? > Will SHA-1 signatures be treated as invalid signatures, causing the > resolver to return SERVFAIL? That will violate RFC 8624 and make users > scramble for quick workarounds. Many will apply far too big hammers, > such as disabling DNSsec validation entirely or switching their whole > system to the LEGACY policy just to be able to resolve a domain name > signed with SHA-1. In this case it should be announced far and wide how > users can unbreak DNS without weakening the security of the rest of > their system. Otherwise this change could easily do more harm than good. As far as I’m aware, the patches caused DNS resolvers to simply treat those zones as if they were unsigned. > 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. DNS resolvers can write code to do this. This proposal does not completely remove support for SHA-1 in signatures, it just disables it by default. Non-standard OpenSSL configurations can still verify SHA-1 signatures. Hopefully the DNSSEC community will start discussions on what to do about post-quantum cryptographic signature algorithms soon, otherwise we’ll end up having the same discussion again in 10 years, when TLS and many other common protocols have moved. -- 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-c
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Hi Vitaly, > On 9. Jun 2024, at 09:15, Vitaly Zaitsev via devel > wrote: > > On 08/06/2024 00:43, Aoife Moloney wrote: >> OpenSSL will no longer trust cryptographic signatures using SHA-1 by >> default, starting from Fedora 41. > > What about Git? AFAIK, AFAIK, Git heavily uses both SHA-1 and SHA-2 to > validate objects and commits. Just to make sure: This proposed change does *not* disallow the use of SHA-1 for hashing (which is what git does). It only prevents the use of SHA-1 for signing and signature verification. Git’s signature support [1] uses the OpenPGP packet format, which can (and in practice likely does) contain a different hash of the signed content, over which it creates a signature, so even commits with a SHA-1 commit ID can be signed in a fashion that will continue to validate with this change. -- 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
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Hi, > On 2. Apr 2024, at 16:31, Luca Boccassi wrote: > > 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. 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. There will always be some effort related to such a transition, but that effort will have to happen one way or the other eventually. I suspect if Fedora decides to keep ENGINE support, we’ll have the exact same discussion in a few years when OpenSSL 4.0 is released, and people will demand that the rebase to 4.0 that removes engine support should be a system-wide change proposal because it breaks engines. -- 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
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Hi Jan, > On 21. Mar 2024, at 14:28, Jun Aruga (he / him) wrote: > > > * 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) As I understand that ticket, the functionality exists in OpenSSL, but ruby OpenSSL module does not expose it. In any case, some providers are also providing workarounds for this problem. See for example https://github.com/latchset/pkcs11-provider/pull/328, which allows the PKCS11 provider to work everywhere where a simple PEM private key file is currently supported. With this, the Ruby OpenSSL module has all the time in the world to make the transition. -- 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
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Hi, > On 20. Mar 2024, at 18:11, Joe Orton wrote: > > On Wed, Mar 20, 2024 at 02:05:52PM +, Daniel Berrange wrote: >> 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. > > This is a really good idea, I hope Daniel's comment is not lost here. It isn’t, we are very much aware of this possibility and have already discussed it before. The ENGINE API is a source of subtle bugs especially when used together with providers, though, so we would really prefer to disable it completely rather than keeping it around. PKEY objects backed by an ENGINE use a number of different lesser tested code paths in the OpenSSL source code, which lead to all sorts of weird an inconsistent behavior. > On 20. Mar 2024, at 16:07, Zbigniew Jędrzejewski-Szmek > wrote: > > Sorry, but the idea to drop symbols without changing the SONAME > must be rejected. If upstream plans to drop the symbols for 4.0, then > that is OK, assuming that the SONAME is bumped then. This does already not match reality. OpenSSL provides a number of symbols that are dependent on compile-time options. Take a look at [1, 2]. Every symbol in there that is tagged with EXIST::FUNCTION followed by a string that is not DEPRECATEDIN_3_0 is only present when the associated configure-time option is enabled. For example, an OpenSSL configured with no-des will not provide the DES_xcbc_encrypt symbol. The assumption that one specific SOVERSION of OpenSSL will always contain the same symbols on all operating systems is thus incorrect. Obviously this is not a change that can be made during the lifetime of a specific Fedora release, but ahead of a mass rebuild, it should be doable to land a change such as this without changing the SONAME, considering the problem you want to avoid with the SONAME bump *already* exists between different builds of OpenSSL with different configuration. [1]: https://github.com/openssl/openssl/blob/master/util/libssl.num [2]: https://github.com/openssl/openssl/blob/master/util/libcrypto.num -- 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
Re: do we need CONFIG_UPROBES=y in our kernels?
Hi, > On 12. Feb 2024, at 19:15, Marius Schwarz wrote: > > In a german developer blog article was the topic raised, that with uprobes > enabled, userland apps can i.e. circumvent tls security(and other > protections), > by telling the kernel to probe the function calls with the uprobes api. As > this enables i.e. the hosting system of a vm or container, to track activity > inside the container, trust is lost i.e. from customer to hoster. To be fair, > you need to be root on the host to do this, but as it "wasn't possible > before", and it is "now" ( out in a greater public ), it tends to create > trust issues, just for being there*. How was this not possible before? If I’m root on the host, I could always start a gdb and attach it to a process running in a container. I could also always have replaced a file in the container (e.g., the libssl.so library with an instrumented one that just writes the TLS communication in clear text into a pipe). On a kernel with /dev/mem, the host could probably have located the encryption keys directly in memory, too. It really sounds to me like the incorrect assumption here is that the host was not already able to do these things. If you don’t trust your host, look into confidential computing and confidential containers. Those also don’t solve every single problem, but they get you closer. -- 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
Re: Figure out what killed an app (rhbz#2253099)
Hey, > On 31. Jan 2024, at 16:24, Petr Pisar wrote: > > Key information is code=128. That code is probably si_code member described in > sigaction(2). The manual lists a lot of values as constants. 128 value is > SI_KERNEL according to /usr/include/asm-generic/siginfo.h. It is documented > as "sent by the kernel from somewhere". It means the first signal does not > come a user space. It's genuinly generated by kernel. E.g. when the process is > killed for out-of-memory reason. However, in this case, I would expect kernel > to log this event into dmesg. E.g. out-of-memory killer is very verbose in > dmesg. > > Strange thing is the second line. It reads that process 3211 (code=0 meads > SI_USER, "sent by kill, sigsend, raise") sent SIGKILL to 3257. It's > questionable how a process 3211 killed with the first signal can still emit > signals. A possible explanation is that the signals are procecessed > asychnously and evolution manages to dispatch the signal to bwrap before > kernel > termites evolution because of the first signal. Or I misinterpret the > log. Throwing some ideas out there, is it possible that evolution runs with a seccomp filter or other BPF program configured to kill the process on violation, and that’s what’s happening here? For software that regularly deals with untrusted input, it doesn’t seem unreasonable that the developers might have implemented something like that, and a seccomp kill might actually look like that. -- 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
Re: Intention to tighten RPM crypto-policy back
Hi, > On 28. Sep 2023, at 14:06, Panu Matilainen wrote: > > On 9/27/23 20:37, Alexander Sosedkin wrote: >> >> In fact, even Chrome can't be installed with the change properly reverted. >> Guess I'll have to shelve the wide discussion for a while, we aren't ready. >> =( > > AIUI the current issue with Chrome is more that they still include the old > SHA-1 based key in their repo along with the newer one in a way that confuses > rpm. Yes, I think that’s what’s happening here. Alex filed https://bugzilla.redhat.com/2241019 about this. I think the importer should be modified to attempt to import all keys in a file and ignore those that fail. The other alternative is that all keys should be imported regardless of whether they will be considered usable for verification, and verification of RPMs will later fail if those keys are used. -- 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
Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
Hi Leon, > On 24. Jun 2023, at 19:44, Leon Fauster via devel > wrote: > >> I will also point out that CentOS Stream is perfectly suitable for >> production use, and I would argue it provides a differentiated > > Nope, its not perfect for production use. Just an example of _many_: > > https://bugzilla.redhat.com/show_bug.cgi?id=2184640 Apologies for this particular one. We thought we had everything covered in this area, but we messed up and our tests didn’t catch this before it exploded into our faces. Rest assured it wasn’t because we were trying to use the community as guinea pigs; we ourselves were surprised by the fallout, and have been working internally with the maintainers of our signing keys to get this resolved. That work is still ongoing, but we will probably delay disabling SHA-1 in PGP use until CentOS Stream 10/RHEL 10. -- 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
Re: What happen kup in Fedora 37
Steve Dickson wrote: I'm trying to access kernel.org with kup script but it does not seem to be in Fedora 37. The only rpm I can find is kup-0.3.6-11.fc36.rpm. What am I missing?? The package has been orphaned and retired: https://src.fedoraproject.org/rpms/kup If you want to unretire and maintain it, see https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package -- Clemens ___ 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: fkinit -u instructions
Hi, Kenneth Goldman wrote: -Original Message- From: Clemens Lang Sent: Tuesday, February 14, 2023 12:59 PM To: Development discussions related to Fedora You are right, but fkinit will tell you, so I don’t think we need to clarify this in the documentation: :) cllang@frootmig:~$ fkinit -u clang Enter your password and OTP concatenated. (Ignore that the prompt is for only the token) Enter OTP Token Value: :) cllang@frootmig:~$ For a newbie (me), it's not clear what the OTP is. Is it something from here? https://accounts.fedoraproject.org/user/kgold/settings/otp/ Yes. If correct, might a link be useful, along with some guidance on then to use it? If you have two-factor authentication enabled on this page (or always?), it will display the following message: Additional configuration is required when using Kerberos tickets when OTP is enabled Read the documentation for details on configuring your system “documentation” is a link to https://docs.fedoraproject.org/en-US/fedora-accounts/user/#pkinit. As a user, you should thus never end up in a situation where you have two-factor authentication enabled, but have not read this documentation. (Additionally, we should probably update this documentation to also explain that fkinit can be used.) It is a bit unfortunate that fkinit always prints the "Enter your password and OTP concatenated. (Ignore that the prompt is for only the token)” line even for users that do not have OTP enabled, though. Compare: $ fkinit -u clang Enter your password and OTP concatenated. (Ignore that the prompt is for only the token) Enter OTP Token Value: with $ fkinit -u jjelen # shamelessly calling you out for not having 2FA enabled! Enter your password and OTP concatenated. (Ignore that the prompt is for only the token) Password for jje...@fedoraproject.org: kinit: Password read interrupted while getting initial credentials Since there seems to be some API that can be used without authentication to determine whether a user has two-factor authentication enabled, maybe fkinit should query that API, and only show that hint when used with an account that actually uses it to avoid confusion? -- 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
Re: fkinit -u instructions
Hi Adam, Adam Williamson wrote: On Tue, 2023-02-14 at 16:35 +, Kenneth Goldman wrote: Yes, much better, thanks. Someone posted that the prompt for an OTP can be ignored and that the Fedora password is enough. IIRC, if you *have* an OTP, you have to include it. If you *don't* have one, of course you just put your password. We should make this clear too (assuming I'm right). You are right, but fkinit will tell you, so I don’t think we need to clarify this in the documentation: :) cllang@frootmig:~$ fkinit -u clang Enter your password and OTP concatenated. (Ignore that the prompt is for only the token) Enter OTP Token Value: :) cllang@frootmig:~$ HTH, Clemens -- 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
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
Hi, Alexander Sosedkin wrote: In RPM world, I've even entertained an idea of having a subpackage for auditability not unlike how we have debuginfo, since rebuilding a package reproducibly requires builddep pinning. But if that's avoidable, I’d rather just not mix artifacts with meta. Debian is working on this already, they call those “buildinfo” files: https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles https://manpages.debian.org/testing/dpkg-dev/deb-buildinfo.5.en.html If we want something similar, I’d propose not to completely re-invent the wheel. HTH, Clemens ___ 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: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)
Hi everyone, Ben Cotton wrote: Neither change is trivial to implement because introducing errors for these constructs (as required by C99) alters the result of autoconf configure checks. Quite a few such checks use an implicitly declared `exit` function, for instance. These failures are not really related to the feature under test. If the build system is well written, the build still succeeds, the relevant features are automatically disabled in the test suite and removed from reference ABI lists, and it's not immediately apparent that feature is gone. Therefore, some care is needed that no such alterations happen, and packages need to be ported to C99. Various tools for this porting activity are being developed to support this proposal. Cross-distribution collaboration will help as well, sharing patches and insights. I may have some good news here: When Apple started shipping arm64 hardware, it switched its system compiler to always treat implicit function declarations as errors. Apple engineers did that because the calling ABI for variadic functions on arm64 differs from that of non-variadic functions, so a declaration is required to determine the correct code to generate. As a consequence, the various macOS package managers have been working on identifying and fixing these autoconf issues for a while now. Obviously, there is a lot of Linux-specific software that nobody will have fixed yet, and the package set may be smaller in the macOS package managers, but commonly used software is probably already fixed. HTH, Clemens -- 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
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Hi Ben, Ben Cotton wrote: Within Fedora package set, this has no impact as everything is already using sufficiently strong crypto. Third party repositories / packages could be signed with insecure crypto, and those may require working around with --nosignature. However this incidentally overlaps with https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 which has effectively the same effect on rpm. Note that the StrongCryptoSettings3Forewarning2 proposal recently failed to gather enough votes to be accepted, so it will likely not be happening (or not in this form) for Fedora 38. Additionally, crypto-policies would have supported switching to LEGACY to allow installation of non-conforming RPMs, so you should at least provide a method to also install such old RPMs, ideally while still verifying the old SHA-1 signature rather than ignoring it completely. HTH, Clemens -- 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
Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)
Hi, Kevin Kofler wrote: Clemens Lang wrote: Note that we’re discussing moving openssl to a src-git approach, so it should eventually become much easier to see the relation between upstream code and our downstream copy. At that point, you have the patent-encumbered files in your (src-)git history. I do not think the src-git approach is legally possible at all for these packages, at least not based on upstream git. See Simo’s mail: we are working towards removing hobbling and replacing with compilation switches that clearly and permanently disable questionable material in the binaries. HTH, Clemens -- 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
Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)
Hi,
Michael J Gruber wrote:
Understanding is helped greatly by communication, though. Legal answers
such as "We can not" do not further this understanding, and "We can not
and we can not tell you why" is not much better, but these are the typical
answer we get, not even with a "sorry, but we can't". Obviously, these
legal questions are difficult to explain, but it can't be true that each
such case is under a "gag order”.
A lawyer at a previous employer told me that explanations of such decisions
can be used against you in court. Presumably, this also applies here.
The other big issue are our hobbled sources: We cannot store some original
sources in the look-aside cache, obviously. But packages such as openssl
do not even specify a hash nor an url for the un-hobbled sources. This
makes it unncessarily difficult to verify that our openssl package has
indeed been built against against the hobbled version of the original
sources - for a package like openssl this really is a trust issue (and
might even violate our packaging guidelines, but I'm not a lawyer…).
As one of the people that has previously generated one of the hobbled
tarballs you consider a potential trust issue: The hobbled tarball is the
upstream tarball for the particular release we ship after we extract it, run
./hobble-openssl (which you’ll find in the package) and repack it.
Feel free to replicate this process and compare the output to check that we
haven’t smuggled anything else into it.
Note that we’re discussing moving openssl to a src-git approach, so it
should eventually become much easier to see the relation between upstream
code and our downstream copy.
As a side effect, it makes it unnecesarily difficult to rebuild the
package locally (though it does not effectively inhibit it either, of
course; it is not an "effective measure" for that cause). I do understand
that providing a functional link can be construed to be “redistribution”,
but in the context of a spec file, a comment really is a reference to the
"source of the source", without which we cannot even claim to distribute
the hobbled version legally (and without which we have no trust chain).
Are you suggesting we add a comment that contains the URL to the upstream
tarball? I don’t think we’d have a problem with that. However, we probably
wouldn’t want to update it for every rebase, and a comment with a %{version}
macro might not be very helpful either.
I also don’t agree that not including the URL to the upstream tarball makes
a local rebuild unnecessarily difficult. If you replace the Source in the
specfile with the upstream tarball URL and remove ec_curve.c and octets.c,
the package should build just fine. How would you prefer we simplified this?
--
Clemens
___
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: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam
Hi, Kevin Kofler via devel wrote: If the default crypto policies fail with the world's largest WiFi network, then surely they are too strict to be useful in practice and need to be relaxed. It may be the world’s largest WiFi network, but authentication is delegated to the various institutions. The TLS server that handles authentication is probably run by this user’s university IT department, and their server does not support modern TLS. I hope you’re not suggesting we keep the defaults insecure because there are some institutions out there that don’t support modern standards. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Richard W.M. Jones wrote: I somehow thought that loading the legacy provider would be the same as the LEGACY crypto policy, except just for Python 2.7 rather than for the entire system. It’s a common misconception. So common that I recently wrote a blog post to explain the difference: https://www.redhat.com/en/blog/legacy-cryptography-fedora-36-and-red-hat-enterprise-linux-9 Setting the whole system crypto-policy to LEGACY (and reverting the code for loading the legacy provider) fixes almost everything. Thanks for testing and confirming that. In that case, it’s really just a case of running the test with a separate OpenSSL configuration file that applies weaker defaults. HTH, Clemens -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Hi, Richard W.M. Jones wrote: On Mon, Jun 27, 2022 at 09:11:29AM +0100, Tom Hughes wrote: On 27/06/2022 08:53, Richard W.M. Jones wrote: On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: Dear Richard, If the only problem is legacy (and unsafe) ciphersuites, loading the legacy provider will solve this problem. Any clues on how to do that? https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers Results unclear. Loading legacy + default doesn't seem to give any errors, but I still see the same errors in the tests. I might be loading these providers in the wrong way however. The code is here: https://github.com/rwmjones/cpython/commits/python-2.7-openssl-3 Two comments: Most of your failures are "no suitable signature algorithm” and “no shared ciphers”. I suspect those might instead be caused by increased minimum TLS versions enforced by the crypto-policy. Did you try running those tests in the LEGACY crypto-policy? If that’s the issue, you don’t need to load the legacy provider, and doing so doesn’t actually help. I know the OpenSSL upstream documentation says so, but please don’t load the legacy provider into the NULL OSSL_LIB_CTX. Doing so activates the legacy provider for all code in the same address space by default. This means, for example, that applications that embed a Python interpreter will inherit its use of the legacy provider, even if they don’t want to. See [1] for further discussion of this issue, and examples on how to avoid it. [1] https://github.com/lsh123/xmlsec/issues/339 HTH, Clemens -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
Hi, Kevin Kofler via devel wrote: I think we need a REALLY_LEGACY that continues allowing MD5 and the like. According to https://github.com/corkami/collisions#chosen-prefix-collisions, a chosen-prefix collision on MD5 took 72 hours to compute in 2009. 13 years later, you really should treat anything that still uses MD5 as if it was completely unsigned. I’m almost tempted to invest some CPU/GPU time to compute a MD5 hash collision of your message to prove the point. I don’t believe this would be in the best interest of our users. Setting a crypto-policy to REALLY_LEGACY would basically mean “I don’t care about encryption”. In these cases, why not just use plain HTTP, or other unencrypted protocols instead? -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
Hi, On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote: Changes like this have been very disruptive in the past because they haven't been completely thought through. Can we please make 100% sure these policies are not going to break things like VPN clients in the way that we have before. This is the reason why the proposal contains extensive methods to test whether things are going to break by modifying the crypto-policy or using bpftrace. Unfortunately there are hundreds of packages that depend on cryptographic libraries, and millions of different configurations out there. We can’t know ahead of time which ones of them are going to break, but the proposal provides tools and a long transition period to identify and fix them. Dan Čermák wrote: They are going to break things, but Ubuntu 22.04 deprecated SHA1 signatures already, so it's very likely that a good chunk of the fallout will be cleared by the time Fedora 38 and 39 ship. This isn’t going to help our cause, but this isn’t correct from what I can see. The Ubuntu 22.04 release notes [1] say: "In particular, certificates using SHA1 or MD5 as hash algorithms are now invalid under the default security level.” Note that this only affects *certificates*, while our changes affect *all signatures made with SHA1*, not just those in certificates. I’ve also checked the published source package for Ubuntu, and it seems they are just setting SECLEVEL to 2 plus raising the default TLS version to 1.2 when SECLEVEL is 2. In conclusion: Ubuntu isn’t ahead of us here. [1]: https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668 -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Problem with SSL in Fedora 36
Hi, José Abílio Matos wrote: After today's update to openssl-1:3.0.2-4.fc36.x86_64 the problem is gone. :-) This means your mail server does not support TLS 1.2. You will have to keep your system set to crypto-policy LEGACY to connect to the server. I would recommend contacting your mail server administrator and asking them to support modern TLS versions. HTH, -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
Hi Stephen, Stephen Gallagher wrote: On Wed, Apr 6, 2022 at 10:43 AM Stephen Gallagher wrote: I put together a potential solution for testing this in ELN and submitted an MR: https://src.fedoraproject.org/rpms/crypto-policies/pull-request/10 It's a little bit heavy-handed of an approach, but it should work. Please keep in mind that Fedora’s openssl package currently does not have the patches that introduce the rh-allow-sha1-signatures option that would be required to do this. Merging your pull request without this change will cause all binaries that use OpenSSL 3.x (1.1 will ignore it) to fail to start. See https://bugzilla.redhat.com/show_bug.cgi?id=2070977 which tracks implementing this. If you want to disable SHA-1 by default in ELN, we should probably also have an option to re-enable it using an environment variable for package build and test execution purposes. I’ll start working on this now. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
> On 16. Mar 2022, at 00:04, Tom Hughes via devel > wrote: > > On 15/03/2022 22:45, Robert Relyea wrote: > >> 1) in fedora 37, provide a policy that turns SHA-1 off. in our testing, we >> encourage people to run with that policy and write bugs against components. > > That policy already exists in Fedora 34 and 35 where the FUTURE policy > does not allow SHA1 in signature algorithms. In the case of OpenSSL, that only affects use of SHA1 as signature algorithms in TLS. It does not cover arbitrary signatures with a SHA1 digest, which is what we are proposing. HTH, Clemens -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
