There is nothing in Debian or FOSS in general that mandates having source control.
(I remember that was a point of contention with WebKit/KHTML... in the olden days of 2000-something, Apple forked KHTML to make WebKit, and in order to comply with GPL, they just published source tarballs, which were basically impossible to merge back into KHTML.)
edit:
ahh I see that the xpdf that is in debian is actually different than this one; someone forked it some time ago and it is in in git here (but no github/other forge, just .git)
Certainly there's nothing in FOSS that mandates source control, but source control is one of the most important technologies discovered for developing software, and I'd be hard pressed to imagine a justification for relying on software that didn't use it.
I'm showing my age here, but making version control public is a relatively recent thing; I can't think of a project before OpenBSD that did it, and it wasn't until SourceForge that the idea of projects just having source repos out there and visible became a popular idea, and that was like '99 or 2000. Most projects would just release tarballs and have a CVS repo that was limited to "approved" developers. And that was well after all the big distro build systems developed.
It is likely that the `xpdf` project is developed under source control, but they don’t make the repository public. SQLite makes their repository public, but they do not accept contributions.
A popular project with release-only distribution is Lua. I don't know whether they have proper source control, but even if they do, AFAIK it isn't publicly available.
A list of only-archive-published projects will be interesting. 7-Zip is another. Regarding that .git web directory, is there an existent tool/script that does something similar to `git clone` for it?
In this specific case, nix uses fetchFromGitHub to download the source archive, which are generated by GitHub for the specified revision[1]. Arch seems to just download the tarball from the releases page[2].
Please don't. Nix UX sucks big time. I don't know about Guix, but I'm pretty darn sure that anything else must be better than Nix cuz Nix is the rock bottom.
Nix might even make it worse. xz made it into unstable and it is part of stdenv. This means almost every package needs to be rebuilt which takes forever and limits the speed in which it can be reverted. They still have 5.6.1 in unstable and, to be honest, I'm not sure why. I don't know if they are still waiting for CI to chew through the tens of thousands package rebuild or there is something else.
Afaict they are in fact waiting for CI to do the big rebuild on staging, in part because the Nixpkgs builds of 5.6.x never pulled down the malicious m4 scripts that inject the backdoor into the output binary (as they never used the release tarball directly from upstream but built from GitHub sources).
It's also worth noting that Guix is different here, as the grafts mechanism is well-established, so they can get a security patch in for xz without waiting for the mass rebuild, even if it's also in their stdenv or equivalent.
Conspiracy theorist: That's what they want you to believe.
And in fairness, the whole nature of their secrecy means there's no way to know for sure. It might be just a boogeyman kept around as a useful tool for scaring people into not breaking national security-level laws. I mean, it's not as though I want to go around hacking the planet, but the idea of ending up at a CIA "black site", assuming such things even exist, would be enough to keep me from trying it.
And I think people should now look at all oddities with Valgrind. Since that is how the issue got discovered. And then look at the problematic library and look for similar outliers of fake personas taking over a project.
It seems it is common practice for people to ignore these errors.
Do you remember the Debian openssl flaw? Okay, it's almost 20 years old now, so you may have forgotten, or you could be too young, I don't know. But it was caused by someone attempting to fix an oddity found by valgrind.
There was an upstream OpenSSL bug there: they depended on reading from uninitialized memory to add entropy and thus increase startup speed of their RNG. But reading from uninitialized memory is undefined behavior, it's not guaranteed to add any entropy and should always be treated as a security bug. The Debian maintainers tried to fix the bug, but screwed up the fix. They should have reported the bug upstream, not just made their own fork.
My memory is fuzzy. In that case, I'd blame the OpenSSL devs if the report wasn't a patch with the (non-working) "fix". Even if it was, they should have accepted the bug & rejected the patch.
I remember this and the like is a good write-up, thanks for the link. I have see things like this over the past 30+ years. So a couple of Items to add:
* Comment the hell out of hidden logic like this. Explain why nor what :)
* Better yet, even though that uninitialized buffer helped with performance. These days it would be better to take the hit and add a random initialization of that buffer. Maybe read /dev/urandom or some other thing.
You do not know who will come along after you, so try and make things explicit.
Valgrind will tell you about memory leaks and won't always behave the way it did here when there's a backdoor. In this case it just so happened that valgrind was throwing errors because the stack layout didn't match what the exploit was expecting. Otherwise valgrind would have probably worked without issues.
I am also curious, and if something like asan would also have found it? It seems social engineering was used to get MS to stop fuzzing the library for malicious code, so if the malicious party expected the valgrind behavior they might have removed it as well.
Which to me is a very carefully orchestrated thing. You don't just spend 2 years of your life doing that. No loner would pre-plan this to such an extent and create sockpuppet accounts for all this.
That's because you're a normal, well adjusted person.
Consider TempleOS[1] which was created by a programmer having a series of manic episodes which he believed was God's instruction to create 640x480 pixels of perfection.
He spent the rest of his life on this.
People vastly underestimate the tenacity of individual fixated people: so much so that in the physical world victims usually feel isolated by their peers who just don't believe the degree of effort they stalker will actually go to.
TempleOS feels a little different because Terry was fairly well-known in the community and didn't try to hide his identity. I'm pretty sure he went to conferences and has met with actual people who could verify his identity.
I haven't seen proof that Jia Tan is a real person and to me that's the most malicious part of the attack. I'm pretty confident that whoever is hiding behind the Jia Tan identity is a well adjusted individual (or group) and knows exactly what they're doing. It feels far too coordinated and careful to chalk up to a psychotic episode or manic behavior.
There are not that many suspicious acts tbh. Randos complaining about unmaintained repos and unclosed issues is a constant in FOSS world.
Sometimes it's even true, some projects really die and stop actually addressing real issues.
But that's just inherent downside of the "bazaar" model. I don't think how we can "treat maintainers better" without going full corporate/without going full "cathedral".
> But that's just inherent downside of the "bazaar" model. I don't think how we can "treat maintainers better" without going full corporate/without going full "cathedral".
We now have two decades of arms-race data in OSS projects influenced by ESR's paper [1].
At least one bazaar [2] has operated for centuries.
Bazaars can develop decentralized responses to dynamic local threats.
For example, xpdfreader, source of xpdf, is distributed just as source tarballs. The maintainer just publishes them every time there is a new version.
https://www.xpdfreader.com/download.html
https://www.xpdfreader.com/old-versions.html
https://packages.debian.org/search?keywords=xpdf
There is nothing in Debian or FOSS in general that mandates having source control.
(I remember that was a point of contention with WebKit/KHTML... in the olden days of 2000-something, Apple forked KHTML to make WebKit, and in order to comply with GPL, they just published source tarballs, which were basically impossible to merge back into KHTML.)
edit:
ahh I see that the xpdf that is in debian is actually different than this one; someone forked it some time ago and it is in in git here (but no github/other forge, just .git)
https://offog.org/git/xpopple.git/
well ok, maybe I was wrong. but still, a .git folder on someone webpage is not that much more reliable than a tarball on someone's webpage