knorker

And I should add: not just github compromise, but supply chain / original author replacing the contents.

Absolutely the SHA-1 is treated as "authenticating". Cargo.lock (for regular crates.io dependencies) are confirmed using SHA-256.

Supposed to be or not, it is.

Package managers even use it. E.g. you can have a cargo dependency pointing to GitHub at a specific commit. It's definitely intended to provide end to end security without depending on GitHub being secure.

Also git submodules.

"The nearest cent" is already a bad assumption. Should IEEE 754 representation dictate taxes and money splitting?

You could end up with splitting an account down the middle, and ending up with an extra cent being created out of thin air, or one destroyed. In billions of transactions each day, this could be a problem for balancing books when there is no longer any equality check.

When not using floats, the rules and checks become more… deterministic, if you don't mind stretching the definition of that word a bit.

Ha ha ha. But were the ads shown OK?

https://www.techradar.com/home/smart-home/samsung-launches-a...

Like 20-30 years ago there was a relativistic raytracer that was like POV-Ray, but with relativistic effects. Maybe named "backlight"?

How does this compare?

Edit: yeah this one: https://web.archive.org/web/20010604001305/http://www.anu.ed...

Right, so your starting point is that the attacker has read-only access to ALL entropy sources, and in that scenario it's worse if the attacker has read-write access to one entropy source.

Yes. I don't find this a particularly interesting scenario, though. Sure, we can come up with stuxnet-like airgap attacks where we on-device, but not remotely, can read entropy sources. AND we can modify the output of RDRAND. And there keys have been generated for data we can later intercept. But despite that control (potentially on a CPU microcode level) we are unable to stegonographically leak it?

Sure. Possible. Has it ever happened?

> that's fine so long as you have other entropy sources

Well, if you literally have nothing else, then you don't have an option anyway, so the whole question is moot.

Except yeah if literally the only way to collect entropy in your system is the platform's opaque RNG, then sure this means your risk assessment should list that as a SPOF. But by definition these cases only have that option, so you can't do anything else.

In reality, you can probably do something else in all but the most extreme embedded environments.

Sure. In general this is a very important factor.

In the context of this topic, it's a bit pedantic.

> if you know one source is bad, might as well take it out.

Yes and no. Mostly no.

In a simplified model, it's only useless if it adds zero bits of entropy. But if a source that's supposed to add 128 bits of entropy only adds 16, well, it's still 16.

I would never trust RDRAND on its own. If nothing else because it's always subject to a microcode backdoor. But if I already have something I'm happy with the entropy of, sure, I'd XOR it with RDRAND output. It cannot make it worse.

Adding bad randomness can't degrade good randomness, can it?

I thought the kernel would not replace anything just because it adds a potentially bad source.

E.g. if you have rand source A, and xor it with rand source B, then you get, at worst, the best of A and B,

I feel like this is hindsight bias, and in a different scenario you'd be saying "not hosting your infrastructure in a DC without AWS level diesel backup contracts is even better".

Which I already said, and you ignored.

Anyway, it's all moot, because the military will now also spread out.

You can go with "Joe's pizza and cloud services", hoping there aren't enough military workloads there, but where are you more likely to have an outage?

Which is why your job as a responsible company you should have verified your offsite backups on 28th Feb.

Just like you would if wildfires started breaking new records in Oregon, if that's where your (for some reason sole) cloud region is.

It should already be set up, of course, but from a data point of view this is when you're thankful that at least this raised risk came with a heads up.

Sure. But given that the affected customers would by definition not have offsite backup, the comparison is against a smaller operator that has way more risk of fires, theft, bankruptcy, incompetence, earthquakes, power delivery, and all the other risks.

Sure, fewer customers per location, but the critique here is of customers who chose AWS, the fair comparison is NOT against those who chose to be in 6 different non-AWS DCs, but against those who chose to be in ONE non-AWS DC. Decentralized aggregated across customers or not, the customers who chose unluckily still lose data.

> If your organization runs on AWS then you should have a contingency plan for the data center being destroyed by drones.

If your organization runs on servers in your basement you should have a contingency plan for flooding, fire, copper thieves, diesel shortages, etc… etc… etc…

Or are you basically saying that the only safe place is outsourcing your ops to a mid sized operator? Too small and nobody will pay for the every day risks. Too big and it's a war target? Ok, let's continue that plan. Now military users move their workloads to the mid sized operators for the exact same reason you did. Oh no, we're back at square 1.

A plan of putting all your eggs in one basket is never good. And it's completely orthogonal to AWS vs the non-AWS options.

Pretty basic stuff.

> If you don't know what Wildberries is

Not exactly esoteric knowledge. But it's also not the same thing. Wildberries could not "back up" their inventory to an offsite location with the footprint of a suitcase.

> If your organization runs on AWS then you should have a contingency plan for the data center being destroyed by drones. Is that on your risk management plan?

Sure, if you discard ALL other risks, that happen every day, leaving only war as the remaining risk to manage, then your risk management plan makes sense.

But the other risks are still there. Your DC operator going bankrupt and having their power cut is a risk that didn't go away.

> You don't need better missile defense than AWS.

Well, obviously.

> You don't need missile defense at all because you won't be a target.

No, you don't need it because you have offsite backups. And this is completely disconnected from whether you use AWS or DIY.

> you won't be a target.

Of missiles, maybe in this particular conflict, sure. But running a DC is not your core business, so which DC is more likely to be subject to burglary, power outages, diesel shortages (Amazon will have better negotiators than you), fire suppression, hell, private fire departments if needed, etc…

Was missiles or copper thieves the biggest threat, even there, in 2020? Would AWS or every small company be better at protecting against the latter?

What's you point? That if you had run your own DC in that region (because that was your business requirement) then you'd have better missile defense than AWS?

Or maybe AWS or DIY, you are always responsible for geographic diversity?

Anyone losing data over this lost it because they'd literally told AWS to only store it in one place.

As someone who did train one of the traditional martial arts for a few years, I appreciate the comparison.

I don't know how much weight your "just" is meant to carry, but I remember a culture of cope and excuses about why "my" flavor wasn't the winner of any MMA event.

But at least I got some exercise, strength, and flexibility out of it.

I think it's an interesting analogy, not to be dismissed so easily.

I don't see him saying the point is volume of code. I see AI generating code, and if I question it, it can justify design choices pretty well. I can give it bug symptoms, and it can find and fix the bug. Usually.

But yes, the analogy breaks down in the fact that I understand what it's saying and understand when it's wrong, because I learned it in the first place.

Or maybe it doesn't break down completely. If an MMA (AI) tells me to move in a way where I know I'll lose my balance, or over extend, I will say no, because of my previously acquired experience.

Well, for one it breaks right click and copy link location.

Again, that only works for large companies, and for companies that can exists even if their service is downloadable.

Which fine, you can choose to take that political stance. But that's a stance of "I want to change the world to my liking", not "I want to help the world/people".

Up to you, of course, but I prefer to help not only large companies.

This means you have only solved the problem for large companies, and specifically those who have money and who have a functioning procurement system that's developer-driven. Which is a very narrow use case.

Also relevant comment: https://news.ycombinator.com/item?id=49596403

Sure, but for anything except large companies it has a bootstrapping problem. I'm absolutely not going to use AGPL software in a test one-person trying to sell a service kind of deal. So if it takes off, I'm already on a non-AGPL stack, so why reach out at that point to get a commercial license for software I don't even use?

And hell, even without money involved, I'm not going to make a hobby project with AGPL software either. Not only may I have small parts of the project I've not opensourced, but AGPL is untested in how far the virality goes. Are my backup cronjobs in scope? I certainly don't want to be the test case for this. Even if I win against an AGPL troll, I'll still lose.

Yup. As I said in another comment "I treat AGPL as a rabies infected animal. I may have uses for it, but I'll keep it EXTREMELY segregated from everything else".

Could you please take my question at face value?

> I chose to do it for free to help other people. And picking a MIT license does the opposite.

I have no idea what this is supposed to mean. I want to help other people, then giving them the means to do what they want with no real restrictions is "the opposite" of that?

> Companies that want to take without giving back

So this is not about helping anyone else, but about mandating a behavior, even if that behavior is "pay it forward".

Not really "one disadvantage" as much as "the main use case".

What's the difference to you between a rug pull and theft?

Do we really need the latest kernel on them, though? As in, is it worth it?

In 100 years, if we need to run kernel 6.12 to use a 3c509, is that all that bad? It's not like being "stuck" on an old IRIX without the proprietary dev CD where you have a catch 22 problem.

An old system version that's completely open is whatever the sysadmin version of "turning complete".

Sure, port the open system to the hardware that does not have an open system. But I question the value of keeping it up to date.

All else being equal, sure it'd be cool. But all else is not equal. So yes, ripping out old code is the right move for Linux, in my opinion.

Huh? You release code so that people will have to rewrite it?

I really don't understand what your goal would be in releasing code at all, then.

Which could make the business untenable. I'm not GP commenter, but I do want to be useful to these too.

And as others have said the deceptive term of "plugging the SaaS loophole" ignores that it means most software cannot be combined with it. Most. By far most.

Sure, some people will say "well fuck that software". And that's a stance. But it ain't freedom.

Do you have data on that last bit, or just a guess? As a hobbyist and OSS developer I treat AGPL as a rabies infected animal. I may have uses for it, but I'll keep it EXTREMELY segregated from everything else.

> Over the years it has been clear that we in the “open source” camp (as opposed to the “free software” camp) were wrong all along.

No. YOU changed your mind, to become less free and more authoritarian.

> gained little for users

What? The world runs on Linux.

> or developers.

Were you even there before "everything" was open source and/or free software?

> our efforts did was to make it easier for big corporations build things more cheaply and for billionaires to become trillionaires.

Yeah that was always allowed.

The problem with freedom is that people get to make their own choices, eh?