-
Notifications
You must be signed in to change notification settings - Fork 51
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
in-toto-run implementation #56
in-toto-run implementation #56
Conversation
LoadPublicKey() and VerifySignature() were too generic. Let's rename them to be more precise in what they are achieving.
In this commit we add a LoadEd25519PublicKey func for loading ed25519 keys in PrivateJSON format from a ed25519 public key file
514e090
to
45a8e93
Compare
The format of a public key is different to the private key JSON format for ed25519 in-toto pubkeys. Therefore we need another function for parsing ed25519 pub keys.
3e13755
to
c66ee1f
Compare
c66ee1f
to
c6cb9c0
Compare
@lukpueh current state right now regarding keylib, all including tests:
|
I've also added a |
Yes, this is what I would have done, as it gives us a sense for interoperability. |
Thanks for the feedback. I am going to finish the missing functions till Friday, then I will start working on the link meta data creation and I hope that I can generate the first link meta data before Monday :) EDIT: If we continue with this pace we can maybe finish the runtime before August and I can have a look on the exclude PR again or any other todo in our README. :) |
This commit adds more test material such like symmetric encrypted private keys.
This commit also changes the example keys in the documentation. We use the keypair of "carol" (see test/data/carol{.pub}) now.
Right now loading encrypted private keys is not yet supported. I need to have a look at it, later. not sure how easy we can implement key encryption/decyption in in-toto-golang. |
We use PKCS1 for parsing/loading RSA private keys. This means we do not support ECDSA yet.
@lukpueh Do we need generate keys in in-toto-golang? |
14fad67
to
849dddb
Compare
849dddb
to
9b5413f
Compare
I'd say no, as long we can parse keys from standard formats. It actually seems preferable to support interoperability with well-known tool chains, such as openssl or gpg, for key creation (see secure-systems-lab/securesystemslib#55 for additional infos). |
@lukpueh k, then we should have all necessary functionality right now for signing/loading keys. Except for ecdsa support + support for encrypted keys. |
Awesome, I'll take a closer look early next week. :) |
I correct: The RSA Sign method is missing. I am coding on this one right now. I just need to clarify one question I have about rsa.SignPSS I have no idea if we can pass I've asked one of the Go Core Cryptographers, he helped me in the past ^^ so maybe he can give me a hint, before I do something totally insane. https://twitter.com/Sh1bumi/status/1276463063898583046 |
We have a few default cases, that were never reached due to validateKey() at the beginning of the function. Let's call a panic, if we run into such a situation.
This commit addresses various spelling issues, substantial mistakes or adds more documentation.
This adds a short comment/todo to our subsetCheck function. In the future we might want to use Sets for our constant getters.
This commits removes the misleading support for ecdsa-sha2-nistp384.
with this commit implements the validatePublicKey function, for checking if we deal with a public key. If the private key value field is not empty, it will fail with the error ErrNoPublicKey. We also call this method in validateLayout from now on.
It's funny that our test coverage decreased, only because of the additional panic + comments. Do comments count as coverage? I can't explain it otherwise. I will try to add a few tests for not catched errors, but it's getting more and more difficult, because most errors are either library external (I don't want to test against functions like ioutil.Writer...), or code that we will never reach (no idea how to test, such code). If you want to have a look on the current coverage in a nice graphical way. Have a look at the coverprofile via:
this should spawn a new tab in your browser with the coverage highlighted on the code in green and red. |
Agreed. Although, it would be nice if the comment were somewhere on the public interface. E.g. on LoadKey (and/or {Generate,Verify}Signature. What do you think? |
Don't worry about those. |
makes sense, let me start GoLand and add a comment for those functions :) |
In this commit, we make Key.KeyIdHashAlgorithms optional. We only check the field now, if the field has been initialized. Furthermore this commit fixes a few tests and removes tests, that are not needed anymore.
in-toto-golang behaves a little bit different to the securesystemslib. We should mention, that we use ecdsa/ecdsa-sha2-nistp256 pairs instead of ecdsa-sha2-nistp256 for key type and key scheme.
Is this okay? 1ac47be |
This adds the missing 'd' to the deadbeef test. We now check for a missing keyfield there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing left to do here! 🎉 😄
... except for maybe removing the some items from the TODO list in the main REAMDE file.
in-toto-golang now supports all signing methods from the reference implementation and has a fully-fledged runlib, to generate signed link metadata. Big kudos to @shibumi! Signed-off-by: Lukas Puehringer <[email protected]>
The following PR is part of the Google Summer of Code 2020 program
Fixes issue #54:
This PR intents to fix Issue #54
Description of pull request:
The goal of this PR is the in-toto-run implementation similar to our reference implementation in python.
Please verify and check that the pull request fulfills the following
requirements: