{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3hoo2op3apdlbnwwozxi2uzmgjniqobko2jnbrbutpqns6gu4hi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkmbfs5afie2"
  },
  "path": "/t/easily-inspect-dependencies/24200#post_8",
  "publishedAt": "2026-04-29T03:08:38.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "https://docs.rs",
    "local-first"
  ],
  "textContent": "epage:\n\n> What do you mean \"without having to redownload\"?\n\nI mean what Kornel suggested:\n\nkornel:\n\n> Currently the easiest safe official method is to view code at https://docs.rs\n\nTo which I agree. But there are caveats:\n\n  * **Cache duplication** : browser and cargo storing similar copies of the same thing\n  * **Not local-first**. Ideally, browsers should allow caching pages for arbitrary periods of time, and they should reuse cached copies when connection fails, but major browsers don't do that; I often see \"security\" and \"document expiration\" cited as excuses, but not all pages need that.\n  * **user-agent sniffing** : if `crates.io` and `docs.rs` get compromised, the source-code view of a crate in the web could look normal, but the one downloaded via `cargo` would have malicious code. This is the same reason why inspecting scripts in a browser before running `curl https://sketchy-sus-site.com | sh` is not enough validation, as `curl` has a different UA-string than the browser. This also answers the other question:\n\n\n\nepage:\n\n> Why does opening the files locally in this way part of supply chain security?\n\nbecause the \"web-view\" of a file _might_ not match the version downloaded through other means.\n\nepage:\n\n> Build scripts are tricky [...]\n\nI see . Thanks for explaining",
  "title": "Easily inspect dependencies"
}