On Tue 2016-09-20 21:51:19 -0400, Benjamin Kaduk <ka...@mit.edu> wrote: > Actually, the documentation is quite poor in this space -- 'change' only > adds the new keys, leaving the old ones in place; 'delold' is required to > remove the old keys (and actually gain the security benefit of fresh keys > for services, since all keys in the keytab, even not-latest-kvno ones, > will be used to accept incoming connections).
right, i understand this tradeoff, though the lack of common-sense policy levers (like "delete after k days") leaves something to be desired. > It's unclear to me whether this behavior matches up with your perception > of what "add new keys" should mean. (It is the case that if you want to > add new keys from a password, or even raw keys, you have to use ktutil and > not k5srvutil, which is secretly just a thin wrapper around kadmin.) yep, i discovered this when i started looking into how k5srvutil was implemented. > So more input is desired, and then we can work on sending patches > upstream. "add new keys" suggests that k5srvutil would be capable of adding a new principal to the srvtab. so if the srvtab had only nfs/foo.example@EXAMPLE you might want to also add host/foo.example@EXAMPLE make sense? fwiw, I agree that this looks like an upstream issue, but i'm not close enough to that community to know the most effective way to push patches there. I'd be happy to have you push whatever you think makes the most sense there, even if it's only to forward this bug report to the right place. Thanks for the followup, Ben. --dkg
Description: PGP signature