-
Notifications
You must be signed in to change notification settings - Fork 788
object: introduce signature abstraction #705
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
73ebe5c
to
95b3408
Compare
This refactors the existing PGP verification and signing code into an abstraction which allows multiple signature types to exist in a backwards compatible manner. Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
11ec329
to
e1b64bc
Compare
Talked with @pjbgf about this last week, and due to the lack of time I have to finalize the "nice" user part of SSH signatures on user systems (i.e. by taking the We thought it may be an option to introduce the abstraction without providing an implementation with a "keyring" like functionality. As the abstraction itself seems sound, and works as is. Any objections against this @mcuadros? If not, I will rebase the PR and spend one more time thinking about the details of the abstraction itself (e.g. the |
crypto.Signer was incorrectly used before. Signer documentation says that Signer.Sign should be used on digests, whereas we were using this on message bodies. To fix this, create our own Signer interface (+ signableObject borrowed from go-git#705) that describes more accurately what we want. As before, the expectation is that signer implementations only need to worry about acting on encoded message bodies rather than needing to encode objects themselves. This is technically a breaking change from the previous Signer implementation, but since this is new and hasn't made it into cut release yet, this seems like an acceptible change. Also adds example test showing how signers can be made (uses base64 for consistent outputs).
crypto.Signer was incorrectly used before. Signer documentation says that Signer.Sign should be used on digests, whereas we were using this on message bodies. To fix this, create our own Signer interface (+ signableObject borrowed from go-git#705) that describes more accurately what we want. As before, the expectation is that signer implementations only need to worry about acting on encoded message bodies rather than needing to encode objects themselves. This is technically a breaking change from the previous Signer implementation, but since this is new and hasn't made it into cut release yet, this seems like an acceptible change. Also adds example test showing how signers can be made (uses base64 for consistent outputs).
crypto.Signer was incorrectly used before. Signer documentation says that Signer.Sign should be used on digests, whereas we were using this on message bodies. To fix this, create our own Signer interface (+ signableObject borrowed from go-git#705) that describes more accurately what we want. As before, the expectation is that signer implementations only need to worry about acting on encoded message bodies rather than needing to encode objects themselves. This is technically a breaking change from the previous Signer implementation, but since this is new and hasn't made it into cut release yet, this seems like an acceptible change. Also adds example test showing how signers can be made (uses base64 for consistent outputs).
crypto.Signer was incorrectly used before. Signer documentation says that Signer.Sign should be used on digests, whereas we were using this on message bodies. To fix this, create our own Signer interface (+ signableObject borrowed from go-git#705) that describes more accurately what we want. As before, the expectation is that signer implementations only need to worry about acting on encoded message bodies rather than needing to encode objects themselves. This is technically a breaking change from the previous Signer implementation, but since this is new and hasn't made it into cut release yet, this seems like an acceptible change. Also adds example test showing how signers can be made (uses base64 for consistent outputs).
crypto.Signer was incorrectly used before. Signer documentation says that Signer.Sign should be used on digests, whereas we were using this on message bodies. To fix this, create our own Signer interface (+ signableObject borrowed from go-git#705) that describes more accurately what we want. As before, the expectation is that signer implementations only need to worry about acting on encoded message bodies rather than needing to encode objects themselves. This is technically a breaking change from the previous Signer implementation, but since this is new and hasn't made it into cut release yet, this seems like an acceptible change. Also adds example test showing how signers can be made (uses base64 for consistent outputs).
This is work in progress to further facilitate #400. As this introduces (non-breaking) but important contract changes, I would like to have eyes on this early on.