WIP: keyfork-shard: traitify functionality #22
Loading…
Reference in New Issue
No description provided.
Delete Branch "keyfork-shard-traitify"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
d1a9fe4cba
to8ddebfc3bb
8ddebfc3bb
tof8848c75bc
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.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.
maybe it's time to bite the bullet and add an initializer. instead of
parse_public_key_data
, havepublic_key_data()
and make it up to the implementer, which can then dodiscover_from_path()
, as well as something likefrom_certs()
special to OpenPGP for wizard. I think this idea will be pursued.41fc804764
to6a3018e5e8