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.

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.

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

Reply via email to