Taking a break

[briansmith]

I am the only maintainer of this project. I am planning on taking a break from working on it indefinitely [EDITED].

As always* If you have security concerns about this project, please use the security vulnerability reporting tool that GitHub provides this project to report it. Don't expect a response, especially not a quick one. [EDITED]

I don't expect others to pick up maintenance of this project. [EDITED]

I hope to release the 0.17.10 release soon.

* Well, as of a while ago. :)

[briansmith]

So, I started thinking about what this will look like and I have some concerns. I think I am going to release the 0.17.10 release but I am also thinking about just marking all of the releases on crates.io as "unmaintained" until/unless somebody else is interested in publishing releases. I think that's the least disruptive thing that could be done at this point. Ideally somebody else would be interested in maintaining what's on crates.io.

[briansmith]

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

[briansmith]

Hi friends, I just want to let you know I edited my previous statements in this thread to reflect my newest thinking.

[ctz]

I'd be open to doing some low-key maintenance on this while you take a break. Things I have in mind: security response, tracking BoringSSL security-relevant fixes, handling any urgent issues, and making incremental releases as needed on the 0.17 release line. Probably nothing more than that (no new features, breaking changes, architectural changes, etc.) so that when you are ready to return to it won't feel foreign. Let me know if you are interested in that.

[djc]

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.

[briansmith]

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

[briansmith]

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.

[ctz]

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.

[ctz]

0.17.11 is now published.