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

Do not require signing if no there are no targets changes #1104

Merged

Conversation

cyli
Copy link
Contributor

@cyli cyli commented Feb 24, 2017

AddTarget and RemoveTarget currently checks if the user has valid signing keys regardless of whether the target actually needs to be added or removed, because both require signing regardless of whether the target needs to be added or removed.

Updates both functions so that if the target being added does not actually change the role, or if the target being removed doesn't actually change the role, signing keys are not required and the roles are not necessarily marked as dirty.


// Removing targets from a role that exists but without metadata succeeds.
func TestRemoveTargetsNonexistentMetadata(t *testing.T) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note - this test didn't actually seem to do what it claimed - the body was a duplicate of TestRemoveTargetsRoleDoesntExist. Since the previous test was supposed to test adding existing and non-existing targets anyway, I just removed this test and updated the previous one.

@cyli cyli force-pushed the do-not-sign-if-no-targets-change branch from b765789 to 62c836f Compare February 24, 2017 04:30
… signing keys

Signed-off-by: Ying Li <ying.li@docker.com>
@cyli cyli force-pushed the do-not-sign-if-no-targets-change branch 2 times, most recently from 2ebe68a to 96a9e1a Compare February 24, 2017 04:46
Copy link
Contributor

@riyazdf riyazdf left a comment

Choose a reason for hiding this comment

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

code LGTM

Only thing is I'm wondering if this will this be an issue for re-signing the contents of an almost expired targets file?

tuf/tuf_test.go Outdated
@@ -917,8 +952,12 @@ func TestRemoveTargetsNoSigningKeys(t *testing.T) {
// now delete the signing key (all keys)
repo.cryptoService = signed.NewEd25519()

// now remove the target - it should fail
err = repo.RemoveTargets("targets/test", "f")
// remove a nonexistant target - it should not fail
Copy link
Contributor

Choose a reason for hiding this comment

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

nit typo: nonexistent

@cyli
Copy link
Contributor Author

cyli commented Feb 24, 2017

@riyazdf I only changed AddTarget and RemoveTarget - it should still be possible to mark a targets file as dirty and cause it to sign, although we may have to add a new function for that. Doing so seems like it'd be more explicit than calling AddTarget of the same target or RemoveTarget of a non-existent target, though.

…igning keys

Signed-off-by: Ying Li <ying.li@docker.com>
@cyli cyli force-pushed the do-not-sign-if-no-targets-change branch from 96a9e1a to 187d076 Compare February 24, 2017 18:27
@riyazdf
Copy link
Contributor

riyazdf commented Feb 24, 2017

@cyli - makes sense, I agree with that. This could be an extension of witness or a new command entirely.

if f.Custom == nil && o.Custom == nil {
return true
}
fBytes, err := f.Custom.MarshalJSON()
Copy link
Contributor

Choose a reason for hiding this comment

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

Custom is of type *json.RawMessage which is just a re-typing of []byte. I'm wondering if it makes sense to unmarshal into a map[string]interface{} and remarshal canonically to determine actual equivalence vs face value byte for byte equality.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess on the other hand, there's no guarantee it's JSON inside the Custom field so maybe that's not worth doing.

if o.Length != f.Length || len(f.Hashes) != len(f.Hashes) {
return false
}
if f.Custom == nil && o.Custom != nil || f.Custom != nil && o.Custom == nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

This and the custom checks further down could probably all just be replaced with if *f.Custom != *o.Custom { return false }

Copy link
Contributor Author

@cyli cyli Feb 24, 2017

Choose a reason for hiding this comment

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

If f.Custom is nil, won't we get a panic trying to get *f.Custom? Also, if neither were nil, I think that still wouldn't work because the equality operator doesn't work on byte slices. :| For instance: https://play.golang.org/p/jY4yrw7lrL

Copy link
Contributor

Choose a reason for hiding this comment

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

ugh, yeah. I was thinking of the RawMessage being a []byte but we essentially have double indirection here. I remember we specifically put that in because of the whole "addressability" thing cause the RawMessage to get double base64 encoded, if that's not necessary any more (I feel like I remember something addressing RawMessage and this problem being merged in Go 1.7, possible 1.6) we could also make Custom a non-pointer RawMessage.

Copy link
Contributor

@endophage endophage left a comment

Choose a reason for hiding this comment

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

LGTM. We'll work out the RawMessage pointer or not in a separate PR at another time.

Copy link
Contributor

@ecordell ecordell left a comment

Choose a reason for hiding this comment

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

LGTM

@endophage endophage merged commit c04e3e6 into notaryproject:master Mar 2, 2017
@cyli cyli deleted the do-not-sign-if-no-targets-change branch March 2, 2017 16:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants