The Linux backdoor attempt of 2003 (2013)

How do they know it wasn't the NSA then?

Developer tries to tell a story...

Sounds like OP interviewed the person who uploaded the code, whose system was previously inflitrated (it can still be the NSA). So why say "If the guy who did it wants to come forward, that is his decision. But he did provide me the full story", it doesn't sound like OP interviewed the "guy who did it"...

What is this a psi-op? This has been deeply frustrating to parse. You don't make sense.

It is very interesting to prove whether or not it was a state actor! Surely you can see that that mystery is interesting to many people.

> Like everything back then it was probably accomplished by exploiting trust relationships

That's wrong on many levels. Bold and stupid "hacks" committed by teenagers using SE tend to get a lot of traction, because it is both bold and stupid. This hasn't changed. But "back then" there was much more than that...

> What is there to say about the hack?

What is there to say about the [discovery]? Like everything back then it was probably accomplished by [a simple source code diff]...it is not at interesting 20 years later.

You get the idea. The story you know might be interesting to you because you happen to know the person involved. And it is sort of interesting? But not really as interesting as the _full_ story would be. In particular because your grammar in your original comment kind of implies you knew the actual attacker.

This all seems fairly obvious to me? Is there anything we're missing about the discovery? It's pretty mundane that one of hundreds of devs working on that source code happened to have a vanilla copy, especially in 2003 with a less reliable and slower internet.

The part of your story that’s still unclear is whether you know the identify of who actually inserted the malicious code.

maybe 10x the salary (probably not) but also a correlated increase in hours instead of a contractually mandated maximum of 40 hours, combined with the legal inability to do work from home, discuss work at home, and a lot of related perks.

Not to mention it being extremely difficult to travel internationally, and not being able to have close personal friendships with many people who live in other countries. Not being able to partake in THC consumption EVER, much less any other recreational substance besides alcohol. The list goes on.

I understand that it pays very well and there's decent work/life balance in terms of hours. But you have to essentially work in a windowless cell with no internet. And for lots of people with the curious hacker mentality, it would be a chore to "keep your nose clean" as they say.

I live in the DC area and the stereotype of the bland, khaki, polo, and white sneakers wearing boring person is true.

Iranian centrifuges would disagree with you as does the conversation about the apple exploit chain from last week.

FAANG money is a relatively recent thing. Stock options used to be the only way you might make millions as a developer, at that was always a gamble. The NSA probably has a lot of seasoned developers who started their careers when the pay gap was much smaller.

> I'm sure there are a select few who find this appealing

That’s really all you need dude. And yet both private and public sector intelligence jobs are selective. Supply and demand might help you reconcile your other points.

You slightly underestimate the pool of extremely patriotic or nationalistic smart engineers and scientists around.

If your basic thesis was correct no video games would get made either. Most of them could go get that FAANG money for arguably better work life balance. People have more motivations than you realize. And the idea that all the smartest engineers and scientists exclusively work for FAANG is a contrivance only believed on this dumb site. (The equally idiotic corollary is that all the smartest people work in software).

I also think you are underestimating the lifetime earning potential of top intelligence workers. 9 to 5 government jobs don’t have to be forever.

Finally, the sophistication of state level attacks such as in Iran is clear. The evidence exists, and you are wrong.

And you’re missing the point, it isn’t even that this attack wasn’t sophisticated it was that clearly no one sat down for even a few minutes to discuss how it would be detected. An organization, even a private hacking group, would have discussed this.

> The idea that the NSA is staffed with "uber hackers" is a Hollywood fantasy.

Inversely correlative, the idea that the NSA/CIA/FBI are staffed by incompetent technologists (hackers, devs, etc) is a Hacker News fantasy.

I replied to their comment because it was related, but where do you get the impression it is not supportive? I’m responding to the idiots poking holes in that claim.

It's funny when you don't read carefully.

I believe unit tests existed. I had a test training in 2000 and things were pretty systematic already then. Not 100% sure whether the exact term was used then.

Edit: JUnit is from 1997. So the name was definitely in use in 2003. I attended a TDD tutorial before 2004 (don't remember the exact year). CI wasn't a thing yet, so you executed your unit tests manually. /edit

Do unit tests exist in the kernel today? There is some (or some would say a lot) of automatic testing for the kernel, but I don't remember seeing a single unit test.

Very similarly to yourself, but I would say backdoor and vulnerability are mutually exclusive (kinda? I guess a backdoor is a deliberate vulnerability but I think you know what I mean) yet both can be exploited (the exploit being the client side code, if you will).

Irregular verb joke incoming:

I log in. You backdoor. They exploit.

> Would you find it more acceptable as `a = (x = y)`? To me, that is reasonably clear.

No, I don’t consider that acceptable. It is not enough that it is clear to some people who know what they are looking at. The language should be more clear to more people.

Modern languages using that syntax tend to prevent that mistake by either outright disallowing assignments in boolean contexts, or by not having implicit conversion of other types to boolean, meaning that the mistake would be limited to the case of comparing a boolean variable to another value, which is quite rare. Some languages further limit the risk by making variables unmodifiable by default, meaning that it would have to be an explicitly modifiable boolean variable.

Assignment is one of the most frequent operations in typical programming languages, so it makes sense for it to be a single-character symbol, and ‘=’ is about the only fitting ASCII symbol for that. (With non-ASCII, there would be ‘≔’ or ‘←’ (the latter being used by APL), but those are non-obvious to type.)

There are two orthogonal issues here:

1) Do you allow assignment as an expression?

2) Do you use the same operator?

If you answer "yes" to #1, you must answer no to #2, but if you answer no to #1 you can choose whether or not you use the same operator. Consider these examples (assuming that if they're different, we use =/==, but of course any other set of operators could be substituted):

    # A) if 'yes' to 1 this would be a "double assignment", setting both a and b to c.
    a = b = c

    # B) if 'no' to 1, and 'yes' to 2, this would be an assignment of the comparison of b and c to a:
    a = b = c

    # C) if 'no' to 1 and 'no' to 2, this would be an assignment of the comparison of b and c to a:
    a = b == c

    # D) if 'no' to 1 and 'no' to 2, this would most likely be a syntax error:
    a = b = c

With respect to confusion, I'd argue that B) creates a lot of potential for confusion. You'd want "a = b = c" to either be "double assignment" (A) or a syntax error (D). If your language does not allow assignments as expressions, I'd go for C/D exactly for the reason you give, as the main reason not to allow assignments as expressions tends to be exactly to avoid the mistake you mention (it's trivial to support in a compiler/interpreter, so it's a question of whether you believe it's more helpful or more damaging)

Yes, that is well known, but it doesn’t prevent the issue in TFA.