Hacker News: kpcyrd

New comment by kpcyrd in "Government orders GitHub to remove Bluetooth-based chat app Bitchat: Jack Dorsey"

kpcyrd — Fri, 24 Jul 2026 17:41:16 +0000

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.

New comment by kpcyrd in "Dependencies should be fetched directly from VCS"

kpcyrd — Tue, 07 Jul 2026 13:04:15 +0000

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

New comment by kpcyrd in "Hetzner Price Adjustment"

kpcyrd — Mon, 15 Jun 2026 23:02:50 +0000

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.

New comment by kpcyrd in "AUR packages compromised with Infostealer and Rootkit"

kpcyrd — Fri, 12 Jun 2026 16:56:10 +0000

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.

New comment by kpcyrd in "AUR Packages Compromised with Infostealer and Rootkit"

kpcyrd — Fri, 12 Jun 2026 15:24:42 +0000

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

New comment by kpcyrd in "AUR packages compromised with Infostealer and Rootkit"

kpcyrd — Fri, 12 Jun 2026 15:14:29 +0000

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

New comment by kpcyrd in "AUR packages compromised with Infostealer and Rootkit"

kpcyrd — Fri, 12 Jun 2026 14:58:42 +0000

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.

New comment by kpcyrd in "AUR packages compromised with Infostealer and Rootkit"

kpcyrd — Fri, 12 Jun 2026 14:55:44 +0000

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.

New comment by kpcyrd in "AUR packages compromised with Infostealer and Rootkit"

kpcyrd — Fri, 12 Jun 2026 14:41:27 +0000

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.

New comment by kpcyrd in "Supply chain nightmare: How Rust will be attacked and what we can do to mitigate"

kpcyrd — Sun, 12 Apr 2026 13:04:55 +0000

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

New comment by kpcyrd in "Supply chain nightmare: How Rust will be attacked and what we can do to mitigate"

kpcyrd — Sun, 12 Apr 2026 13:00:22 +0000

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.

New comment by kpcyrd in "Supply chain nightmare: How Rust will be attacked and what we can do to mitigate"

kpcyrd — Sun, 12 Apr 2026 12:55:09 +0000

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.

New comment by kpcyrd in "Supply chain nightmare: How Rust will be attacked and what we can do to mitigate"

kpcyrd — Sun, 12 Apr 2026 12:48:16 +0000

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

New comment by kpcyrd in "Supply chain nightmare: How Rust will be attacked and what we can do to mitigate"

kpcyrd — Sun, 12 Apr 2026 12:34:56 +0000

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.

New comment by kpcyrd in "Employers use your personal data to figure out the lowest salary you'll accept"

kpcyrd — Mon, 06 Apr 2026 13:15:52 +0000

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.

New comment by kpcyrd in "Blocking Internet Archive Won't Stop AI, but Will Erase Web's Historical Record"

kpcyrd — Sat, 21 Mar 2026 12:52:44 +0000

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.

New comment by kpcyrd in "Astral to Join OpenAI"

kpcyrd — Fri, 20 Mar 2026 01:36:17 +0000

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

New comment by kpcyrd in "Astral to Join OpenAI"

kpcyrd — Fri, 20 Mar 2026 01:23:08 +0000

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.

New comment by kpcyrd in "Astral to Join OpenAI"

kpcyrd — Fri, 20 Mar 2026 01:09:25 +0000

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

New comment by kpcyrd in "Malus – Clean Room as a Service"

kpcyrd — Thu, 12 Mar 2026 17:30:12 +0000

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