Ah but I suspect in all of your supervision of employees you never had an employee who was under contract from the Russian military, and probably being paid millions of rubles or whatever they are using there, at the same time you were supervising them, who's job was to pwn the project for his actual employers needs instead of your needs.
Such an employee would have been the perfect one to supervise, and he would have also insured that the process was working perfectly as well. The very last thing he would want is for you to get involved to fix something. FOSS operates because it's NOT crapped up by 6 committee meetings and a dozen code reviews which your typical programmer hates with a passion. The process works or Linux wouldn't be good enough today to run mission critical stuff. In this case it was one PERSON operating in that working environment who's job was to subvert it. Letting him into the party to play with the toys was not done properly, or as a bad actor he would have been screened out. It's not process - it's absolutely the supervision. A commercial org with Agile development and code review and process up the wazoo ...well that's Microsoft. And their process doesn't deliver any better code as witnessed by all the problems with the March security update.... Ted -----Original Message----- From: PLUG <[email protected]> On Behalf Of MC_Sequoia Sent: Saturday, April 6, 2024 5:28 PM To: Portland Linux/Unix Group <[email protected]> Subject: Re: [PLUG] - attack on sshd via xz => More XZ Libs malware info "The most troubling aspect is that there's too little supervision of changes in projects." Nope! It's far less about supervision and far more about process. Especially in the FOSS world, which relies heavily on peer review & the user community to ferret out bad code as happened in this cause by someone doing database benchmark tests and noticed the SSH logins were taking much longer than normal. If you've ever found yourself supervising a bad process, you'd know this beyond a shadow of a doubt. I can't tell you the number of jobs, where as a technical person, I did way more work fixing bad & broken processes than I did fixing bad & broken workers, with the exception of the occasional incompetent, lazy or bad worker who doesn't want to follow process or is unable to. In which case, you set them free to find another job! =)
