Sorry to clarify I’m talking generically me installing something from cargo, pip or npm, rather than any specific package.

I personally don’t hold much value in ‘reproducible builds’ as being some silver bullet - back doors can almost as easily be hidden in source code, particularly if nobody gives it a once-over read, same goes for compiled code only it normally requires a sandbox and some R.E.

I disagree, it is easier to hide back doors in binaries than in source code. "some RE" is way harder to do on scale than looking at diffs of source code. But yes, it's also possible to put back doors into source code as well.

Still, I think in the open source world, the primary distribution method, at least the one emanating from the original developer, should be in forms of source code, to ensure that the original developer can't include special closed source features. Also, for end users it's easier when the source code is available, then they can rebuild things using standardized methodology. all the distro packages have a bunch of commands you can run and then you can rebuild the distro package.

I think you’re probably right but it would depend on languages - something statically typed and well defined like rust would be much easier to analyse than something like php which could construct and execute a backdoor dynamically in a very non obvious way. All this depends on code readability and simplicity, which in software which is a complete mess would probably need a sandbox to have at least some level of assurance (I’d prefer to see unreadable apps outright rejected from use, but that opinion won’t fly in the face of the business world).

So in summary, I concede you are right in most, but not all cases.