Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 23, 2022 at 7:05 AM Alexander Sosedkin <asosedkin@xxxxxxxxxx> wrote:
>
> On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin <asosedkin@xxxxxxxxxx> wrote:
> > >
> > > Hello, community, I need your wisdom for planning a disruptive change.
> > >
> > > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> > > Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > > I believe we should start planning
> > > for the next cryptographic defaults tightening.
> > > And next time it's gonna be even more disruptive because of SHA-1 (again).
> > >
> > > SHA-1 is a hash function from 1995,
> > > which collision resistance is no longer to be relied upon for security [1].
> > > At the same time, it's not like software has successfully migrated off it,
> > > not even close.
> > > It's not a question of "if" the world should migrate from it,
> > > sooner or later we must part ways with it.
> > > (Technically, some acute energy crisis or a collapse of civilization
> > >  forever raising the costs of computations thousandfold would also do,
> > >  but let's agree that migrating to a more modern hash is the way =)
> > >
> > > We've been disabling it in TLS, but its usage is much wider than TLS.
> > > The next agonizing step is to restrict its usage for signatures
> > > on the cryptographic libraries level, with openssl being the scariest one.
> > >
> > > Good news is, RHEL-9 is gonna lead the way
> > > and thus will take a lot of the hits first.
> > > Fedora doesn't have to pioneer it.
> > > Bad news is, Fedora has to follow suit someday anyway,
> > > and this brings me to how does one land such a change.
> >
> > Given that RHEL 9 already switched the crypto-policy defaults, and we
> > presume that future RHEL releases will not deviate from that, is this
> > change already made in ELN?  I honestly can't tell because it looks
> > like it is, but I don't see any conditionalization in the spec file
> > that would lead me to believe the same default isn't already flipped
> > in Rawhide.  That leaves me wondering what needs to be changed and
> > where at this point.
> >
> > josh
>
> No, it's neither in ELN nor in Rawhide yet.

Could you please make this change in ELN?  It might actually prove
fruitful for the broader Fedora activity because it gives you an
isolated base to see what happens.

If we already know there are other similar changes for future RHEL
releases, making those in ELN now would go a long way towards sorting
those out as well.  That can be a follow-on after SHA-1 though, which
is certainly more pressing.

josh
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux