Skip to content
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

Flattened the filekeystore: Post0.4 #872

Merged
merged 11 commits into from
Sep 12, 2016
Merged

Conversation

avaid96
Copy link
Contributor

@avaid96 avaid96 commented Jul 25, 2016

  • Stores all keys under the private directory
  • Key data now contains the gun that was otherwise inferred by filepath
  • Root keys delegations keys etc don't get a GUN
  • Backwards compatibility to 0.1 (already there) and 0.3 (added tests and fixtures) has been tested for

closes #838

@docker-jenkins
Copy link

Can one of the admins verify this patch?

@riyazdf
Copy link
Contributor

riyazdf commented Jul 25, 2016

jenkins, test this please.

@@ -409,6 +409,17 @@ func KeyToPEM(privKey data.PrivateKey, role string) ([]byte, error) {
"role": role,
}
}
if gun != "" {
headers = map[string]string{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally non-blocking - can we just set the header value for the given key in two if blocks, rather than redeclaring it in three if blocks?

@cyli
Copy link
Contributor

cyli commented Jul 26, 2016

Apologies! I'm sure this would work fine with the new code - could we add a delegation to the fixtures so we have a delegation key imported into the key store? It should be fine, since it could have had any role anyway, but just wanted to make sure that something with that that particular key can still be used.

This looks great! So clean!

@avaid96
Copy link
Contributor Author

avaid96 commented Jul 28, 2016

Thanks for this comment @cyli

"Apologies! I'm sure this would work fine with the new code - could we add a delegation to the fixtures so we have a delegation key imported into the key store? It should be fine, since it could have had any role anyway, but just wanted to make sure that something with that that particular key can still be used.

This looks great! So clean!"

it picked up a case that I hadn't looked for. Made the necessary changes with a new fixture that uses delegations and tests that with the new keystore

@avaid96 avaid96 force-pushed the flattenKS branch 2 times, most recently from 698dc61 to 7505832 Compare July 28, 2016 00:53
@avaid96 avaid96 changed the title Flattened the keystore on disk POC: Flattened the keystore on disk, for post 0.4 Jul 28, 2016
@avaid96 avaid96 force-pushed the flattenKS branch 2 times, most recently from ef12247 to 1516bb7 Compare August 11, 2016 18:49
@avaid96 avaid96 changed the title POC: Flattened the keystore on disk, for post 0.4 WIP: Flattened the keystore on disk, for post 0.4 Aug 11, 2016
@avaid96 avaid96 force-pushed the flattenKS branch 2 times, most recently from d8bb796 to 3d6c8f5 Compare August 11, 2016 22:49
@avaid96 avaid96 changed the title WIP: Flattened the keystore on disk, for post 0.4 Flattened the filekeystore Aug 11, 2016
f.moveKeyTo0Dot4Location(filepath.Join(notary.RootKeysSubdir, file))
}
// delete the old directory
if rootKeysSubDir == "" || rootKeysSubDir == "/" {
Copy link
Contributor

@cyli cyli Aug 22, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking: Can this ever happen, since we control the constants notary.RootKeysSubdir and notary.NonRootKeysSubdir - they're not empty, and we do a filepath.Join, so won't it always contain at least some of the constant values?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: I'm not sure filepath.Abs(filepath.Clean(filepath.Join(...))) could result in rootKeysSubDir being either empty or "/".

https://play.golang.org/p/OCxAa4jtjL were the only cases I tried, so I might have missed some stuff.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cyli is 100% correct. I asked @avaid96 to put these checks in as a sanity check in case anyone is making updates in the future and does something silly.

@cyli has also made the suggestion that we check f.Location and the (Non)RootKeysSubdir constants at the start instead of checking the joined values here and later. That would stop a possible walk over / which would take a long time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cyli you're 100% correct about the fact that as of now we won't enter these statements but as correctly pointed out by @endophage these are just to make the migrations futureproof

@cyli the prior checks make sense. I have implemented something similar in the latest push (coming soon)- checking the concatenated value but checking this before the walk over the directory. Let me know if you like this or would prefer separate checks. I prefer this because it will be simpler to understand what is going on

@cyli
Copy link
Contributor

cyli commented Aug 22, 2016

So sorry I didn't comment sooner. :( I will be happy to address the comments above in a few days.

@avaid96
Copy link
Contributor Author

avaid96 commented Aug 23, 2016

No issues at all @cyli. Thanks for the awesome comments. I think they're all mostly addressed besides the migration test which I can write some time this week 😄 Let me know if there's anything else!

@avaid96 avaid96 force-pushed the flattenKS branch 2 times, most recently from eb2f04c to 68bfaa6 Compare August 23, 2016 13:21
@avaid96
Copy link
Contributor Author

avaid96 commented Aug 24, 2016

added the tests for the migrations @cyli 😃

@cyli
Copy link
Contributor

cyli commented Sep 8, 2016

@avaid96 So so sorry I hadn't finished going over this yet. Thank you for adding those tests! LGTM, and thank you so much for slogging through all of this and keeping it up to date!

@avaid96
Copy link
Contributor Author

avaid96 commented Sep 9, 2016

bumping this for a final review and merge. Has one slightly out of date LGTM from @riyazdf (doesn't include last commit) and another up to date one from @cyli

@cyli
Copy link
Contributor

cyli commented Sep 9, 2016

@avaid96 Many apologies, this seems to require some conflict resolution. :| I think github allows collaboration on forks now (https://github.com/blog/2247-improving-collaboration-with-forks), so if it's enabled we'd be happy to rebase :)

@riyazdf
Copy link
Contributor

riyazdf commented Sep 9, 2016

Final commit LGTM!

And yeah, unfortunately we'll need to rebase -- let us know if you hit that checkbox and we can handle that :)

…newer functionality and tests to be compatible with the flat KS

Signed-off-by: Avi Vaid <[email protected]>
have been added for backwards compatibility testing

Signed-off-by: avaid96 <[email protected]>
…ormatted repos which are irrelevant after migration. Address @riyazdf 's concern about having an empty role

Signed-off-by: Avi Vaid <[email protected]>
…sts. Work is required on the integration tests still

Signed-off-by: Avi Vaid <[email protected]>
@avaid96
Copy link
Contributor Author

avaid96 commented Sep 10, 2016

No worries, I rebased. Sorry I think Circle ran into something 😞 Could you rebuild?

I've also allowed edits from maintainers in case there's any minor tweak you'll want to make 😄

Signed-off-by: Riyaz Faizullabhoy <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Discussion: Can we fully flatten the keystore?
6 participants