On 2017-11-07 11:21:45, Roland C. Dowdeswell wrote:
> On Tue, Nov 07, 2017 at 10:55:08AM +0100, Patrik Lundin wrote:
> > Additionally, I see that the prune code basically figures out the most
> > recent keyset timestamp that is older than the ticket maximum lifetime and
> > then removes all keysets with a timestamp older than that one. This
> > means that this too old but most recent keyset will be kept, but since
> > it was calculated to be older than max-lifetime, shouldnt it be removed
> > as well? As it stands now there will always remain at least one keyset
> > (depending on if there are more than one keyset with the same timestamp)
> > too old to be useful.
> > Would it make sense to alter the code to also remove that most recent
> > (but too old) keyset? The only functional difference of the diff below
> > is the "<" to "<=" change at the bottom, but it felt like it would
> > warrant a more fitting variable name as well:
> It isn't too old, however. What we are trying to achieve here is
> that we keep all of the keys which might have outstanding tickets in
> someone's ccache.
Ah, I was confused by the "get" calls censoring the returned entries.
I was under the impression hdb_prune_keys() actually modified the database, I
understand now that it only acts as a filter and the actual modification of
the database is performed separately when a new key is set.
It makes sense to leave at least one trailing keyset if they are only trimmed in
conjunction with the principal getting a new key.
Sorry for the confusion on the list!