unfortunately i have developed another theory
19
Replies
0
Boosts
@hipsterelectron new day new banger theory
this one is so unsatisfying it doesn't even satisfy me
so there's a reason google makes use of backdoors to do essentially boring things. and especially a reason build systems and compilers are often both very slow and know absolutely nothing about i/o
just a note this guy dan kaminsky sucks i hate everything this paper fucking says https://eprint.iacr.org/2004/357.pdf
Not that malice from the developers is a required component of such an attack. Maynor [6] describes a fascinating failure mode whereby the multitude of compilation, assembly, and packaging tools used to bring code from raw text to deployed code are themselves attacked. The logical progression of Thompson’s classic essay on Trusting Trust [7], in which a C Compiler was infected and would subsequently infect anything else compiled with it, including other C Compilers, Maynor’s approach has some interesting implications when combined with Stripwire. Conceivably, ”Ice” could be injected into each build
assembled by the developers, thus allowing internal testing to proceed uninhibited. But, upon shipment ”Fire” would be swapped in by a malicious third party.
https://blackhat.com/presentations/bh-usa-04/bh-us-04-maynor.pdf
My compiler? You MUST be joking!
the point this is exactly the kind of shit people like ron rivest fantasize about doing, is letting every single process any one of us peons performs pay them a tithe
i will claim that this has happened to the rust programming language
we begin with the most basic two protocols and step deeper into supposition
- Packages with 1 character names are placed in a directory named 1.
- Packages with 2 character names are placed in a directory named 2.
- Packages with 3 character names are placed in the directory 3/{first-character} where {first-character} is the first character of the package name.
- All other packages are stored in directories named {first-two}/{second-two} where the top directory is the first two characters of the package name, and the next subdirectory is the third and fourth characters of the package name. For example, cargo would be stored in a file named
ca/rg/cargo.
features— Some features may be placed in thefeatures2field. Note: This is only a legacy requirement for crates.io; other registries should not need to bother with modifying the features map. Thevfield indicates the presence of thefeatures2field.
https://doc.rust-lang.org/cargo/reference/registry-index.html#index-protocols
recall how long it took rust to get off of just dumping the entire packaging ecosystem into a single git repo?
the hash function that git uses is of a form designed by ron rivest and has since been referred to as SHA-1. it is essentially unchanged in character from md5, from the same guy
side note: lol
Cargo will attempt to fetch the config.json file before fetching any other files. If the server responds with an HTTP 401, then Cargo will assume that the registry requires authentication and re-attempt the request for config.json with the authentication token included.
If a registry is using some kind of CDN or proxy which caches access to the index files, then it is recommended that registries implement some form of cache invalidation when the files are updated. If these caches are not updated, then users may not be able to access new crates until the cache is cleared.
this doesn't make any sense if you think caching is about data, because you could obviously just serve a progressive stream of new crates, bucketed into discrete timesteps for the purpose of easier caching
https://doc.rust-lang.org/cargo/reference/source-replacement.html#local-registry-sources
A “local registry source” is intended to be a subset of another registry source, but available on the local filesystem (aka vendoring). Local registries are downloaded ahead of time, typically sync’d with a Cargo.lock, and are made up of a set of *.crate files and an index like the normal registry is.
this is obviously a backdoor. but why? for what purpose?
[cfg.options.set]
Set configuration options[cfg.options.intro]
Which configuration options are set is determined statically during the compilation of the crate.[cfg.options.target]
Some options are compiler-set based on data about the compilation.[cfg.options.other]
Other options are arbitrarily-set based on input passed to the compiler outside of the code.[cfg.options.crate]
It is not possible to set a configuration option from within the source code of the crate being compiled.
you are not capable of observing or understanding the changes being made to your system by the rust compiler and cargo
so:
https://users.rust-lang.org/t/idea-for-a-crate-tool-cargo-task/15300
When developing Rust code, I often have to run repetetive tasks.
What I would really love is the ability to write this "scripts" in Rust...
later:
The job of cargo-task is:
find out the workspace root and
cdin there
run the resulting tasks binary, forwaring all the command-line arguments.
