Ownership of `bitcoin-internals`

[Kixunil]

I was thinking of reporting bitcoin-internals as potentially malicious - the uploader got the code before it was published by the authors and uploaded. It's not clear if this was a mistake or malicious intent but accidentally relying on it could be dangerous. Full story: https://github.com/rust-bitcoin/rust-bitcoin/discussions/1702

The current contribution guidelines don't describe how to report such situation. While it could be assumed that such reports are not accepted, I think it would be useful to start accepting them?

[alex]

Looking at the source for the 0.1.0 release uploaded to crates.io, I don't see anything malicious there.

On Sun, Mar 19, 2023 at 2:07 PM Martin Habovštiak @.***> wrote:

I was thinking of reporting bitcoin-internals as potentially malicious - the uploader got the code before it was published by the authors and uploaded. It's not clear if this was a mistake or malicious intent but accidentally relying on it could be dangerous. Full story: rust-bitcoin/rust-bitcoin#1702 https://github.com/rust-bitcoin/rust-bitcoin/discussions/1702

The current contribution guidelines don't describe how to report such situation. While it could be assumed that such reports are not accepted, I think it would be useful to start accepting them?

— Reply to this email directly, view it on GitHub https://github.com/rustsec/advisory-db/issues/1649, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAGBFXISNAXRB5RIASB53W45DN7ANCNFSM6AAAAAAWAH72NU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[Kixunil]

There currently isn't. What's not clear is why the uploader uploaded it. Is the plan to replace it with malicious code later? Hard to say. That's why I wrote "potentially".

[pinkforest]

When there is e.g. a malicious build script then this would be malicious and we forward these to crates.io.

They would say that namesquatting isn't malicious and crates.io is clear about squatting.

https://crates.io/policies#package-ownership

This would be the place to fix it:

https://github.com/rust-lang/rfcs/pull/2614 https://users.rust-lang.org/t/name-squatting-on-the-crates-io/42415 https://internals.rust-lang.org/t/pre-rfc-formal-squatting-policy-on-crates-io/11302

Another reason crates should use namespaces but this isn't going to happen given the previous attempts to do so.

Closing - re-open if the crate becomes malicious.

[Shnatsel]

I would say this is not a simple case of namesquatting, since it also contains the complete code of the crate it is impersonating, instead of just a placeholder.

I suppose we could make an informational = notice advisory about this.

[pinkforest]

Wider precedent

Should we:

1) Be the advisory authority to judge who owns or is the legitimate owner of a crate if it has never been published ?

2) Use advisories as a mechanism to mitigate the shortcomings of long running crates.io policies ?

3) Make any opinion/s of metadata validity in any given crate ?

For 1) we would have to do a lot of legwork to figure out who supposedly claimed the name in first place and effectively try to draw some level of conclusion who owns the name without crates.io being the single source of truth - the facts would be questionable and left open to intepretation in many cases who really had the name first.

In principle I would not like to create this expectation / precedent here as-is nor I would like to create special cases without clear understanding of the full precedent it creates.

This specific issue

Metadata may have been simply copied 1:1 that may or may not mislead someone -

The metadata and the code seems to be the same that is in GitHub repository pointing to plain publisher confusion.

Impersonation is different if so alleged - e.g. the code is doing something else under the hood to deceive / mislead ?

The crate is neither used by anything and this crate has never been released anywhere -

Therefore not entirely sure if anyone - including us - should claim innuendo upon mere suspicion of others intent and be very clear what we signal via our advisories that either furthers or contribute/s any opinion/s either e.g. by way of linking to the original discussion.

However if we were to do so regardless the above -

It seems that the supposedly illegitimate owner is plainly confused and has been contacted to handover the crate: https://github.com/rust-bitcoin/rust-bitcoin/discussions/1702#discussioncomment-5248168

I don't see this crossing the threshold of anything suspicious if we were to judge that to insinuate malicious intent.

Cc/ @marspoolxyz - the current owner in crates.io of the name bitcoin-internals maybe can chime in ?

Current Precedent

Yes we do flag helpful and factual information for notice, unmaintained and unsound

One could argue if we already do it for the unmaintained we also should be doing it for the squatters supposedly allegedly plotting to misuse the name supposedly owns without them registering it before it happened.

Nonetheless we require high threshold for unmaintained e.g. who ever has ownership in crates.io telling us it is so or waiting 90 days without reply - the facts are relatively easy to draw on and decide given source of truth is crates.io.

Keep in mind that OS package maintainers something similar all day without drawing on the metadata - effectively taking the code and re-publishing that supposedly presents the software as intended by the original maintainer/s and contributor/s where as in reality there is selective sets of patches applied on top where one could argue it represents a fork.

[Kixunil]

Fair points, perhaps notice saying that the crate appears to be owned by rust-bitcoin organization but it isn't would be fine? I guess I will try to hack some script to monitor it for malicious releases.

[Shnatsel]

Ideally this is something that crates.io itself should handle.

We can file an advisory, but I don't think it will really mitigate a supply chain attack. IIRC informational = notice would not be exported to Github and OSV, so it would be limited to people running cargo audit. If the package ships a malicious build script, then it would probably be already executed by the time cargo audit is run - so the info would be surfaced too late.

So I'm going to close this, but if you need help communicating with the crates.io team (explaining why this is an issue, etc) please feel free to contact me.