3 ms·

There actually is a good bit of problem with this method even in the browser space. For one, which key do you bundle? If it's a central root key see the part a

There actually is a good bit of problem with this method even in the browser space. For one, which key do you bundle? If it's a central root key see the part about Linux as that's essentially what they do. Also the part about not having the work force that the for profit CA vendors have is relevant here too.

peterwwillis 13y ago
tl;dr no, there is no problem with it in the browser space Step 1. Red Hat creates a CA and ships key with OS. Step 2. Red Hat creates a keystore that allows any developer to add their own key. Step 3. Package is created.[1] Step 4a. Package is signed by Red Hat when they create the package.[2] Step 4b. If 4a not followed, Package is signed by the package creator using their key from the Red Hat keystore. Step 5. User downloads package. Step 6. User installs package. Package signature is verified.[3] [1] As with all Linux distros, packages are either created/approved by a distribution release manager or made by 3rd parties completely independent of the distro. [2] Just like with browsers and certs, you can install a 3rd-party CA for a 3rd-party package if you want, but the key distribution is left up to the user to do safely. Most people don't do this. [3] Again, just like with browsers and certs, a package signature is either signed by a CA or by a developer. If it's CA-signed, the OS already has the cert, and it is verified. If it's developer-signed, the developer's public cert is shipped with the package. Some crypto math tells you whether this developer cert was created by the CA or is a phony. Red Hat can do this for virtually no cost; they just need to host a public web service that lets you create a signed key. They already host tons of free public services, so I don't see how this would be an issue for them. Not to mention someone could host a distro-independent service that does this exact same thing, and every distro could include its CA. The only "problem" here is people have wacky expectations of trust. Bob creates a distro, Sally creates some software, and Frank creates a package of the software for the distro. You have to trust all three of them - which you can do by accepting all of their signed keys. But realize that there is no "easy" way to trust Frank. Frank's essentially a stranger. We don't trust Frank in the browser world, so I don't know why we're expected to trust him with our packages.

peterwwillis 13y ago

tl;dr no, there is no problem with it in the browser space Step 1. Red Hat creates a CA and ships key with OS. Step 2. Red Hat creates a keystore that allows any developer to add their own key. Step 3. Package is created.[1] Step 4a. Package is signed by Red Hat when they create the package.[2] Step 4b. If 4a not followed, Package is signed by the package creator using their key from the Red Hat keystore. Step 5. User downloads package. Step 6. User installs package. Package signature is verified.[3] [1] As with all Linux distros, packages are either created/approved by a distribution release manager or made by 3rd parties completely independent of the distro. [2] Just like with browsers and certs, you can install a 3rd-party CA for a 3rd-party package if you want, but the key distribution is left up to the user to do safely. Most people don't do this. [3] Again, just like with browsers and certs, a package signature is either signed by a CA or by a developer. If it's CA-signed, the OS already has the cert, and it is verified. If it's developer-signed, the developer's public cert is shipped with the package. Some crypto math tells you whether this developer cert was created by the CA or is a phony. Red Hat can do this for virtually no cost; they just need to host a public web service that lets you create a signed key. They already host tons of free public services, so I don't see how this would be an issue for them. Not to mention someone could host a distro-independent service that does this exact same thing, and every distro could include its CA. The only "problem" here is people have wacky expectations of trust. Bob creates a distro, Sally creates some software, and Frank creates a package of the software for the distro. You have to trust all three of them - which you can do by accepting all of their signed keys. But realize that there is no "easy" way to trust Frank. Frank's essentially a stranger. We don't trust Frank in the browser world, so I don't know why we're expected to trust him with our packages.