They use the word "Reproducible Builds" for linking the VCS commit to PyPI's repacked source code upload, that's why "reproduce the source code" sounds a little confusing.
For projects with native bindings you can still fairly trivially solve this with SBOMs, and some Linux distributions are doing this for many years now. The compiler is a dependency that needs documenting, and they explicitly write they need means to re-create the documented environment from that SBOM.
> For projects with native bindings you can still fairly trivially solve this with SBOMs
For bitwise identical results there are many small details that need to be taken care of, even in the pure-Python case: Ensuring that files appear in the wheel (zip) file in the same order (glob() doesn't guarantee this and you can definitely see different orders from run to run), timestamps are set to some fixed standard time. Any kind of build-time code generation or pulling in of external info like git commit hashes needs to be handled. Then once you include compiled build dependencies, there might be nondeterminism in the order that a multithreaded compiler writes object code, hidden timestamps, hidden absolute paths, and things like runtime detection of CPU version leading to different instructions being emitted on different machines.
I'm well aware of those issues (having worked on this for many years), but I still believe the majority of python packages won't be affected by this. :)
Most of these you would fix once on the relevant [build-system] and be done with it, no need to fix each individual python library.
Please try building with conda-build to understand the actual problems this entails. Your solution is a fantasy because of how library linkage works. Dynamically loaded libraries need to be able to find each other at runtime. In order to do that, they need to store the location (the filesystem path) to the library they want to load. How these links are resolved is beyond the scope of Python (on Linux, this is managed by ld and ldconf).
A lot of Python package maintainers don't understand this problem and don't understand how to make a portable library. Often times builds contain either an absolute path to another library, or a relative path... into nowhere, or a collection of paths... into questionable places. And there's no standard that tells the library authors how to do this the right way. As long as there's no standard, anyone can claim to have done it right and expect their users to accommodate them (which is what currently happens in Python).
About your other ideas: making a compiler a dependency is... an awful idea. Unless you can require the same compiler is used for every dependency in your project, at the minimum, you will have an uncontrolled (how are you going to make sure that the right compiler is used to build a package?) zoo of compilers and their versions in your project. In the worst case, compilers will embed their signatures in the generated binary code preventing other binaries from loading such code, if they are generated with a different compiler version (kind of like what happens if you try to load Linux drivers that weren't compiled with the same compiler that compiled the kernel).
* * *
Like I said: these people have next to no practical experience with the problem they are trying to solve. Why can't they just go some place else and apply themselves elsewhere is beyond my comprehension.
I think running this with network access disabled is a good idea, but it's also important to note "was independently reproduced" is about "we challenged the SBOM and were able to produce this output from the stated inputs".
Whether the code in the SBOM subvertly downloads additional code (during build time or later during runtime) is still for the code reviewer to be found.
An SSH bastion host allows to request direct-tcpip channels, but is going to restrict other channel types, like pty requests, shell requests, exec requests or other subsystems.
The "login permission" term is confusing because it's likely supposed to mean "shell requests", but SSH channel requests in general are all post auth, which could also be considered a "login". In OpenSSH you still need to explicitly configure permitted channel requests, which I think is what GP is referring to.
For git specifically I would recommend the ForceCommand feature in OpenSSH, all exec requests are then forwarded to this program, with $SSH_ORIGINAL_COMMAND set to the original command. You may then use an allow-list of commands you want to permit.
Unfortunately Bitchat feels like an unfinished proof of concept.
At a festival I got notifications there are "other users nearby", which made me question if and how the app is broadcasting it's presence, possibly at all times. I also couldn't figure out a way to turn off these notifications (there's barely any settings) and I ended up uninstalling the app.
This makes the problem harder instead of easier. The most practical conclusion is "the package registry is the VCS, but with stricter rules".
Those stricter rules are useful, the registry acts as a authority to ensure no version string is ever reused in a way that would make it non-canonical. It also ensures availability of the source code, so your software won't suddenly fail to compile because somebody decided to delete the repository from their server, delete their Github/codeberg user, or they can't pay for their domain anymore (which is a fail-open identity system, not a fail-close one like crates.io). Sure there's also the risk of crates.io ceasing to exist, but that's less likely than "some software engineer gets layed off, decides tech is a dead-end and becomes a domain-less goose farmer".
You could try rkhunter or unhide from the official repositories, but I haven't tested this myself and I don't know how well they work with BPF rootkits (and/or this one specifically).
All of the packages I have triaged involved the atomic-lockfile npm package, so this is something you could try:
npm cache ls | grep atomic-lockfile
The problem with an officially endorsed solution is that the rootkit authors could push an update that hides/removes the indicators of compromise the endorsed script checks for (e.g. it would be trivial to have the malware delete atomic-lockfile from the npm cache).
This is essentially what the [extra] repository is. Not using the AUR and sticking to official Arch Linux packages exclusively is a very valid and reasonable choice (that I follow myself actually).
A large number of "an Arch Linux update broke my system" is very likely due to incorrect AUR use that AUR helpers don't handle for you. There's an elaborate writeup here from just 2 months ago: https://lists.archlinux.org/archives/list/arch-dev-public@li...
This is an "in addition to" problem though, not an "instead of" problem.
Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
Also have realized at some point that reviewing the PKGBUILD and code in github repo still doesn't check whether the github release files are compromised.
https://en.wikipedia.org/wiki/Public_recursive_name_server