Could tags be added to corespond with all releases on crates.io?

[abrisco]

This would make it easier to triage issues 🙏

[farcaller]

I was just about to open the same issue. I would consider it crucial for a security library to have tagging for any releases that are published elsewhere (e.g. on crates). In a perfect world I'd also love to see the CI doing this (and I am willing to provide my time to work on that if the author is interested).

[briansmith]

My plan is to tag all future releases (any new 0.16.x releases and any new 0.17.x releases). I'm not planning to spend time tagging old releases. Please don't use any old releases.

[abrisco]

The goal isn't to solidify on an old release, it's to be able to assess what code I'm picking up when I update. It would be very helpful to have at least 1 year's worth of tags to make auditing easier. But at the very least tags for new releases is greatly appreciated. So thank you!

[briansmith]

I would consider it crucial for a security library to have tagging for any releases that are published elsewhere (e.g. on crates).

It is dangerous to rely on assumptions about Git tags that correspond to crates.io or other releases. Even if everybody is well intentioned, it is easy to accidentally modify a tag so it points to the wrong commit, and it is easy to accidentally release something that isn't exactly what matches the tagged revision. This is actually the main reason I've always avoided the tagging--so that people don't make such dangerous assumptions. Not just for this library, but all libraries. Git tags are simply not a good tool for security purposes.

I do see some value in tagging, especially for people who are maintaining (temporary) forks.

My goal is to concentrate on getting 0.17.0 released. I currently plan to tag the 0.17.0 release and all future releases. Then I will help people migrate from 0.16.x to 0.17.0. Barring a security emergency, all work on 0.16.x is done, from my perspective.

[ColonelThirtyTwo]

Are you aware you can sign tags in git? That should alleviate some concerns you have about tagging.

Frankly, I could make your argument the other way around. How am I supposed to know that the package you upload to crates.io matches what is in the source tree if I don't know what particular commit is actually published?

[hoodie]

Hi there, I just ran into an issue and wished to find out what has changed between 0.17.0 and 0.17.4 and it is not easy to see. Would it be possible to add a changelog or maintain releases on github just for documentation?
Thank you.

[richardpringle]

I would consider it crucial for a security library to have tagging for any releases that are published elsewhere (e.g. on crates).

It is dangerous to rely on assumptions about Git tags that correspond to crates.io or other releases. Even if everybody is well intentioned, it is easy to accidentally modify a tag so it points to the wrong commit, and it is easy to accidentally release something that isn't exactly what matches the tagged revision. This is actually the main reason I've always avoided the tagging--so that people don't make such dangerous assumptions. Not just for this library, but all libraries. Git tags are simply not a good tool for security purposes.

I do see some value in tagging, especially for people who are maintaining (temporary) forks.

My goal is to concentrate on getting 0.17.0 released. I currently plan to tag the 0.17.0 release and all future releases. Then I will help people migrate from 0.16.x to 0.17.0. Barring a security emergency, all work on 0.16.x is done, from my perspective.

Hey @briansmith! Not sure I understand the downvotes there... But I think this issue is not aptly named. The real request here should be a method (of your choosing) to be able to audit the difference between versions. Is there a guide for migrating between 0.16 and 0.17?

[briansmith]

So, friends, I would like to make progress on this. OTOH, I always have something more pressing to do, and I don't think that will change soon, so I will likely need some help. There are many things in this project that are too hard for other people to do, so I have to do them. (I am working on fixing that.) However, this is one thing where I think it's better to let others contribute a solution. With that in mind, here's some background and thoughts:

Currently you can do git log --grep "0\\.17\\.*" to see the recent releases. Note that each release corresponds to the commit that has the version number as its name. So git log --grep "0.17.5" makes it easy to find the commit that 0.17.5 was released from.

Here is how the releases are done, roughly:

$ mk/package.sh
$ cargo publish --allow-dirty
$ rm -Rf pregenerated

The first line generates the .S and .asm files from the PerlAsm sources. It also preassembles the .asm files to .obj files on Windows. This way, people using ring from crates.io do not need Perl or nasm installed to build ring-based projects. Note that the version of nasm used is pinned to aid reproducibility, though I understand that some of the debug info leaks details of my build environment that breaks 100% reproducability (there is an open issue for resolving this). Because of the Windows hacks, this is done on Windows (Git Bash shell); I think Nasm for Linux could be used to do the equivalent on Linux and I'd accept patches to make that happen. Anyway, this is why you'll never find a Git commit that contains all the files in the pregenerated directory in the published crate archive.

As far as tags go, I really do think Git tags are a poor mechanism for people doing security-related audits of the code, exactly because tags are malleable. Of course I can sign the commits but that's a poor guarantee compared to the blockchain-like qualities that Git commits give us. So personally I would prefer a solution that makes the system I already have (a commit signifying the release where the commit message is the version number) foolproof and more automated. For example, there should be a script that modifies the Cargo.toml version and links fields and creates a Git commit with the version number, etc.

I also think that cargo publish should have a machanism for embedding the commit hash into the published crate's Cargo.toml Note that it already pretty-prints and otherwise modifies Cargo.toml before creating the crate archive. So, I guess we could just, after doing the git commit step, and before cargo publish, stuff the commit hash into Cargo.toml somewhere, to prototype this.

From my part, I have a longer-term plan to make the preassembly for Windows unnecessary, at least. Of course we are grinding away at making Perl unnecessary too. I am happy to help others contribute intermediate solutions but I need to stay focused on the longer-term stuff.

[briansmith]

Here are the exact steps I am doing for the 0.17.6 release:

# Start Windows machine, open a "Git Bash" prompt, and change to my *ring* checkout directory.
$ git checkout main
$ git checkout -b b/0.17.6
# Change `version = "0.17.6"` and `links = "ring_core_0_17_6"` in Cargo.toml.
$ git commit -m "0.17.6."
$ git push -u
# Create the "0.17.6." pull request in the GitHub UI. TODO: automate using `gh`
# Wait for all the CI jobs to pass.
$ mk/package.sh
$ cargo publish --allow-dirty
$ rm -Rf pregenerated

[briansmith]

I left a commit at rust-lang/cargo#9398 (comment) requesting an improvement to Cargo so that it will be easy to automatically map a crates.io release to a Git commit for this project.

[VorpalBlade]

I also think that cargo publish should have a machanism for embedding the commit hash into the published crate's Cargo.toml Note that it already pretty-prints and otherwise modifies Cargo.toml before creating the crate archive.

There is a mechanism to add a .cargo_vcs_info.json with this info already. Unfortunately using --allow-dirty disables this. There is an open issue about this: rust-lang/cargo#13695

[briansmith]

rust-lang/cargo#13960 looks like it will be a useful step towards making it easier to trace a crates.io release back to the git commit.