Update crate owners

[tcharding]

Because I saved the name bitcoin-io I am showing up as an owner (on crates.io) of the new bitcoin-io crate. This, IMO, is not correct. If anyone should be an additional owner that crate it should be @TheBlueMatt since he wrote it.

Furthermore, we should revise the crate ownership of all the crates in the rust-bitcoin repository with the following in mind:

• Have multiple owners to mitigate the bus factor
• Have owners with long standing in the Bitcoin community

I personally do not want to be an owner of any of the crates in the rust-bitcoin org unless I specifically wrote them (eg, rust-ordered) because I have not been a part of the Bitcoin community for long enough.

[apoelstra]

Ok, of the 22 repos in this org I have identified the following as "core" crates that should have multiple owners:

• base58ck (current owners: just me)
• bitcoin (current owners: me and Matt)
• bitcoinconsensus (current owners: me, Matt, Steven, Tamas †)
• hashes (current owners: me and Matt)
• hex (current owners: just me) (lol how did this happen?)
• internals (current owners: just me)
• io (current owners: me and Tobin)
• ordered (current owners: me and Tobin)
• secp256k1 (current owners: me and Jonas Nick)

We then have miniscript co-owned by me an Sanket which I think is correct, bitcoind owned by Riccardo and Leo which also seems correct, bech32 owned by Clark and Matt and me, and bitcoincore-rpc owned by Steven and @tcharding (which sounds like @tcharding took one for the team to increase the bus factor on a thankless and frustrating crate :P).

We also have the website repo which I don't think is a crate.

You're welcome to check my work, but I believe everything else is unmaintained (including 4 which are explicitly archived on Github). As a separate issue we may want to audit these and decide whether we should explicitly mark them on RUSTSEC as being unmaintained as a warning to users.

With the the exception of secp, which I like to keep a close grip on, I think it's reasonable that all of these should be co-owned by me, @sanket1729, @tcharding, and possibly @Kixunil and @TheBlueMatt if they are willing. Though even secp maybe should have Sanket added, or Matt.

I appreciate that @tcharding has only been around for a couple of years. On the other hand, our crazy lockfile system and general crates.io inflexibility mean that I'm really not worried about him (or anyone) publishing a rogue version of these crates without being noticed very quickly and having their reputation permanently destroyed. (I am also confident that everyone listed is a single individual using a name that they widely use professionally, and is not some ephemeral pseudonym ready to be torched.)

Though I guess, it would be reasonable fo us to have a top-level manifest somewhere with the latest versions of all tools, and a script to verify against crates.io if that changes. I might set up a local cronjob which emails me if this ever changes. It'd be an extra annoying thing to maintain but OTOH it's not the end of the world if we're slow about it, it just means we'd get some warning emails around release time. (This tool would maybe also be useful for planning/tracking releases, which involves coordinating a tree of dependencies that AFAICT isn't explicitly drawn out anywhere.)

[tcharding]

My list of core crates has 11, please see: rust-bitcoin/.github#1

The two extras I think should be included are units and bech32.

[tcharding]

I'm going to go ahead and file a RustSec advisory for rust-wallet because it has an issue already that can be used in the filing: rust-bitcoin/rust-wallet#36

[tcharding]

I'm really not worried about him (or anyone) publishing a rogue version

I can actually do this without ownership of any other crates because I'm owner of ordered. If I was malicious or compromised I could push an exploit as part of a point release to ordered and then anyone using that feature would run the code soon as cargo automatically pulled down the new point release. Same applies for other devs with publish rights to any crate depended on by rust-bitcoin.

I agree we should have some system in place that notifies when new releases are pushed to crates.io - the versions to check against likely should be kept locally on devs machines otherwise if in a file online that file just becomes part of the attack. This is starting to sound like a general software development issue that someone else should have already solved.

Since most applications are using ~3000 other random dependencies it might not be worth the additional bother to lock rust-bitcoin down too much more than that. But at some stage in the future perhaps we should?

I think it's reasonable that all of these should be co-owned by me, @sanket1729, @tcharding, and possibly @Kixunil and @TheBlueMatt if they are willing.

As long as there are at least 3 owners on each crate then I am willing to taking on that responsibility.

[sanket1729]

If the purpose of having keys is primarily redundancy; sign me up. I can assure that I don't intend to use any of push permission and I won't even register a new token for pushing stuff to rust bitcoin or miniscript org.

Any push from my account should be by default considered compromised unless we discuss otherwise beforehand.

w.r.t supply chain attacks, I don't think they fall in the scope of this issue. Users might vendor code or actively review what is published and downloaded.

[tcharding]

Oh that is a good idea, we can both declare that our publish permissions are only for the case where @apoelstra is AWOL, assumed dead, or certified mad. Then any publish by me or @sanket1729 can be assumed malicious. I like it!

[apoelstra]

I agree we should have some system in place that notifies when new releases are pushed to crates.io - the versions to check against likely should be kept locally on devs machines otherwise if in a file online that file just becomes part of the attack. This is starting to sound like a general software development issue that someone else should have already solved.

Well, crates.io solved it to the extent that they will publish on their website when dependencies get updated. But it's on us to fetch that data and do something useful for us as far as sending notifications. Though it may be that crates.io itself has a way for us to be emailed when new stuff is released..

I think it's fine to have the reference be in a git repo on github. Yes, in theory somebody could just push to this (though we can prevent direct pushes in github and add a one-ack rule for pull requests), but that wouldn't immediately update anyone's machines and it would be very visible when they did.

Since most applications are using ~3000 other random dependencies it might not be worth the additional bother to lock rust-bitcoin down too much more than that. But at some stage in the future perhaps we should?

I don't think we should compare ourselves to "most applications" :).

Oh that is a good idea, we can both declare that our publish permissions are only for the case where @apoelstra is AWOL, assumed dead, or certified mad. Then any publish by me or @sanket1729 can be assumed malicious. I like it!

Lol, that's a good point. We can easily script that (assuming we have scripts to notice updates at all).

[tcharding]

I don't think we should compare ourselves to "most applications" :).

Woops, I meant most applications that use rust-bitcoin ie., even if rust-bitcoin is locked down they likely have a ton of other dependencies that can be attacked.