Ticket 5338: Race conditions in key rotation
jaltman at secure-endpoints.com
Tue Jun 24 09:06:03 EDT 2008
Roland Dowdeswell wrote:
> Also, I was suggesting that we default to failing back if we have
> not analysed the error and determined that it is permanent. That
> is, if we prove to ourselves that a particular error is permanent,
> then we should make it so. But the default for errors that we have
> not analysed should not be permanent. An example of a permanent
> errors might be `ticket not forwardable' or `ticket not renewable'.
> Those do not depend on data in the slave's database and so we can
> presume that if the slave successfully decrypted the ticket and
> decided to return those errors then it is right.
Actually, forwardable and renewable errors do depend on the policy flags
service principal entry. Therefore, they cannot be considered permanent.
I looked through the errors and I do not think there are any errors that
considered to be permanent.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080624/824e2a57/attachment.bin
More information about the krbdev