Add metadata to output to indicate origin of keys #21

Open
opened 8 months ago by caesar · 1 comments

Sometimes, a key could come from any one of multiple sources (in particular, if the keys.fetch() or keys.fetchURI() method is used).
It would be useful to have metadata on the output of all the fetch methods, giving the origin (URL and request method) of the key.

This would enable implementation of my suggestion on keyoxide-cli#11 to indicate the origin of a key fetched using the "automatic" algorithm.

I'm not sure what the best way to return this information is, since all the fetch methods return an openpgp.PublicKey directly. Are we happy modifying this object to add our own metadata keys? Alternatively we could return an object containing both the openpgp.PublicKey and our own metadata, but that would be a breaking API change (semver-major).

Sometimes, a key could come from any one of multiple sources (in particular, if the `keys.fetch()` or `keys.fetchURI()` method is used). It would be useful to have metadata on the output of all the fetch methods, giving the origin (URL and request method) of the key. This would enable implementation of [my suggestion on keyoxide-cli#11](https://codeberg.org/keyoxide/keyoxide-cli/issues/11#issuecomment-413005) to indicate the origin of a key fetched using the "automatic" algorithm. I'm not sure what the best way to return this information is, since all the fetch methods return an `openpgp.PublicKey` directly. Are we happy modifying this object to add our own metadata keys? Alternatively we could return an object containing both the `openpgp.PublicKey` and our own metadata, but that would be a breaking API change (semver-major).
Poster

I would argue strongly that wrapping the openpgp.PublicKey in our own object, which can also contain whatever metadata we want, is the semantically superior solution. The only drawback I can see is the semver-major API change.

I would argue strongly that wrapping the `openpgp.PublicKey` in our own object, which can also contain whatever metadata we want, is the semantically superior solution. The only drawback I can see is the semver-major API change.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: keyoxide/doipjs#21
Loading…
There is no content yet.