Maybe AI isn't that incredible, the more you use it, the more you realize it's a tool, like a VCR, maybe that's why?
What was sold as AI was basically a "computer person". Maybe that isn't the reality so when people are like, "here's the self coding machine" everyone is a bit disappointed because it's not C3PO?
cargo add + rust-analyzer instantly executes build.rs before you have a chance to audit the code.
Cargo, please PLEASE give me a way to disable third-party build.rs and whitelist the ones I need. And please loudly mark any update that adds a build.rs where there was none before.
cargo-deny can audit build scripts, but unfortunately not prevent execution of malicious build scripts exactly for the reason you gave. It could still help if you only ever use cargo add and update in a sandbox.
Safe-ish recommendation: Only add well-known, trusted crates. Failing that, treat unknown crates as malware or containing malware dependencies until proven otherwise. Test untested tools/crates in a VM/dev container to be sure they work properly before trust them. Use Mark I eyeball and Mark III brain too. :)
Audit and limit crates (cargo-deny &| cargo-crev, && --offline) until tools exist to audit build.rs safety semi-automatically ($$ safeguard.sh maybe).
The root problem is two parts:
1. crates.io doesn't do mandatory curation. Lack of curation is fail. It's time-consuming and costly for reviewers without a doubt, but so is letting an ecosystem gain maximum entropy (go to shit) by Tragedy of the Commons depending entirely on the honor system. Name squatting, low-quality, unmaintained, typosquatting, and malware are the consequences of too much self-service / semi-self-service freedom.
2. Many, many cargo subcommands are over-eager to run build.rs because it assumes trusted crates:
In an untrusted/uncurated crates world and a build.rs exists or exists in a selected dependency, it shouldn't run at cargo-add time (unless it must). If it exists, on first run, it should be presented to the user in a viewer for manual review unless a magic CLI flag/env var is specified to accept it.
These 2 factors combined appear to create a Swiss cheese holes failure mode for running arbitrary crate `cargo add`. I have confidence a suitable add-in workflow &| standard command &| repository workflow will be adjusted to reduce the attack surface of the ecosystem.
You audit the code, then you run cargo update and you are pwned. Asking the user to not make mistakes is the c++ approach to security - it doesn’t work.
This comment is both true and entirely irrelevant. The context of this subthread is not running a Cargo command in a checkout of a malicious git repo, it's alleging that `cargo add foo` runs the build script of the crate `foo`, which is false.
The primary problem with SPAs is actually that the server state is duplicated client-side, which inevitably leads to state desync bugs.
The secondary problem is SPAs approximately double the amount of code you need to write compared to a server-side approach for the same level of interactivity.
Our webapp is achieving 800:1 to 5000:1 compression ratios pushing down the entire HTML page over brotli and zstd. The first render is about 20:1 compression, every interaction after that is 800-5000:1.
We are using datastar with the recommended "fat morph" approach where we re-render the entire HTML page from scratch on every request. Our typical RTT is <100ms including rendering, then the brotli / zstd compression window cuts down the wire size to literally _bytes_.
This is SO much more efficient than our previous reactjs & graphql render waterfalls with state duplication in the client side. All states lives on the server, all renders are authoritative, and we need to maintain roughly half the code size for better first-render and massively better interactive performance. Appserver and DB pressure is massively reduced too.
(This is a medical device with a highly interactive UI, image viewers, editors, not a boring old static website.)
Okay, so, to parse this — you have a highly performant http/1 app using a fresh connection setup/teardown at 100ms per cycle?
Have you tested that same app over http/3 with tuning to reuse the underlying channel, and if so, what were your outcomes?
H1 can be pretty awesome but my core curiosity here is whether reducing the connection overhead through H3 matters or not. I am not out to disprove H1 full-page HTML as a delivery mechanism.
reply