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. - 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. If this understanding is correct, this seems like a trap for the unwary. 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, and only doing the removal in F31? Zbyszek > > Right. Basically, if any one of these: > > * Warnings in previous versions about principals without modern etypes > * Logging in the new version to say why tickets wouldn't issue for > principals with old etypes > * A checkup tool in either the old or current versions to tell me what's > gone wrong > > had existed then there would have been no confusion. Certainly I was > able to figure it out but... if someone had just done an OS update > without proper testing then they could be in a pretty bad position.i > > So basically the big issue as I see it is that there's simply nothing to > tell you that things are going to break, and after the update there's > nothing that tells you why things are broken. And I was concerned that > if some encryption routines go away completely then it would be possible > to be in a state where you can't even decrypt the database. > > - J< > _______________________________________________ > 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 _______________________________________________ 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
