Jason L Tibbitts III <tibbs@xxxxxxxxxxx> writes: >>>>>> "RH" == Robbie Harwood <rharwood@xxxxxxxxxx> writes: > > 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. I've spent a nontrivial amount of time working on improving that, but am always willing to process more bugs in the documentation/errors area. krb5 only has five bugzillas in Fedora, so don't sweat giving me more to do :) > 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. Correct. > But if the algorithms are disabled completely, then... I don't know > what would happen. My memory is that it complains about a bad enctype on K/M, but it's been a while. If you want, as part of this change I can make sure it generates a useful error message. > RH> I'm sure you're aware, then, that there's only so much I can do as > RH> a 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. Yes but also no. The problem is where to complain. For most users, Kerberos functionally exists in library form (with some CLI for various functions). Libraries can't log anywhere - which is why krb5 has KRB5_TRACE. But unless something isn't working, there's no reason to go look at the KRB5_TRACE output. For folks running KDCs, we do have existing logging. But as an admin, you know that I'm already logging every issuance - including their etypes. (Now, the raw numbers aren't very helpful unless you're used to looking at them - but that's why I've got https://bugzilla.redhat.com/show_bug.cgi?id=1664156 .) This is pretty chatty! I don't think that putting more messages in here would be useful, but I could be persuaded otherwise. > 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 comment you're quoting is intended to refer to pushing changes to non-KDC machines in the network (such as keytabs). My point was that I can't make everything seamless. See above for a discussion of "deprecation warnings". > 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. As previously stated, I'm investigating providing tooling. > 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. Arguably, we telegraphed single-DES removal in 2009 (and there have been two RFCs about this that I cited), but you're right that Kerberos has never been a "move fast and deprecate things" kind of situation. This has worked to our detriment and we shouldn't let tradition be the enemy of improvement. I don't want to go on too long about this, but the perception that Kerberos is somehow "maintenance mode" isn't quite right. A lot of the changes we've made recently haven't really been end-user visible (like SPAKE), but things in the pipe will be more so (this crypto change, FIDO/U2F support, etc.). > 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. Maybe in Fedora, but we're leading here. The concerns you're raising are important for other distros that make these changes down the line. I may not be happy about them (because they make this harder), but we still need to talk them through :) For Fedora specifically, I do think we have a lot of end users (even just from kinit followed by fedpkg), a smaller-but-not-insignificant number of service users (people running Kerberized services), and a pretty small number of folks running full-on KDCs (whose testing is very helpful) in comparison to other distros. 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
