Re: F30 Self-Contained Change proposal: krb5 crypto modernization

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

 



Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> writes:

> On Tue, Jan 08, 2019 at 04:45:53PM -0600, Jason L Tibbitts III wrote:
>> >>>>> "RH" == Robbie Harwood <rharwood@xxxxxxxxxx> writes:
>> 
>> RH> Ah, I see, you're talking about the case when the enctype is already
>> RH> not permitted.  That all makes sense then.
>
> Hi,
>
> after re-reading this thread, I'm still unclear on some issues. Please
> correct me if I'm wrong.
>
> - The plan is to patch the Fedora package to remove support for some
>   algorithms above and beyond what upstream is removing right now.

Upstream has never removed an algorithm.  Hopefully the Fedora changes
will allow us to do so, both by providing the code, and by showing that
the fallout isn't catastrophic.

> - Current implementation in F29 does not warn that those algorithms
>   will become unimplemented.
>
> - Because of the combination of two previous points, users who simply
>   upgrade to F30 without paying attention will have to temporarily
>   downgrade to the F29 version, perform key roll-over, and only then
>   upgrade.

That's not a consequence of the previous two points but is nontheless
true.

> If this understanding is correct, this seems like a trap for the unwary.

So is keeping any of these algorithms around.

> What about turning the removal into a big warning in the logs each
> time kdc is started and needs to use those deprecated algorithms in
> F30,

Still in progress.  It may prove too invasive to be feasible.

If I can't, then I'll be providing external tooling that will check for
some common-ish legacy cruft in setups that might break.

Also, I don't know if you've ever looked at krb5kdc logs, but they're
really chatty - I doubt anyone reads regularly them unless they're
trying to debug a problem.

> and only doing the removal in F31?

It may come to that.  If it does, then I want to be sure everything is
lined up for it, and we won't slip to fc32 or later.

Finally, I do want to call out here that announcing crypto deprecations
in the previous release is not the norm for Fedora.  Since fc20, there
have been seven crypto Changes (mostly to do with adding crypto-policies
support), none of which performed any notification other than what was
in the release notes:

https://fedoraproject.org/wiki/Changes/RemoveSSL3andRc4
https://fedoraproject.org/wiki/Changes/CryptoPolicyKrb5
https://fedoraproject.org/wiki/Changes/NSSCryptoPolicies
https://fedoraproject.org/wiki/Changes/OpenSSH_Crypto_Policy
https://fedoraproject.org/wiki/Changes/Remove_SSH-1_from_OpenSSH
https://fedoraproject.org/wiki/Changes/OpenSSH_Server_Crypto_Policy
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings

Furthermore, at no point have there even been Change/Feature pages for
all the TLS changes relating to vulnerable ciphers.

Thanks,
--Robbie

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[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