kpcyrd

1,578 karmajoined 11 tahun yang lalu

Submissions

GitHub Actions' VM image doesn't match published source code

lists.reproducible-builds.org

9 pointsby kpcyrd8 bulan yang lalu0 comments

comments

4 hari yang laludiscuss

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".

25 hari yang laludiscuss

This. Capitalism only became problematic the minute it stopped having a cozy spot for software developers~

And even then people prefer blaming the prediction machine instead of recognizing their situation as the logical conclusion of capitalism.

29 hari yang laludiscuss

The server actually hosting the rootkit executable is npmjs.com, run by a for-profit company, and they still take about 24h to act on our reports, while reported AUR packages have been processed in about 1-2h by people that work unrelated dayjobs on top of this, to self-subsidize their open source work.

Sorry you're displeased with us not writing blogposts faster on top of all this. The situation is already exhausting enough without people like you.

29 hari yang laludiscuss

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).

29 hari yang laludiscuss

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...

29 hari yang laludiscuss

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.

29 hari yang laludiscuss

There's no shortage in ideas of how to make the AUR easier to moderate. A "quarantine button", an invite system, a request system for adoption similiar to how orphan requests work, code review attestations similiar to cargo-crev, pacing controls similiar to those in discourse.

There is a shortage however of people skilled enough to implement them (with available time to do so).

What we also don't have a shortage of is angry people in comment sections.

29 hari yang laludiscuss

This may happen even with `pkgctl build` if a makedepends= (transitively) pulled in the shared library into the build environment, but depends= doesn't.

There's warnings in place if a .so dependency is detected, but it's up to the maintainer to notice and act on it.

For safety/security concerns, Arch Linux has been one of the driving forces in the reproducible builds project, and for large parts of the operating system it's possible to independently verify that those binaries have in fact been built from source code. It's auditing story for official packages is stronger than that of NixOS (and on par with Debian):

https://reproducible.archlinux.org/

All of this is entirely unrelated to the AUR incident however.

3 bulan yang laludiscuss

You don't need vendoring for this, Cargo.lock already gives you locked-dependencies until you run `cargo update`. There is an ongoing RFC to support having cargo intentionally only use library versions that are least X days old:

https://github.com/rust-lang/rfcs/pull/3923

3 bulan yang laludiscuss

The repository suddenly contains thousands of files that I need to worry about. With regular locked-dependencies (but non-vendored) like Cargo.lock does, I have them contained in archives with well-known hashes that other people have also looked at.

If I have to manually match the content of the vendor/ folder with the contents of the Cargo.lock referenced source code anyway, I could just use Cargo.lock directly without having to concern myself with the thousands of files in your vendor/ folder.

3 bulan yang laludiscuss

You are getting distracted by domain names, your Cargo.lock files already cryptographically address the source code. Either make sure all your Cargo.lock files contain no known-bad hashes, or make sure all your Cargo.lock files contain only known-good hashes. Maybe also mirror the .crate files for the absolute worst case scenario of crates.io going offline.

3 bulan yang laludiscuss

1) This is only relevant for rustup.rs, most Rust source code is coming from crates.io 2) Most projects have a Cargo.lock that contain sha256 checksums of the source code. You can still announce new versions of everything and hope people pull them in through `cargo update`, but you are not going to get anywhere close to "all Rust users".

3 bulan yang laludiscuss

crates.io _is_ the source code repository (: It's explicitly the source of truth that cargo-crev and cargo-vet reviews are based on, linking it to a git repository first is not a substitute for reading the source code.

3 bulan yang laludiscuss

This is "only" used for loans and renting, the German government is never going to query the score this company has assigned you. Social services are never impacted.

Equifax on the other hand claims:

> Social Services - When government agencies can't verify your information, you may have to wait longer to start receiving benefits.

4 bulan yang laludiscuss

You don't think non-consensually revealing somebody's identity is a problem?

Resorting to DDoS is not pretty, but "why is my violent behavior met with violence" is a little oblivious and reversal of victim and perpetrator roles.

4 bulan yang laludiscuss

I stopped programming in python about 8-9 years ago because the tooling was so bad.

4 bulan yang laludiscuss

Step 1: discontinue the public repository, step 2: sell access to your GPL codebase.

The GPL (and even the AGPL) doesn't require you to make your modified source code publicly available (Debian explicitly considers licenses with this requirement non-free). The GPL only states you need to provide your customers with source code.

4 bulan yang laludiscuss

I think this was more about "please choose _any_ license" because of the problem outlined here:

https://opensource.stackexchange.com/questions/1150/is-my-co...

4 bulan yang laludiscuss

I feel like this is related to these issues (with somebody attempting this approach for real):

https://github.com/chardet/chardet/issues/327

https://github.com/chardet/chardet/issues/331

4 bulan yang laludiscuss

Many of the anti-debugging techniques for desktop binaries do not work on WebAssembly: it can't jump to an address, it can't read the instruction pointer, it can't read/access it's own machine code, ...