best practices for secret_handle and secret?

[Brad Fitzpatrick]

On Wed, 8 Jun 2005, Paul Crowley wrote:

> Brad Fitzpatrick wrote:
> > Heh, I did that last night too.  I even made it generate secrets too,
> > provided you gave it a storage interface.  But then I couldn't solve the
> > race condition problems inherent in a caller only providing "get" and
> > "set" for a time.  So still debating that interface.
>
> What's the race condition?

I suppose one that couldn't be fixed by documentation and warnings, but:

-- two callers who GET the secret at time t, but fail due to that secret
   not yet existing
-- both generate a new one
-- both SET secret(t) = their own random, one blowing away the other

I suppose if the setter is documented to MUST fail on duplicate, the
module can then just re-GET the value.

Obvious things like that weren't coming to me last night, which is why I
stopped working on it.

- Brad