I started this process at rustsec/advisory-db#2227

I'm happy to help out with minimal maintenance, basically the bare necessity to allow RustSec to retract the advisory. That should allow downstream folks to migrate at their preferred pace, and give us the chance to grow (things like) graviola.

@ctz I went ahead and added you as an owner. I think you need to accept the "invitation." Thanks!

Here are the steps for doing a release in the same way I did it, from #1460 (comment):

# 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

I have found it useful to do an -alpha1 release first and then verifying that important packages build and pass their tests correctly against the -alpha1, because of how the pregeneration affects things. Probably it could be solved by just checking the generated assembly into git.

Thanks for the pointers, that is very useful. I have successfully published https://crates.io/crates/ring/0.17.11-alpha1 and am currently validating that in downstream CI.

0.17.11 is now published.

Do you intend to bring in the changes from the rustls fork? It seems confusing when two different repositories are being used to publish releases in parallel.

I will bring in the changes from that repo into a branch(es) into this repo so this repo contains the full history for every release. I think some of the changes have already been made with a different history; for example, fixing the smart quotes in the build.rs license file. I will sync them before release.

So how is the situation different from 3 weeks ago? Are you owning minimal maintenance for ring going forward? Do you still want/need the rustls team involved, and if so, how?

We'll see. In order to spend significant effort on this project, I need to find some funding. If I can find some funding, I can push it over the finish line. If not, then I have to move on sooner.

Regardless, I'm really interested in finding a team to join; despite what it might appear like from looking at this project, I really enjoy working as part of a team.

I don't know what to expect given [look around gesture].

I think we should find some way to cooperate better. We should have worked out something long ago.

Sounds good. I would be happy to collaborate in this repo, and I suspect the same might be true for @ctz.

I'd like to open a feature PR against ring (for AES-CTR), is someone willing to review it? I realize this goes against the current no new features policy and a clear "no" is a good answer too :).

I reopened #414. It would be good to write up an outline of your planned approach, e.g. whether 96-bit nonces and 32-bit counters are sufficient or whether you intend to support larger counters, if/how the AES-GCM code and AES-CTR code will avoid duplicate logic w/o regressing performance of the AES-GCM code, how you will test it, the proposed API, etc.

Thanks being open to this, I'll try to prepare an outline tomorrow.