Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   CRUX (http://www.linux-archive.org/crux/)
-   -   Can we talk about package signing? (http://www.linux-archive.org/crux/672682-can-we-talk-about-package-signing.html)

Ryan Mullen 05-30-2012 03:07 PM

Can we talk about package signing?
 
Hi Crux,

In my (humble) opinion, package signing for Crux's ports system should
be seriously considered. It's a modern feature and is not too complex
to implement.

The advantages are twofold.

First, a "web of trust" can be developed between core (and opt,
contrib, whatever) ports maintainers so that there is some degree of
accountability for the origin of any given port.

Second, there is more assurance that a Pkgfile, footprint, or md5sum
wasn't modified without the port maintainer's knowledge.

The disadvantages include ports tree bloat (less than 1kB per port)
and a dependency on crypto software (gnupg probably).

Assuming we use something like gnupg's detached signatures, the
process could be entirely optional. Perhaps there could be a
configuration directive that controls whether the signatures are
downloaded, and/or whether they are actually verified. The ports
system would work just fine (and just as it does now) if the user
chooses to do neither.

As a quick example, to create a detached signature, the port
maintainer would do this:

gpg --output portname.asc --detach-sig --armor Pkgfile .footprint .md5sum

And to verify, a user would do this:

gpg --verify portname.asc Pkgfile .footprint .md5sum

They would first need to import the public keys of the port
maintainers, done like this:

gpg --recv-keys $KEYID

The $KEYID is given if a verification is attempted on a signature for
which a public key does not exist. The --recv-keys option downloads
the public key from a keysesrver and imports it automatically.
Alternatively, Crux could ship the public keys of port maintainers so
that this step could be omitted.

One little caveat is that the list of files for signature creation and
verification must always appear in the same order.

Anyway, I think some discussion is called for.

Regards,
Ryan (rmull on IRC)
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux

bohoomil 05-31-2012 01:47 PM

Can we talk about package signing?
 
Hi Ryan.

On Wed, May 30, 2012 at 5:07 PM, Ryan Mullen <rmmullen@gmail.com> wrote:

> In my (humble) opinion, package signing for Crux's ports system should
> be seriously considered. It's a modern feature and is not too complex
> to implement.

A *package* and *ports* system are IMO two different things: the first is
a binary blob prepared for the end user by a responsible packager. The
latter is nothing but a bash script that you may use as-is to compile
the code yourself (and any Pkgfile you should IMO examine before using it).
Therefore, in the first case there's someone standing between you and
the source code, while in the other it's only the code and you. In both
cases the same code is used, but only in the first one someone other than
you is responsible for producing the binary. That's why the thing is
called *package signing*, because in the other case -- if I understand
it correctly -- there's actually nothing to sign. ;)

(A different thing is code signing, but that's the upstream's pain, not
port maintainer's.)

> Second, there is more assurance that a Pkgfile, footprint, or md5sum
> wasn't modified without the port maintainer's knowledge.

Well... .md5sum has very little to do with maintainer's job: basically
it proves that the source tarball you pull to build the package on your
system is the same the port maintainer used to create the Pkgfile. Other
files included in the port should be nothing but text files, and the
checksum should be enough to prove they are valid. Any other signing
here, even if possible, seems a bit superfluous because with a distro
like CRUX you should be able to verify if the script you run contains
malicious code or not.

> The disadvantages include ports tree bloat (less than 1kB per port)
> and a dependency on crypto software (gnupg probably).

The main disadvantage IMO is that the whole idea of *package* signing
doesn't improve the security of the *ports* system because it wasn't
meant to be used there. You can argue if the entire port can be signed
somehow, though this would require high level of correctness as far as
the content of .footprint files is concerned (among other things), and
those not always appear to follow the changes in the package content.

Besides, I decided to use CRUX because it allows for even further
package customization than other distros, and because I wanted to
compile the packages I use so that they fit my machine's specs (avoiding
at the same time 'universal' binaries: a binary is a convenient way
to go, but not always the best one). The simplicity of ports system improves
security by the way it works: making a package myself I know who should be
blamed if something doesn't work the way I wanted. :) And if the security
flow comes from the upstream, well, that's where package signing can't
help a lot really...

Anyway, the bottom line: let's verify the scripts we run before we
press Enter. For distros like CRUX it should be the default user action. ;)

Best regards,

bohoomil

_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux


All times are GMT. The time now is 05:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.