On Fri, Jan 31, 2020 at 11:39:32AM +0100, Johnny Billquist wrote:
> On 2020-01-31 11:34, Manuel Bouyer wrote:
> > On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote:
> > > On 2020-01-31 10:25, yarl-bau...@mailoo.org wrote:
> > > > That's exactly the answer I was waiting and hoping for. Thank you.
> > > >
> > > > I'll follow tech-pkg from now on. Packages must be signed.
> > >
> > > And with that signature, you know that what you got from the server was
> > > not
> > > tampered with during transport to you, which is the same thing https would
> > > give you. And which still means you have no idea if the software is sane,
> > > proper, does what you think, or hasn't been tampered with.
> >
> > No it's not the same thing.
> > package signature guarantees that the data have not been modified since it
> > has been built.
> > https guarantees that the data have not been modified between the http
> > server
> > and client. It doesn't tell anything about what happened to the binary pkg
> > between the build server and the http server at the time you download it.
>
> Right you are. I was too fast and loose on that one.
>
> Signatures are better in that sense. However, you then also have to trust
> that the signature have not been altered along with a alteration of the
> package... So does a signature really tell you much at all? I guess if you
> then had signatures with public/private keys. But then again, that don't
> really work if you have multiple places doing builds, unless they then share
> the private key, but that in turn leads to the question about how private do
> you then think that key is?
Why would they have to share the same private key ?
You can trust multiple public keys, this is how other binary package managers
works.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
