ilyt

From my experience it only work in CM repos where you have a lot of very small changes and usually unrelated.

Well, the one that didn't got breached.

I think we'd be in far healthier society if corporations not turning profit for half a decade would just die instead of entangling more users into their failure. via investment money...

We use similiar gpg-based one in our Configuration Management infrastructure, works really well.

The data files are encrypted with keys of the CM main servers and other admins, GIt has history in case something that should not get removed got removed and if you want you can also force that the data will always be signed with certain keys on server side git hooks if you want to have more accountability than just git logs.

With little config even git diff/git log work showing unencrypted (if you have right key) content.

Ain't nobody giving shit about your pictures kept on home server. Security measures need to be relevant to chance of attack, they do not exist in the void.

And so mediocre protection of irrelevant target can be far more effective than good protection of juicy target

Actually if browser used plain old smartcard cert off yubikey for client cert auth it would be prevented, but that's too PITA to use.

Well, if implemented right. Techically every ssl connection would carry user's identity so cookie with that identity wouldn't even be required

> And whether Heartbleed was worse than log4shell is mostly philosophical.

Most definitely not. Heartbleed means that as long as your are on the internet they have your certs, full stop. Log4shell required access in both directions (to inject the vulnerable string, then for target machine to load the payload off internet) to do anything.

The sheer fact that you think it is 'philosophical' difference points to you not understanding anything about the topic. log4shell could be trivally prevented by common security practices like "not allowing your apps to freely access anything on internet", heartbleed could not.

And you can just wash hands because you used "industry's best practice" and continue the security theatre.

Extremely unlikely, PSUs are not built in the way where that would be really possible

Apple updates their phones for LOOONG time compared to Android

At least it makes it easier to spot the inept and incompetent in the crowd.

Actually no, they were first to have code successfully run in (space dust) cloud for so long

I feel like it will converge to just having RV + FPGA chips rather than people wasting precious FPGA space on softcores. Zynq's are plenty popular already

They want to have the cake and eat it too with same instruction set fitting "small" (few hundred kB of flash/RAM at most) and "big" (Linux kernel running devices and up) ones.

IMO it's futile effort that unnecesarily taxes the big codes.

If they bothered to mount extra connector they didn't bother to remove rest of the parts, I'd imagine the connector is connected to same power rail anyway.

It's still probably at wattage as advertised, but I wouldn't be surprised if some models that differ by "only" 100W had only difference being current limit resistor set on the different value.

"Not this visit"

Why US allows such clowns to enforce law ?

No reaction ? Straight to jail

Nervous ? Straight to jail

Laughing ? Straight to jail

Laughing nervously ? Guess what, straight to jail

AES instructions still fill CPU's time regardless of how fast they run

Doing 2.6GB/s in single thread means you have one core less to use...

Doesn't answer question "why?"

In other languages they were used coz they were far lighter than native threads but that's not the case in Go

Ask a full stack JS developer to make their app use a proxy and they will get nervous breakdown

If it was actually meant to prevent eyesore it would be about how many of them are in front of the property, not overall

They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.

> I assume the root cause is DNS tricks.

Maybe read the article

Did that, can confirm.

For other more sensible reasons but still.

> Why is it even possible to issue more than 1 certificate on the same domain via Let’s Encrypt? Shouldn't the previous certificate be revoked when a new one is issued?

First, you want to have to have some leeway so you don't need to rotate certs at exact second the old one expires

Second, you might want to have cert-per-server rather than cert-per-domain, as that's frankly easier to implement vs having common store for certs+key

FDE is overrated, most leaks are not "someone stole my laptop" but "user clicked malicious links" ad other stupid stuff like that.

And it is also entirely useless for good amount of data volume-wise on machine.

I never need video game files to be encrypted for example. It's entirely waste of power and CPU time to do it.

Right, then commit that one line fix to the plugin

Or remove it altogether, warn people for years about deprecation, then remove all of them. Which they did.

More net lines removed too.

But hey, it annoyed Man That Is Bad At Dependency Management and Wrote A Book About It so it must be bad!

I put "throwing the cruft away" in the same sentence EXPLICITLY to address that I am not just talking about refactoring.

Learn to read before throwing dictionary definitions at people

Providing method now-provided by standard libs is by definition unnecessary cruft. Nobody wants that in their codebase. They warned people for 2 years.

But apparently basic competence is too hard requirement in software ecosystems.