On Tue, Jun 23, 2026 at 01:53:14PM -0400, Simo Sorce wrote: > On Tue, 2026-06-23 at 16:53 +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 23, 2026 at 09:58:16AM -0400, Simo Sorce wrote: > > > On Tue, 2026-06-23 at 11:31 +0100, Daniel P. Berrangé wrote: > > > > On Tue, Jun 23, 2026 at 12:04:25PM +0200, Fabio Valentini wrote: > > > > > On Tue, Jun 23, 2026 at 10:57 AM Alexander Sosedkin > > > > > <[email protected]> wrote: > > > > > > > > > > > > On Tue, Jun 23, 2026 at 12:46 AM Gordon Messmer > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Fedora's crypto policies say that I should talk to crypto-team > > > > > > > about > > > > > > > adding a new crypto library to Fedora, and refers to a mailing > > > > > > > list > > > > > > > which requires membership to send messages. > > > > > > > > > > > > Huh, that doesn't sound right to me indeed, > > > > > > one should be able to just send emails to it. > > > > > > > > > > FWIW I had the same experience. Sending emails to this list was > > > > > equivalent to sending them to /dev/null. > > > > > > > > Is the list even working ? The archives are restricted so not visible > > > > if you don't login (why can't they be public ?), and once logging in, > > > > the archives appear to be completely empty. Has archiving been > > > > disabled ? > > > > > > > > > > > > https://lists.fedoraproject.org/archives/list/[email protected]/ > > > > > > > > > As for AWS-LC support in Fedora - I have been waiting for a definitive > > > > > answer on that for over a year now: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2350145 > > > > > > > > > > At this point both a definitive "yes" and a definitive "no" would both > > > > > be better than radio silence. > > > > > > > > At what point do we say the process is broken, and we need to change > > > > the guidelines to remove the special gate keeping rule for crypto ? > > > > This feels overdue for a proposal to FESCO to change the guidelines > > > > to something that is workable without such delays. > > > > > > I am not sure why I did not see stuff on that list, this is probably > > > just a matter of the communication alias/list being broken, so we > > > should fix that, and not immediately assume that Red Hat does not care. > > > > > > And Dan, you know very well we are very responsive when you ask us for > > > anything, so this witch hunt is a bit annoying. > > > > > > > As long as it is not causing regression in existing distro behaviour/ > > > > features for crypto, let crypto best practice problems[1] be addressed > > > > asynchronously after the package is imported. > > > > > > Well it will cause problems the moment our users get very bad > > > cryptography and their data is exposed or their connections are > > > compromised. > > > > > > The reason we want to vet libraries, is for both quality, integration > > > with crypto-policies, integration with the OS certificate store. > > > > > > In the future we'll have thing like UPKI or similar tool to deal with > > > MCTs, CRLs, etc..., and we do not have the bandwidth to go and change > > > dozens of libraries to work well in Fedora. > > > > > > So that's why we "gate-keep", cryptography is black and white, either > > > it works completely or it fails completely ... and we rather have good > > > options, rather than whatever random-joe decided to push through... > > > > If we block or delay packages into Fedora though, that doesn't imply > > the user is safe. Instead people will likely turn to non-Fedora sources > > instead, whether that means building themselves, or using a copr > > repo, or a 3rd party repo or a container. They'll still be exposed > > the same crypto risk, and in addition, loose the other benefits of > > having a Fedora maintained package. > > That is one way to see it it, instead I see it as legitimizing bad > packages.
Yes, that is true. Mostly though, Fedora avoids expressing any opinion about the quality standards for packages. If someone is willing to package something, we'll take it, even if upstream has been dead for decades with countless unfixed security flaws. We don't even have an SLA for fixing CVEs in packages with an active upstream, nor consider many other measures of "quality". > > I agree we want our crypto to be the highest quality it can be. If > > a package can build with a choice of crypto libraries, we should > > definitely pick the one with the best match for Fedora policies. > > If a new package doesn't meet our standards though, IMHO, we are > > better off getting that fixed in the asynchronously after import, > > than by pushing users to obtain the software from non-Fedora > > sources. > > And by "asynchronously after import" it is understood as "never", I > rather have those users know the software does not reach Fedora's > standard by having to source them elsewhere in some cases. Fedora is positioned as a "big tent" where all are welcome though, the packaging guidelines broadly avoid listing any "quality" factors beyond stuff that impacts the ability to put it in an RPM and/or comply with licensing/legal requirements. A Fedora where we entirely block packages based on an judgement of their "quality" is somewhat different from our general position. I do actually think that Fedora should have a way to express package "quality" though in general though (including crypto aspects). The pratical realization of it is admittedly hard starting with a pre-existng huge package set, but there are a few big ticket things we could do. Flagging stuff that is dead upstream would be a good start, considering we still ship things like GTK1. If people want to ship GTK1 for a legacy app, it is ok to be in Fedora in general, but I rather wish it wasn't alongside modern stuff by default. Legacy stuff ought to require enabling a non default yum repo IMHO. The same could apply for anything with undesirable crypto characteristics. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
