Re: Intention to tighten RPM crypto-policy back

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

 



On Tue, Sep 26, 2023 at 7:40 PM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Alexander Sosedkin wrote:
> > Because of that, I'd like to revert that RPM policy relaxation
> > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5
> > in (f39) rawhide and align RPM security with the rest of the policy.
> >
> > Thoughts / feedback?
>
> I am still opposed, because it is still a backwards-incompatible change that
> breaks existing repositories (such as my Calcforge one) just so that someone
> can tick a checkbox on some "security" checklist.

Yes, those who want to trust that key you've generated back in 2007
will have to use LEGACY policy or relax it in some other way
unless you generate a stronger key, that's precisely my intention.
I'm sorry for putting extra work on you, this is never pleasant,
but, all things considered, I find it well worth the benefit.

If you like *your* systems insecure, I do respect that choice of yours,
and I strive to offer a convenient opt-out of "security"
that should let you lag behind the modern world by ~5 extra years.
But we do need secure *defaults*, and I hope that you see how
compromising the security of most of the of installations
at the expense of the convenience of a few packagers
doesn't seem like the right course to me.

I often joke that the four Fedora values are
"Freedom", "Friends", "Features" and "Fecurity"
but, jokes aside, "First" still made that list:
https://docs.fedoraproject.org/en-US/project/#_first
and my reading of it is that
"15 years of backwards compatibility no matter what"
is explicitly a non-goal.

Fedora defaults are already lagging significantly behind, say, RHEL-9,
but there must be some limit to accepting insecure legacy stuff by default,
and I'll keep proposing the limits I find sensible
until I get completely disappointed in this distro.
Feel free to strike down these proposals
using whatever mechanisms Fedora governance offers.
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3
rejection suggests they do work.
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue




[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