-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Dimi,
Why remove the verification of the code's gpg signature? It seems to break a basic security maxim: don't trust the network.
On Thursday 10 June 2004 22:48, Dimitrie O. Paun wrote:
ChangeLog Do not include irrelevant stuff in the _history. Do not instruct the client to verify the .sig, it's a b0rken idea anyway.
- -- Paul Millar
We don't have a good way of distributing and managing the gpg keys, there is no script control over that part of winrash. If there was an automated and secure way of keeping the trusted signatures up to date I wouldn't mind turning it back on. It just has to be something that can be maintained without manual intervention with gpg. I'm also not really sure how the whole gpg signature thing works. Right now we bundle a config file for gpg that trusts your signature. Can we have that managed by the service so it happens automatically or does that implicitly violate the trust as we are getting the signature from the service initially?
Chris
On Friday 11 June 2004 9:49 am, Paul Millar wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Dimi,
Why remove the verification of the code's gpg signature? It seems to break a basic security maxim: don't trust the network.
On Thursday 10 June 2004 22:48, Dimitrie O. Paun wrote:
ChangeLog Do not include irrelevant stuff in the _history. Do not instruct the client to verify the .sig, it's a b0rken idea anyway.
Paul Millar -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAybhq/9JwS78PA+kRAuv/AJ9Ulntb1MLGn+2gp8r/qpy6VqJDVACePwVB VXxAHr9gaBuMhIJ7P81ahMA= =0tkh -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Chris,
Ultimately, all PKI suffers from the weakness that, unless you distribute the public keys out-of-band (e.g. via CDROM and recorded delivery), then you can't trust signatures.
Practically, with web browers (for example), what happens is certain public keys (of known CAs) are distributed with the software. Its fairly unlikely (but not impossible) that these are altered whilst someone's downloading their browser. Since that happens fairly rarely (less frequently than verifying a certificate), its fairly safe.
Much the same applies with the gpg config file which says to trust the key used for signing the binaries (id 651FD487). The config file *could* be modified in-flight (a la ettacap), modified on the website, or by a malicious packager (cue evil grin). But, if you trust the people involved and the integrity of the website, then its a pretty safe bet.
Moreover, the config file only needs to be downloaded when the winrash code is updated. This doesn't happen too often (compared to verifying the signature of winetest.exe) so for each set of binaries and the corresponding signature, the client should be able to confirm (with a good level of confidence) that the binary was generated on quisquiliae.
There's some additional level of confidence that comes from my having signed the code-signing key with my personal key. Other people have signed my personal key, so there should be a web-of-trust between the code-signing key and others out there. The truly paranoid could leaver that to garner additional trust :)
So, I believe downloading the gpg config file with winrash is equivalent to downloading CA public keys with a web-browser. Technically is bad, but practically is OK.
Alternatively, if you don't want to distribute the key, just tell gpg to download it from one of the key-servers out there, but that's (more-or-less) equivalent to distributing the key.
(phew, didn't mean for the email to get that big!)
Cheers,
Paul.
On Friday 11 June 2004 15:28, Chris Morgan wrote:
We don't have a good way of distributing and managing the gpg keys, there is no script control over that part of winrash. If there was an automated and secure way of keeping the trusted signatures up to date I wouldn't mind turning it back on. It just has to be something that can be maintained without manual intervention with gpg. I'm also not really sure how the whole gpg signature thing works. Right now we bundle a config file for gpg that trusts your signature. Can we have that managed by the service so it happens automatically or does that implicitly violate the trust as we are getting the signature from the service initially?
Chris
On Friday 11 June 2004 9:49 am, Paul Millar wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Dimi,
Why remove the verification of the code's gpg signature? It seems to break a basic security maxim: don't trust the network.
On Thursday 10 June 2004 22:48, Dimitrie O. Paun wrote:
ChangeLog Do not include irrelevant stuff in the _history. Do not instruct the client to verify the .sig, it's a b0rken idea anyway.
Paul Millar -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAybhq/9JwS78PA+kRAuv/AJ9Ulntb1MLGn+2gp8r/qpy6VqJDVACePwVB VXxAHr9gaBuMhIJ7P81ahMA= =0tkh -----END PGP SIGNATURE-----
- ---- Paul Millar
On Fri, Jun 11, 2004 at 02:49:21PM +0100, Paul Millar wrote:
Why remove the verification of the code's gpg signature? It seems to break a basic security maxim: don't trust the network.
Because the current implementation is b0rken, and it just gives us a false sense of security. If we can't trust the network: -- why do we trust the script to tell us to do the verification?!? If anything, we would have to automatically always do the verification, not have a command for it. So a command of download url.foo should implicitily generate a download url.foo.sig gpgverify url.foo.sig
-- also, why do we trust the script at all? We should also always sign and verify every time the script. But this will make it rather inconvenient to work with... Oh well, we'll do it if we must. But we have to be careful to NOT accept downloads signed my WineHQ (the sig used to sign the script), because if WineHQ is hacked, all bets are off. In other words, we should trust only human signatures for file download. I'm not sure how easily all this can be implemented in winrash.
In any event, those two lines in the script that I've removed are not the answer. For now I guess we can trust the network.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Dimi,
I think most security software gives a false sense of security, because a lot of security problems happen at a ISO-OSI layer 9 (the nut behind the wheel :)
With network security, any activity implies at least some trust. The script wasn't brilliant, but pushing the functionality into winrash doesn't really solve the problem: we'd still need to verify the binaries somehow, or just trust that the binaries are OK.
But, in the mean time, I'll continue generating the sig files (as it happens automatically) so future gpg verification-code has something to test against.
Cheers,
Paul.
On Friday 11 June 2004 22:16, Dimitrie O. Paun wrote:
On Fri, Jun 11, 2004 at 02:49:21PM +0100, Paul Millar wrote:
Why remove the verification of the code's gpg signature? It seems to break a basic security maxim: don't trust the network.
Because the current implementation is b0rken, and it just gives us a false sense of security. If we can't trust the network: -- why do we trust the script to tell us to do the verification?!? If anything, we would have to automatically always do the verification, not have a command for it. So a command of download url.foo should implicitily generate a download url.foo.sig gpgverify url.foo.sig
-- also, why do we trust the script at all? We should also always sign and verify every time the script. But this will make it rather inconvenient to work with... Oh well, we'll do it if we must. But we have to be careful to NOT accept downloads signed my WineHQ (the sig used to sign the script), because if WineHQ is hacked, all bets are off. In other words, we should trust only human signatures for file download. I'm not sure how easily all this can be implemented in winrash.
In any event, those two lines in the script that I've removed are not the answer. For now I guess we can trust the network.
-- Dimi.
On Tue, Jun 15, 2004 at 05:14:46PM +0100, Paul Millar wrote:
With network security, any activity implies at least some trust. The script wasn't brilliant, but pushing the functionality into winrash doesn't really solve the problem: we'd still need to verify the binaries somehow, or just trust that the binaries are OK.
Yes, we need to verify them, but not before we verify the script. Otherwise, it's much easier to feed us a hacked script...
But, in the mean time, I'll continue generating the sig files (as it happens automatically) so future gpg verification-code has something to test against.
Sure, that can't hurt, maybe one day we'll use it.
-
Chris Morgan -
Dimitrie O. Paun -
Paul Millar