Intoto Indexing Bug: cannot find entry by payloadHash

[asraa]

Description

Currently at head, we cannot use the search index to find entries by payloadHash, which should be indexed:

rekor/pkg/types/intoto/v0.0.1/entry.go

Lines 77 to 78 in 744339f

	payloadKey := "sha256:" + hex.EncodeToString(h[:])
	result = append(result, payloadKey)

Version

I spun up a local rekor instance and uploaded an intoto attestation. I logged what keys were added. Check out the payloadHash in all cases:

The entry:

Body: {
  "IntotoObj": {
    "content": {
      "hash": {
        "algorithm": "sha256",
        "value": "51a0a4f22ff245835d264cd41c6969a58fb3e37884c7aa2cace767714beb2a22"
      },
      "payloadHash": {
        "algorithm": "sha256",
        "value": "d941d60e3f06985f970096cc0ff5ae2990ae64eab57230e5f9c9f4cf89d4e5de"
      }
    },
    "publicKey": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRRENDQXNXZ0F3SUJBZ0lVQU9ySkxadHRpTXFZUm1nWHdRczVva3FHczlNd0NnWUlLb1pJemowRUF3TXcKS2pFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUkV3RHdZRFZRUURFd2h6YVdkemRHOXlaVEFlRncweQpNakEyTVRZeE16STJNREZhRncweU1qQTJNVFl4TXpNMk1EQmFNQUF3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPClBRTUJCd05DQUFUUlQ4WlFMZnl4RThNZE5DcmhsZWNnQmFyWUs3WjJvb0c1SllCaElwV3IwaTRFSVEzSGg2bSsKYThrcnZVWFFnSmlGclNRdFl6V0EyWlk3WEU2Zi9HNFhvNElCOFRDQ0FlMHdEZ1lEVlIwUEFRSC9CQVFEQWdlQQpNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01ETUF3R0ExVWRFd0VCL3dRQ01BQXdIUVlEVlIwT0JCWUVGSU91ClZEK01RcDJiRDk1c3UwMzN1MTU5bDliT01COEdBMVVkSXdRWU1CYUFGRmpBSGwrUlJhVm1xWHJNa0tHVEl0QXEKeGNYNk1IMEdBMVVkRVFFQi93UnpNSEdHYjJoMGRIQnpPaTh2WjJsMGFIVmlMbU52YlM5emJITmhMV1p5WVcxbApkMjl5YXk5emJITmhMV2RwZEdoMVlpMW5aVzVsY21GMGIzSXZMbWRwZEdoMVlpOTNiM0pyWm14dmQzTXZZblZwCmJHUmxjbDluYjE5emJITmhNeTU1Yld4QWNtVm1jeTkwWVdkekwzWXhMakF1TURBZkJnb3JCZ0VFQVlPL01BRUMKQkJGM2IzSnJabXh2ZDE5a2FYTndZWFJqYURBZEJnb3JCZ0VFQVlPL01BRUVCQTlIYnlCVFRGTkJJRkpsYkdWaApjMlV3T1FZS0t3WUJCQUdEdnpBQkFRUXJhSFIwY0hNNkx5OTBiMnRsYmk1aFkzUnBiMjV6TG1kcGRHaDFZblZ6ClpYSmpiMjUwWlc1MExtTnZiVEEyQmdvckJnRUVBWU8vTUFFREJDZ3laRFEzTldRM05HRTVNMlV6TnpWaVptWXoKTkRJd1pqTXdPVE13TXpNMFlUaGpPRGhpTjJVeU1CMEdDaXNHQVFRQmc3OHdBUVlFRDNKbFpuTXZhR1ZoWkhNdgpiV0ZwYmpBbkJnb3JCZ0VFQVlPL01BRUZCQmxoYzNKaFlTOXpiSE5oTFc5dUxXZHBkR2gxWWkxMFpYTjBNQW9HCkNDcUdTTTQ5QkFNREEya0FNR1lDTVFEMGVpU09FZWVoenVXWlhwWHVYMlJvVEFEY3UrUG9NSEVpb0NYalQwUjkKeE03VzBtQkFZZmVyUmk0YmxmQkxXVVlDTVFDdzhiWjBsaTV2eE9yd25rVFIxU2JsU1lOWk91b2Q1SC8vK09vZwo2WHdXeUp4cnNzcm8rT0RRcHZuYzB0VXB2Szg9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
  }
}

The indexed keys:

 sha256:fe24a8c9e6a0eab15c97c70c3d1e56f2dd36b36c231c544c75374a7c96c4d8ac (payloadHash), 

sha256:51a0a4f22ff245835d264cd41c6969a58fb3e37884c7aa2cace767714beb2a22, (envelope digest)

sha256:4bdb495d05cbb9eb0722ec4fcfef8a02d5ca7a2fca0b0fed718447f89d39a589, (subject digest)

sha1:2d475d74a93e375bff3420f30930334a8c88b7e2 (materials)

Note that the payload hashes do NOT match

1. Calculated for the entry here via AttestationKeyValue
2. Calculated for the index here

[asraa]

I think this is related to #872

The difference in the computation is whether the attestation payload is base64 decoded or not

@bobcallaway

[bobcallaway]

I'm not sure these issues are related; #872 is more about attestation lookup failing for entries created before payloadHash was part of the type.

I agree with your assessment that v.env.Payload returns the base64-encoded payload as a string, which isn't the correct thing to compute the index key against. I think we should change the digest computation to be off of the []byte returned from v.env.DecodeB64Payload() instead of taking the hash over the base64 string.

[asraa]

I can take care of that!

FWIW I think the original issue of not finding entries in the slsa code was fixed by #870