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.

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.