Comment by NotPavlovsDog | Hacker News Reader

Comment by NotPavlovsDog | Hacker News Reader

Parent Full thread

This leaves a bad taste as to what the "forensics" could uncover just due to the open development model. It's nice to be the prophet of evident mistakes when the trail is easy to follow, even if you can't exactly master the lingo.

From the article:

   >The change, which in the parlance of software development is known as a “git commit,”

It was a change. Parlance commit. Parlance, per tool used, "git commit" (and then check as to tool standard parlance). My point being, what do we routinely hide thanks to not coding in public? What do engineers routinely hide, when possible?

I would rather, as an engineer, discuss core issues we can fundamentally address: compromising on inadequate workflows (including core architecture and paradigms), commitment to over-delivery, and the ever-dooming deadlines. What victories of the CTO went ignored, as part of "the job"?

It's nice to be smart when you have regular 8 hours of sleep. I've had enough stress to remember just how idiotic many of my decisions were, as a "leader". Most of them went ignored just because we were covered by being invisible, by design. Morally, I can't judge this CTO. If you look at your coding history, can you?

There's a difference between commiting hacky-but-working code during an Agile sprint and commiting code that allows unsanitized input to a SQL query.

Yes, but then, really, the fundamental popular software paradigm is not just unsanitized but unsanitary. The models for sanitary-by-design are there. It's just math.

   The core leadership behind inadequate decisions, often above the CTO, are frequently of the "don't care about the math, just the numbers" type.

Perhaps the CTO raised concerns. Maybe, not. But if we want an open engineering culture in software, unlike "applied engineering" in other industries, we should actively oppose punishing those that embrace open-to-peer-review models, even when the openness backfires and the history gets removed by the open workflow participants.

We may still have a fragile and unique culture in software, that perhaps contradicts past history such as engineering in construction (look up "corruption construction") or the unique corruption of medicine ("sugar lobby", "food pyramid").

Despite bad decisions and the fumbled cover-up, the attempt to perform in public on their part is valuable to me. We don't have easy access to which of the doctors took money to publish "research" that "calories are the same", pushing for more carbohydrates in diets. This may translate to multiple people, people you might personally know, dying of diabetes.

With open software, we get the names. This should not reward click-bait media witch-hunting.

I can 100% judge him. It is the CTO's job to put in place processes and safeguards that reduce the possibility of one of the most common widely known security vulnerabilities. Either he didn't put in the safeguards or he bypassed them, either way it's a fireable offense that put the whole business in danger.

Do you have your commit history available in a public repository? I don't. Honestly, i'm paid for being a professional fuck-up. I just fix things quickly and support my team enough for us to bear the mutual guilt in silence.

There are SQL injection fuzzing tools that will have no problem catching this. This is not the kind of security defect that would depend on "white box" testing.

If you're suggesting that the obscurity of closed source would have prevented the hack then I very much disagree. There are countless examples of sql injection attacks in closed source software.

I am commenting on the core foundation of the "article", to quote:

   > "A quick review of Gab’s open source code shows that the critical vulnerability—or at least one very much like it—was introduced by the company’s chief technology officer."

What would the writer have without the open source?

Ok that's true. With a closed source process the company gets to more carefully control the narrative. That might be better for the company and for protecting reputations, but it's not better for the public at large.

Further, with a closed model, one can always peruse the emergency clause, force majeure, the ever popular "state actor".

"Independent experts indicate (fee undisclosed), a powerful malevolent actor was involved in the recent malicious attack on our infrastructure. This aligns with the recent series of threats identified by the State Department and other US government agencies as enemy state activity to undermine Democracy! They hate our Freedom!"

Most of my company's code is open source.

The CTO has only been there since November. No idea what type of situation he or she may have inherited.

However, it looks like the CTO pushed this directly, no PR.

> commitment to over-delivery, and the ever-dooming deadlines.

Surely the difficulty in recruiting people to work for their shitty website with shitty politics should illuminate for you and everyone also in denial that politics is also engineering.

Reply on news.ycombinator.com