Jason L Tibbitts III <tibbs@xxxxxxxxxxx> writes: >>>>>> "RH" == Robbie Harwood <rharwood@xxxxxxxxxx> writes: >>> >>> Well certainly there isn't much you can do to fix old principals on >>> existing systems. But the current versions should be complaining >>> loudly when it has to issue a ticket for a principal that lacks a >>> modern enctype today, if not six months ago. > > RH> For folks running KDCs, we do have existing logging. > > The problem is that the principal in question hasn't been touched in > twelve years (which I guess you can see from the list of etypes.) That > coupled with the change (which I don't think was your doing) to > /etc/crypto-policies/back-ends/krb5.config to remove des3-cbc-sha1 > caused the KDC to fail to issue those tickets. Ah, I see, you're talking about the case when the enctype is already not permitted. That all makes sense then. > RH> I don't think that putting more messages in here would be useful, > RH> but I could be persuaded otherwise. > > Doesn't technically have to be more messages, even adding more > information to the existing message would help. Adding ", Only > deprecated etypes issued" to the end of the ISSUE lines would sort of be > in keeping with the existing format. > > But really, whether it's in something that gets logged or some separate > tool I can run or something, it would just be nice to have some > established procedure to know that that you're going to be hit by > expiring crypto before you actually get hit by it. This is good feedback, thanks. My plan is to try for an external "realm check" type tool - but I need to make it first :) >>> Of course, if I'm reading that wrong and this is merely an effect of >>> moving to version 1.18 then.... the current devel documentation >>> doesn't seem to say much about deprecation of additional algorithms. >>> Which I know doesn't mean much, but given how kerberos development >>> progresses, I would have expected the complete removal of an >>> encryption type to be telegraphed years in advance. > > RH> Arguably, we telegraphed single-DES removal in 2009 (and there have > RH> been two RFCs about this that I cited), but you're right that > RH> Kerberos has never been a "move fast and deprecate things" kind of > RH> situation. > > Yes, single-DES removal has been yelled about loudly for a long time. > There's a section in every release announcement about it. But isn't the > current proposal about removing more than just 1DES? It may help understanding my motivations here to know that upstream won't consider removal until some distro has done so and they have a sense of what it entails. Until then, it's a bit Catch-22: no one wants to divert from upstream and upstream doesn't want to break downstreams... We've yet to remove anything of import from any Kerberos implementation; MIT still includes Kerberos4 support, for instance. The MIT-specific telegraphing is single-DES specific. The RFCs (which also include RC4 and 3DES) are applicable to the entire ecosystem. But ignoring all that, fundamentally I don't want to do this same process three times - and I can't imagine admins do, either. Which is to say: I think that the only telegraphing I can meaningfully do is administrative (RFCs, release notes, change proposals, etc.), and then try to smooth the roadbumps. 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
