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
signature.asc
Description: PGP signature
