better-macro has deliberate RCE in proc-macro

[jsgf]

It's "Proving A Point" in https://github.com/raycar5/better-macro/blob/master/doc/hi.md but there's
no guarantee that this will remain benign (or is actually benign right now). The crate also has no useful functionality.

[tarcieri]

There's been some conflicting opinions on how to handle crates like this. See #826 as some precedent.

Personally I think this one in particular is OK to include, but I'm curious what other people think.

[jsgf]

Well, with all these examples I think I'd want them flagged if they turn up in my dep graphs - certainly at a higher pri than the "X is unmaintained" advisories, which are pretty low value from from my POV.

In this case, because its safety depends on whatever the embedded URL is currently pointing to, which as it can be changed at any moment, can't be statically audited. At least with the other examples you can fully describe what any specific version would do (perhaps in combination with a specific compiler given the UB games they play).

[Shnatsel]

We do carry informational = "notice" for some deliberately subversive crates. I can't see why not do so here.

They're not particularly dangerous in their current form, but it's something you don't want in your dependency graph in a production binary.

[tarcieri]

That's not really what it was made for, although we have used it for that once.

[jsgf]

OK, I refreshed my memory of the other "interesting" cases, specifically plutonium and totally-safe-transmute.

I agree that those two are marginal, but the way I'd frame it is that the RustSec DB is a set of information about crates, particularly various non-standard behaviours. What one does with that information is a local policy choice; just because something is listed doesn't mean one must or should act on it. It really depends on how the advisory interacts with the local threat model.

So in the case of plutonium, I see it as a legitimate part of the conversation about what Rust's safety rules actually mean in practice. But also it has very unusual behaviour for a Rust package, so I'd want to know if it ever turns up in my dep graph, regardless of whether it's functioning as intended. Obviously I could build my own tooling to track packages of note, so it's really a question of whether this is in RustSec's scope, or if it should be. We can leave that for another conversation.

But I think this case is distinct. It's similar to plutonium in that it's trying to make a point, but:

1. The point it's making is that "build systems run arbitrary code from unknown places", which isn't a Rust-specific. But OK.
2. The name better-macro, while vague, gives no clue at all to the intent (unlike plutonium and totally-safe-transmute). Someone might read the doc and think it does something useful for them.
3. The mechanism is fundamentally insecure, as it (effectively) does a live http fetch at build time, so even if the code is well known and the URL is currently safe, it could become actually malicious at any point. It's intrinsically unauditable.

So it's possible that someone could use this package without real due diligence (perhaps without noticing if none of the mechanisms the proc macro uses to draw attention to itself work in their environment), and in the process introduce an unbounded build-time RCE vulnerability for their downstream dependencies.

I would therefore argue that this crate does not work as intended.

[tarcieri]

I think it's worth including. We'll see if people disagree, but if so, we can talk about it then.