Bug #5724
Updated by Tom Clegg about 9 years ago
The default_trash_lifetime config setting (and the defaultTrashLifetime discovery doc key) are currently unused and were intended to control the default interval after pushing the "trash" button on an object in Workbench (or doing a similar action) during which the object could be rescued/undeleted. This is achieved by setting expires_at=now()+defaultTrashLifetime on an object. Note:
* This is not the same kind of "trash" as unreferenced data blocks in Keep.
* This is only a default: a client can also choose to set expires_at to now()+1h or now()+8y.
* A larger value makes it more likely a user can recover accidentally deleted data.
* A smaller value conserves disk space.
* This is not a security feature.
Meanwhile, the API server's blob_signing_ttl config setting refers to the permission signature hints on Keep locators. When the API server sends manifest_text to a client, it includes signature hints that claim to expire (and do in fact expire) at now()+blob_signing_ttl. Clients expect to be able to read the blocks until that time, without any further contact with the API server. Note:
* Whether the collection's expires_at is now+1h, now+8y, or null, the signature TTL is the same (default is 2 weeks).
* This is a security feature. It prevents a client from stockpiling signatures over time and reading data which it had permission to read 8 years ago (but doesn't now).
Closely related is keepstore's -blob-signing-ttl command line flag. This is expected to be equal to the API server's blob_signing_ttl config setting, but currently no mechanism is in place to guarantee this.
* This limits the time a client can take to build a collection.
* Like the API server's ttl, this TTL is visible to clients (the expiry time part is easy to parse out of the blob signature) so clients can be expected to make decisions on this basis ("the block signature will expire soon, so I'd better create a collection to get a fresh one"). Therefore, a keepstore that has provided a signature expiring on January 15 must not delete the corresponding data before January 15 merely because that block hasn't appeared in any collections yet.
* keepstore should (but currently doesn't) advertise its blob_signing_ttl to clients explicitly. Currently, clients can figure it out by writing a block and subtracting now() from the resulting signature expiry time.