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

> 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

> 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

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

Thanks for the followup, Ben.


Attachment: signature.asc
Description: PGP signature

Reply via email to