Support the creation of a new mutable object with a pre-determined signature key #3962

Closed
opened 2023-01-06 20:46:29 +00:00 by exarkun · 3 comments

Sometimes you want to create or re-create a specific mutable object.

Two examples:

  • You are writing a compliance test suite and you want to verify certain test vectors are handled correctly.
  • You are embedding a mutable capability into an external backup system which you want to initialize before you have uploaded anything to a storage server.

Currently this is not possible because the mutable creation APIs all randomly generate a new RSA key and use that. If you try to write the compliance test suite, all your mutable capabilities come out different each time because they each have a new random RSA key. If you want to embed a capability in an external system, you must create it first because otherwise you won't know what RSA key it includes (so you won't know the capability itself).

This is certainly an "advanced" feature. If poor choices are made specifying the RSA key then certain significant features of Tahoe will be compromised (eg, if you re-use a key expecting to get a different object, you will be sorely disappointed). Still, for advanced uses, it is very important.

Sometimes you want to create or re-create a specific mutable object. Two examples: * You are writing a compliance test suite and you want to verify certain test vectors are handled correctly. * You are embedding a mutable capability into an external backup system which you want to initialize _before_ you have uploaded anything to a storage server. Currently this is not possible because the mutable creation APIs all randomly generate a new RSA key and use that. If you try to write the compliance test suite, all your mutable capabilities come out different each time because they each have a new random RSA key. If you want to embed a capability in an external system, you must create it first because otherwise you won't know what RSA key it includes (so you won't know the capability itself). This is certainly an "advanced" feature. If poor choices are made specifying the RSA key then certain significant features of Tahoe will be compromised (eg, if you re-use a key expecting to get a different object, you will be sorely disappointed). Still, for advanced uses, it is very important.
exarkun added the
unknown
normal
defect
n/a
labels 2023-01-06 20:46:29 +00:00
exarkun added this to the undecided milestone 2023-01-06 20:46:29 +00:00
Author

And the "compliance test" issue is /tahoe-lafs/trac-2024-07-25/issues/8611...

And the "compliance test" issue is [/tahoe-lafs/trac-2024-07-25/issues/8611](/tahoe-lafs/trac-2024-07-25/issues/8611)...
Author
(https://github.com/tahoe-lafs/tahoe-lafs/pull/1245)
Author
Merged in <https://github.com/tahoe-lafs/tahoe-lafs/commit/7b768fdaca6404285776225ecf1f69af626fd053>
exarkun added the
fixed
label 2023-01-13 17:28:58 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#3962
No description provided.