On Mon, Mar 12, 2012 at 1:11 AM, David Barrera <[email protected]> wrote: > I've been following this mailing list and thought I should chime in on > the topic of digital signatures for apps. > > On Sun, Mar 11, 2012 at 8:20 PM, lkcl luke <[email protected]> wrote: >> jonas. i'm a bit shocked and taken aback that you're saying this. >> do you understand why the debian project has the infrastructure that >> it has? >> >> this is *important*, jonas. >> >> if you do not understand what jim is referring to, and you are going >> to be the person in charge of implementing the security of B2G please >> for god's sake do some research into why debian digitally-signs all >> packages. >> >> you've come up with some absolutely fantastic ideas on the issue of >> B2G security but if you are, as you say, "not a big believer in code >> signing" this is a really big alarm bell. >> >> the simple version is: the reason why debian digitally signs each >> individual package is to ensure that malicious packages cannot be >> installed [on an uncompromised unmodified system]. >> > > Debian signs packages so that they can use mirrors to distribute > updates. Some mirrors might use http, some mirrors may be malicious, > some mirrors may be defective and exhibit file corruption. Digitally > signing each file allows client software to verify that the packages > originated from Debian, and that they haven't been modified in > transit. If Debian decides to package up malware (intentionally or > not), digital signatures will still verify. Signing is used for > authentication, not malware prevention.
no it's more than that. it's good that you've described this, but it's not the whole picture. > It is trivial to remove a signature from a package and re-sign it with > a different key. yes but you've missed the point. it is *not* trivial to sign it with the ftp master's private key, is it? not only would you have to compromise the package maintainer's private key, but also you would need to compromise the ftp master's private key, which is actually distributed across N out of M different people. also, those people are absolutely paranoid about where they keep it. there is actually a weaker link in the chain: you compromise the person's machine and you disable the public key checking. or, you add an extra line to /etc/apt/sources.list _and_ add a keychain package which contains the "illegitimate" public key from the malwared site. but that requires that you actually compromise the person's machine, first! bottom line: the setup is a bit more sophisticated that it first appears, and it definitely fulfils the requirements raised by .... by... arg, going back through a few messages.... jim! yes. definitely solves the issues raised by jim. l. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
