Stream: wg-secure-code

Topic: build-time sandboxing


Tony Arcieri (Jan 23 2019 at 16:45, on Zulip):

This keeps coming up: https://github.com/rust-secure-code/wg/issues/29

Shnatsel (Feb 03 2019 at 21:45, on Zulip):

Since this is a second line of defence and you're pwned regardless of whether we have it or not, I'm not sure I'm on board with this being a 2019 goal. There is already so much on our plates, and I'd expect better authenticating downloaded packages in the first place to take priority.

snf (Feb 03 2019 at 22:27, on Zulip):

you're pwned regardless of whether we have it or not

Are you referring to having the resulting build contaminated whether there is a sandbox or not?

Shnatsel (Feb 03 2019 at 22:32, on Zulip):

Yes.

Tony Arcieri (Feb 04 2019 at 18:20, on Zulip):

I was encouraged by seeing crater disable network access

Tony Arcieri (Feb 04 2019 at 18:20, on Zulip):

that leads me to believe that crates aren't presently doing things like hitting the network during builds

Tony Arcieri (Feb 04 2019 at 18:21, on Zulip):

for a "do no harm" sandbox, the longer you wait, the harder it will be to retrofit restrictions

Tony Arcieri (Feb 04 2019 at 18:22, on Zulip):

and yes... it seems people have pretty polarized opinions on this

Tony Arcieri (Feb 04 2019 at 18:24, on Zulip):

on the one hand, there's the "RCE? game over man, game over" argument https://users.rust-lang.org/t/how-does-crates-io-differ-from-npm/22658/21

Tony Arcieri (Feb 04 2019 at 18:25, on Zulip):

Attacking at build-time allows for a fly-by-night attack that leaves no forensic evidence and potentially permits lateral movement

Tony Arcieri (Feb 04 2019 at 18:25, on Zulip):

as such, it's also the superset of the alternative, which is to trojan the target artifact

Tony Arcieri (Feb 04 2019 at 18:26, on Zulip):

to me, one of these things is clearly worse than the other

Tony Arcieri (Feb 04 2019 at 18:29, on Zulip):

speaking as someone who used to work on a DFIR team for several years... a non-build-script attack leaves forensic evidence not just in the target binary, but in the original source code

Tony Arcieri (Feb 04 2019 at 18:29, on Zulip):

that makes finding the payload a matter of examining the source of the original crate

Tony Arcieri (Feb 04 2019 at 18:29, on Zulip):

you don't get that guarantee with build scripts

Tony Arcieri (Feb 04 2019 at 18:30, on Zulip):

they could grab a malicious payload off the Internet, and do it in such a way that thwarts attempts by researchers to discover it

Tony Arcieri (Feb 04 2019 at 18:30, on Zulip):

build-time attacks are much, much more worrisome to me

Zach Reizner (Feb 04 2019 at 18:31, on Zulip):

that leads me to believe that crates aren't presently doing things like hitting the network during builds

I've seen crates that download code using git to build a C dependency.

Tony Arcieri (Feb 04 2019 at 18:32, on Zulip):

huh... do those pass crater?

Tony Arcieri (Feb 04 2019 at 18:32, on Zulip):

I'm going to guess no

Zach Reizner (Feb 04 2019 at 18:32, on Zulip):

No idea. The only example I know of is in crosvm's new vTPM code.

Tony Arcieri (Feb 04 2019 at 18:32, on Zulip):

happen to know a crate name?

Zach Reizner (Feb 04 2019 at 18:33, on Zulip):

dtolnay might. I got the impression he got the idea from another crate.

Tony Arcieri (Feb 04 2019 at 18:33, on Zulip):

to me the "proper" way to do that is a git submodule in the original repo, and then that can just package the source at the commit the submodule is pinned to into the resulting crate...

Zach Reizner (Feb 04 2019 at 18:33, on Zulip):

The idea is that the source is downloaded and built only when the platform hasn't already installed a static lib.

Tony Arcieri (Feb 04 2019 at 18:33, on Zulip):

aah

Zach Reizner (Feb 04 2019 at 18:34, on Zulip):

Agreed that crates should have a more graceful way of using third-party code than downloading in build.rs.

Tony Arcieri (Feb 04 2019 at 18:35, on Zulip):

if you happen to know the name of such a crate, I'd be interested in investigating how crater handles those crates

Tony Arcieri (Feb 04 2019 at 18:36, on Zulip):

the fact crater is shutting off things like network access to operate kind of speaks to the need for the general feature, IMO...

Tony Arcieri (Feb 04 2019 at 18:36, on Zulip):

but maybe I'm just a fan of POLA :stuck_out_tongue_wink:

Zach Reizner (Feb 04 2019 at 18:40, on Zulip):

Found one: https://github.com/tversteeg/castle-game/blob/master/build.rs

Zach Reizner (Feb 04 2019 at 18:40, on Zulip):

https://crates.io/crates/castle-game

Zach Reizner (Feb 04 2019 at 18:41, on Zulip):

I just looked through a few pages of crates that depend on git2 and this was the first one I found that used it in build.rs for downloading.

Tony Arcieri (Feb 04 2019 at 18:43, on Zulip):

it's listed as "skipped" in crater

Zach Reizner (Feb 04 2019 at 18:46, on Zulip):

Where can I get this crater information?

Tony Arcieri (Feb 04 2019 at 18:47, on Zulip):

it doesn't exactly have the world's most usable/browsable UI, heh

Tony Arcieri (Feb 04 2019 at 18:47, on Zulip):

https://crater-reports.s3.amazonaws.com/beta-1.33-1/index.html

Tony Arcieri (Feb 04 2019 at 18:47, on Zulip):

https://crater.rust-lang.org/ex/beta-1.33-1

Tony Arcieri (Feb 06 2019 at 17:07, on Zulip):

hmmm some discussion of external dependency handling here https://internals.rust-lang.org/t/external-dependencies-in-declarative-format/9372

Alex Gaynor (Feb 06 2019 at 23:14, on Zulip):

I'm not wading into this thread, but if everyone is on the same page that we should sandbox, I'm happy to review/write whatevers needed by way of a sandboxing library.

Tony Arcieri (Feb 06 2019 at 23:18, on Zulip):

I think it'd be at least be interesting to build a prototype with something like gaol

Tony Arcieri (Feb 06 2019 at 23:18, on Zulip):

having something tangible to talk about at least breaks the endless pontificating cycle

Cem Karan (Feb 07 2019 at 15:50, on Zulip):

Is depending on containers (at least for right now) out of the question?

Cem Karan (Feb 07 2019 at 15:51, on Zulip):

I know that could make for a heavy-weight dependency, and it could be a headache for supporting multiple platforms, but until gaol is considered to be production ready, containers may be a good option.

Shnatsel (Feb 07 2019 at 18:43, on Zulip):

Containers are chroot+cgroups with a bunch of tooling on top. They do not really introduce much in the way of dependencies - they just need a kernel with those facilities, such as Linux, FreeBSD or Solaris/Illumos. This means that MacOS and Windows would be missing out.

Tony Arcieri (Feb 11 2019 at 06:38, on Zulip):

see also namespaces+seccomp, which are IMO the more interesting tools for security. as it were, gaol provides a cross-platform abstraction to those and, well... not entirely dissimilar facilities on other operating systems (not entirely similar either, but "best sandbox for the current OS" is probably a reasonable goal)

Zach Reizner (Feb 11 2019 at 19:23, on Zulip):

spitballing her: for tackling the cross-platform issue: what if the build script were compiled to wasm and run with an OS-agnostic abi?

Tony Arcieri (Feb 12 2019 at 16:28, on Zulip):

I saw there was a WASM + CloudABI project as it were... but that seems like a substantially larger change than just sandboxing the build script

Tony Arcieri (Feb 12 2019 at 16:29, on Zulip):

what's nice about using something like gaol is crate consumers could opt into giving the build script all of the access ones today have

Tony Arcieri (Feb 12 2019 at 16:29, on Zulip):

aah yeah this: https://github.com/CraneStation/wasmtime

Tony Arcieri (Feb 12 2019 at 16:29, on Zulip):

fun name :wink:

Tony Arcieri (Feb 17 2019 at 22:03, on Zulip):

apparently Amazon wrote a tool of this ilk for Firecracker: https://github.com/firecracker-microvm/firecracker/blob/master/docs/jailer.md

Zach Reizner (Feb 17 2019 at 22:07, on Zulip):

Seems similar to minijail which we use in crosvm and in Chrome OS

Leo Le Bouter (Mar 22 2019 at 20:24, on Zulip):

hi there, considering that most people are importing dependencies without reading their code and that these can contain build scripts or procedural macros that can compromise one's computer, I was thinking we should maybe provide a sandboxed offline compilation process by default in Cargo (SELinux, Hyper-V APIs, jail). What is your opinion on such a thing?

I'm also thinking about RLS that automatically compiles dependencies, which means it's automatically running untrusted code unsandboxed.

Zach Reizner (Mar 22 2019 at 20:33, on Zulip):

There is already a topic for this that you might want to read through and repost your question: "build-time sandboxing"

Leo Le Bouter (Mar 22 2019 at 20:35, on Zulip):

Yes sorry, I have realized, happy to see it's already being discussed.

Leo Le Bouter (Mar 22 2019 at 20:38, on Zulip):

So I wanted to insist on the fact that this has to be default in everyone's development environment else the risk wont be mitigated

Leo Le Bouter (Mar 22 2019 at 20:40, on Zulip):

There's also a problem that I see, it's that we couldnt flag crates that perform network access in build scripts or macros on crates.io because these can always set up a buffer with shellcode and run networked malware there.

Leo Le Bouter (Mar 22 2019 at 20:42, on Zulip):

I don't think that any build script or procedural macro code should ever be allowed to access the network.

JP Sugarbroad (Mar 22 2019 at 22:31, on Zulip):

I mean, I'm sure someone will come up with reasons why they need their build script to do so. Off-hand, I'm thinking of cases where you want to ask the build script to automatically update to the upstream version. But by default, no, no build-time code should be able to access the network or arbitrary places on the FS or even arbitrary syscalls. Whatever solution is engineered will need an escape hatch.

Shnatsel (Mar 22 2019 at 22:38, on Zulip):

Is downloading a C library if it's not installed locally still a thing? I imagine it would be pretty big on Windows

JP Sugarbroad (Mar 22 2019 at 22:39, on Zulip):

It was a thing?!

Zach Reizner (Mar 22 2019 at 22:39, on Zulip):

Yeah, it's pretty convenient for ssl and zlib wrappers that are in the ecosystem.

JP Sugarbroad (Mar 22 2019 at 22:39, on Zulip):

Oh, you mean for -sys crates.

JP Sugarbroad (Mar 22 2019 at 22:40, on Zulip):

Probably. submodules would be better, but people don't use/understand them.

Shnatsel (Mar 22 2019 at 22:43, on Zulip):

What kind of submodules? I hope you don't mean git submodules?

Shnatsel (Mar 22 2019 at 22:44, on Zulip):

But yeah, this is a thing, and this practice is especially horrifying for something like OpenSSL that gets a new batch of vulnerabilities every 3 months or so, because you get this thing statically linked with no record of which version compiled or even downloaded. And the worst part is that while on Linux you have an easy way to install these libs, on Windows you don't - or at least, it didn't have anything like that back when I last saw it 10 years ago.

JP Sugarbroad (Mar 22 2019 at 22:53, on Zulip):

Yes, git submodules? Why not?

Zach Reizner (Mar 22 2019 at 22:53, on Zulip):

Opinion/rant: git submodules solves its problem domain in such a confusing way that it poisons any future attempts to improve on its problem domain. Kind of like PGP.

Shnatsel (Mar 22 2019 at 22:55, on Zulip):

No submodules would be way better than what git ended up with.

Shnatsel (Mar 22 2019 at 22:56, on Zulip):

Although compared to the rest of user-facing parts of git it doesn't even stand out all that much

Shnatsel (Mar 22 2019 at 22:58, on Zulip):

Frankly I do not see how git submodules are relevant to crates published on crates.io

Zach Reizner (Mar 22 2019 at 22:59, on Zulip):

I guess the equivalent idea is one could upload sidecar zips to crates.io that could be optionally downloaded if the build script wanted it.

Zach Reizner (Mar 22 2019 at 23:00, on Zulip):

You can't have real networking, but you can have safety-scissors that are impossible to cut yourself with.

Shnatsel (Mar 22 2019 at 23:00, on Zulip):

This... actually sounds like a pretty great idea.

Shnatsel (Mar 22 2019 at 23:01, on Zulip):

Quick, jot it down in https://github.com/rust-secure-code/wg/issues/29

Zach Reizner (Mar 22 2019 at 23:01, on Zulip):

ok

JP Sugarbroad (Mar 22 2019 at 23:01, on Zulip):

Well, I like submodules as implemented in the plumbing (the porcelain for them is terrible). Most importantly, they propagate the core git guarantee -- if you download a specific sha1 you get exactly the same tree.

Zach Reizner (Mar 22 2019 at 23:02, on Zulip):

I don't think cargo downloads crates with git though. I thought it downloaded zips.

JP Sugarbroad (Mar 22 2019 at 23:04, on Zulip):

Ah, that I did not know. Why not have people package up their C dependencies then?

JP Sugarbroad (Mar 22 2019 at 23:05, on Zulip):

I mean, first question is how hard is that to do? If it's hard to do, we should fix that first.

JP Sugarbroad (Mar 22 2019 at 23:05, on Zulip):

(I have never published a crate...)

Zach Reizner (Mar 22 2019 at 23:06, on Zulip):

Depending on the source being packaged, it may be very large.

Zach Reizner (Mar 22 2019 at 23:06, on Zulip):

It's also not always necessary if pkg-config can just give them a lib from the system.

JP Sugarbroad (Mar 22 2019 at 23:06, on Zulip):

Hence sidecar zips?

JP Sugarbroad (Mar 22 2019 at 23:06, on Zulip):

Alternatively one could specify URL+hash pairs somewhere.

Zach Reizner (Mar 22 2019 at 23:06, on Zulip):

I guess. Honestly I'm not certain it's a good solution. I was only spit-balling ideas.

JP Sugarbroad (Mar 22 2019 at 23:07, on Zulip):

It's not a terrible idea. But I'm reading the crates.io docs and they have a strict 10MB limit on .crate files.

Zach Reizner (Mar 22 2019 at 23:07, on Zulip):

URL+hash seems reasonable, assuming the URLs are pinned down to trusted domains

JP Sugarbroad (Mar 22 2019 at 23:07, on Zulip):

trusted domains?

JP Sugarbroad (Mar 22 2019 at 23:07, on Zulip):

Are you concerned about leaking information about who's downloading?

Zach Reizner (Mar 22 2019 at 23:08, on Zulip):

Yeah. If cargo contacted a domain controlled by an attacker, that would probably violate what people imagine a "sandbox" is good for.

Zach Reizner (Mar 22 2019 at 23:08, on Zulip):

I also want to reserve the option of caching/rewriting/mirroring domains for the purposes of hermetic build systems, like the kind in Chrome OS.

Zach Reizner (Mar 22 2019 at 23:09, on Zulip):

Although I suppose the "hash" part solves the issue well enough.

JP Sugarbroad (Mar 22 2019 at 23:09, on Zulip):

You get that from the hash, though. Your build system can look up that hash wherever it wants

JP Sugarbroad (Mar 22 2019 at 23:09, on Zulip):

The URL is just a hint

Zach Reizner (Mar 22 2019 at 23:10, on Zulip):

But most people won't have a pre-mirrored system but would still like a sandbox.

JP Sugarbroad (Mar 22 2019 at 23:10, on Zulip):

Most people won't care about the leak.

Zach Reizner (Mar 22 2019 at 23:11, on Zulip):

Most people don't care about build time sandboxing either.

JP Sugarbroad (Mar 22 2019 at 23:11, on Zulip):

They want a sandbox to protect their systems, not their privacy.

Zach Reizner (Mar 22 2019 at 23:11, on Zulip):

Who are we building this sandbox for?

JP Sugarbroad (Mar 22 2019 at 23:11, on Zulip):

Fair question.

Shnatsel (Mar 22 2019 at 23:11, on Zulip):

Time for a product requirements document!

Zach Reizner (Mar 22 2019 at 23:12, on Zulip):

Also, malware that is being distributed through crates.io can be purged. Malware that is distributed from a attacker controlled server that cargo is directed to download from is harder to purge.

Zach Reizner (Mar 22 2019 at 23:13, on Zulip):

So I would argue it's not only privacy being preserved.

Shnatsel (Mar 22 2019 at 23:13, on Zulip):

you also get an audit trail that way, since crates.io is supposedly immutable

JP Sugarbroad (Mar 22 2019 at 23:13, on Zulip):

Audit trail of... the malware?

JP Sugarbroad (Mar 22 2019 at 23:14, on Zulip):

The people who downloaded it?

JP Sugarbroad (Mar 22 2019 at 23:14, on Zulip):

Sorry, getting distracted.

JP Sugarbroad (Mar 22 2019 at 23:14, on Zulip):

Who is the sandbox for?

JP Sugarbroad (Mar 22 2019 at 23:15, on Zulip):

The first tranche is obviously the majority -- don't care until they get malware on their box or in their product.

Zach Reizner (Mar 22 2019 at 23:15, on Zulip):

I would think it is for everybody to run by default unless they have a very good reason not to.

JP Sugarbroad (Mar 22 2019 at 23:15, on Zulip):

We can't do anything about the product side, obviously.

Zach Reizner (Mar 22 2019 at 23:15, on Zulip):

Good reasons might be legacy crates or the crate is from a trusted party (i.e. an internal team wrote it).

JP Sugarbroad (Mar 22 2019 at 23:16, on Zulip):

(We should also model the attack side, which means we're really building a full threat model.)

Zach Reizner (Mar 22 2019 at 23:21, on Zulip):

I guess we can start with the easy stuff:
The attacker has control over the Cargo.toml/Cargo.lock and can upload arbitrary zips to crates.io under crate names that they own.

Zach Reizner (Mar 22 2019 at 23:22, on Zulip):

The attacker can perform a cargo build but can not do a cargo test or cargo run

JP Sugarbroad (Mar 22 2019 at 23:23, on Zulip):

Control over my Cargo.toml? How?

Zach Reizner (Mar 22 2019 at 23:24, on Zulip):

They gave you a really cool demo on hackernews and explained how you too can make your own ray-traced doom clone with this nice crate.

JP Sugarbroad (Mar 22 2019 at 23:24, on Zulip):

Sure, so you copy-pasted their Cargo.toml including some weird directives they said were needed to make it work.

JP Sugarbroad (Mar 22 2019 at 23:24, on Zulip):

Why can the attacker build but not run?

Zach Reizner (Mar 22 2019 at 23:25, on Zulip):

How are we going to sandbox arbitrary rust programs?

JP Sugarbroad (Mar 22 2019 at 23:25, on Zulip):

Oh, I see. You're saying only build is in scope.

Zach Reizner (Mar 22 2019 at 23:25, on Zulip):

The rust program is probably going to be doing something useful most of the time. We can't hope to sandbox it without everybody disabling it all the time.

Zach Reizner (Mar 22 2019 at 23:26, on Zulip):

Yeah, most build scripts do a common subset of simple things.

JP Sugarbroad (Mar 22 2019 at 23:30, on Zulip):

I think "download this external archive so I can compile it" is a pretty common thing and easy to provide a safe(r) API for.

Zach Reizner (Mar 22 2019 at 23:30, on Zulip):

Agreed

JP Sugarbroad (Mar 22 2019 at 23:31, on Zulip):

Probably what we need to do is make a simple sandbox and crater it.

JP Sugarbroad (Mar 22 2019 at 23:31, on Zulip):

See what breaks.

Shnatsel (Mar 23 2019 at 00:22, on Zulip):

Crater already prohibits network access, so there's that

briansmith (Mar 23 2019 at 00:46, on Zulip):

I believe it is pretty common for people to do it (see e.g. https://github.com/danburkert/prost/commit/e0317f83958892d716e99423f07525db5c7469e6#diff-3457fb1ebde739813ad9692cad895f1f) and people don't understand why (for so many reasons) why they shouldn't. I see that as a quite distinct issue from sandboxing the build, though.

briansmith (Mar 23 2019 at 00:50, on Zulip):

Note in particular that I ended up embedding like 20MB of executables into that crate in order to avoid the network access.

Shnatsel (Mar 23 2019 at 00:50, on Zulip):

...so you've embedded OpenSSL and now you need to issue a security update to your crate every time they find yet another CVE in that thing?

briansmith (Mar 23 2019 at 00:51, on Zulip):

I don't think we embedded OpenSSL into PROST directly or indirectly since i think those executables don't do network I/O.

briansmith (Mar 23 2019 at 00:52, on Zulip):

But, in the case of rust-openssl or similar, yes you would.

Shnatsel (Mar 23 2019 at 00:55, on Zulip):

"Importantly, this eliminates very heavy and brittle non-Rust dependencies
including in particular curl and OpenSSL." says the commit message

briansmith (Mar 23 2019 at 00:55, on Zulip):

Right, because OpenSSL was used to download the files.

Shnatsel (Mar 23 2019 at 00:55, on Zulip):

oooh

briansmith (Mar 23 2019 at 00:55, on Zulip):

Since the downloading was removed, OpenSSL dep was removed.

briansmith (Mar 23 2019 at 00:59, on Zulip):

Anyway, I think that to realistically have a chance at implementing a sandbox that blocks network I/O by default (and if not by default, why bother?) and/or all the time (ideally), one would need to implement a new build stage, separate from build.rs, that can be used for downloading dependencies.

briansmith (Mar 23 2019 at 01:00, on Zulip):

Similarly, people embed executables in build.rs, there would probably need to be some mechanism for whitelisting/approving the execution of such embedded executables, if blocking them is to be blocked by default.

Shnatsel (Mar 23 2019 at 01:03, on Zulip):

I don't actually mind embedding executables because proc macros can do literally anything anyway. You already got arbitrary code in, congratulations.

briansmith (Mar 23 2019 at 01:12, on Zulip):

I would assume that people expect proc macros to be safer because they can read the code.

briansmith (Mar 23 2019 at 01:13, on Zulip):

I seem to remember that when the executables in PROST get updated, some doc enumerating their SHA-256(?) hashes and the source of the executable gets updated.

Shnatsel (Mar 23 2019 at 10:55, on Zulip):

Well, you can always embed a long hex string with a compiled binary in your source code

Zach Reizner (Mar 23 2019 at 17:16, on Zulip):

Let's assume the download of source code is handled safely. The next thing that is typically done is executing gcc/clang/make on it. That seems really hard to sandbox because essentially arbitrary and highly complex binaries are being fed attacker controlled input.

Tony Arcieri (Mar 24 2019 at 02:07, on Zulip):

wow discussion

Tony Arcieri (Mar 24 2019 at 02:07, on Zulip):

/me scrolls up

Tony Arcieri (Mar 24 2019 at 02:07, on Zulip):

so uhh

Tony Arcieri (Mar 24 2019 at 02:08, on Zulip):

people who want to hit the network to download some external asset/what have you

Tony Arcieri (Mar 24 2019 at 02:08, on Zulip):

that seems like a gross hack

Tony Arcieri (Mar 24 2019 at 02:08, on Zulip):

what is the justification as opposed to packaging the thing you'd otherwise download in the crate itself?

Tony Arcieri (Mar 24 2019 at 02:08, on Zulip):

microoptimizing bandwidth?

Tony Arcieri (Mar 24 2019 at 02:09, on Zulip):

it seems like there's a boring KISS solution to this problem and it's "put the thing you'd otherwise hit the network to download in the crate and you're done"

Tony Arcieri (Mar 24 2019 at 02:10, on Zulip):

shelling out to git/curl/etc from build.rs seems like a cargo-culted antipattern which is probably best eliminated

Alex Gaynor (Mar 24 2019 at 02:12, on Zulip):

Probably the best way to eliminate it is to find the commonality and make it easier to do something better.

Tony Arcieri (Mar 24 2019 at 02:13, on Zulip):

1) add git submodule for the code you'd otherwise use build.rs to go clone
2) package said code into your crate
3) you're done

Tony Arcieri (Mar 24 2019 at 02:14, on Zulip):

[img:thereisnospoon] "there is no build.rs"

Tony Arcieri (Mar 24 2019 at 02:15, on Zulip):

or any need for new cargo features, barring a legitimate need to microoptimize bandwidth in the case crates have, umm, "optional assets"

Zach Reizner (Mar 24 2019 at 02:15, on Zulip):

The code is usually C, so a build.rs is needed to build it.

Tony Arcieri (Mar 24 2019 at 02:16, on Zulip):

that sort of thing feels like playing with fire in terms of things like reliable or better yet reproducible builds... or binary transparency efforts (for, say, a hypothetical future community build server)

Zach Reizner (Mar 24 2019 at 02:16, on Zulip):

The size restrictions of 10MB on crates.io means you can't put all the code in.

Tony Arcieri (Mar 24 2019 at 02:16, on Zulip):

haha yeah sure I'm not talking about the cc crate :wink:

Tony Arcieri (Mar 24 2019 at 02:17, on Zulip):

so the counterpoint to concerns about the feasibility of shoving everything into a crate are... left-pad

Tony Arcieri (Mar 24 2019 at 02:17, on Zulip):

or reproducible builds

Tony Arcieri (Mar 24 2019 at 02:17, on Zulip):

I guess my question about 10MB is: what isn't fitting into 10MB at the moment?

Tony Arcieri (Mar 24 2019 at 02:19, on Zulip):

some option for optional external assets would be interesting, but I'd also be curious what the real-world use cases are

Tony Arcieri (Mar 24 2019 at 02:19, on Zulip):

LLVM?

Tony Arcieri (Mar 24 2019 at 02:21, on Zulip):

I guess the next question is "who is the custodian of these assets who is volunteering to indefinitely and reliably host them for free?"

Tony Arcieri (Mar 24 2019 at 02:22, on Zulip):

but that said, aside from the 10MB limit the right answer to me is to put the relevant external artifacts directly into the published crate

Zach Reizner (Mar 24 2019 at 02:22, on Zulip):

Usually the external artifacts are optional.

Tony Arcieri (Mar 24 2019 at 02:22, on Zulip):

sure, but nobody's forcing you to use them

Zach Reizner (Mar 24 2019 at 02:23, on Zulip):

That is, if your system already has LLVM or openssl or whatever, you can simply use that.

Tony Arcieri (Mar 24 2019 at 02:23, on Zulip):

if you download them and don't use them, that's what I was describing as "optimizing bandwidth"

Zach Reizner (Mar 24 2019 at 02:23, on Zulip):

My thinking is that as long as people want to optimize bandwidth, which they seem to do, we need to make it easiest to do it in a safe manner.

Tony Arcieri (Mar 24 2019 at 02:23, on Zulip):

which is a concern I would rate lower than "build.rs is shelling out to random tools to attempt to obtain essential build artifacts that may have disappeared from wherever they were originally supposed to be hosted"

Tony Arcieri (Mar 24 2019 at 02:24, on Zulip):

yes, but that's a microoptimization...

Zach Reizner (Mar 24 2019 at 02:24, on Zulip):

I can understand that perspective.

Tony Arcieri (Mar 24 2019 at 02:25, on Zulip):

if a Rust-friendly CDN provider were to volunteer to be the custodian of the "optional crate asset archive" I could see something like that happening

Zach Reizner (Mar 24 2019 at 02:25, on Zulip):

But on the other hand, it's usually downloading several times the size of the original crate.

Zach Reizner (Mar 24 2019 at 02:25, on Zulip):

I would assume the custodian would have to be crates.io

Tony Arcieri (Mar 24 2019 at 02:25, on Zulip):

but anything short of that seems kinda gross to me

Tony Arcieri (Mar 24 2019 at 02:26, on Zulip):

well I assume that 10MB limit is there for a reason

Tony Arcieri (Mar 24 2019 at 02:26, on Zulip):

but perhaps it could be raised?

Zach Reizner (Mar 24 2019 at 02:26, on Zulip):

It would be nice to find out. Does anybody have contacts on the team?

Tony Arcieri (Mar 24 2019 at 02:27, on Zulip):

can look in either the infra IRC or Discord channels I guess? I assume the latter is the current place

Tony Arcieri (Mar 24 2019 at 02:28, on Zulip):

but I'm really wondering now how much crazysauce abuse of build.rs to go grab random code from git could be trivially replaced with a git submodule whose contents are published as part of a crate

Tony Arcieri (Mar 24 2019 at 02:29, on Zulip):

say, small, infrequently updated libraries

Tony Arcieri (Mar 24 2019 at 02:29, on Zulip):

there might be a system version to link to, but if not, use the source

Tony Arcieri (Mar 24 2019 at 02:30, on Zulip):

I imagine there might be a surprising amount of that sort of thing

Leo Le Bouter (Mar 24 2019 at 16:28, on Zulip):

@Tony Arcieri Downloading things in build scripts is what makes Google Chrome's build system horrible and what makes NPM packages unportable. It's literally impossible to port some Electron applications to a new platform even if Electron itself was ported because most NPM packages blatantly download x86 binaries to compile or do other various tasks. It clearly should be eliminated, if you require third party stuff tell the user to install a package from their distribution and add to PATH variable, just like openssl-sys or libcurl-sys crates.

Leo Le Bouter (Mar 24 2019 at 16:30, on Zulip):

Also for the 10MB limit, can't they create another crate and set it as a dev-dependency?

Leo Le Bouter (Mar 24 2019 at 16:31, on Zulip):

I feel like creating as many reusable crates as possible is the way to go.

Shnatsel (Mar 24 2019 at 17:24, on Zulip):

oh, reusability is a good point, I have not considered it

Tony Arcieri (Mar 24 2019 at 20:44, on Zulip):

yeah for sure

Tony Arcieri (Mar 24 2019 at 20:45, on Zulip):

@Leo Le Bouter I am definitely not a fan of using ad hoc mechanisms for fetching build dependencies exactly for those reasons. Right now, aside from that, Cargo and crates.io are quite good at making sure all build artifacts remain available indefinitely (and are all checksummed in the index)

Shnatsel (Mar 24 2019 at 22:07, on Zulip):

This also ties into auditing binaries for vulnerable libs: as soon as you get those statically linked C blobs versioned and checksummed, you can have an audit trail and check your binaries for vulnerable dependencies even if those came from C

Tony Arcieri (May 18 2019 at 16:37, on Zulip):

made a crate for this: https://github.com/rust-secure-code/cargo-sandbox

Tony Arcieri (May 18 2019 at 16:37, on Zulip):

like cargo-repro it's empty/vaporware

Tony Arcieri (May 18 2019 at 16:37, on Zulip):

here's an issue to discuss: https://github.com/rust-secure-code/cargo-sandbox/issues/3

DevQps (May 20 2019 at 11:50, on Zulip):

Just to be sure I understand it correctly again! Is it actually about building in a sandboxed environment? Or about running the binary in a sandboxed environment?

If it's the first one!: Do we mean that we should be able to download crates in the sandboxed environment? Or that everything should already be there and isolated?

Tony Arcieri (May 20 2019 at 14:03, on Zulip):

/me thinking the former: crates get downloaded in advance, and then subsequent build-time code execution occurs in a sandbox

Tony Arcieri (May 20 2019 at 14:04, on Zulip):

gaol specifically has a set of capabilities the build process is allowed to do. they could be tweakable, but denying network access by default, well... that's what crater does already

DevQps (May 21 2019 at 03:19, on Zulip):

Ahh I think I understand now. It's mainly because there can be a build.rs script that can potentially do anything it would like right? I hope to check the mentioned issue/project and contribute some ideas somewhere this week!

Tony Arcieri (May 21 2019 at 04:03, on Zulip):

build.rs, proc macros, I think there's stuff beyond that

Tony Arcieri (May 24 2019 at 22:22, on Zulip):

More reasons why builds having access to the network is a bad idea: https://twitter.com/lukejacksonn/status/1131506699356037121

snf (Jun 06 2019 at 22:54, on Zulip):

"domain.com/not-a-targeted-backdoor.js". I've seen popular packages in npm using installation telemtry too

Tony Arcieri (Jun 07 2019 at 00:29, on Zulip):

hey look, another case-in-point :wink: https://github.com/RustSec/advisory-db/pull/104/files

Tony Arcieri (Sep 04 2019 at 04:24, on Zulip):

some fun discussion on this thread https://internals.rust-lang.org/t/pre-rfc-procmacros-implemented-in-wasm/10860/75?u=bascule

ecstatic-morse (Sep 04 2019 at 04:40, on Zulip):

(deleted)

ecstatic-morse (Sep 04 2019 at 04:41, on Zulip):

Whoops wrong thread

Thom Chiovoloni (Sep 04 2019 at 16:28, on Zulip):

The desire to do build-time sandboxing also came up a few times in the enterprise rust meetup at rustconf. one of the other people there even broke down a list of things build.rs files tend to do:

1. search for or otherwise wrangle external libraries
2. check rustc version and enable/disable features
3. generate some code to be included in the build
4. (there were 4 of these but i don't remember the fourth one, unfortunately).
most of these are amenable to some form of sandboxing, although number 1 is probably the hardest. number 2 could hypothetically be avoided in more cases if there were a way to query the compiler version info via a builtin cfg(...) thing, which i think there's an RFC for that just nobody has implemented.

Tony Arcieri (Sep 04 2019 at 16:54, on Zulip):

there's been some interesting discussion of using WASM/WASI for this on rust-internals

Tony Arcieri (Sep 04 2019 at 16:55, on Zulip):

which I hadn't seriously considered before but it seems there's a great deal of interest

Shnatsel (Sep 04 2019 at 19:38, on Zulip):

a new cfg_if_rusct without build.rs showed up on Reddit a couple of days ago

Thom Chiovoloni (Sep 04 2019 at 19:52, on Zulip):

without a build.rs? how?

ecstatic-morse (Sep 04 2019 at 19:54, on Zulip):

There's been a crate that does this via a proc-macro attribute for some time: https://crates.io/crates/rustversion

Thom Chiovoloni (Sep 04 2019 at 19:55, on Zulip):

ah right, that makes sense. not really that meaningfully different than build.rs though, although i guess proc macros will probably be easier to sandbox

Thom Chiovoloni (Sep 04 2019 at 20:22, on Zulip):

(OTOH proc macros that depend on the target environment are probably not very well behaved from the standpoint of related goals like being able to download prebuilt artifacts from crates.io)

Shnatsel (Sep 04 2019 at 20:36, on Zulip):

https://crates.io/crates/if_rust_version this one, doesn't depend on syn either so probably not a proc macro?

Shnatsel (Sep 04 2019 at 20:37, on Zulip):

oh it comes with build.rs too, just pushes it one level down

Tony Arcieri (Sep 18 2019 at 16:36, on Zulip):

this looks interesting: https://github.com/rust-lang/rustwide

Tony Arcieri (Sep 18 2019 at 16:37, on Zulip):

wrapper for a Docker sandbox used by crater and docs.rs

Tony Arcieri (Sep 18 2019 at 16:46, on Zulip):

also: https://hub.docker.com/r/rustops/crates-build-env

Shnatsel (Oct 14 2019 at 18:17, on Zulip):

https://github.com/dtolnay/watt - this sure is a step in the right direction, with proc macros being walled off in a small, 100% safe code WASM environment

Shnatsel (Oct 14 2019 at 18:18, on Zulip):

Also helps with reproducible builds

Tony Arcieri (Oct 14 2019 at 18:25, on Zulip):

Yeah saw the relevant rust-internals thread. WASM certainly seems like an interesting way to do sandboxing

Tony Arcieri (Oct 14 2019 at 18:26, on Zulip):

I still want to play with rustwide

Stuart Small (Oct 14 2019 at 18:27, on Zulip):

We had a long talk about sandboxing the other day at work. I'm really excited for wasms potential there

Tony Arcieri (Oct 14 2019 at 18:33, on Zulip):

build.rs + WASI might be interesting

Tony Arcieri (Nov 03 2019 at 15:52, on Zulip):

been playing with Rustwide. It seems pretty cool

Shnatsel (Nov 03 2019 at 17:24, on Zulip):

Nice! I'm thinking of making Clippy security lints into their own category and then running it rustwide

Last update: Nov 11 2019 at 22:15UTC