Sure, but that's true for 99% of things. Unless you establish trust outside of the normal distribution channel how would you protect against this? What is your proposed channel that is not bootstrapped from HTTPS PKI?
What? The bootstrapping happened already! The official and correct AMD software already running on the computers. Preventing a human from falling for an impostor-website with malicious Download Now links is a separate problem.
The basics are straightforward: It'd be better if the current installation contains one (or more) public keys, and anything it downloads must validate as being signed by a corresponding private key. You don't need to do fancy things like global certs, discoverable keys, or revocation lists.
If today's installation doesn't have those checks and relies solely on HTTPS... well, that's unfortunate, but it's not like it poses a tricky dilemma! You simply use today's not-so-secure mechanism to install the new code which has more-secure behavior, and it closes the attacker's window of (easier) opportunity.
I still can't figure out what problem you believe needs-fixing or what process you think needs to be explained. My most-charitable guesses are:
A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised.
B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com .
C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy.
Those are all interesting to contemplate, but they are at best "out of scope".
[Followup] To over-communicate in the hope that it somehow resolves things, we already have this chain of trust:
1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant.
2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a user who can do that doesn't need to.
3. The daemon is already coded to trust a replacement/successor installer if it meets certain criteria, which are:
3a. It comes from a trusted domain name it already knows should be owned by the same developer/company.
3b. The remote end is authenticated to "be" that domain via certificates from the (trusted) OS.
3c. The content is protected from tampering due, becauese we trust that TLS/SSL encrypts it.
That all already exists, it does not need to be torn down or rebooted. The proposal here is to simply to harden it with a new requirement in the next version:
3d. The next install must be signed by a trusted key-pair that was shipped with the current install.
This improves trust because it means an attacker would also need to compromise keys held in a release pipeline, which is much easier to secure than a CDN/webserver.
Sure, but the OEM is the definition of a ‘trusted environment’. They literally are assembling the equipment, if you can’t trust that, nothing else can be trusted from that point on anyway.
AMD (and Intel and everyone else) processors already have an HSM inside for confidential computing so use that? I would hope the HSM isn't as badly implemented as this update mechanism, but then again ...
AMD Software Engineers giving AMD Stupid Gaming Accessory Software Engineers access to a signing system backed by PSP seems like a much worse outcome than trusting HTTPS, really. Like, there are definitely intelligent and secure ways to do this, but this one in particular is overkill with a huge blast radius when it is (invariably) done incorrectly.
Confidential computing is a whole thing with a key in each processor and a chain of trust and a way to remotely attest that your software is running in a secure enclave. All the vendors do it differently (sadly) but it's very much a solved problem.
There was a time when RDRAND on Zen gave all zeroes, or something, so eh...
I'm happy enough with TLS introduced: knowing the server I'm reaching for updates is actually 'amd.com'. Signatures would be nice, sure, but I wouldn't consider them nearly as critical or useful until now. Before we get too caught up in signatures, however, I'd like to see their new/improved updater actually take precedence.
As things stand, I'm not sure key rotation would go well... the updater doesn't mind itself, apparently.
Yes. Or you can license it for specific purposes. But in general open data refers to data that is open to use by anyone, for any purpose, without restrictions except in some cases attribution.
A license only means something if you can enforce it. This means you can catch violations, and get courts to enforce it in a way that means something. If you can't catch a violation it is de facto allowed. What a license can restrict is limited by law, and so depending on the terms the court may say "you are not allowed to restrict that: they are allowed, go away". Or the court may impose a fine that is small enough everyone considers it a cost of doing business. How this plays out depends on the violation as well: if the violator can show they did their best to not violate that is very different from intentional violation. (I'm convinced the GPL will be broken - when a company shows they have lots of process to prevent the misuse, but a "rogue employee" hid their actions - the company will pay a fine but won't have to give their source code.)
Isn't that including things like google workspace and similar? Both Azure and GCP have sometimes included things that most people think of as unrelated SaaS (office 365, gsuite/workspace) to make themselves look bigger in the cloud sector.
> Isn't that including things like google workspace and similar?
AWS also includes Amazon WorkSpaces. Moreover, AWS includes all of Amazon's cloud infrastructure for things like Amazon music, Ring, Amazon Prime Video, etc.
But as a percentage of revenue I'd assume those are a lot smaller than Office365 is for microsoft and Workspace is for google.
Last I checked I don't think AWS included things like Amazon Prime Video either, AWS is primarily their buissness/platform offerings, not consumer things like Twitch/Prime/Music/etc.
> This means you can keep your palette of color, spacing, and other options fully enumerated in `globals.css` and elsewhere,
Why not use native css variables?
> Moreover, if you're working within a framework, such as Next.js, this minimization step automatically happens when you build, without even having to worry about whether it's happening
Again, if you are using plain css I don't think this is an issue. With any modern build system it will spit out css file for that build, right?
> After a long while, I concluded that, for me, Tailwind really is more efficient and maintainable and even more readable, but it definitely took quite a bit.
I think this sentence says it all: Any framework will be "more efficient and maintainable" once learned, even if "took quite a bit".
For tailwind I think it's an abstraction too far, but that's a decision we all do ourselves.
It's vastly different to do TLS termination within your own network and to do it on a rando VPS and then send normal TCP over the internet. It's not an argument of it being on the same server.
The VPS is your security in this case. It's not sending plaintext over the internet, is it?
Edit: No, the article mentions listening on port 80 at home. I thought they'd be SSH tunneling or something. That is unusual, but I guess for a static website it doesn't really matter.
> That is unusual, but I guess for a static website it doesn't really matter.
It sorta does matter. Either the actual raspi does nothing of value or the traffic has value that should be protected.
Sure, I heard the argument that public HTTP traffic does not need encryption but if it is of any value then both parties have a interest in it unmanipulated, uncenscored, validated or all of the before. Even if it is just preventing the ISP injecting dumb ads.
reply