It's standard autoconf stuff, BUT... the right thing to do for a security option should be to throw an error at the configure stage If the Option is requested but can't be supported, And not to silently turn it off.

That is because a human should have to Look at the build and manually make the decision to switch off a security feature from the build.

Autocomf output is so incredibly noisy though, still long odds someone would notice anytime soon.

If you break the build they’ll notice

Good thing they disabled the check that would have broken the build/tests in this case eh?

It's worrisome for sure.. the original maintainer mentions longterm mental health issues, "but also due to some other things"

My worry would be "other things" they didn't mention can include deliberate acts of sabotage by said unknown agency. Devs can have health issues or other problems come up with themself or family in their personal lives, but also intelligence agents can tamper with people covertly in different ways such as deliberately causing various kind of accidents or contaminations/poisonings.

In any case; they could only have to disrupt the developer's life for a few months to persuade them that they need to step down to put one of their confederates at the head of the project, I begin to worry for All developers' safety now if you are the sole maintainer of a key project critical system daemons may link against.

The other thing besides the autoconf soup is the XZ project contains incomprehensible binaries as "test data"; the "bad-3-corrupt_lzma2.xz" part of the backdoor that they even put in the repo.

It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.

Still.. At this point the default assumption should be every commit is a vulnerability or facilitating a potential vulnerability.

For example, change from safe_fprintf to fprintf. It would be appropriate that every commit should be reviewed and either tweaked or re-written to ensure the task is being done in the safest way and doesn't have anything that is "off" or introducing a deviation from the way that codebase standardly goes about tasks within functions.

Surely this is happening right now.

A lot of eyes are on the code. From all sides. Folks trying to find old unpatched backdoors to exploit or patch.

Consider the possibility those type of submissions were part of the adversary's strategy in order to make their account appear more legitimate rather than appearing out of nowhere wanting to become the maintainer of some project.

Lasership, Inc. v. Watson. Found a NDA unenforceable because the term was indefinite that the court deemed to be an unreasonable term for the agreement - It is important that contracts have a well-defined start date and end date.

An agreement cannot be perpetual.. A contract without a specific time period stated may potentially be terminable by either party with notice once the business relationship ends after a reasonable amount of time. So stating a number of years (less than 50) may strengthen the NDA in some respect - The "indefinite" NDA of an employee may possibly be terminated unilaterally by the employee with written notice after they left the job, so better for the employer to have them signing a new NDA at the time of separation giving a time period for the agreement.

If you rent the backhoe... make sure you call before you dig and don't cut one of my fibers, please.

You can use financing arrangements to avoid dropping the money all at once -- for example: A service provider offers you a monthly subscription or "lease-to-own deal" where you sign a contract to buy the software or hardware in exchange for monthly payments to be made over a period of time; that could be indefinite, or you become the owner of the hardware after the end of its useful life. Or just go to a bank, and they will be happy to create a loan and write a check out to your vendor for the lump sum, and so you are only responsible for making required monthly payments of the interest plus any principal, etc, required by the contract.

So no... not necessarily... CapEx is not necessarily paid out all at once. So the accounting ought to be the same whether its a CapEx purchase under a Subscription Agreement/Loan, or if its an "OpEx" payment for 1 month of services.

in the case of computer equipment that needs replacement very 4-5 yrs (or less depending on compute and other reqs) you’re perpetually in a lease and this starts to become opex

The thing is the AHCI interface is native to Intel chipset, so they had to do some sort of extra work to block access to enable it......

They provided a new proprietary storage interface, because it's purported to be Faster, and the better performance should benefit Windows users.

I vote incompetency and apathy on Lenovo's part, not malice.

Perhaps he didn't deliver the point... but BASH is not a good or safe language to write to.

Writing to '/bin/sh' is understandable due to its ubiquitousness.

Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does.

If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.

/bin/bash is on literally every machine I ever touch. It is on every Debian machine. It is on every Ubuntu machine. It is on every OS X machine. It is on every Windows (!) machine. And there are plenty of operations that are significantly more cumbersome to write in Ruby--otherwise, sure, I would do so. Backticks are nice, but there's no `set -e` (that I am aware of) and it becomes a huge hassle to do things in a smart, error-checking way.

No-one claimed Bash isn't widely distributed and installed by default.

However, unless you are patching and compiling the same version of Bash, you absolutely do not have the same version on all those machines, and that is the whole reason NOT to target Bash in shell scripts - its features are not always consistent/compatible across versions.

> /bin/bash is on literally every machine I ever touch. It is on every Debian machine. It is on every Ubuntu machine. It is on every OS X machine. It is on every Windows (!) machine.

Yes. Yes. Yes. Yes. No (unless Cygwin is installed).

/bin/bash is on literally every machine I ever touch. Did you miss the operative phrase?

(I have init scripts for Cygwin, too, because I need Windows but life is too short for CSRSS.)

> /bin/bash is on literally every machine I ever touch. Did you miss the operative phrase?

You intended that subjunctive clause to apply to all the sentences, an intent I missed. My mistake. :)

This may soon become a tempest in a teapot, as patched Bash versions are now appearing. I just patched all my machines.