GitHub "community" is just awful. There are people trying to get real work done in that thread, but then there are all these random bystanders piling up to throw in their comments which range from useless to actively harmful and distracting.
And it's not an isolated case, this happens pretty much always when some issues attracts attention on GH.
Can't we respect the project and give the people there space to work, and leave the peanut gallery commenting to reddit/hn/twitter/whatev.
I like the comment that started with "way too many arm chair 'researchers' in this thread" and then goes on to rudely say that the maintainers are doing a bad job because they merged in the original changes by Jia Tan.
What are you sitting on, if not an arm chair? We all agree that the xz attack was of unparalleled sophistication and complexity, spread carefully over years, funded by a State. Many people were taken in so how is it helpful to pile on Jia Tan's primary victims?
I thought that was a good question, and certainly one I'd like to know the answer too, but I very much agree it was done rudely. It didn't seem like it was asked in good faith.
Anyone who has maintained large/complex software like this knows that name recognition is worth a ton, and it kind of has to be that way. It's just not practical at all to scrutinize every commit/change as though the committer is an adversary, and particularly when you know the person it is not a reasonable ask. I would bet the truth is basically "yes, we knew him so it didn't get full scrutiny," and honestly that's an honest (but hard to give) answer.
I do hope (perhaps naively) that this (security code reviews) is something AI can get really good at in the future, because that would be a real value add IMHO.
It seems that blaming victims can really provide some power thrill, to which human can easily become addicted to.
Raising competent empathic well balanced individuals is difficult, to say the least. And it’s not like the so called world leader elites really show they are some paragons of these traits.
I recently removed the arm rests from my shitty IKEA chair (to apply WD40 silicone, because the standard cheap mechanism was creaking every time I leaned back, even if it was locked), and decided not to put them back, because they incentivized slouching
so akcheually some people are sitting on a block of concrete!
theorizing that it was wrong to merge in itself is not victim blaming. but of course piling up in GH discussions and issues unconstructively, and just expressing opinions is bullying.
The opposite. Whenever some project migrates to an inferior alternative like Github or Discord they always claim a number of arguments which boil down to "it's where people go these days" (e.g. less friction for newcomers, most people have an account there already, larger community, whatever excuse you can come up).
So I say they are getting exactly what they wanted to get.
Not a bad idea. I guess the UX is not hard, but likely it would clash with GH's bias towards openness/transparency/public record. Possibly risk making moderation 1st class citizen, they may fear this would detract from the main purpose of collaborative code production. Yet...it could help that. But I understand it's a tricky nuance.
So, they have comment minimization by assigned moderators. Or you can just delete / edit comments and issues. Obviously not as powerful as a pre-screening queue. Less work tho!
It seems like GitHub encourages that? I mean, emoji reacts to issue comments? Not really sure what the point of that is besides "driving engagement".
I guess the argument for it is that it lets people easily "get involved"? Seems like there's some merit to making it easy for users to leave feedback. Maybe thumbs-up or thumbs-down on an issue really is valuable feedback in some situations. I'm torn between saying the social features are bad because they lower the barrier for low quality engagement, and saying that even low quality engagement can lead to valuable insights.
I'm confused why this is being posted now? This thread appears to have taken place in the days immediately following the original XZ discovery, with no new activity since very early April. It was discussed heavily at the time that Jia Tan had made contributions to other projects and that those were being investigated as well.
Is there something new here I missed, or some additional context that makes this specific commit relevant right now?
Since the posted thread has been locked since April, even if there’s new information it can’t be on the posted page. I suspect a lot of votes come from people thinking there’s significant new information (otherwise why would this suddenly be #1?) when there’s none.
Ok, but to what end? Is there some karma-to-dollars pipeline that I don't know about? There a bunch of other platforms that superficially seem like much softer targets with more obvious payoffs.
Like, if we put it in the classic context of
1. Farm Karma
2. ?
3. Profit!
I'm not clear on step 2. What's step 2
And of course that pre-supposes malice (or at least greed), which is in violation of Hanlon's Razor.
I guess for those not sure of the context: The user Jia Tan added exploit code to the 'xz' tool as part of a larger deal. Wikipedia has a page on it here [1].
In this post, they are discussing some changes to print code specifically for the libarchive project, and some notable personalities in the security community chime in, including Colin Percival (Tarsnap among others) and Taviso (Google project zero among others).
Am I the only one a little concerned that no obvious attack has been found from this?
It seems doubtful that a state actor is trying to use terminal escape sequences to hide an error message... The state actor wants code execution, not the ability to backspace some warning on a developers terminal. Besides, using such a vulnerability seems far too dangerous - those escape sequences would be plainly obvious in any log file or any inspection of files on-disk.
And at the same time, if you are an undercover state actor, there is no point in potentially revealing yourself by inserting some security problem that isn't exploitable.
The goal here is to submit what appears to be a sequence of innocuous changes, none of which on their own are “obvious” vulnerabilities. The truth is, we don’t know what the strategic depths of this actor are. It may be years before we know whether an attack is successful.
For example — and this is just hypothetical - the author may have found that some consumer of this codebase uses it in a script, and consumes console output in some form. By modifying its output to behave differently, they may be able to influence the consumer’s execution in some clever way so as to create other conditions necessary for additional exploitation.
Or - the PR could have just been a test to gauge the scrutiny of the approvers.
The "funny" thing here is that this is (somewhat, perhaps?) how an AI intelligent beyond human capacity might execute an attack - or what an attack by one such might feel like: Lots of apparently unrelated actions, many or all of which make no sense ...
... (until and if you see the larger picture, which might be insurmountably difficult ...
... this, coupled with AI-level scalability of social engineering, at AI-level scale -and- with an AI-level understanding of "known-outcomes" that might be desirable towards given goals: "Leader change", etc.-)
I'm a little unclear as to why JiaT75's github account still exists? Surely this should be nuked from orbit so that no one accidentally ends up using their shady code?
The deletion of the account would not delete commits associated with it. The commit would still contain everything potentially malicious, plus a reference to an account that would be deleted. Which is actually worse, you cant track what code a malicious actor has contributed (easily). So the correct thing to do is take away login / deactivate the account, and then start going through all contributions and check them via the account that references all of this.
Sure, but there is zero indication of that on their user page. At the very least the account should be disabled, all repos should be archived, and a big fat warning banner should be prominently visible. The current state of affairs seems irresponsible.
> The diff doesn't make this obvious due to the removal of a newline in a parameter list.
I like to separate every little intentional change into their own commits. So a formatting change would be separated into its own commit.
If you are looking for “red flags” notice if the diff is clean or not according to what you expect to see changed; if you only expect to see some error text change then multiple lines being changed is weird. Also use a decent diff viewer which is somewhat content/language-aware.
Readit News
And it's not an isolated case, this happens pretty much always when some issues attracts attention on GH.
Can't we respect the project and give the people there space to work, and leave the peanut gallery commenting to reddit/hn/twitter/whatev.
What are you sitting on, if not an arm chair? We all agree that the xz attack was of unparalleled sophistication and complexity, spread carefully over years, funded by a State. Many people were taken in so how is it helpful to pile on Jia Tan's primary victims?
Anyone who has maintained large/complex software like this knows that name recognition is worth a ton, and it kind of has to be that way. It's just not practical at all to scrutinize every commit/change as though the committer is an adversary, and particularly when you know the person it is not a reasonable ask. I would bet the truth is basically "yes, we knew him so it didn't get full scrutiny," and honestly that's an honest (but hard to give) answer.
I do hope (perhaps naively) that this (security code reviews) is something AI can get really good at in the future, because that would be a real value add IMHO.
Raising competent empathic well balanced individuals is difficult, to say the least. And it’s not like the so called world leader elites really show they are some paragons of these traits.
so akcheually some people are sitting on a block of concrete!
theorizing that it was wrong to merge in itself is not victim blaming. but of course piling up in GH discussions and issues unconstructively, and just expressing opinions is bullying.
So I say they are getting exactly what they wanted to get.
Maintainers can 'lock down' the issue to just projects members, but that's very much an after-the-fact thing.
So, they have comment minimization by assigned moderators. Or you can just delete / edit comments and issues. Obviously not as powerful as a pre-screening queue. Less work tho!
I guess the argument for it is that it lets people easily "get involved"? Seems like there's some merit to making it easy for users to leave feedback. Maybe thumbs-up or thumbs-down on an issue really is valuable feedback in some situations. I'm torn between saying the social features are bad because they lower the barrier for low quality engagement, and saying that even low quality engagement can lead to valuable insights.
https://web.archive.org/web/20081216011059/https://github.co...
Which changed to "social coding" later:
https://web.archive.org/web/20110217073759/https://github.co...
"social coding" eventually moved to the page title, and disappeared from the page itself:
https://web.archive.org/web/20120202143623/https://github.co...
"Social code hosting" and "social coding" are not on the front page anymore, but they definitely kept all the social features.
Is there something new here I missed, or some additional context that makes this specific commit relevant right now?
Like, if we put it in the classic context of
1. Farm Karma
2. ?
3. Profit!
I'm not clear on step 2. What's step 2
And of course that pre-supposes malice (or at least greed), which is in violation of Hanlon's Razor.
In this post, they are discussing some changes to print code specifically for the libarchive project, and some notable personalities in the security community chime in, including Colin Percival (Tarsnap among others) and Taviso (Google project zero among others).
[1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor
Various discussions on this backdoor (in rough chronological order):
* Backdoor in upstream xz/liblzma leading to SSH server compromise:† https://news.ycombinator.com/item?id=39865810
* What we know about the xz Utils backdoor that almost infected the world: https://news.ycombinator.com/item?id=39891607
* How the XZ Backdoor Works: https://news.ycombinator.com/item?id=39911311
* The xz sshd backdoor rabbithole goes quite a bit deeper: https://news.ycombinator.com/item?id=39956455
* XZ backdoor story – Initial analysis: https://news.ycombinator.com/item?id=40017310
† Original report, AFAICT.
Here are parts 2 and 3 (weren't discussed on HN):
>Part 2: Assessing the Y, and How, of the XZ Utils incident (social engineering)
https://securelist.com/xz-backdoor-story-part-2-social-engin...
>Part 3: XZ backdoor. Hook analysis
https://securelist.com/xz-backdoor-part-3-hooking-ssh/113007...
it's not a major flaw, and no exploit. but it seems as if nobody paid due attention to actual changes.
This comment sums it up nicely with a gif: https://github.com/libarchive/libarchive/pull/1609#issuecomm...
It seems doubtful that a state actor is trying to use terminal escape sequences to hide an error message... The state actor wants code execution, not the ability to backspace some warning on a developers terminal. Besides, using such a vulnerability seems far too dangerous - those escape sequences would be plainly obvious in any log file or any inspection of files on-disk.
And at the same time, if you are an undercover state actor, there is no point in potentially revealing yourself by inserting some security problem that isn't exploitable.
For example — and this is just hypothetical - the author may have found that some consumer of this codebase uses it in a script, and consumes console output in some form. By modifying its output to behave differently, they may be able to influence the consumer’s execution in some clever way so as to create other conditions necessary for additional exploitation.
Or - the PR could have just been a test to gauge the scrutiny of the approvers.
... (until and if you see the larger picture, which might be insurmountably difficult ...
... this, coupled with AI-level scalability of social engineering, at AI-level scale -and- with an AI-level understanding of "known-outcomes" that might be desirable towards given goals: "Leader change", etc.-)
https://news.ycombinator.com/item?id=40428032 - Abusing url handling in iTerm2 and Hyper for code execution (2024-05-21)
I like to separate every little intentional change into their own commits. So a formatting change would be separated into its own commit.
If you are looking for “red flags” notice if the diff is clean or not according to what you expect to see changed; if you only expect to see some error text change then multiple lines being changed is weird. Also use a decent diff viewer which is somewhat content/language-aware.