Add checksum to ArtC's data.fileInformation objects

[magnusbaeck]

Description

The objects in the data.fileInformation array of ArtC should have an optional checksum member so that consumers can verify the integrity of the artifact's files. Example:

{
  "meta": {
    "type": "EiffelArtifactCreatedEvent",
    ...
  },
  "data": {
    "fileInformation": [
      {
        "name": "image.bin",
        "integrity": {
          "checksum": "a480451897f590d3eb032c946de140b092dcda58356b5647bdeeee30f965769b",
          "alg": "SHA-256"
        }
      },
    ],
    ...
  },
  ...
}

It's tempting to align with meta.security.integrityProtection, but they're not quite the same as the latter signs the payload and references algorithms for signatures and HMACs but in this case we just want a plain checksum with no secret (neither shared key or public key).

Motivation

An artifact consumer can verify that the file they eventually download actually is the same file as the original and that no corruption or funny business has taken place.

Exemplification

See above.

Benefits

An opportunity to improve the integrity of the software supply chain by using Eiffel to verify the end-to-end integrity of artifacts produced in a pipeline. This can be used to detect honest mistakes, corruption, and malicious attacks on the artifact storage.

Possible Drawbacks

None.

[magnusbaeck]

Regarding the value space of the data.fileInformation.integrity.alg member, perhaps we can refer to p. 23 of FIPS 202 (table 4; section A.1)? That's not a complete list of all unkeyed hash algorithms, but maybe it doesn't have to be? The vast, vast majority of producers and consumers should be able to use one of the algorithms listed there. I would've preferred a non-PDF but I currently don't have a better suggestion.

[m-linner-ericsson]

Sound good to link to a list. For links to sources, could we use any of these:

• https://en.wikipedia.org/wiki/Secure_Hash_Algorithms
• https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions

[magnusbaeck]

I don't think it'd be wise for a spec like Eiffel to link to a mutable source like a Wikipedia page. The second page is better but it's also mutable, but we could include a reference to the date (2015-08-05) and assume that the current text will be accessible in the future just like the old policies from 2012-09-28 and 2006-03-15.