kpcyrd

When you link GPL code with your proprietary code into a binary (shared address space), and distribute the binary to people, those people are entitled to your proprietary source code.

When I compile my GPL code with a copy of somebody else's MIT code into a binary (shared address space), other people's copy of that MIT code is still MIT licensed.

I've worked with German law enforcement in the past, seizing foreign servers as evidence without going through due process in that foreign country is not a thing. They need a warrant from a court in that country, which requires dealing with their jurisdiction.

Of course, they would've loved if they could just collect US servers for evidence-gathering.

The Netherlands doesn't consider A/I terrorists though, does it? Therefore, dual criminality doesn't apply.

Russia considers Facebook/Meta a terrorist organization in their jurisdiction, that doesn't make universally true. Saying "terrorism is illegal" to dismiss due process in a foreign jurisdiction is actually very close to attempting "crime is illegal" as an argument.

That's like saying crime is illegal in the United States and all countries of the EU, therefore I should be able to get US citizens prosecuted for EU laws.

The US-Netherlands Extradition Treaty, Article 2 says it needs to be considered criminal conduct in both jurisdiction, one jurisdiction calling it 'terrorism' is not enough for dual criminality to apply. I asked GPT-6 and it said you're wrong.

Curious, how do I apply German law to US citizens living in the United States? Last time I checked that wasn't possible, even though they have coorporations it's still different jurisdictions.

It feels like it's from back when we unironically thought memorizing quirks like this makes us better programmers, or is somehow important for making computers more secure, aka middle of the 2010s tech bubble.

The XZ incident was using binary files checked into git. When you successfully collide this file, one with the trigger, one without the trigger, they get the same git blob-object hash (assuming the chosen-prefix includes the git blob-object header). Because of this, any git tree-object referring to this file is valid for either variant (no further collision needed). This tree-object can itself be part of another tree-object, which can be referred to by a commit-object. Signing this commit with ed25519+sha256 doesn't fix the fact that the tree-object underneath is ambiguous.

People assume sha1 git is cryptographically sound, and a git commit is a secure identifier to reason about source code, whether you and me like it or not.

The XZ incident would have been so much worse if it would have involved a collision, pushing one object variant to github.com, and one variant to git.tukaani.org.

Then you would have security researchers making conflicting claims depending on which repository they first pulled from, even though they are on the same git commit hash.

Basing your cryptographic advice on a 20 year old opinion-piece from somebody with no background in cryptography is not the flex you think it is.

Please educate yourself what a merkle tree is. It's a well understood building block of various security systems, including certificate transparency (which explicitly uses sha256).

You refer to PGP signed Git objects, but you also argue:

> Git hashes are not supposed to be a security mechanism

Guess what the Git PGP signature is signing.

This article is full of mistakes and misleading claims:

1) It's claiming SHA1 insecurity is theoretical, while SHAttered from 2017 was specifically a pratical proof of concept. The only reason Git wasn't affected, is because they didn't bother bruteforcing a git-blob prefix.

2) It's claiming collision attacks don't matter, only second-preimage attacks do. This is incorrect, collision attacks are enough for code-smuggling problems, when two repositories are on the same git commit (verified by the full commit hash), yet contain different code in their git checkout.

3) The Linus quote "The real security is in distribution" is arguing that "git's content-addressed system should not be used to address content". It's arguing that, in case of curl|sh, you shouldn't use a sha256sum-gate to pin the content to something you've reviewed, you should instead ensure curl is fetching from an https server.

Since this seems to be the thread for public DoH providers, this article is probably worth mentioning (it can sort by DoH, DoT, DoQ, etc support).

https://en.wikipedia.org/wiki/Public_recursive_name_server

I'm well aware of those issues (having worked on this for many years), but I still believe the majority of python packages won't be affected by this. :)

Most of these you would fix once on the relevant [build-system] and be done with it, no need to fix each individual python library.

They use the word "Reproducible Builds" for linking the VCS commit to PyPI's repacked source code upload, that's why "reproduce the source code" sounds a little confusing.

For projects with native bindings you can still fairly trivially solve this with SBOMs, and some Linux distributions are doing this for many years now. The compiler is a dependency that needs documenting, and they explicitly write they need means to re-create the documented environment from that SBOM.

I think running this with network access disabled is a good idea, but it's also important to note "was independently reproduced" is about "we challenged the SBOM and were able to produce this output from the stated inputs".

Whether the code in the SBOM subvertly downloads additional code (during build time or later during runtime) is still for the code reviewer to be found.

An SSH bastion host allows to request direct-tcpip channels, but is going to restrict other channel types, like pty requests, shell requests, exec requests or other subsystems.

The "login permission" term is confusing because it's likely supposed to mean "shell requests", but SSH channel requests in general are all post auth, which could also be considered a "login". In OpenSSH you still need to explicitly configure permitted channel requests, which I think is what GP is referring to.

For git specifically I would recommend the ForceCommand feature in OpenSSH, all exec requests are then forwarded to this program, with $SSH_ORIGINAL_COMMAND set to the original command. You may then use an allow-list of commands you want to permit.

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.

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

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

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.