kpcyrd

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

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.

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.

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

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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.

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

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

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

Obfuscated javascript could still import a WebAssembly polyfill, if there really was any advantage in doing so: https://github.com/evanw/polywasm

Since WebAssembly instructions are much easier to reason about, you could probably auto-optimize away a lot of the obfuscation, like "this is a silly way to do X, so we can just do X directly".

It's mostly Rust compiled to wasm binaries. There's also TinyGo and you could use C/C++ as well, but those 3 are a lot less common as far as I can tell.

Your open source experience is very different from my open source experience.

Running Rust on them worked well for me: https://github.com/kpcyrd/ch32v003-demo

I had to put in more effort regarding RAM use and flash size, but I managed to fit a game into the 16kb limit regardless: https://github.com/kpcyrd/game-streetcat2026

I just want to be able to call Default::default() from within const {}

The time you lose at the syscall boundary you may be able to win back during much shorter GC pauses.

Security, sha1 was deprecated in 2011 by NIST due to security concerns, and browsers reject sha1 certificates as invalid since 2017.

Yet programmers in 2026 for some reason are still using it when signing their git tags and commits. Unless they are using a sha256 git repository.

What about using the filesystem as an optimized dict implementation?

The ch32v003 implements RISC-V without the M extension, meaning there's not even a MUL/DIV instruction.

Out of all micro controllers I've worked with, only a single one had AES cpu instructions.

I moved one of my projects from Github to codeberg because Github can't deal with sha256 repositories, but codeberg can.