Félix Saparelli
Félix Saparelli
> This is a good point! However, splitting these into separate scopes only makes sense if you expect people to generate low privilege yank-only tokens. I can't think of a...
To add on and contrast with kornel's usecase as in the above comment, I specifically would *not* want "releasers" to automatically have "ownership" — these are two different concepts, and...
I don't see how that works for tokens scoped to non-new-publish permissions, if those are a thing (as of this rfc or in the future)
Also that means publish-new-crate tokens can now publish any name, instead of being limited to whatever the associated pattern is.
Alright, good points, I can see the logic in them.
It could be a consideration to have some kind of scoping or restriction being able to be set on submitted public keys, but as it stands (without this RFC) a...
I've got this kind of workflow for my own (and, coincidentally, for Ryan's cargo-binstall) crates, and I've just made a github action that provides support for it: https://github.com/cargo-bins/release-pr
Not exactly relevant to this issue, but I _was_ interested in the reverse, CSL-JSON to CFF, so I made a standalone tool for it: https://github.com/passcod/citeworks Might be helpful to someone
Customer (my co) was using 7.2 at the time iirc, now 7.3, in transition to 7.4
Just normal use via rollbar error logging. No particular high usage (we hit a few thousand error logs a day at most), it was fairly random. We haven't had occurrences...