WIP: keyfork-shard: traitify functionality #22

Manually merged
ryan merged 8 commits from keyfork-shard-traitify into main 2024-02-19 10:51:04 +00:00
Owner

This makes functionality generic across any format and means all any format has to do is provide the functions required by the trait. Could probably have made it reasonable for the trait objects to store things inside of themselves (i.e. don't enforce it by the trait parsing) but this way it generates a design flow for how a new format should be added. Something like a hardware-only pkcs#11 implementation might want to never have private key data, so it can have Self::PrivateKeyData be a zero sized () and infallibly return that.

The provided split functionality has not yet been implemented.

This makes functionality generic across any format and means all any format has to do is provide the functions required by the trait. Could probably have made it reasonable for the trait objects to store things inside of themselves (i.e. don't enforce it by the trait parsing) but this way it generates a design flow for how a new format should be added. Something like a hardware-only pkcs#11 implementation might want to never have private key data, so it can have Self::PrivateKeyData be a zero sized `()` and infallibly return that. The provided split functionality has not yet been implemented.
ryan added 1 commit 2024-01-20 06:25:49 +00:00
ryan force-pushed keyfork-shard-traitify from d1a9fe4cba to 8ddebfc3bb 2024-02-12 13:46:56 +00:00 Compare
ryan force-pushed keyfork-shard-traitify from 8ddebfc3bb to f8848c75bc 2024-02-12 13:58:37 +00:00 Compare
ryan added 2 commits 2024-02-15 06:38:28 +00:00
ryan added 1 commit 2024-02-15 08:01:46 +00:00
Author
Owner

Still missing the ability to replace keyfork_shard::openpgp::split() usage in the Wizard. Not entirely sure what to do about that. Maybe the Wizard should export the certs for shardholders? That way, if they'll be serialized anyways, I have no issues re-parsing them.

Still missing the ability to replace `keyfork_shard::openpgp::split()` usage in the Wizard. Not entirely sure what to do about that. Maybe the Wizard should export the certs for shardholders? That way, if they'll be serialized anyways, I have no issues re-parsing them.
Author
Owner

May need to refactor out usages of PathBuf, both to make the wizard shard usable as well as making testing down the line actually possible.

May need to refactor out usages of PathBuf, both to make the wizard shard usable as well as making testing down the line actually possible.
Author
Owner

maybe it's time to bite the bullet and add an initializer. instead of parse_public_key_data, have public_key_data() and make it up to the implementer, which can then do discover_from_path(), as well as something like from_certs() special to OpenPGP for wizard. I think this idea will be pursued.

maybe it's time to bite the bullet and add an initializer. instead of `parse_public_key_data`, have `public_key_data()` and make it up to the implementer, which can then do `discover_from_path()`, as well as something like `from_certs()` special to OpenPGP for wizard. I think this idea will be pursued.
ryan added 1 commit 2024-02-19 01:21:41 +00:00
ryan force-pushed keyfork-shard-traitify from 41fc804764 to 6a3018e5e8 2024-02-19 10:41:58 +00:00 Compare
ryan added 1 commit 2024-02-19 10:50:07 +00:00
ryan manually merged commit 425aa30aa6 into main 2024-02-19 10:51:04 +00:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No project
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.

Dependencies

No dependencies set.

Reference: public/keyfork#22
No description provided.