>>>>> "RH" == Robbie Harwood <rharwood@xxxxxxxxxx> writes: RH> Per your follow-up email, I'm not clear on whether you want changes RH> here. If you do, speak up, especially if you have suggestions. Well, it was just odd that the summary had information not contained at all within the detailed description. Since this was a change that particularly interests me, I skipped straight to the details and then was left with the question about exactly what was changing. RH> I really don't think that "it won't work and there'll be error RH> messages" is an "extremely optimistic description". But to be fair, MIT krb5 is not known for having great error output. Not being able to start at all because the K/M has an enctype which is acceptable and not at all deprecated according to the documentation that exists today _and_ failing in the way the software tends to fail (with obscure and sometimes numeric messages) would be... tough. Not that I think anyone would just do dnf system-upgrade on their master KDC. RH> If you have langauge changes, I'm happy to hear them out. I'm just not optimistic that it would be much better than "may fail in a completely inexplicable fashion". Having a couple of principals that can't get tickets because they lack a supported enctype is one thing. (I've seen that and the error messages you get are OK, I guess.) But having your entire database not load because it doesn't the enctype on K/M is a different thing entirely. Note that currently things do work fine if the enctype on K/M isn't in supported_enctypes. It doesn't even warn. Presumably because supported_enctypes is related to issuing tickets, not decrypting the database. But if the algorithms are disabled completely, then... I don't know what would happen. That's why I was asking whether the algorithms will still exist. >> There is a good document for migrating from old encryption types at >> https://web.mit.edu/kerberos/krb5-1.16/doc/admin/advanced/retiring-des.html >> Note that the last paragraph there mentions that single-DES is still >> basically OK for the K/M principal and it's not required to use >> allow_weak_crypto to access a database encrypted with single-DES. RH> That reading only applies to sites with a stash file nearby (though RH> sites set up otherwise remain relatively uncommon in my impression, RH> or are freeipa and will have AES keys). I guess I can see that if I read it a few times. The idea is that if the stash file is there on the disk, then having raw access to the database probably means you can also just read the stash and so the encryption type doesn't really matter much. If you're not using a stash file then it then becomes more important. Still, rolling over K/M seems relatively simple (though I haven't actually done it). RH> (Added rollover langauge to "Upgrade/Compatability Impact" section.) Thanks. RH> I'm sure you're aware, then, that there's only so much I can do as a RH> packager here. 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. Also, I'm curious, because I read all of this as "Fedora is going to patch upstream to disable certain algorithms because we don't think the software should support them at all even if upstream does." If that's a correct interpretation, then it's a bit disingenuous to say there's nothing a packager can do when it's the packager who is introducing the change. For example, if we're deviating from upsteam, then it's not a stretch to patch in additional deprecation warnings for existing releases (though that should have been done some time ago if the deprecation is happening in F30). The package could provide additional utilities to check for problematic principals and have them run when the server starts. Certainly people have to check their logs, but the server certainly has enough information to warn. 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. But after all that, the number of sites running a KDC on Fedora with old principals has to be vanishingly small so I may be the only person who would actually care. - 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
