Re: pkgsrc binary packages security with pkgin

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2020-01-31 12:32, Johnny Billquist wrote:
> On 2020-01-31 12:07, Manuel Bouyer wrote:
> > 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-baudig%mailoo.org@localhost 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.
>
> Of course you can. But then you need to have a whole list of trusted 
> public keys that needs to be managed, which again leads to the question 
> of which keys are now the acceptable ones. And how to you trust new 
> builders? Can anyone then be added to the list of official builders of 
> packages, or how to you manage that side?
> Key management is not trivial.

And this of course also leads to the question, can you trust all of them 
to properly maintain security of their systems? Too many accepted keys 
eventually leads to them not giving any security at all. And as soon as 
a system is compromised, all the packages built there is potentially 
compromised. Not to mention that the key should be considered 
compromised, and needs to be revoked. And all systems needs to no longer 
accept that key, which then is also a piece of information that needs to 
be distributed and enforced. And how do you push such information 
without that also becoming an attack vector, meaning keys could be 
added/revoked by the wrong people, or just with the wrong data.

Same thing as with anything sensitive. Too many have access and it's 
most likely compromised somewhere.

Me paranoid? Not really... :-)

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol