Notary repository lazy initialization #1105

n4ss · 2017-02-24T13:59:11Z

This work depends on the work done in #1094, allowing us to inject a remote store and a cache in a NotaryRepository object.
Since this PR is stacked on top of #1094 which just got merged, make sure you pull the latests changes.

We are now initializing the repository when publishing, if needed. We do this for three reasons:

reduce the amount of operations necessary for notary users to setup their repo
avoid metadata corruption when calling init several times on the same repo - duplicate init on gun causes corrupted state #1071
give more flexibility on how to initialize

The lazy initialization is done either from scratch by NotaryRepository.Initialize() when starting from a blank state or by NotaryRepository.bootstrapRepo() if metadata is found on disk (example: when someone does a notary key rotate as a first operation).

Some updates have been added to the way change lists were handled, we can now inject one in aNotaryRepository object.

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Signed-off-by: David Lawrence <david.lawrence@docker.com> (github: endophage)

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

…sh time Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

riyazdf · 2017-03-02T20:35:50Z

client/client_test.go

+	requireRepoHasExpectedMetadata(t, repo, data.CanonicalTargetsRole, true)
+}
+
+// Tnitializing a repo and republishing after should succeed


nit typo: Initializing

riyazdf · 2017-03-02T20:36:48Z

client/client_test.go

-func TestRemoteRotationNonexistentRepo(t *testing.T) {
+// The repo is initialized at publish time after
+// rotating the key. We should be denied the access
+// to metadata by the server when trying to retrieve it.


I'm not sure I follow why this is the case?

I made a mistake here, my bad. This is the current behavior which is buggy, I need to fix this. It seems like operations' order is not the right one in this code path.

@endophage found the issue, we needed a fullTestServer rather than a simpleTestServer.

riyazdf · 2017-03-02T20:37:58Z

client/helpers.go

+		_, err := cache.GetSized(role.String(), store.NoSizeLimit)
+		if err != nil {
+			if _, ok := err.(store.ErrMetaNotFound); ok {
+				continue


is this intended? This function seems to return true if a cache exists but none of the roles have metadata in it

No, for each roles, we search if there is metadata. We keep searching for other roles only if the error we get while searching is that there is no metadata in it.

Is there a bug in the logic or implementation in your opinion?

@n4ss - sorry yes, you're correct. Could we add a docstring-style comment to this function?

riyazdf · 2017-03-02T20:38:58Z

cmd/notary/tuf.go

@@ -142,7 +142,10 @@ func (t *tufCommander) AddToCommand(cmd *cobra.Command) {
 	cmdReset.Flags().BoolVar(&t.resetAll, "all", false, "Reset all changes shown in the status list")
 	cmd.AddCommand(cmdReset)

-	cmd.AddCommand(cmdTUFPublishTemplate.ToCommand(t.tufPublish))
+	cmdTUFPublish := cmdTUFPublishTemplate.ToCommand(t.tufPublish)
+	cmdTUFPublish.Flags().StringVar(&t.rootKey, "rootkey", "", "Root key to initialize the repository with")


nit: can the flag description indicate that it's only used if this is the first publish?

I'll actually remove this as we don't really need it.

hm it depends on whether we want lazy initialization to support this (we'd have to inject the root key into this call to Initialize), and it will get messy with the auto-publish flag.

I'm ok with removing this for now, since notary init will still allow for this functionality. We can figure out the best way to handle this for lazy init on a followup PR 👍

sounds good, I tried to draft it but there is no clean way to propagate the root key to Initialize in this code path.. we should talk about it later indeed

riyazdf · 2017-03-02T20:39:12Z

cmd/notary/tuf.go

@@ -1031,14 +1037,14 @@ func maybeAutoPublish(cmd *cobra.Command, doPublish bool, gun data.GUN, config *
 		return err
 	}

-	cmd.Println("Auto-publishing changes to", gun)
-	return publishAndPrintToCLI(cmd, nRepo, gun)
+	cmd.Println("Auto-publishing changes to", nRepo.GetGUN())


gun is already an argument to this function. No need to create a new getter for it on NotaryRepository.

ah you're right, the getter isn't needed - for some reason thought I had seen it somewhere else 😅

repo.Publish() will use repo.gun for every operations (in bootstrapClient in oldKeysForLegacyClientSupport for example) and not necessarily the one provided as an argument here.

Providing a different gun that the one inside the repository object could lead to misleading logging entry here, this is why I removed it from the prototype and used the "internal" one instead. Does it make sense?

I don't think you need the getter because we use thegun argument to get the repository here

nRepo, err := notaryclient.NewFileCachedNotaryRepository( config.GetString("trust_dir"), gun, getRemoteTrustServer(config), rt, passRetriever, trustPin)

I was thinking about the case where this function might be called elsewhere in the same package, we have no "contract" on the fact that the gun in the argument is the same as the one used for this repo.

It's just less error-prone if we don't allow someone to provide an unrelated gun. For now it's only used properly because we get it from this same repo but people might call it in a different way..

I was thinking about the case where this function might be called elsewhere in the same package, we have no "contract" on the fact that the gun in the argument is the same as the one used for this repo.

If the gun passed in to the constructor of the repo, wouldn't that gun and the gun on the repo by contract of the NotaryRepository have to be the same?

Update: unless you mean the contract between the gun and publishAndPrintToCLI?

I mean the contract at the publishAndPrintToCLI level only, which can be called with different values for repo.gun and gun.

Ah ok, that makes sense.

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

cyli · 2017-03-03T18:06:43Z

client/client_test.go

+}
+
+// Initializing a repo and republishing after should succeed
+func TestPublishInitializedRepo(t *testing.T) {


I think this test case may already be covered by TestPublishBareRepo

indeed, will fix.

cyli · 2017-03-03T18:40:07Z

client/client.go

@@ -837,6 +834,29 @@ func (r *NotaryRepository) bootstrapRepo() error {
 	return nil
 }

+// initializeFromCache looks for cached metadata to bootstrap from


Non-blocking: Since isMetaCached basically running the same loop as bootstrapRepo, I wonder if we can modify bootstrapRepo to just call Initialize if it encounters an ErrMetaNotFound error that is not related to a missing timestamp or snapshot.

That would eliminate the need for initializeFromCache.

Alternately, in the publish logic, if ErrMetadataNotFound is returned by bootstrapRepo, we can then call Initialize rather than return the previous ErrRepoNotInitialized.

Will fix with the second solution. Thanks that's way cleaner that way.

…scratch Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

riyazdf · 2017-03-03T22:50:20Z

cmd/notary/tuf.go

@@ -142,7 +142,9 @@ func (t *tufCommander) AddToCommand(cmd *cobra.Command) {
 	cmdReset.Flags().BoolVar(&t.resetAll, "all", false, "Reset all changes shown in the status list")
 	cmd.AddCommand(cmdReset)

-	cmd.AddCommand(cmdTUFPublishTemplate.ToCommand(t.tufPublish))


nit: I think this can stay as is now that the flag is gone

sounds good!

riyazdf · 2017-03-03T22:51:01Z

client/client.go

 		if _, ok := err.(ErrRepositoryNotExist); ok {
 			err := r.bootstrapRepo()
+			if _, ok := err.(store.ErrMetaNotFound); ok {


Great cleanup! Could we add some debug logs for these cases?

sure, good idea

Non-blocking: I'm wondering if this should be logged as Info so that users can see it. Mainly because while trying this out, I'm seeing something like:

$ bin/notary -c cmd/notary/config.json delegation add repo2 targets/releases --all-paths fixtures/notary-server.crt Addition of delegation role targets/releases with keys [d67a3bf8194b6cccbce29c859dc3677fedfb0a5e236d24b57c37edc202cc73dd], with paths ["" <all paths>], to repository "repo2" staged for next publish. $ bin/notary -c cmd/notary/config.json publish repo2 Pushing changes to repo2 Enter passphrase for root key with ID f6ff23d: Enter passphrase for new targets key with ID 4788565: Repeat passphrase for new targets key with ID 4788565: Passphrases do not match. Please retry. Enter passphrase for new targets key with ID 4788565: Repeat passphrase for new targets key with ID 4788565: Enter passphrase for new snapshot key with ID b5c6cd5: Repeat passphrase for new snapshot key with ID b5c6cd5: Successfully published changes for repository repo2

And there's not a lot of difference between "passphrase for root key" and "passphrase for new targets key", etc. It may be useful for users to see a note about what's going on, instead of wondering why they're being asked for all these passphrases (since it's hard to distinguish between the output of the lazy init vs publishing an actual change).

Possibly the log message could be "No TUF data found locally or remotely - initializing repository %s for the first time" or something? (also totally cool with "from scratch", but "first time" might make it more clear to users since we document how notary generates keys when initializing repos for the first time.

Very good point, I didn't realize how disturbing it might be regarding the passphrases.

Will fix!

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

cyli · 2017-03-04T01:55:40Z

Other than minor bikeshedding about a log message, this LGTM! Thanks for all your work on this!

endophage · 2017-03-04T05:50:54Z

This came out a LOT shorter than I was anticipating! Great work. It looks good but I'm reviewing it late-ish at night so will take another look when I'm a bit more alert.

endophage

LGTM! This looks great.

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

n4ss force-pushed the repo-lazy-init branch from b174084 to 348cde4 Compare March 2, 2017 16:06

n4ss changed the title ~~WIP: Notary repository lazy initialization - depends on https://github.com/docker/notary/pull/1094~~ Notary repository lazy initialization Mar 2, 2017

n4ss requested review from cyli, endophage and riyazdf March 2, 2017 16:58

GordonTheTurtle added the dco/no label Mar 2, 2017

n4ss force-pushed the repo-lazy-init branch from 9fa5c09 to 7512f85 Compare March 2, 2017 18:00

GordonTheTurtle removed the dco/no label Mar 2, 2017

n4ss and others added 12 commits March 2, 2017 19:15

Add lazy initialization of a repository at publish time

c046614

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Syntax fix by gofmt

9a4d4b8

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Add lazy initialization of a repository at publish time

d11ad89

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

lots of failing tests

dd059a6

Signed-off-by: David Lawrence <david.lawrence@docker.com> (github: endophage)

Fix rootkey IDs list creation causing faulty access at repo init

e556e94

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

TestNotInitializedOnPublish doesn't work with repo lazy init at publi…

5a9636a

…sh time Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Modify lazy init logic to bootstrap if metadata on disk

52a07d3

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Fix deprecated test accordingly to the new logic

1da4d7f

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Fix mishandled conflicts with types update PR

4182ca0

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Update deprecated tests for repo lazy init behavior

afc4985

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Move the decision to init repo based on cached content to its own method

1702384

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Move private keys retrieval from a crypto service to a helper function

6a1f1c1

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

n4ss force-pushed the repo-lazy-init branch from 7512f85 to 6a1f1c1 Compare March 2, 2017 18:15

riyazdf reviewed Mar 2, 2017

View reviewed changes

n4ss added 3 commits March 3, 2017 18:26

Fix test for rotation without explicit init by using a full test server

2e8d5ad

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Remove the root key cli parameter to 'notary publish'

9ff8415

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Add comments for metadata lookup function and initializeFromCache

73f678c

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

cyli reviewed Mar 3, 2017

View reviewed changes

n4ss added 2 commits March 3, 2017 23:29

Refactor the metadata retrieval to bootstrap repo from cache or from …

556e2b4

…scratch Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

Remove duplicate test for repo init and publish

7e74573

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

riyazdf reviewed Mar 3, 2017

View reviewed changes

Add debug logs in publish

d6ba9f9

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

endophage approved these changes Mar 8, 2017

View reviewed changes

Improve logs and adjust log-level for repo bootstrap

dd1ef8b

Signed-off-by: Nassim 'Nass' Eddequiouaq <eddequiouaq.nassim@gmail.com>

n4ss force-pushed the repo-lazy-init branch from f6fab38 to dd1ef8b Compare March 8, 2017 20:52

endophage merged commit 9917b88 into notaryproject:master Mar 8, 2017

Notary repository lazy initialization #1105

Notary repository lazy initialization #1105

Conversation

n4ss commented Feb 24, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

riyazdf Mar 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cyli commented Mar 4, 2017

endophage commented Mar 4, 2017

endophage left a comment

Choose a reason for hiding this comment

n4ss commented Feb 24, 2017 •

edited

Loading

riyazdf Mar 2, 2017 •

edited

Loading