mysidia

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.

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.

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.

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.