tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: officially signed packages



Hi Pierre,

On Apr 6, 2014, at 18:37 , Pierre Pronchery <khorben%defora.org@localhost> 
wrote:
> Signed PGP part
>                       Hi Fredrik, tech-pkg@,
> 
> On 06/04/2014 17:58, Fredrik Pettai wrote:
> > On Jan 22, 2014, at 17:51 , Jeremy C. Reed <reed%reedmedia.net@localhost>
> > wrote:
> >> What do we need to do next to get officially signed packages?
> >>
> >> I saw the thread at
> >> http://mail-index.netbsd.org/pkgsrc-users/2013/08/30/msg018511.html
> >>
> >>
> >>
> Should we have some role account for GPG_SIGN_AS ?
> 
> I think that would be great. Some steps are probably necessary before
> we can provide signed packages by default though.
> 
> >> p.s. Should this ticket be closed? http://gnats.netbsd.org/48194
> 
> Thanks for the heads-up, I have just closed it.
> 
> > I noted that khorben@ committed (the final?) updates to pkgsrc
> > infrastructure, so it's time to resurrect this thread again.
> 
> :)
> 
> > What's the next step(s)?
> 
> I'd say one important thing is the ability to verify package
> signatures without relying on any package to be installed already.

Question: Could a signed package be installed etc. without verification easily? 
(treated as a unsigned package). This without needing to change the default 
behaviour/configuration of the pkg tools? There are a lot of older systems out 
there, and if a flag day could be avoided, it would be great...

> I think that's possible for X509-based signatures.

x509 doesn't sound appealing compared to GPG, from an "admin" PoV though… 
having to do the whole PKI-dance
But the benefit of having x509 is that it also works out of the box for most 
non-NetBSD platforms, if they also want to have verifiable signatures.
I guess this should be discussed some more before choosing path here…

> In the case of GPG
> signatures though, installing security/gnupg is currently required -
> and it obviously can't verify itself while installing.
>  
> Checking GPG signatures could however be done with netpgp(1) from
> base. It doesn't work out of the box yet, but it shouldn't be much
> work to achieve (?). Feel free to beat me to it in any case :)

I was about to ask that earlier. netpgp seems like the way forward (if GPG is 
chosen) now that it's in base…
What's the missing "link" from using netpgp, instead of gnupg?

> Once this done I feel like it should be possible to let official
> NetBSD releases default to signed binary packages, shipping the
> release with the GPG public key pre-installed (possibly in a distinct
> keyring), and then strictly checking the signatures by default.

I feel that a better/leaner approach would be to have the user decide if he/she 
wants to verify the signatures as first step.
(For instance, in the pkgsrc release announcement, include a short howto turn 
on package validation)

Other things to think of before that day: How long should the signature be 
valid?

> This may be problematic on slow architectures though, this will require
> testing on the slower models of each to ensure operations on packages
> are still usable - when installing in particular.

I don't think the main goal should be to have all architectures to have signed 
packages & validation turn on by default.
Why not let the port-maintainer(s) test/delegate testing and then decide.

> On a related note, the file format for signed packages isn't
> particularly great at the moment. It will probably make sense to
> re-design it at some point, but to me this is not a blocker.

Yes, I heard you talked about that. "ar" libraries, was it? 
Do you have any suggestions on a better format? What does other package systems 
do?

/P

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



Home | Main Index | Thread Index | Old Index