441–450 of 482 posts
I wonder, once the attacker gained commit permissions, were they able to rewrite and force push existing commits? In that case rolling back to older commits may not be a solution. If my speculation is correct then the the exact date on which access was granted must then first be known, after that a trusted backup of the repo from before that date is needed. Ideally Lasse Collin would have a daily backup of the repo.…
Force pushes tend to be noticed easily. All it takes is for one external developer to try to pull to see the failure. And it's actually hard to do because you need to comb through the tree to update all the tags that point to the old commits. On top of that it obviously breaks any external references to the commit IDs (e.g. in distro or build configurations), all the way up to cryptographic signatures that might have…
Earlier quoted context omitted.
Where are the email addresses visible? I've also seen this a few times, but never the actual addresses.
eg "Hans Jansen" is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
This could be "Denizens":
- an inhabitant or occupant of a particular place.
- a person admitted to residence in a foreign country especially : an alien admitted to rights of citizenship
Good way to describe Jia Tan (singular or plural) and their sockpuppets.
One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.
We should be moving from No Obvious Bugs to Obviously No Bugs (Tony Hoare).
One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.
What's inscrutable code? Was it m4 or sh or the combination of the two? Who will pay for all the rewriting you want done? Or even just for the new frameworks that are "scrutable"? How do we guarantee that the result is not inscrutable to you or others? There is so much knee-jerking in this xz debacle. (And I say this / ask these questions with no love for autoconf/m4/sh.)
Is there any law enforcement at all involved in tracking down the players and trying to understand their motivations (is who is Jia Tan, etc)?
I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.
I'm kinda the opposite. Way too many times I've seen "upgrades" actively remove things I liked and add things I hate. I hold off on letting mobile apps update because they almost always get worse, not better.
I still think this is the way to go, but it does move some of the problem around in that you have to pick good cleave lines such that people aren’t forced to pull 5 libraries in for 5 features they need. You want one software domain to use two or three and another to use an overlapping set of three.