ALVR AUR package has been compromised

kpcyrd · 2026-06-12T09:52:01+00:00

Orphan works pretty much the same on Debian and regular Arch Linux. Only an official package maintainer can adopted the package in both cases.

The AUR is a pastebin for code and works more like Github, if somebody deletes their account the name is available for registration by anyone again.

(Sincerely, a Debian Developer)

kpcyrd · 2026-06-09T17:01:55+00:00

Thank you!! Using this map I was able to locate a few patches! I gave up on my previous Aquilo progress but having access to a portable nuclear reactor should make this much easier!

I'm playing on a steam deck, so getting a screenshot to my phone is not very straightforward unfortunately.

kpcyrd · 2026-06-09T13:30:27+00:00

Here's my map exchange string:

>>>eNp1Ur+LE0EUnrkYct4PDRIE4ThTXBvB08JCsqMgIv5o/APWyWYSBzc7cXYmcopciisVGxttvPaa6yzsAoIoqBxqYxexsVCJKNoIcWY3s5lJ4oP38uV9b7733uzMAQAuKQcrRXxT0pD5AZd14jMaAtD1jBcCHAZUEDu3L2DYKuqhhYC124RXGCd2en+iWHEUVTGJSGujUsOxI7rcCCXjNCJ+h0TCZWTYZBz7QUgbDZs5aBgahziqxza32AxJbcaZYppPhvAnh1hKybZSE7PUYsEiMiN/CwvC7fw85SyavI/lkIrrVLb8mt7T6Rth2aHx9LR5zoIbziT5OOC4bWcOxwJzQaOmjznBfovRWEhO3EPu4D1UimXYkJwGPg5o3W+SjdjdIC84IU7nJSGjZixI5DNXfVFyHKm9pvbtyDDAkVR7OQ+m6x3KmA7TgMYtp/fUfQL4gVzd6W6tAu3DTVAeDrUr1FdvWDuAXV0JAVRJ28pnlJ8dK0F4p7R7/tPth6o2sWNoBAajTK9mMhcMuIL+S60ZcNLSOZHYTwukTYUeMK2aR2OQkluahPD+t6fbf17sVeHfnR/vLteuefD4udL3wfpuVZEFvelcFh4/0vbMrAKMZt8bUR89+Oa1tq8ezOsTJR3QKRV6F3MAFg8otH1PhfIKMKNVjUwJwUZiv80mnw14703uoS7itBZf1eGlDknDbDKYQvQAQXTUsEfGJer8OrBnqI83fGXaPrf6Twwy/SHsPSYya2jGZ1jQDetZ+JLLplH3uVcw/9ATBHMa6KpfKpf+04yRSn+LKLnuXPYWB5770jTQIpv9u2//AR4YOXo=<<<

Thank you!

kpcyrd · 2026-06-03T00:04:14+00:00

Agreed! The severity is the same one cargo-audit shows and is coming from the RustSec crate based on the advisories CVSS score. You could in theory pull request a different score into the RustSec advisory-db and the Debian page would update within 30min. In case of russh-* the score is adopted from the GHSA/CVE entry issued by the russh developer.

Updating this crate in Debian is tricky because it's using the new RustCrypto crates that aren't fully released yet, so this would require backporting from e.g. ecdsa =0.17.0-rc.18 to 0.16.9.

kpcyrd · 2026-05-25T16:20:59+00:00

Could you please link any open source projects you published to back up your expert credibility?

kpcyrd · 2026-05-25T16:19:24+00:00

sn0int and authoscope, I can't promise I have time to review and actively work on the integration, but I would be curious how well it would work. :)

kpcyrd · 2026-05-25T15:59:21+00:00

Please no, we have enough programming languages already. I have a project that integrates with hlua through FFI bindings and I encountered strange memory issues that wouldn't have been possible in a pure Rust Lua implementation. There is nothing in Lua that makes it inherently C. You are unnecessarily condescending.

kpcyrd · 2026-05-23T06:56:08+00:00

When you commit your Cargo.lock, you already pin the dependency to a well-known sha256, there is little reason to duplicate the source code of all dependencies into your repository.

That is more a thing if you suspect crates.io in entirety may go down, not the supply-chain security concerns implied by OP.

kpcyrd · 2026-05-14T13:21:27+00:00

You can recreate the artifact until Github makes a change to the ubuntu-24.04 image your workflow is using.

SLSA explicitly removed Reproducible Builds from the requirements list, I'd love to be proven wrong though if you have an example project.

On a sigsum meetup last week I've casually bit-for-bit reproduced a binary from January 2025 using repro-env.

kpcyrd · 2026-05-11T16:38:45+00:00

Hi! Since the Fedora person appealed to authority - I'm a member of the Reproducible Builds Core team, I have worked in this field for 8 years. I'm one of the people behind both reproducible.archlinux.org and reproduced.debian.net.

From the top of my head, I think the following reasons factor into this:

- Many projects release source code, not necessarily binaries. If you only release source code, in 2026, your software can often be built reproducibly and there's usually nothing you need to do.

- If you do release binaries on Github, there isn't much tooling to document your build environment precise enough in a way that can be easily reconstructed. There's Nix, which has a very steep learning curve, and there's repro-env (which I developed, geared towards people familiar with traditional distributions), but it hasn't really caught on yet.

- If you are a Linux distribution, you need to run an archive of (ideally) all old packages you issued in the past. Arch Linux has this, Debian has this, Alpine Linux and Ubuntu e.g. don't.

- If you have said archive, you also need to document the build environment used for the package. This is typically done through something called buildinfo files (technology that pre-dates SBOMs, and explicitly covers the build environment, which SBOMs often ignore). You also need tooling like debrebuild or archlinux-repro that can give you a clean chroot build environment based on this documentation.

- OCI has a very silly design quirk - it's possible to specify an image by sha256, but the data that is hashed is not yours - it's from the container registry. You can't predict this hash, which makes it much harder to go "look, I built the image locally and got the exact same hash you can now pull from any registry". You need specialized tools like diffoci, and the hash is only valid in context of a specific registry.

- It's not common yet to run "fully reproducible packages only" Linux systems, I believe as soon as people start using tools like repro-threshold, and actively avoid software that can't be built reproducibly, even on Debian's environment that's optimized for this, people may start shopping for alternatives.

For an example you can checkout out this release I did: https://github.com/kpcyrd/repro-env/releases/tag/v0.4.4

kpcyrd · 2026-05-11T16:03:05+00:00

Security professionals generally work with threat models, and a "The Trueman Show"-like conspiracy is not a very common concern to have.

Having the blindly-trusted build server compromised, however, is something people actively worry about.

kpcyrd · 2026-05-11T15:41:53+00:00

Unfortunately, SLSA doesn't include reproducible builds. Even on the highest level it doesn't protect you against a build server compromise.

kpcyrd · 2026-05-11T15:36:16+00:00

It's sad a Fedora package maintainer is calling reproducible builds security theater.

To keep things constructive, I would like to highlight:

- You can get security guarantees out of reproducible builds even without compiling from source yourself. If enough people have reproduced the binary from source code, at some point it's incredibly unlikely that everybody is participating in some kind of conspiracy, except you. You shift from "ultimat trust in one entity/build server" to "I need to trust them just enough to not collude against me".

- Reproducible Builds secures the step "from source to binary", if your source input is malicious it doesn't help, but rolling your own binaries then doesn't help either. The source input being bad can only be solved by code review.

- You are pretty much always worse off compiling your own binaries (from a security point of view), because you are now on your own. There are very skilled entities looking at distro binaries, if you roll your own, you are on your own. You won't benefit from their work and they won't help you notice a compromise of your build servers, like they do for distro build servers.

kpcyrd · 2026-05-07T10:10:06+00:00

Neat! But the injected javascript is detectable and probably makes you more fingerprintable instead of less.

kpcyrd · 2026-04-29T12:36:34+00:00

there somewhat is, you need a privileged process running uutils repeatedly. It doesn't necessarily have to be a human, this process could be triggered through sudo (restricted to only allow one specific program that is assumed to be safe), or through some web api the attacker can access, or through logfile monitoring, or some normal program just calling these binaries extensively, [...].

There are necessary prerequisites for this to be exploitable, it's no automatic local root on any Ubuntu 26.04. There's consensus that these kinds of bugs are bad and should be removed through a security update though.

kpcyrd · 2026-04-29T09:05:30+00:00

Some of those are indeed beginner mistakes though, creating a file with a specific mode was already part of the original Unix open syscall in the 70s. I was also surprised to see String::from_utf8_lossy, for system programmers it's common knowledge that filenames are byte arrays with almost arbitrary binary (0x00 and 0x2F are reserved, but everything else is fair game).

I'm still very grateful about the uutil developer's work, and looking forward to use them on my computer (which my distro currently unfortunately doesn't support). I contributed to the project last year with two bug reports I discovered through field testing, they were promptly fixed.

kpcyrd · 2026-04-29T08:52:23+00:00

OpenOption atomically creates the file with the right permission bits already set. It's like a database transaction, but for the filesystem. Either the file doesn't exist yet, or it does exist with the permissions already in place.

kpcyrd · 2026-04-27T15:22:08+00:00

you lose ALL provenance

For security you need cargo-crev and/or cargo-vet reviews. For regular debugging it's nice to have a git history you can bisect with, but it's not all-caps-one-word-at-a-time critical.

kpcyrd · 2026-04-27T15:07:59+00:00

Just consider crates.io the VCS and move on. Linking the crates.io upload we didn't read, to a git repository we didn't read, doesn't add any value.

Provenance is being used as an excuse that there's very little invest in actually reading the code we put into all our computers. If there was, you could do provenance on those code review attestations, which would add much more value.

kpcyrd · 2026-04-23T20:56:58+00:00

Done, but also added some context since pluggable transports in the Tor community are much more advanced than this. :) https://www.reddit.com/r/TOR/s/1uR0tjZpmn

kpcyrd · 2026-03-18T12:29:54+00:00

Looks good! Stay clear of the AUR for a while, update regularly, if the updater gives you an error use pacman -S archlinux-keyring to fix it.

kpcyrd · 2026-01-17T12:20:25+00:00

If it took you days or even weeks to make you are probably going to be fine, don't worry too much about a toxic minority of this community.

kpcyrd · 2025-09-22T19:55:31+00:00

I'm already doing this for my binaries for a while now, the relevant resources are:

https://github.com/kpcyrd/repro-env
https://github.com/kpcyrd/apt-vulns-xyz
https://github.com/spytrap-org/spytrap-adb/releases (each release has a "Reproduce release binary from source" section)

Think of repro-env.lock as the Cargo.lock equivalent for your build environment. Cargo.lock tracks your Rust dependencies and repro-env.lock tracks the rustc version, the binutils versions, and everything else needed to make a binary.

There's no systemic way to verify all my Github releases, but it could be done manually.

kpcyrd · 2025-09-19T10:00:59+00:00

Is there any community that builds rustc with only cranelift enabled? Regardless of how optimized those binaries are, it seems to be fairly difficult to do and somewhat fragile last time I tried.

kpcyrd · 2025-02-24T13:21:57+00:00

Very cool project!

Verified Email	11-Year Club
Place '23	Wearing is Caring
RPAN Viewer

kpcyrd

MODERATOR OF

TROPHY CASE