[haiku-development] Re: Design for signed packages
- From: Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 26 Mar 2014 22:49:02 +0100
Am 26.03.2014 um 22:29 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:
> How is supporting multiple algorithms in one format different from
> supporting different formats versions with one algorithm each in this
> respect? In either case the older algorithm can easily be disabled when it is
> no longer considered secure.
True, the difference would only be which field to use to indicate the
algorithm. I don't care about that too much.
> The signing algorithm is implied by the certificate (when using X.509
> certificates at least).
Well, if we want to use full blown X509 certificates, that is. Is there any
simpler standard?
>> You need to implement different algorithms, etc.
>
> We only need to implement the algorithms we want to support. If that is
> a single one ATM, that's fine. But we wouldn't have to change the format
> when adding another algorithm (respectively replacing the old one) later, if
> we add the necessary field(s) to handle different algorithms, now.
Agreed. The only difference between what you proposed and what I proposed is
which field stores the algorithm used, to more concrete whether the version
implies it or if it is an extra field.
> You're not even replying to what this argument thread is about. I'm
> criticizing the method you suggest for signing, not signing itself. And
> just to be clear, this applies to both signing packages and repositories.
So to summarize: Are you against signing individual hpkg or are you ok with it?
Because by now, I'm really confused.
>> OpenSSL does not work in the kernel-space / bootloader.
>
> Which isn't need, if we don't want to implement Secure Boot.
Yes, but if we do want to implement it at some point (because Windows 9
requires that SecureBoot can't be disabled - which wouldn't surprise me at all,
considering that's already the Windows 8 requirement for ARM), we'd have a
problem. So it might make sense to keep that in mind now even if we're not
going to implement it now.
> I wasn't talking about the signature algorithm itself, but the stuff
> around it, like the certificate format etc.
That's why I wanted to have basically no stuff around it :). The certificate
would just be the public key generated by Ed25519.
> So you delegate the trust for your immensely secure signing procedure to SSL?
> I suppose the key is published on the same website you got the package from?
I don't, but the user has the option to do that.
>> * Publish the key and sign it with PGP
>
> And the public PGP key is published alongside the certificate key?
The public key might be signed by someone you know. As I'm regularly at open
source events, I happen to have quite a few people in my PGP web of trust.
> It is rather difficult to find an independent channel. A trusted third-party
> website (authenticated via SSL again) that publishes the key signature, is
> probably the most realistic one. But why not have the website owner just sign
> the certificate in the first place? Then the user gets that information
> already when trying to install the package.
Well, it might be difficult sometimes indeed. But it doesn't mean there are no
independent channels. My proposal basically allows the user to choose which
channels he trusts.
> You missed the part where the SSL root certificates are from entities I don't
> know, while a package certificate could be signed by an entity (or even
> multiple ones) I known and trust (e.g. Haiku, Inc.). In the latter case there
> wouldn't be any implicit trust delegation either.
And how do we determine who is trustworthy and who isn't? Should we audit their
code? Should we just believe them their trustworthy because they say so? Who's
responsible for it?
I think it's clear we can't audit it. And if we just believe anybody because he
claims to be trustworthy, it's no added security. Thus I fail to see the
advantage of that approach.
> No, it isn't. The problem is that certificates signed by no one provide the
> user with less information than certificates that are signed by someone they
> might trust.
>
> In principle the certificate signature(s) wouldn't even have to come with the
> certificate, but could be stored elsewhere (e.g. on the HaikuDepot website).
> That would, however, require internet access at the time of installation and
> would introduce a possible point of failure (website down/unreachable).
So what certificates would be able to sign others by default? What comes to
mind is Haiku Inc. But see the problem above. So I'm not really seeing how this
is an advantage.
Sure, we could implement it because theoretically, there could be an instance
which reviews all binaries in a disassembler and signs packages that are ok.
But we all know that won't happen, so I don't see much benefit in adding a lot
of complexity for a feature that in reality doesn't offer any additional
security. Signing something means you vouch for it being safe, which means you
take some kind of responsibility. I don't think Haiku Inc. wants to be
responsible for 3rd party packages, right?
--
Jonathan
Other related posts:
