Repository navigation
docs(release): the sha256 hex form holds for the artifacts digests only (build_hash stays base64) - #30
Merged
Conversation
…ly; build_hash and the provenance digests stay base64 The digest paragraph said the form is the form of the receipt fields (primitive_build_hash, grammar_sha256) so a consumer needs no re-encoding for the new fields. That is true of the artifacts digests and false for primitive_build_hash: release.build_hash is an existing field and still base64 SHA-256, like provenance.grammar_*, dependency_lock_sha256 and specs[].meta_hash. The sentence now says so and says that the conversion belongs to the consumer's own contract, which this contract does not define. English (normative) and Hungarian (summary) alike. No record, code or vector changes. --- [signing-metadata] key = cic-my-sign-key signature = vault:v1:MEQCIEecwxmWXVnV8Gf8KgxpX+cgdpXXBLDWtwMwN3Xy0wVGAiAS9MlFuLD7d9AkMjz5kGJKNAub+Fp0cNiiPe1uHQzkig== hash-algorithm = sha256 digest = LIOryfKo5q0Uohv8YPsacJ2SsaY22CesJ/CqIpdUBFE= [certificate] -----BEGIN CERTIFICATE----- MIICBjCCAaygAwIBAgIUSnRMR6RPnEbg296XWPOqq/u5PCwwCgYIKoZIzj0EAwIw QzELMAkGA1UEBhMCSFUxGTAXBgNVBAoMEENlbnRyYWxJbmZyYUNvcmUxGTAXBgNV BAMMEENJQyBEZXZlbG9wZXIgQ0EwHhcNMjYwMzIwMTMyMjU5WhcNMjYxMjMxMTMy MjU5WjBFMQswCQYDVQQGEwJIVTEZMBcGA1UECgwQQ2VudHJhbEluZnJhQ29yZTEb MBkGA1UEAwwSR2Fib3IgWm9sdGFuIFNpbmtvMFkwEwYHKoZIzj0CAQYIKoZIzj0D AQcDQgAEIG2CVmTfmLB9pLLclj7YmP2eedAjklpy4LGrU2ijoiy6Xqpuybv7OgJe i+ez31s65NEV8+X/ByeX1cstR988z6N8MHowCQYDVR0TBAIwADAdBgNVHQ4EFgQU yZN6AIX/TNnIJ9GwAa/NRN3ujHAwHwYDVR0jBBgwFoAUXn6CHYzPUqU4JVP8g+OS WeDYjhcwDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAKBggqhkjOPQQDAgNIADBFAiEA+bFzXRoJ4PCQbhAAtpkcMjt0vNj5rEW0 lOMBGDNyaWkCIB1vmM7PcZzv/c9bIrxF5kqv6QXomouhByUfeNUTbpKW -----END CERTIFICATE-----
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
One sentence of the record contract (section on the digest form, English normative and the Hungarian summary), documentation only.
It said the `sha256:` hex form is "the form of the receipt fields (`primitive_build_hash`, `grammar_sha256`), so a consumer needs no re-encoding for the new fields". That is true of the new `artifacts` digests. It is not true of `primitive_build_hash`: `release.build_hash` is an existing field and still base64 SHA-256 (as are `provenance.grammar_*`, `dependency_lock_sha256` and `specs[].meta_hash`). Measured on the `v0.2.1` record: `build_hash` is 44 base64 characters.
The sentence now limits the claim to the `artifacts` digests, lists the fields that stay base64, and says the conversion belongs to the consumer's own contract, which this contract does not define.
Found while planning the receipt digest mapping in cic-primitive-forms (condition 8).
Not part of this PR
No record, verifier, compiler, vector or release changes. The v0.2.1 record is untouched.