Verify image signature #13585

mfojtik · 2017-03-30T12:54:36Z

Fresh version of: #12616 based on @mtrmac branch (rebased and polished to complain with the origin commit format).

This version is based on the containers/image and not just bundling the opengpg support for origin.
Trello: https://trello.com/c/BIJBu7qi/788-5-images-fill-in-the-metadata-signature-fields-when-a-signature-is-valid

mfojtik · 2017-03-30T12:55:42Z

[test]

@mtrmac I think the db3a491 commit is controversial and I don't think it will pass our validation. Can you explain why we need that there? (it does not exists in the upstream yet?). In that case we might need to add that as a "pick" or "carry" patch.

mfojtik · 2017-03-30T12:56:02Z

@smarterclayton @miminar can you guys review this pls?

mtrmac · 2017-03-30T14:27:45Z

@mtrmac I think the db3a491 commit is controversial and I don't think it will pass our validation

Which one is that? github can’t find it.

FWIW some points to consider WRT the c-i-verify-image-signature branch:

It would be nice to get rid of 5d42163 (“Eliminate dependency on containers/image/docker … to minimize version skew (on strslice, tlsconfig)”, by using a compatible version of both. I didn’t look into what that would take.
ed7bc58 (“Use signature.PolicyContext for image verification … instead of manual usage of SignatureMechanism.”) may not be what you want, notably it causes VerifyImageSignatureOptions.PublicKey* in this PR to be accepted and ignored, and instead the system-wide policy.json is used.

What to do really depends on what kind of CLI you want.

A plausible alternative would be to replace the signature.DefaultPolicy(nil) with manually constructing a policy with
```
 pr, err := signature.NewPRSignedByKeyPath(signature.SBKeyTypeGPGKeys, options.PublicKeyFilename, signature.NewPRMMatchRepoDigestOrExact())
 if err != nil {…}
 policy := signature.Policy{Default:[]signature.PolicyRequirement{pr}}
```
or so.

mtrmac · 2017-03-30T14:58:16Z

@mtrmac I think the db3a491 commit is controversial and I don't think it will pass our validation

Which one is that? github can’t find it.

Well, now I see it: “Manually add vendor/github.com/opencontainers/image-spec/specs-go/v1/ : I have no idea how to make Godeps copy this in it seems.”

That commit is not “controversial”, it’s flat out wrong; I just couldn’t find a working solution quickly when preparing the prototype. Hopefully someone familiar with the OpenShift use of Godeps can find it trivial to do the right thing; if not, I’d have to do some digging.

mfojtik · 2017-03-30T16:50:02Z

@mtrmac i made it so our commit checker won't scream, but I want to ask why you need to manually add those

mtrmac · 2017-03-30T16:53:11Z

It’s not that I want to add them manually. github.com/opencontainers/image-spec/specs-go/v1 is a package required by some subpackages of containers/image, so it is needed and it should be somehow pulled in by Godeps. It’s just that I couldn’t, in the limited time I spent on this, persuade Godeps to actually do so.

This definitely should be done by using Godeps correctly instead of this manual patch.

mfojtik · 2017-03-31T09:05:36Z

@mtrmac i think my question was more like if the github.com/opencontainers/image-spec/specs-go/v1 mean we need newer version of this image-spec.

mfojtik · 2017-04-03T10:32:44Z

@mtrmac I think I realized why this will not work:

$ go get -u github.com/mtrmac/gpgme
# github.com/mtrmac/gpgme
../../mtrmac/gpgme/data.go:4:20: fatal error: gpgme.h: No such file or directory
 // #include <gpgme.h>

This is what basically godep restore calls (go get -u ...). I know that we have build tag that prevents origin from building with gpgme support, but since we have to go get it during the godep restoration process, it will always fail if we don't install gpgme-devel and libassuan-devel.

@smarterclayton would adding two extra packages to the build process acceptable? Note that those are disabled by a build tag that force it to build with Go openpgp instead... But we need to get them because godep sux :-(

mtrmac · 2017-04-03T17:59:38Z

@mtrmac i think my question was more like if the github.com/opencontainers/image-spec/specs-go/v1 mean we need newer version of this image-spec.

N/A? OpenShift does not currently, AFAICS, depend on the above-quoted package at all. This PR is adding the dependency; so I don’t know what newer/older is referring to.

mtrmac · 2017-04-03T18:03:26Z

@mtrmac I think I realized why this will not work:
$ go get -u github.com/mtrmac/gpgme
# github.com/mtrmac/gpgme
../../mtrmac/gpgme/data.go:4:20: fatal error: gpgme.h: No such file or directory
 // #include <gpgme.h>
This is what basically godep restore calls (go get -u ...).

That does not quite explain why I wasn’t able to use godep for that, because I do have all the necessary headers to use gpgme and the above go get does not fail for me. But you are quite right that it may be very relevant for the OpenShift build process.

mfojtik · 2017-04-04T08:13:08Z

(btw. I am waiting here for the 1.6 rebase to land and then do the godep restore one more time...)

mfojtik · 2017-04-04T08:25:10Z

@mtrmac

N/A? OpenShift does not currently, AFAICS, depend on the above-quoted package at all. This PR is adding the dependency; so I don’t know what newer/older is referring to.

If it is adding new dependency, why you then added the v1/ folder in extra commmit instead of just adding it together with the new package? It is because the package version you copied to godeps does not include the v1/ folder? If yes, what I'm asking is to give me the version that does include it, or an explanation why you added it as a separate commit :-)

I figured it out, it can be squashed to the initial addition as the revision you used in Godeps.json includes v1/ folder.

That does not quite explain why I wasn’t able to use godep for that, because I do have all the necessary headers to use gpgme and the above go get does not fail for me. But you are quite right that it may be very relevant for the OpenShift build process.

You do, but if our Jenkins or any Origin developer will do godep restore after this merge, they don't necessary have those headers/libs installed. What I am saying is the Origin does not require those headers/libs (because we use build tag to opt-them-out), but godeps does not respect the build tags at all and will fail without having them (because it will try to build the containers/image)...
I don't think it is a show-stopper here, just annoying for other maintainers and reason why I hate to
use build tags.

At this point, I will just wait for the rebase to land (maybe I will start rebasing this on top of kubernetes 1.6 rebase when it gets stable) and we target to merge this for origin 3.6 (after 1.6 rebase lands, so we don't mess the guys doing the rebase...) Meanwhile, are there any review comments on the current PR/approach that should be addressed (besides godeps), or is this good to go after we are unblocked on the rebase?

@smarterclayton @soltysh @miminar PTAL as well, this is required from PM in 3.6

miminar · 2017-04-04T11:26:59Z

hack/common.sh

@@ -187,6 +187,8 @@ os::build::internal::build_binaries() {
    version_ldflags=$(os::build::ldflags)

    # Use eval to preserve embedded quoted strings.


The eval comment should be followed by the eval statement.

miminar · 2017-04-04T11:34:57Z

pkg/cmd/admin/image/verify-signature.go

+// verifySignature verifies the image signature and returns the identity when the signature
+// is valid.
+func (o *VerifyImageSignatureOptions) verifySignature(pc *signature.PolicyContext, img *imageapi.Image, sigBlob []byte) (string, error) {
+	// Pretend that this is the only signature of img, and see what the policy says.


I thought, this doesn't take into account any policy file.

@mtrmac ^ i thought we are not going to require policy.json here at all.

nvmd. this is referring to PolicyContext which we create in caller of this function.

i thought we are not going to require policy.json here at all.

This is up to you.

The code as is right now includes ed7bc58 , which uses policy.json.

#13585 (comment) instead proposes another alternative, asking the user to provide a keyring and using only that one.

(The original PR was using the user’s default keyring by default; that’s plausible but not obviously the right thing to do: Habitual GPG users tend to have keyserver-options auto-key-retrieve in ~/.gnupg/gpg.conf, i.e. the default keyring contains various keys with varying levels of trust for email and such, which tends to have very little intersection with trust for running containers. The current containers/image API does not make it trivial to use the signature verification code with “all of ~/.gnupg” as the set of trusted keys, hence the two proposed alternatives above.)

miminar · 2017-04-04T11:35:41Z

pkg/cmd/admin/image/verify-signature.go

+		return "", errors.New("internal error: signature rejected but no error set")
+	}
+	if err != nil {
+		return "", fmt.Errorf("signsture rejected: %v", err)


miminar · 2017-04-04T11:41:28Z

pkg/cmd/admin/image/verify-signature.go

+		return "", fmt.Errorf("signsture rejected: %v", err)
+	}
+
+	// Because s.Content was the only signature used above, we now know that s.Content is acceptable, so untrustedInfo is good enough.


This is outdated and doesn't make sense to me.

AFAICT this comment still applies: It was trying to say that we are calling an UntrustedSignatureInformation function but presenting the key ID as a trusted value, and the comment justifies why this is a safe thing to do. (Feel free to leave it out if you think this does not need pointing out.)

miminar · 2017-04-04T12:52:32Z

pkg/cmd/admin/image/verify-signature.go

+// fakeDockerReference is containers/image/docker.Reference, except that only provides identity information.
+type fakeDockerReference struct{ ref reference.Named }
+
+// parseReference converts a string, which should not start with the ImageTransport.Name prefix, into an Docker ImageReference.


parseDockerReference

miminar · 2017-04-04T13:07:15Z

pkg/image/registry/image/strategy.go

@@ -115,9 +112,6 @@ func (s imageStrategy) PrepareForUpdate(ctx kapi.Context, obj, old runtime.Objec
 	if err = api.ImageWithMetadata(newImage); err != nil {
 		utilruntime.HandleError(fmt.Errorf("Unable to update image metadata for %q: %v", newImage.Name, err))
 	}
-
-	// clear signature fields that will be later set by server once it's able to parse the content
-	s.clearSignatureDetails(newImage)


This method doesn't seem to be used anymore.

miminar · 2017-04-04T13:10:56Z

pkg/cmd/admin/image/verify-signature.go

+func NewCmdVerifyImageSignature(name, fullName string, f *clientcmd.Factory, out, errOut io.Writer) *cobra.Command {
+	opts := &VerifyImageSignatureOptions{ErrOut: errOut, Out: out}
+	cmd := &cobra.Command{
+		Use:     fmt.Sprintf("%s IMAGE [--confirm]", name),


This should mention --expected-identity=… since it's mandatory argument.

I'd prefer just %s IMAGE EXPECTED_IDENTITY [--confirm], but I'm repeating myself.

miminar · 2017-04-04T13:15:04Z

pkg/cmd/admin/image/verify-signature.go

+	By default, this command will not record a signature condition back to the Image object but only
+	print the verification status to the console.
+
+	To record a new condition, you have to pass the "--confirm" flag.


The help should mention that verifying single signature using different --public-key will clear verification status from all the other image signatures not signed by this key.

And the same for expected-identity.

Dump question, but can I verify just single image with this key? Is it possible to specify multiple public keys when validating multiple images?

I read further, when only single image is verified at the time, how can I clear status from other images. Seems odd reading this.

Dump question, but can I verify just single image with this key?

The command works on single image. The problem is that the command can verify at most one signature at the time. The image can have multiple signatures though.

Is it possible to specify multiple public keys when validating multiple images?

Currently not but may be nice. I wouldn't make it a requirement for this PR though.

how can I clear status from other images

I think a script or oc observe are your best options.

Seems odd reading this.

Agree.

Is it possible to specify multiple public keys when validating multiple images?

That depends on what the verification mechanism will end up being (see #13585 (comment) ), but so far all of the alternatives (policy.json, manually-created single-rule policy, manual SignatureMechanism invocation) accept a GPG keyring, which can contain several public keys; any of the keys is equally acceptable. (When that keyring is specified for a command, all images verified using that command would use the same keyring and the same complete set of public keys; it is not a 1-1 image-key mapping.)

mfojtik · 2017-04-05T14:45:38Z

[test]

interesting... it seems like just flakes.

mfojtik · 2017-04-06T11:20:24Z

[test]

mfojtik · 2017-04-06T19:03:51Z

[test]

miminar · 2017-04-07T05:03:49Z

pkg/cmd/admin/image/verify-signature.go

+func NewCmdVerifyImageSignature(name, fullName string, f *clientcmd.Factory, out, errOut io.Writer) *cobra.Command {
+	opts := &VerifyImageSignatureOptions{ErrOut: errOut, Out: out}
+	cmd := &cobra.Command{
+		Use:     fmt.Sprintf("%s IMAGE EXPECTED_IDENTITY [--confirm]", name),


The EXPECTED_IDENTITY suggests that the identity is a positional argument (something passed without leading --option on a fixed position). I like that, but the code below still defines --expected-identity and expects len(args) == 1 which is wrong. To keep the help message as is, the --expected-identity needs to go away and the identity needs to be fetched from args[1].

will "%s IMAGE --expected-identity=EXPECTED_IDENTITY [--confirm]" do?

@mfojtik sure

Why do you hate positional args? 😄 I don't get it. 😕

@miminar if we ever want to add additional args with expected something, then we will have to keep adding to positional args which is ugly ;-) I want admins to know what they are doing.

I just find --expected-identity= too long to be given every time. This limits the usage of the tool really just to scripts. But it's just a subjective observation. I don't push you to any further changes.

it makes it long, but on the other hand it makes it really explicit on what are you expecting to be in the signature and it also helps understand what that flag is for. Otherwise it might look really strange to provide the name of the image (sha256:xxxxxxx) and then, again a name of the image...

soltysh

I left you some comments, the only part I didn't inspect carefully is the code verification. I guess there are more knowledgeable people to verify it.

soltysh · 2017-04-07T08:53:13Z

Godeps/Godeps.json

+			"Rev": "c07f8fdceeda1517556602778a61ba94894e7c02"
+		},
+		{
+			"ImportPath": "github.com/containers/storage/pkg/homedir",


Can we get this part a separate commit, for clear history?

thanks for hating me :-) sure it can.

It's not about hating you, I ❤️ you man! It's about having clear history when and what was added 😉

soltysh · 2017-04-07T08:55:14Z

Godeps/Godeps.json

@@ -1964,6 +1964,10 @@
 			"Rev": "5cbbc6bafb45bd7ef10486b673deb3b81bb3b787"
 		},
 		{
+			"ImportPath": "github.com/mtrmac/gpgme",


If we are planning on using fork, create one under openshift org.

This is still not addressed.

This is not an OpenShift-specific fork; containers/image and projectatomic/skopeo use the same one. See proglottis/gpgme#6 for the full history behind creating it. Hopefully it will eventually go away.

If OpenShift wants to take over that fork and commit to maintaining it, sure, why not. I don’t see how OpenShift benefits (especially because OpenShift opts out of actually using anything in this package, using the containers_image_openpgp build tag), but I’d be only too happy to hand over this responsibility :)

OK, I wasn't aware of the full story behind it.

soltysh · 2017-04-07T08:57:17Z

pkg/cmd/admin/image/verify-signature.go

+
+var (
+	verifyImageSignatureLongDesc = templates.LongDesc(`
+	Verifies the imported image signature using the local public key.


Imported where? Is this only against images from the internal registry, if so be explicit.

soltysh · 2017-04-07T08:59:13Z

pkg/cmd/admin/image/verify-signature.go

+	By default, this command will not record a signature condition back to the Image object but only
+	print the verification status to the console.
+
+	To record a new condition, you have to pass the "--confirm" flag.


Dump question, but can I verify just single image with this key? Is it possible to specify multiple public keys when validating multiple images?

soltysh · 2017-04-07T09:00:41Z

pkg/cmd/admin/image/verify-signature.go

+	By default, this command will not record a signature condition back to the Image object but only
+	print the verification status to the console.
+
+	To record a new condition, you have to pass the "--confirm" flag.


I read further, when only single image is verified at the time, how can I clear status from other images. Seems odd reading this.

soltysh · 2017-04-07T09:10:57Z

pkg/cmd/admin/image/verify-signature.go

+		},
+	}
+
+	cmd.Flags().BoolVar(&opts.Confirm, "confirm", opts.Confirm, "If true, the result of the verification will be recorded to an image object.")


I'd suggest using record here, rather than confirm. The former suggests that something has to be recorded from the operation, see --record in oc apply. Whereas confirm, suggests confirmation, that's not what happens here, you're not doing any dry run which needs to be then confirmed.

@soltysh --record records the command into an annotation. it will be confusing if it has different behavior for verification?

For me --confirm holds this type of confusion right now. Whereas --record seems more reasonable. @openshift/cli-review wdyt?

--record=false: Record current kubectl command in the resource annotation.

This is clearely not this case, since --record will do more than recording an annotation. We also have --confirm for pruning and importing image stream, so I will want to keep it --confirm just for the sake of consistency.... you spend too much time in kubectl world @soltysh :P

For me --confirm + verify does not sound good enough. --confirm for pruning is because the initial operation is dry-run, and you need to explicitly confirm it. Not sure how this applies to signature verification. I'm not saying --record is the best option, I'm just arguing against using --confirm. Maybe something else should be used here, that's why I asked @openshift/cli-review, we developers are soooo bad at naming things 😉

"record", "log", "post", "confirm"... No perfect option, IMO.

As a user I assume this is the default. Why do we need this option? I would rather add a "do not record status" flag later based on user feedback.

One reason to include this option is if the user does not have privilege to write the verification status. I'm okay with not writing the status as long as we report that to the user.

Another use case is if someone has an incorrect public key. They would be annotating incorrect status.

Record is very specific to apply today.

Confirm is when we ask the user a question. Force is when we override a safety default. We're not doing either here. --save is probably the closest to what you want.

I'm good with --save. Thinking through this, there are probably plenty of use cases to justify a --save=false default. Ignore my noise above.

i'm taking --save as our best option. thanks!

soltysh · 2017-04-07T09:15:22Z

pkg/cmd/admin/image/verify-signature.go

+				LastProbeTime:      now,
+				LastTransitionTime: now,
+				Reason:             "verified manually",
+				Message:            fmt.Sprintf("verified by user %s", o.CurrentUser),


verified by %q, would give use nice verified by 'userA'

also records quotes into API object ;-) i don't mind honestly, but I found no quotes nicer as they don't have to be escaped.

soltysh · 2017-04-07T09:20:45Z

pkg/cmd/admin/image/verify-signature.go

+}
+
+// fakeDockerReference is containers/image/docker.Reference, except that only provides identity information.
+type fakeDockerReference struct{ ref reference.Named }


fake suggests it's used for testing, pick a different name, eg. identityOnlyDockerReference, dummyDockerReference. I think, I'm leaning towards the former.

you must be looking at outdating commit, this was removed already.

soltysh · 2017-04-07T09:21:55Z

pkg/cmd/cli/describe/describer.go

+	formatString(out, "\tType", s.Type)
+	if s.IssuedBy == nil {
+		// FIXME: Make this constant
+		formatString(out, "\tStatus", "Unverified")


I think <none would make it more explicit and stand out more.

No, it should be either "verified" or "unverified". Any image that was not verified manually is "unverified"... "<none>" might be misleading.

I don't like using the negation - generally we try to have status constants that are significantly different from each other. The constants are what are important - why not simply output the conditions?

@smarterclayton I thought we want to have clear message about "verified vs. unverified" image. Returning only conditions gives a person who is familiar with them clue about the verification status but I don't think it will make it obvious.

soltysh · 2017-04-07T09:23:20Z

pkg/cmd/admin/image/verify-signature.go

+	`)
+)
+
+type VerifyImageSignatureOptions struct {


Tests are needed, preferably unit and cmd, but at least one is required.

it will have to be a follow up and we have to rely on QE manual testing of this for now.
having a test for this will require infra changes (need a gpg key, skopeo installed, copying signed image, genering public key, etc..)

Sigh.... I'm ok with a followup (at least partially) + QE.

issue created...

soltysh

One godep I'd suggest to turn into a openshift fork + the flag naming is my only objections. All the rest lgtm.

soltysh · 2017-04-10T13:36:16Z

Godeps/Godeps.json

@@ -1964,6 +1964,10 @@
 			"Rev": "5cbbc6bafb45bd7ef10486b673deb3b81bb3b787"
 		},
 		{
+			"ImportPath": "github.com/mtrmac/gpgme",


This is still not addressed.

aweiteka · 2017-04-10T15:00:52Z

pkg/cmd/admin/image/verify-signature.go

+	cmd.Flags().BoolVar(&opts.Confirm, "confirm", opts.Confirm, "If true, the result of the verification will be recorded to an image object.")
+	cmd.Flags().BoolVar(&opts.Remove, "remove", opts.Remove, "If set, all signature verifications will be removed from the given image.")
+	cmd.Flags().StringVar(&opts.PublicKeyFilename, "public-key", opts.PublicKeyFilename, "A path to a public GPG key to be used for verification.")
+	cmd.Flags().StringVar(&opts.ExpectedIdentity, "expected-identity", opts.ExpectedIdentity, "An expected image docker reference to verify.")


"--expected-identity" isn't clear enough to me.

"--image-name", "--image-reference" or just "--name" works better IMO.

--expect-name would be correct, if the thing being compared is the "name" of the image.

From the perspective of the end user, they know project/imagestream==name. I believe that's the value we expect here.

@aweiteka @mtrmac thought this should match with the skopeo terminology where this thing is called "image identity". Also this does not match to "image name" (as openshift image name is in sha256:foo format), but it matches to the docker pull spec (x.x.x.x:5000/foo/bar@...).

As for the format, of the value, this is ordinarily a hostname/ns…/repo:tag, but it also may be a hostname/ns…/repo@algo:digest.

For internally created images the value would ordinarily semantically match project/imagestream, ± details of the syntax.

For externally imported images, the expected identity and the imagestream name would, in general, not match; the expected identity of a RHEL image imported into the imagestream, when verifying the Red Hat signature, is registry.access.redhat.com/…/rhel:$something, not mycluster.example.com/myproject/baseimage:$somethingelse.

smarterclayton · 2017-04-10T19:36:43Z

hack/common.sh

@@ -234,7 +236,7 @@ os::build::internal::build_binaries() {
      if [[ ${#nonstatics[@]} -gt 0 ]]; then
        GOOS=${platform%/*} GOARCH=${platform##*/} go install \
          -pkgdir "${OS_OUTPUT_PKGDIR}/${platform}" \
-          -tags "${OS_GOFLAGS_TAGS-} ${!platform_gotags_envvar:-}" \
+          -tags "${common_gotags} ${OS_GOFLAGS_TAGS-} ${!platform_gotags_envvar:-}" \


The code at this level shouldn't have to know about specific tags. You need to set this in build-cross / build-go.

mfojtik · 2017-05-02T12:33:31Z

@mtrmac @miminar ok, I wrote a simple helper that will retrieve the manifest from the registry. It will use the bearer token/username from the user running the command (which makes using --as=system:admin impossible, but that is a good thing because you don't want to hide the identity of the user that is verifying the image anyway...).

The latest version is also not using the DefaultPolicy(nil), so I believe it should really do some level of verification of the image identity/signature...

I really hesistate to make this command more complex by using containers/image docker transport/etc. For the current scope of this command, this is only intended for local (managed) images only (iow. only images managed by openshift registry)...

miminar · 2017-05-02T12:47:54Z

pkg/image/util/manifest.go

+
+// GetImageManifestFromRegistry retrieves the image manifest from the registry using the basic
+// authentication using the image ID.
+func GetImageManifestFromRegistry(registry *url.URL, repositoryName, imageID, username, password string) ([]byte, error) {


Can you name it like GetImageManifestByIDFromRegistry() since it doesn't support tags?

mfojtik · 2017-05-02T19:50:04Z

[test]

…4e7c02

…8e77b9159ba1eb

…b7000b2fcbd26fa

mfojtik · 2017-05-03T09:44:14Z

as a follow ups:

make an extended test using the origin image + gpg + skopeo to actually push signed image into registry and use this command to verify it
human readable GPG identity instead of GPG key ID
fix error messages in containers/image (when GPG keyring is not found for example or GNUPGHOME is not set)
add support for external registries (so I can verify image imported from an non-openshift registry - trelloed)
remove imageapi.SignatureForImage crazyness from validation (or at least make it useful and contain the actual identity of the image)

openshift-bot · 2017-05-03T09:53:29Z

Evaluated for origin test up to 8d19047

openshift-bot · 2017-05-03T11:19:25Z

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/1110/) (Base Commit: 13b90e2)

mfojtik · 2017-05-03T12:51:00Z

lgtmed by @miminar per IRC

[merge]

mfojtik · 2017-05-04T08:14:24Z

flake: #13942

[merge]

mfojtik · 2017-05-04T11:53:12Z

[merge] flake: #14044

openshift-bot · 2017-05-04T11:53:27Z

Evaluated for origin merge up to 8d19047

openshift-bot · 2017-05-05T02:45:42Z

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin/561/) (Base Commit: 8508081) (Image: devenv-rhel7_6212)

miminar · 2017-05-09T07:36:26Z

mfojtik · 2017-05-09T08:06:29Z

@aweiteka FYI

mfojtik force-pushed the verify-signature branch from d2b074a to c47f0ad Compare March 30, 2017 13:39

mfojtik mentioned this pull request Mar 30, 2017

Verify image signatures #12616

Closed

mfojtik added this to the 1.6.0 milestone Apr 3, 2017

miminar suggested changes Apr 4, 2017

View reviewed changes

mfojtik force-pushed the verify-signature branch from c47f0ad to 4e34ccd Compare April 5, 2017 12:06

This was referenced Apr 6, 2017

Add gpgme and libassuan to install dependencies openshift/vagrant-openshift#535

Merged

Add gpgme and libassuan to release dockerfile #13652

Merged

miminar reviewed Apr 7, 2017

View reviewed changes

soltysh requested changes Apr 7, 2017

View reviewed changes

mfojtik force-pushed the verify-signature branch 2 times, most recently from 2967181 to 479caf0 Compare April 10, 2017 11:37

mfojtik mentioned this pull request Apr 10, 2017

Add tests for image signatures #13698

Closed

soltysh requested changes Apr 10, 2017

View reviewed changes

aweiteka reviewed Apr 10, 2017

View reviewed changes

smarterclayton reviewed Apr 10, 2017

View reviewed changes

mfojtik force-pushed the verify-signature branch 2 times, most recently from ace87fc to f64d637 Compare May 2, 2017 12:15

miminar reviewed May 2, 2017

View reviewed changes

mfojtik force-pushed the verify-signature branch 2 times, most recently from 285f8b8 to f247cc0 Compare May 2, 2017 14:24

mfojtik and others added 9 commits May 3, 2017 10:58

bump(golang.org/x/crypto): 1f22c0103821b9390939b6776727195525381532

fbd207f

bump(github.com/containers/image): c07f8fdceeda1517556602778a61ba9489…

84b968e

…4e7c02

bump(github.com/containers/storage): 5cbbc6b

900e51e

bump(github.com/mtrmac/gpgme): b2432428689ca58c2b8e8dea9449d3295cf96fc9

01704f7

bump(github.com/opencontainers/go-digest): a6d0ee40d4207ea02364bd3b9e…

301e787

…8e77b9159ba1eb

bump(github.com/opencontainers/image-spec): 00850eca2ab993e282a4921f8…

3b471f6

…b7000b2fcbd26fa

Always build with -tags=containers_image_openpgp

15a5b91

image: add verify-image-signature command for image admins

9bf5f8d

update generated docs and completion

8d19047

mfojtik force-pushed the verify-signature branch from f247cc0 to 8d19047 Compare May 3, 2017 09:45

openshift-bot merged commit e7e8ae1 into openshift:master May 5, 2017

mtrmac mentioned this pull request May 10, 2017

Add signing metadata during push to API containers/skopeo#193

Closed

mfojtik deleted the verify-signature branch September 5, 2018 21:08

		@@ -187,6 +187,8 @@ os::build::internal::build_binaries() {
		version_ldflags=$(os::build::ldflags)

		# Use eval to preserve embedded quoted strings.

Verify image signature #13585

Verify image signature #13585

Conversation

mfojtik commented Mar 30, 2017 • edited Loading

mfojtik commented Mar 30, 2017

mfojtik commented Mar 30, 2017

mtrmac commented Mar 30, 2017 • edited Loading

mtrmac commented Mar 30, 2017

mfojtik commented Mar 30, 2017

mtrmac commented Mar 30, 2017

mfojtik commented Mar 31, 2017

mfojtik commented Apr 3, 2017

mtrmac commented Apr 3, 2017

mtrmac commented Apr 3, 2017

mfojtik commented Apr 4, 2017

mfojtik commented Apr 4, 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

mfojtik commented Apr 5, 2017

mfojtik commented Apr 6, 2017

mfojtik commented Apr 6, 2017

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

mfojtik Apr 10, 2017 • edited Loading

Choose a reason for hiding this comment

miminar Apr 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

soltysh left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfojtik Apr 10, 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

mfojtik commented Mar 30, 2017 •

edited

Loading

mtrmac commented Mar 30, 2017 •

edited

Loading

mfojtik commented Apr 4, 2017 •

edited

Loading

mfojtik Apr 10, 2017 •

edited

Loading

miminar Apr 10, 2017 •

edited

Loading

mfojtik Apr 10, 2017 •

edited

Loading