111–120 of 131 posts
Earlier quoted context omitted.
Each user would get its own private key that could only be used on its own device. It could not be used to sign software for someone else device
Hmm, that's actually the first suggestion I've heard that's at least technically workable, though it's pretty darn impractical to do at any kind of scale.
Earlier quoted context omitted.
What you've just described is a completely insecure hardware platform. Giving out a second private key that can still be used to install third-party updates is just as insecure as giving out their normal private key, the only real difference is if anyone actually looks at the code signature they can tell the difference between third-party and first-party code. Allowing the user to lock out that second key doesn't fix…
> Allowing the user to lock out that second key doesn't fix anything because 99.99% of users will never do that, or even know it exists. That's easily solved: On initial device setup, the user could be asked to explicitly disable the key by asking something like "Would you like to secure your device by permanently disallowing the installation of untrusted software? Y/N" Also, as someone else clarified below, the alte…
For example, can the user change their own key? If yes, the device can never be trusted second-hand - the OS might have been modified to secretly accept more keys. If no, then the device also can never be trusted second-hand - the previous owner could well have retained the key. And which key is superior, the manufacturer key or the user key? Can the possessor of a key override actions attempted using the other key?
Also, as written, this is just a bad solution. So you ask the user on initial setup. Let's say 99% of users won't know what the question is asking. So maybe they hit "yes", and now we're just back to iPhones and no user freedom, for them or any subsequent device owners. Or maybe they hit "no", and now they're no more secure and there was really no point in asking them. Maybe it's a 50-50 split, depending on how they feel (and not related to how they would choose given informed consent). Or maybe the user is informed, in which case they are very likely to just hit "no", if for no other reason than to preserve the resale value.
Don't get me wrong, I do think this could be done right. But attempting to guarantee "security" (that is, the dubious sort of security that is manufacturer-only updates) to naive users, freedom to power users, and preserve those guarantees as the device changes hands... well, that's a Hard Problem. I think only Chromebooks have attempted it so far.
Earlier quoted context omitted.
Hmm, that's actually the first suggestion I've heard that's at least technically workable, though it's pretty darn impractical to do at any kind of scale.
> though it's pretty darn impractical to do at any kind of scale. How so? It's a solved problem. Don't smartphones already have numerous device-specific identifiers and keys loaded to them? All they would really need to do is slap an extra sticker on the device with the device-specific key printed on it. For instance, my phone came with a sticker with its IMEI printed on it.
Earlier quoted context omitted.
I'm not familiar with the security model of Chromebooks. How does it work?
Out of the box, they only accept Google OS updates. For reference, the OS is basically Gentoo+Chrome. If you've a mind to, you can put the Chromebook in "developer mode" with a magic sequence of commands (requiring physical access as it's a boot procedure). This gives you root. To protect naive users from being exploited, a Chromebook in developer mode will display a nasty warning on boot. This warning lingers on the…
Earlier quoted context omitted.
A platform that is insecure-by-default and relies on users being knowledgeable and motivated enough to learn how to lock down their own devices is still an insecure platform.
People have taken their time to draw you a picture of a solution you could have come up with yourself. They are not talking about opt-in security, you are the only one. GPLv3 does not hinder security. You are furthering FUD.
Earlier quoted context omitted.
It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you to learn that different people value different things and have different opinions, and so want different licenses. GPLv3 is really a pretty extreme license that imposes a lot of restrictions that a lot of people simply don't want. If GPLv3 does what you want, by all means use it, but don't denigrate the choices other people make.
I explicitly said a superior copyleft license. That is, I stated the value I presuppose, and in this context GPLv3's superiority to GPLv3 is clear. What's "extreme" is denying users control of their own devices, not the reverse.
There's two issues at play with copyleft licenses. The first is making the source available to others, and the second is allowing others to install modified versions of the software. GPLv3 mandates both. GPLv2 was certainly intended to mandate both, but ends up mostly just mandating the first. If all you care about is having other people who use your software release the source to their modified versions, then GPLv2 is clearly superior to GPLv3 because it has fewer restrictions. Similarly, if you care about having source made available but you also want to have your software become as popular as possible, you may opt for GPLv2 because it's a lot more likely for companies to use your software than if it's GPLv3.
Earlier quoted context omitted.
> though it's pretty darn impractical to do at any kind of scale. How so? It's a solved problem. Don't smartphones already have numerous device-specific identifiers and keys loaded to them? All they would really need to do is slap an extra sticker on the device with the device-specific key printed on it. For instance, my phone came with a sticker with its IMEI printed on it.
IMEI can be recovered once you throw the sticker away. A private key that can be used to install new software cannot be recovered, or if it can that's a huge security risk.
The IMEI example was just to demonstrate the ability to slap a device-unique code + matching sticker on something during manufacturing at scale.
Earlier quoted context omitted.
> Allowing the user to lock out that second key doesn't fix anything because 99.99% of users will never do that, or even know it exists. That's easily solved: On initial device setup, the user could be asked to explicitly disable the key by asking something like "Would you like to secure your device by permanently disallowing the installation of untrusted software? Y/N" Also, as someone else clarified below, the alte…
Now you have a number of thorny design decisions. For example, can the user change their own key? If yes, the device can never be trusted second-hand - the OS might have been modified to secretly accept more keys. If no, then the device also can never be trusted second-hand - the previous owner could well have retained the key. And which key is superior, the manufacturer key or the user key? Can the possessor of a ke…
That's always going to be a risk with second-hand devices (or even new devices). Who knows what kind sneaky things someone did to a device that they had long-term access to. You can never really totally trust something that you didn't build yourself from the ground up, so you always have to accept some level of risk.
That UI solution was just a random idea, I'm sure there are better ones. Like you said, it's a Hard Problem.
Earlier quoted context omitted.
IMEI can be recovered once you throw the sticker away. A private key that can be used to install new software cannot be recovered, or if it can that's a huge security risk.
The device should not have the private key loaded onto it at all, just the corresponding public key. The private key would only exist on the sticker and thus be unrecoverable if you threw it out or destroyed it. The IMEI example was just to demonstrate the ability to slap a device-unique code + matching sticker on something during manufacturing at scale.
Earlier quoted context omitted.
So, as Linus controls the kernel, Lennart wants to control userspace?
I have a sneaking suspicion one day systemd is going to try to replace the gnu in gnu/linux.
Iirc, glibc used to be maintained by a RH guy until he got on so many people's wrong side there was fork made that ran for a number of years until the original was merged into it and the fork renamed.