Earlier quoted context omitted.
[flagged]
Javascript is pretty much guaranteed to be permanent. It is the language of the web. (There's webassembly too, but that doesn't remove js)
I don't think anything is "pretty much guaranteed": things evolve
Timeline of the xz open source attack
231–240 of 482 posts
Re: Timeline of the xz open source attack
#232Something I've wondered about wrt this debacle: presumably the smart part of xz was the compression algorithm. I'm guessing but that's probably less than 500 lines of code. The rest is plumbing to do with running the algorithm in a CLI utility, on various different OSes, on different architectures, as a library, and so on. All that stuff is at some level of abstraction the same for all things that do bulk processing…
we were discussing this on the IRC. Imagine spinning up a thread, then running a bsd style pledge(2) on it to call liblzma. Kinda janky but it would work. Another option would be to just go out and call the xz util and not rely on a library to do so. That process can be locked down with pledge to only have stdin/stdout. That's all you need.
So, like UNIX does have this plumbing, its just that reaching for libraries and tight integration has been the pursuit of Lennart Poopering and his clan for years.
Re: Timeline of the xz open source attack
#233"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…
Never understood why our industry seems unique in our willingness to do unpaid work for giant corps. Your compression library isn't saving the world, it's making it easier for amazon to save a few bucks. You have the right to be paid for your time. It's valuable. I enjoy coding too... but the only free coding I do is for myself. Use a proper license, charge for your time and stop killing yourself doing unpaid hobby p…
Did you get paid for the post you just wrote? People at giant corps are reading it right now, they're getting value from it. You deserve to be paid!
IF you understand why you'd post without being paid, you're 80% of the way to realizing why people program without being paid.
Re: Timeline of the xz open source attack
#234Earlier quoted context omitted.
That's a great first step, but ready your pitchforks for this next take, because the next step is to completely eliminate Turing-complete languages and arbitrary I/O access from standard build systems. 99.9% of all projects have the capability to be built with trivial declarative rulesets.
Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left. There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverag…
Maybe now that we have things like GitHub Actions, Bitbucket Pipelines, etc., which can run steps in separate containers, maybe most of those things could be moved from the Maven build step to a different pipeline step?
I'm not sure how well isolated the containers are (probably not very – I think GitHub gives access to the Docker socket) and you'd have to make sure they don't share secret tokens etc., but at least it might make things simpler to audit, and isolation could be improved in the future.
Re: Timeline of the xz open source attack
#235Earlier quoted context omitted.
tbf, most security issues aren't from some insider, but outsiders discovering exploits. The insider scenario here is extremely rare both in commercial and FOSS software. Corporate insiders do stuff like this too, its just how often do we hear about it? FOSS has high visibility but closed source doesn't. Think of all the shady backdoors out there. Or what Snowden and others revealed. On average a 100% FOSS organizatio…
>Corporate insiders do stuff like this too, its just how often do we hear about it? Pretty much never. One particular terrible case I saw was when a developer left a testing flag in a build that got pushed to production and used for years. Had you set the right &whatever flag in the URL you'd have unauthenticated access to everything. It was discovered years after the fact when the software was no longer in supported…
And I'm guessing there was no Five Whys or equivalent to ask how to prevent this from happening again.
No time to do things right...
Re: Timeline of the xz open source attack
#236Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.
People have been bullied out of 'nice' communities. See the 'Actix' debacle in Rust.
Re: Timeline of the xz open source attack
#237I 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.
> Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Another example of this was log4j: if you were still using the old 1.x log4j versions, you wouldn't have been vulnerable to the log4shell vulnerability, since it was introduced early in the 2.x series. The old 1.x log4j versions had other known vulnerabilities, but only if…
> Another example of this was log4j: if you were still using the old 1.x log4j versions, you wouldn't have been vulnerable to the log4shell vulnerability
Lol, this exact thing happened at my last gig. When I first learned of the vulnerability I panicked, until I found out we were so outdated it didn't affect us. We had a sad laugh about it.
> "so that when another vulnerability happens, upgrading to a fixed version (which is assumed to be based on the latest release) will be easy".
I think there is some truth to this motivation though - if you are on an ancient 1.X version and have to jump a major version of two, that almost always causes pain depending on how critical the service or library is. I don't pretend to know the right answer but I always tend to wait several versions before upgrading so any vulnerabilities or fixes can come by the time I get to the upgrade.
Re: Timeline of the xz open source attack
#238One 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.
[flagged]
Nonsensical argument. JavaScript and TypeScript projects are developed with patches of the original source not some compressed artefact. Take your trolling elsewhere
Re: Timeline of the xz open source attack
#239Earlier quoted context omitted.
If you casually ask this while you can study (and preferably record!) the person's posture and they react in real-time then you can apply interrogation technique which CIA et al use.
So becoming an open source maintainer will involve an in-person trip to an interrogation? The xz attack involves, in significant part, a maintainer burned out and happy to accept offered help. I don't think making it substantially harder to receive genuine help is likely to improve the situation.
I just wanted to bring up that technique (it is not unique to CIA; LE also uses it). I never asserted the technique would've been useful in this very situation. However, in your framing you ignored the option of video conferencing.
Also, you are forgetting bringing up 'are you trying to pull xz to me?' is a yellow flag towards the person who said it. It isn't definite, it just makes people raise up, it gathers the attention of watchful eyes. We should be careful not overdoing it though.
Re: Timeline of the xz open source attack
#240Joe Cooper's take on pressuring project maintainers: https://forum.virtualmin.com/t/dont-panic-ssh-exploit-in-ble... somewhat ironic, but I'd say effective.
I don't even think it's necessarily moderation so much as maintaining these high-traffic projects is now akin to a full-time job minus the pay.
At a certain point, companies need to step up and provide funding or engineering work or they should just keep expecting to get owned.