[haiku-development] Re: Design for signed packages
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 30 Mar 2014 17:17:17 +0200
On 26.03.2014 22:49, Jonathan Schleifer wrote:
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?
I haven't researched that. In userland, openssl would do all the work
for us anyway. Should we need them in the kernel and/or boot loader all
we need to do is read the certificate and extract the key (i.e.
implement a basic CER/DER parser). We wouldn't have to interpret all
extensions etc.
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.
As I explained on the haikuports-svn list, I haven't really made up my
mind yet.
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.
This doesn't have anything to do with signing packages, though, only
with signing the boot loader. And for that we are even bound by whatever
the UEFI standard requires.
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 :).
Yes, that's the problem. Not having anything around it that makes it
practical.
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.
That's good for you. Then you have a few people from which you can
install software (I wonder how many Haiku developers are among those --
certainly not me).
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.
Yes, you could always visit the package signer in person. But that's
impractical, as are (at least for most people) the alternatives that
don't just reduce the security to trusting SSL certificates anyway.
My proposal basically allows the
user to choose which channels he trusts.
Your proposal does not allow the user to do anything. It *forces* them
to find an independent channel to verify the authenticity of the
certificate, which in many cases simply won't be possible, unless you
delegate the trust to SSL certificates.
CU, Ingo
Other related posts:
