Consider storing pregenerated files in git

[madsmtm]

The ring package is published on crates.io without git information, because it includes files that are not part of the repository. I would be better if all the files that are on crates.io were also present in the repository - while I recognize that this isn't really the "pure" and "clean" way to use git, on the other hand, it just also makes part of automatic security auditing much easier, see e.g. https://lib.rs/~briansmith/dash#crate-ring.

I encountered this today when trying to use ring from source via. crates-io.patch on Mac Catalyst, and having it fail to pre-generate the files there, so it's also a usability issue.

Tip: You can add pregenerated linguist-generated to .gitattributes to avoid GitHub from counting it, and you should probably also add exclude = ["generated/tmp/*"] to Cargo.toml to avoid the temp files from being uploaded to crates.io too.

[briansmith]

Here is my tentative plan:

• [ ] Add doc/supply-chain-integrity.md (or whatever) that documents the design of the solution we choose.
• [ ] Create a new briansmith/ring-packaged-crate repository that will contain one commit for each release to crates.io.
• [ ] Document the situation in briansmith/ring-packaged-crate/README.md include a link to the "real" briansmith/ring repository.
• [ ] Update Cargo.toml to point to briansmith/ring-packaged-crate instead of briansmith/ring, along with comments that point to the documentation.
• [ ] Add mk/release.sh that executes mk/package.sh and then creates a PR to briansmith/ring-packaged-crate with the new package contents, where the commit messsage of the commit in the PR mentions the corresponding briansmith/ring commit hash.
• [ ] Add a mk/verify-packaged.sh that verifies that a particular commit of briansmith/ring-packaged-crate contains exactly the output of mk/release.sh for the git commit hash of briansmith/ring that is mentioned in that commit's commit message.
• [ ] Add a GitHub Actions job that runs mk/verify-packaged.sh

This way, people who naively run generic "check that the package contents match what is in Git" tools will automatically get a good result. We can also expand the supply chain integrity verification document to explain how users can run mk/verify-package.sh and/or mk/release.sh themselves as part of a less naive verification process.