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. [EDITED: It was done, and 0.17.11 was released too.]

* 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.

[briansmith]

Just keeping people in the loop here. In the last day or two I had some time to rebase some of my already-written PRs onto the relicensing changes in 0.17.10. I've started posting them with the intention of making another release soon. Note that that release will probably increase the minimum binutils version (if using GNU as) and the MSRV to 1.66.

I also created another forum category https://github.com/briansmith/ring/discussions/categories/building for people to help each other with build configuration difficulties. My intent is that, if/when people file issues about ring failing to build, I will convert those issues into a discussion in that category and let others address the difficulty. That way the issue tracker stays focused on actual bugs. (Of course, the fact that cross compilation is so difficult is itself a usability bug, but we don't need issues to know that the build is difficult to configure for many people.)

[djc]

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.

[briansmith]

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.

[djc]

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?

[briansmith]

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.

[djc]

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

[briansmith]

I have started a thread for the 0.17.12 release here: #2443.