Autoreview against I/O

[vporton]

I propose to autoreview as "clean" these packages that:

1. refer only to other reviewed packages
2. don't use I/O (except of channels, which are OK) and can't produce undefined behavior

This automation will make your unmanageable task to review the entire crates.io manageable.

This automatic mode of review should be optional, there should nevertheless be fully manual mode of review.

[dpc]

don't use I/O (except of channels, which are OK) and can't produce undefined behavior

This one is hard because Rust does not have any facilities to enforce it, or even just track it (like an language level effect system).

First, we would have to parse the code somehow, in a reliable way. Then we have to forbid:

• bunch of stdlib APIs
• unsafe

and then ultimately there's a problem that if a crate sus uses easy_file_reader (which is reviewed, perfectly fine and trusted) to snoop on files, and reqwest (again, popular, trustworthy crate) to send secrets to some host somewhere, then just because sus doesn't make any directly I/O, it's hard to say how it is using the I/O of it's legitimate and reviewed dependencies it has.

Even worse, a crate sus2 might not have any dependencies, but have API that require injecting to it things that do I/O and that could potentially be used maliciously.

So, while there is some valuable heuristic here, it's definitely not a golden bullet or really reliable. It's might make the job of malicious code a bit harder.

I am hoping that in a decade or two PL research will bring us a Rust-like language but with an addition of side effect control, which would allow language level isolation and security.

[vporton]

So, we need to have two levels of auto-review:

1. not malicious (sus falls here)
2. not malicious and doesn't do any I/O (except of harmless one, like creating a /tmp file)

I deliberately do not consider the ability to inject IO (sus2 is still to be considered safe), because we blame the injector of I/O code, not the function where it is injected. (It is because the system of code with injection and injector are together potentially malicious, we need to define only one of them to be potentially malicious. It's better to define to be potentially malicious the injector, because otherwise we would define malicious any code that allows injection what is clearly wrong.)

[dpc]

because we blame the injector of I/O code, not the function where it is injected.

Why?

I'm kind of out of time to debate and explain all the details right now, but I don't believe this is feasible. However if you really think it is, I would encourage you to give it a try, and it will be easier to talk once there is some code to review and try.

[vporton]

Why?

I explained in the parentheses.

However if you really think it is, I would encourage you to give it a try, and it will be easier to talk once there is some code to review and try.

I don't have free time to write this free software.

[MaeIsBad]

On top of everything dpc said soundness bugs exist in the language, making it trivial to execute arbitrary bytecode by abusing them