cosign icon indicating copy to clipboard operation
cosign copied to clipboard

Unify verification messages between containers and blobs

Open jonvnadelberg opened this issue 2 years ago • 3 comments

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 avatar Oct 23 '23 14:10 jonvnadelberg

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.

viveksahu26 avatar Jan 27 '24 03:01 viveksahu26

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 https://github.com/sigstore/cosign/issues/2210, I could imagine similar output.

haydentherapper avatar Jan 30 '24 21:01 haydentherapper

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": "[email protected]"
    }
  }
]

@haydentherapper :point_up:

viveksahu26 avatar Feb 12 '24 09:02 viveksahu26