Skip to content
This repository has been archived by the owner on May 3, 2022. It is now read-only.

Signing a bundle now imply resolving image references into immutable references #428

Closed
wants to merge 12 commits into from
Closed

Signing a bundle now imply resolving image references into immutable references #428

wants to merge 12 commits into from

Conversation

simonferquel
Copy link
Contributor

This aims at having signed bundles truly immutable. That means that all referenced images (invocationImages or images) without a digest are modified into digested references:

  • if an image is available in the docker engine, and it has already a RepoDigest, we use it
  • if an image is not available in the docker engine, we pull it and get its RepoDigest
  • if an image is available in the docker engine, but has no RepoDigest, we consider that it has been built locally and has not yet been pushed. In that case we fail, and tell the user to push it.

Signed-off-by: Simon Ferquel simon.ferquel@docker.com

@technosophos
Copy link
Member

I am very much in favor of this.

@technosophos
Copy link
Member

make lint failed with a style error. I didn't look too carefully at it.

@simonferquel
Copy link
Contributor Author

Fixed linting issues.
A follow-up PR should be written to make "build" output an unsigned bundle (as build output references freshly built images, not yet in the registry).

Before merging this, I would also like to add a "--push-local-images" flag to the sign subcommand, leading to a "--push-images-and-sign" kind of flag for the build command.

@technosophos
Copy link
Member

/cc @radu-matei

@@ -23,6 +24,12 @@ func defaultUserID() signature.UserID {
name = account.Name
username = account.Username
}
// on Windows, account name are prefixed with '<machinename>\' which makes the generated email invalid
// and makes the key user identity parser fail
if ix := strings.Index(username, "\\"); ix != -1 {
Copy link
Member

Choose a reason for hiding this comment

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

Ah! Glad you caught that. Thanks

@simonferquel
Copy link
Contributor Author

PTAL @technosophos

This was referenced Nov 21, 2018
@simonferquel
Copy link
Contributor Author

Rebased and splitted the change to fix user-identity resolution on Windows

@jeremyrickard
Copy link
Member

jeremyrickard commented Nov 28, 2018

@simonferquel I went ahead and updated this to fix the conflicts and resolve the repo move.

I also updated this todo the following:

Updated duffle build so that by default it pushes the images (the build process image resolver defaults to true ) since we desire to have signing happen by default

In summary:

  • $ duffle bundle sign <...> will fail if an image isn't pushed, but you can tell it to
  • $ duffle build will default push images to the registry to get the digest and update the bundle before the signing happens

Repeating: When you do a duffle build it will by default push images to your registry since we need that to get the digests

jeremyrickard and others added 5 commits November 28, 2018 16:52
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
@jeremyrickard jeremyrickard added this to In progress in MVP via automation Dec 3, 2018
@jeremyrickard jeremyrickard moved this from In progress to Needs review in MVP Dec 3, 2018
@@ -134,6 +135,19 @@ func (b *buildCmd) run() (err error) {
if err := bldr.Build(ctx, app); err != nil {
return err
}
cli := command.NewDockerCli(os.Stdin, os.Stdout, os.Stderr, false)
if err := cli.Initialize(dockerflags.NewClientOptions()); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a reason we aren't using b.dockerClientOptions here?

@@ -48,13 +52,20 @@ func newBundleSignCmd(w io.Writer) *cobra.Command {
if err != nil {
return err
}
return sign.signBundle(bundle, secring)
cli := command.NewDockerCli(os.Stdin, os.Stdout, os.Stderr, false)
if err := cli.Initialize(flags.NewClientOptions()); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

we should probably add all the docker CLI flags similar to duffle build if we're pushing images with duffle bundle sign.

@bacongobbler
Copy link
Contributor

I'm not a huge fan of the experience of having to push when building or signing bundles. It breaks the most basic first-time user story, which is pasted all across the documentation:

$ duffle create helloworld
Creating helloworld
$ duffle build .\helloworld\
Step 1/5 : FROM alpine:latest
 ---> 196d12cf6ab1
Step 2/5 : RUN apk add -u bash
 ---> Using cache
 ---> 54b3a85c5c2e
Step 3/5 : COPY Dockerfile /cnab/Dockerfile
 ---> Using cache
 ---> cd6f4ff8d83d
Step 4/5 : COPY app /cnab/app
 ---> Using cache
 ---> 17c792d82fd8
Step 5/5 : CMD ["/cnab/app/run"]
 ---> Using cache
 ---> 918e05577bd7
Successfully built 918e05577bd7
Successfully tagged microsoft/helloworld-cnab:b96538fe33ad4eb65c70e254af58b0f7187ee408
The push refers to repository [docker.io/microsoft/helloworld-cnab]

?[1Bdcd4ba9d: Preparing
?[1B22981d33: Preparing
?[1Bb351a0cb: Preparing
?[1BError: denied: requested access to the resource is denied

In my opinion this is an incredibly poor user experience and we're going to have a very hard time explaining this to first-time users. My view is that given we know there's a technical limitation with how docker's CLI requires pushing to a registry to compute a digest, we should not merge this and instead focus on replacing the docker driver with buildkit as explained in #563. I feel that users being on-boarded to the project would be more understanding about us holding out for a better solution than shoehorning something in last minute that significantly affects the first-time user experience.

@squillace
Copy link

I've thought a lot about this, because from about almost every technical and usability angle it's a poor story with little defense except for "stuff is this way at the moment". I'm going to suggest that this be closed in favor of something like #563, however tempting it is to move things along. It is just not the right way to do this.

I'll leave the PR open for comments for today, but absent a better argument, I'll close it tomorrow morning. (I hate closing PRs on well-submitted code. booo.)

@bacongobbler
Copy link
Contributor

closing in favour of #563.

MVP automation moved this from Needs review to Done Dec 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
MVP
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

5 participants