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

Unify verification messages between containers and blobs #3317

Open
jonvnadelberg opened this issue Oct 23, 2023 · 3 comments
Open

Unify verification messages between containers and blobs #3317

jonvnadelberg opened this issue Oct 23, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@jonvnadelberg
Copy link
Contributor

Description

Currently, when verifying a container, you get a message saying what items were verified followed by a non-human readable string of text.

When you verify a blob, you get back the simple string "Verified OK".

The two verification processes should produce the same output, and probably should not spit out large volumes of text that are not supposed to be readable by humans.

@jonvnadelberg jonvnadelberg added the enhancement New feature or request label Oct 23, 2023
@viveksahu26
Copy link
Contributor

I looked into the internal working of cosign verification for blob as well as image for key mode.

  • Image verification:
    • When we verify a image, we provide a public key and image(i.e. payload or kind of artifact). And internally cosign verifies the signature(stored in image layer) against the public key. That's it and return the output.
  • Blob verification:
    • When we verify a blob, we provide a public key, signature and artifact. Internally, cosign uses public key against the signature, which returns the hash value. And this hash value is check against the calculated hash value of a provided artifact. And if both hash matches, then artifact is verified.

Difference b/w Image verification and blob verification:

  • In image verification cosign doesn't matches the hash values, whereas in case of blob, it matches the hash values.
  • Just for additional info: In image, signature is present in image layer, i.e. within the image(i.e. artifact) itself, whereas in blob it's not the case.

Now, come back to the issue: What we can do to make the o/p of verification of blob and image as the same:

  • In image verification, we can configure cosign to go one more step ahead for verification and that is to verify the hash value. We know when public key is check against the signature, it must returns the hash, which is actually the hash of payload. Cosign can internally calculate the hash of payload and match them. If they does, that means verification success and simple return the same o/p for blob i.e. Verified OK.

I tried to verify image like verifying blob by providing payload(i.e. artifact), public key, and signature:

$ cosign verify-blob --key cosign.pub --signature signature payload 
Verified OK

NOTE: I didn't sign the image as like blob, i simply extracted those values during normal image signing process.

$ cosign sign --key cosign.key --output-payload=payload --output-signature=signature  viveksahu26/hi-cosign:main

Hey @haydentherapper @cpanato @hectorj2f need your suggestion on this. Would be great to hear from you all.

@haydentherapper
Copy link
Contributor

Rather than simply output Verified OK, I'd rather look at structuring the output to be machine readable, and contain information about what steps were taken during verification (key vs cert, log verification, timestamp verification etc). This relates to #2210, I could imagine similar output.

@viveksahu26
Copy link
Contributor

Rather than simply output Verified OK,

But that what an user want. Complete verification to be done internally and no machine-readable o/p to be thrown until and unless user explicit want that. The blob verification whether using key or keyless follows the same simple o/p in one line Verified Ok. Therefore same, could be applicable for image as well.

I'd rather look at structuring the output to be machine readable, and contain information about what steps were taken during verification (key vs cert, log verification, timestamp verification etc).

This seems to be heading towards inspect command. So, we can do one thing is, to add support of a flag --inspect in verify command. If the flag is true then show the whole o/p in detail. Whether we can show the same o/p which currently image verification shows or add more detail to it later that inspect supposed to show. And if flag is false, then simple print Verified OK.

I'd rather look at structuring the output to be machine readable. This relates to #2210, I could imagine similar output.

I didn't get about machine readable format. AFAIK, the machine o/p is similar to below o/p or something else you mean to.

{
    "critical": {
      "identity": {
        "docker-reference": "index.docker.io/viveksahu26/hi-cosign"
      },
      "image": {
        "docker-manifest-digest": "sha256:2a82a3d5bfda5c43d2e0e8880a7044985d6839e3c892f2b0c1fd0b010a0eedcc"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "1.3.6.1.4.1.57264.1.1": "https://accounts.google.com",
      "Bundle": {
        "SignedEntryTimestamp": "MEQCIG1746zc7KR8YOEArWLpHFEFI6hxLUZcBkSdWj8ahOO3AiBlLPsKOdZocMb5tUXgJFJLLJ3vgc3bGFCAJNM1ok8JUA==",
        "Payload": {
          "body": "eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiIzNTg2Y2ZiOTU0ZTgxYTU0Yzg3NzRiZWY1MjhhZWVhYTQ5OGExNWRkZDQxNjU2MWRjZjZlN2VlYmU2MTUzNjVhIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FWUNJUUNZUjFCZlFmSi96c3FKeEgxZ2VTOFFlM2JQZWpiQ0xrRHN2ZDFzdjg2RUt3SWhBTGRINzcwdzdjNi9NN0hCd3pVZWhFck1iWFhJNUNCV2N1aG1RdnhEKzlMWCIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2sxSlNVTXhWRU5EUVd4NVowRjNTVUpCWjBsVlNWUXJWbUpDTW01cFVHWTBaM0ZDWmpkMmRtNU9SRWxxYjNWQmQwTm5XVWxMYjFwSmVtb3dSVUYzVFhjS1RucEZWazFDVFVkQk1WVkZRMmhOVFdNeWJHNWpNMUoyWTIxVmRWcEhWakpOVWpSM1NFRlpSRlpSVVVSRmVGWjZZVmRrZW1SSE9YbGFVekZ3WW01U2JBcGpiVEZzV2tkc2FHUkhWWGRJYUdOT1RXcFJkMDFxUlhsTlJGbDVUVlJGZDFkb1kwNU5hbEYzVFdwRmVVMUVXWHBOVkVWM1YycEJRVTFHYTNkRmQxbElDa3R2V2tsNmFqQkRRVkZaU1V0dldrbDZhakJFUVZGalJGRm5RVVZSS3k5SmFHTlBRUzl4WnpsTE1VTnVTa1pzTkdSR1VXeFhkRkZUVEdReWRqWmpZMjhLWm1wWlJuQk5jRGRRV0hSS1ExQllaemN6VGtKTmNFUlhaakV2TjNsck1sRXpLMjlFTDNnNFZrOHdlVXBySzFGcWF6WlBRMEZZYzNkblowWXpUVUUwUndwQk1WVmtSSGRGUWk5M1VVVkJkMGxJWjBSQlZFSm5UbFpJVTFWRlJFUkJTMEpuWjNKQ1owVkdRbEZqUkVGNlFXUkNaMDVXU0ZFMFJVWm5VVlZ5U205MkNubHJjME0xYTFWUFVXVXlSMlV6VlZFeGIzSlFZbTh3ZDBoM1dVUldVakJxUWtKbmQwWnZRVlV6T1ZCd2VqRlphMFZhWWpWeFRtcHdTMFpYYVhocE5Ga0tXa1E0ZDB0bldVUldVakJTUVZGSUwwSkRRWGRJYjBWaldUSjRkbVJYVW5WWldGSndaRzFXYW1SWGVEQmtXRXBzVVVka2RGbFhiSE5NYlU1MllsUkJjQXBDWjI5eVFtZEZSVUZaVHk5TlFVVkNRa0owYjJSSVVuZGplbTkyVERKR2Fsa3lPVEZpYmxKNlRHMWtkbUl5WkhOYVV6VnFZakl3ZDB0M1dVdExkMWxDQ2tKQlIwUjJla0ZDUTBGUlpFUkNkRzlrU0ZKM1kzcHZka3d5Um1wWk1qa3hZbTVTZWt4dFpIWmlNbVJ6V2xNMWFtSXlNSGRuV1hOSFEybHpSMEZSVVVJS01XNXJRMEpCU1VWbVVWSTNRVWhyUVdSM1JHUlFWRUp4ZUhOalVrMXRUVnBJYUhsYVducGpRMjlyY0dWMVRqUTRjbVlyU0dsdVMwRk1lVzUxYW1kQlFRcEJXVEppSzJkVWVVRkJRVVZCZDBKSlRVVlpRMGxSUXpSTE1YazRTRlpOVkhaM056SlZjall4YmxCQlZrY3pNMGRCYlhFMVRHRmFVa3gwTWtSRFQySk5Da1pSU1doQlRteFJTbmN5VlVkdEwwaG9ibGM1V2tKUWVrSlphRmRJWTB0VWF5ODJlVlJhYVRGMFdVTnZiSEpPVWsxQmIwZERRM0ZIVTAwME9VSkJUVVFLUVRKalFVMUhVVU5OUldsemRUbEJUVTV1TkdvMlNtdDJlbkZwSzFWNE9HSktSM05qWWpkcVpsTnJLeTlhUXpKc1FtYzBSbmcwVkc5cGRuWjRjblpKT1FwalZXWndXamgwV1VkblNYZEJiR2RSVmpOdFVsTlZRU3RxYWxKa0t6QlBWVTVZYm1kRk9GQlpWVmRTWjNSbVNqWlFZMVZEVEZKUWJHeFhUMEpVYUhaMkNrMUtNa1JFZFZRd1lURnliUW90TFMwdExVVk9SQ0JEUlZKVVNVWkpRMEZVUlMwdExTMHRDZz09In19fX0=",
          "integratedTime": 1707718874,
          "logIndex": 70787776,
          "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"
        }
      },
      "Issuer": "https://accounts.google.com",
      "Subject": "cloudnativeculture@gmail.com"
    }
  }
]

@haydentherapper ☝️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants