@Tony Arcieri can you do an absicca release and then bump the absiscca and failure versions in cargo-audit? I think that'll reduce the number of copies of syn/quote/proc-macro2 that get compiled, which should help with build speed
I'm happy to do the PRs for cargo-audit, but obviously I can't do an absicca release
yeah I've been planning on it. there are a few other things I want to get in there
just been updating all of my other pre-1.0 custom derive stuff
Just realized we also need gumpdrop-derive, which doesn't have a release that uses the 1.0 family. Left a comment asking them for it.
yeah that just got a PR to bump it
which I've also been waiting on
The PR was merged, so I left a comment asking about a release.
gumdrop release out!
ok, this gets rid of all of the pre-1.0 proc macro crates: https://github.com/iqlusioninc/abscissa/pull/141
I did a
cargo +nightly build -Z timings --release on cargo-audit
master. That's the build graph, filtered to only crates that took >15 seconds to compile. It looks like getting down to only a single version of the proc macro crates will help a lot, but there's some other crates that still take a ton of time to compile.
heh, wow @
darling_core taking longer than
I feel like both of them are at 10x what I'd like :-)
ok, v0.10.0 is out w\ the upgrades https://crates.io/crates/cargo-audit
Cool! I left a few comments
Great comments, thanks a lot!
Hmm, I wonder if I can abuse my access at Google to get Go developers to chime in on what has and hasn't worked for them with this metadata
@Shnatsel when I was at Square we had a tool like this for Ruby applications. It found all Gemfile.lock files on production servers/containers, audited them against RubySec, and then auto-filed VULN tickets against the app owners
tickets also auto-closed when the apps were updated
I am not familiar with the Ruby software distribution model. Is that file necessary to run the program?
it's the most common way of managing Ruby apps. not completely necessary but definitely the most popular
So it was a distinct file you had to ship, but it was typical for it to be shipped. Cool! Could you add this as a comment on the PR?
If Go had a vuln db, and I had a lot more free time, I'd probably write something at $work that scanned docker images for binaries with embedded go.mod info, did a vuln check on them, and then filed tickets if either a) that image was :latest, or b) there was anything in the container orchestration system using that image.
@Shnatsel yeah sure. you can imagine it sort of like a runtime Cargo.lock
@Tony Arcieri could you chime in on the reproducible builds angle in https://github.com/rust-lang/rfcs/pull/2801 ?
Cargo.lock should be deterministic for a given toolchain and index state, I think...
I'm playing around with trying to make a reproducible build tool based on Rustwide
Eh, I don't think I can vouch for Cargo.lock having stable sort order
For reproducible builds this seems to be both a blessing (the info is right there in the binary) and a curse (the info itself is hard to make reproducible) - and there are concerns around the crate coming from one registry or another and that evaluating to different metadata
I mean, if anything...
reproducing a build needs Cargo.lock
you can't reproduce a build without it
as an input
so if anything it's a helpful forensic artifact for reproducing builds! :smiley:
Some are calling for including
(crate-name, version, hash) only without the source URL of any kind. Do you think including registry URL or git repo url is helpful, or hinders reproducibility?
the git repo stuff should allow you to reproduce the build still, if you have access to the repo and the relevant commits are still there
Cargo.lock encodes all of the commit hashes for each package
I guess this is about commit hash only vs repo url as well
I think they might be a bit... entangled
uuh, repo url is not included in the hash
here's an example:
[[package]] name = "libra-config" version = "0.1.0" source = "git+https://github.com/libra/libra.git?rev=66734424#667344248287a1647f42a793e92414853a5fa335"
also trying to redact Cargo.lock all gets very tricky with v1 vs v2, heh
What's v1 vs v2?
Darn, embedding paths is getting really thorny really quickly. Maybe I should just make it an optional, off-by default thing. This way enterprise can enforce it and use it, and everybody else enjoys no-info-leaks.
shipped in 1.38 I think?
OIC. Thanks for the input on the thread!
We got a response from a Rust team member too, encouraging on the basic direction but with a lot of valid points about the weaknesses of the current proposal.
They all seem to be actionable, so I'll try to iterate on the RFC and request another round of review. Any help is appreciated, just brainstorming solutions for those points would be great.