FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 02-19-2012, 03:18 PM
Pierre Schmitz
 
Default Keyring package for real

Hello,

I'd like to push the creation of our keyring package. This package will
contain all gpg keys needed to verify our packages. First of all: if
you
disagree with everything I did: don't worry; I am fine if we end up
with
an entirely different solution but this should be a good start.

After talking to others I would sum up the design goals as:
* clear and transparent process; for the maintainer and users
* complete and verifiable history of changes
* has to work without any internet connection
* no magic, no binary blobs; keep it as simple as possible

As a result I created a git repo which is meant to store all
packager and master keys:
https://projects.archlinux.org/archlinux-keyring.git/ The advantage
over
putting these files directly into svn is that we could use a cleaner
layout with subdirs, sign tags and verify the source. The result is a
(signed) tarball which can be used in the actual package which would
contain additional logic. The keyids are exported from archweb. I
didn't
distinguish between developers and trusted users as pacman itself does
not know about this difference either. It also makes maintenance easier
when people move between these groups or are active in both of them.

A package prototype can be found at
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/archlinux-keyring
It is not in any repo yet but I hope to put something into [testing]
after a brief discussion. All this package does is installing/updating
all master and packager keys and add them to the pacman keyring.

Note that this does not set any trust level which is needed to actually
verify packages. The user has to trust (lsign) each of the master keys
to establish this. This is some kind of bootstrapping problem. Future
versions of our installer should take care of and do this
automatically during install.

To make live easier for our current users we could add a simple helper
script which displays the master keys and lsigns them after
confirmation. The best way to do this is to use gpg --import-ownertrust
which takes a simple text file of the format "<keyid>:<trustlevel>". I
wouldn't want to use a binary file here. It is important that users
always know what is going on.

To sum things up: The keyring package would install all needed keys and
contain a simple helper script to verify and trust the master keys. A
news item would then describe how to use this helper but also show
several
ways to verify the authenticity of the master keys.

Greetings,

Pierre

--
Pierre Schmitz, http://pierre-schmitz.com
 
Old 02-19-2012, 10:05 PM
Gaetan Bisson
 
Default Keyring package for real

[2012-02-19 17:18:51 +0100] Pierre Schmitz:
> As a result I created a git repo which is meant to store all
> packager and master keys:
> https://projects.archlinux.org/archlinux-keyring.git/ The advantage
> over
> putting these files directly into svn is that we could use a cleaner
> layout with subdirs, sign tags and verify the source. The result is a
> (signed) tarball which can be used in the actual package which would
> contain additional logic. The keyids are exported from archweb.

I do not understand the purpose of this tree. Actual key verification
happens when a user lsigns certain keys of their keyring, why do it
here? Our public key infrastructure can cope perfectly well with a
keyring package shipping corrupted keys, so long as users do some
verification before lsigning the master keys.

If you feel our public key infrastructure needs more security, it should
be added down in the infrastructure itself rather than convenience
layers such as the keyring package.

Since that tree duplicates information from archweb and data that I
thought we agreed to let keyservers handle, I would consider much
simpler and convenient to generate the list of packagers from archweb
and retrieve the corresponding keys from a keyserver as we go in the
build() function of the package. And there should be no need to manually
verify anything but the master keys: if there is, that would be a flaw
in GPG and/or the use pacman makes of it, not the keyring package.

Cheers.

--
Gaetan
 
Old 02-19-2012, 10:38 PM
Pierre Schmitz
 
Default Keyring package for real

Am 20.02.2012 00:05, schrieb Gaetan Bisson:
> I do not understand the purpose of this tree. Actual key verification
> happens when a user lsigns certain keys of their keyring, why do it
> here? Our public key infrastructure can cope perfectly well with a
> keyring package shipping corrupted keys, so long as users do some
> verification before lsigning the master keys.

Sure the verification in the update script is technically not needed.
This is more a QA check for the package maintainer. And I'd also think
it'll be good practice to ensure the the package only contains valid and
fully trusted keys.

> If you feel our public key infrastructure needs more security, it should
> be added down in the infrastructure itself rather than convenience
> layers such as the keyring package.
>
> Since that tree duplicates information from archweb and data that I
> thought we agreed to let keyservers handle, I would consider much
> simpler and convenient to generate the list of packagers from archweb
> and retrieve the corresponding keys from a keyserver as we go in the
> build() function of the package.

The keyids come from archweb (maybe we can have a simple export later).
We also download missing keys from the keyservers. Imho it's nice to
have a local copy independent from any third party services. But sure,
some of this design decisions are a matter of taste and we could even
change it as we go. Imho it's more important to concentrate things that
really matter here.

--
Pierre Schmitz, http://pierre-schmitz.com
 
Old 02-19-2012, 10:54 PM
Gaetan Bisson
 
Default Keyring package for real

[2012-02-20 00:38:33 +0100] Pierre Schmitz:
> Imho it's more important to concentrate things that
> really matter here.

I certainly agree with your design goals and basic package workflow; in
fact, Allan and I already posted isomorphic packages to this list and no
critics were made. Hence my discussing your specific tree and package.

--
Gaetan
 
Old 03-03-2012, 07:54 PM
Pierre Schmitz
 
Default Keyring package for real

Hi,

I have pushed an archlinux-keyring package into [testing] so we have
something real to talk about. I revised some of my initial ideas. The
package is compatible to pacman-key --populate; it seems gpg will also
just accept a keyring that is just a bunch of keys put into one file.

The remaining issues is the install script of the actual package. Atm I
run "pacman-key --init" on install and "--populate" on upgrade. Is there
a scenario where running init might not be a good idea? It wont increase
security to let users do this manually; even worse: people might just
not do it then. So I am going with a "works out-of-the-box" experience
here.

There are at least two problems with using pacman-key: It is extremely
verbose and it requires the keyring to be signed which will lead to a
bootstrapping problem. I started a thread about this on pacman-dev; so
if you have ideas why this signature check might not be useless let me
know there.

Greetings,

Pierre

--
Pierre Schmitz, http://pierre-schmitz.com
 
Old 03-04-2012, 03:38 AM
Allan McRae
 
Default Keyring package for real

On 04/03/12 06:54, Pierre Schmitz wrote:
> Hi,
>
> I have pushed an archlinux-keyring package into [testing] so we have
> something real to talk about. I revised some of my initial ideas. The
> package is compatible to pacman-key --populate; it seems gpg will also
> just accept a keyring that is just a bunch of keys put into one file.
>
> The remaining issues is the install script of the actual package. Atm I
> run "pacman-key --init" on install and "--populate" on upgrade. Is there
> a scenario where running init might not be a good idea? It wont increase
> security to let users do this manually; even worse: people might just
> not do it then. So I am going with a "works out-of-the-box" experience
> here.

There have been so many issues with people not generating enough entropy
to generate the initial key with "pacman-key --init" that I am not so
sure that this is a good idea.

Not that the revoke file is optional so you do not need to provide an
empty one.

> There are at least two problems with using pacman-key: It is extremely
> verbose and it requires the keyring to be signed which will lead to a
> bootstrapping problem. I started a thread about this on pacman-dev; so
> if you have ideas why this signature check might not be useless let me
> know there.

I will discuss pacman-key in the other thread. But we still have a
bootstrap issues here... What key is the package signed by? Users
will need to verify that key. I think this is the only case where a
package should be signed by one (or more) of the master keys.

I am finding it difficult to see how turning on signing in a current
system can be done both automatically and securely (with a new install,
setting up the keyring can be automatically done during install under
the assumption that the user verified the install media...). Telling
users to install a package that sets up their keyring without verifying
the signature of the package first seems like a failure at step one.

We could just create a news entry/wiki page with instructions on setting
up the keyring. something like:

pacman-key --init
wget $(pacman -Sp archlinux-keyring){,.sig}
pacman-key --revc-keys <keys> (key IDs need widely published)
pacman-key --verify archlinux-keyring-2012*-1-any.pkg.tar.xz.sig
pacman -U archlinux-keyring-2012*-1-any.pkg.tar.xz

Allan
 
Old 03-04-2012, 08:59 AM
Pierre Schmitz
 
Default Keyring package for real

Am 04.03.2012 05:38, schrieb Allan McRae:
> On 04/03/12 06:54, Pierre Schmitz wrote:
>> Hi,
>>
>> I have pushed an archlinux-keyring package into [testing] so we have
>> something real to talk about. I revised some of my initial ideas. The
>> package is compatible to pacman-key --populate; it seems gpg will also
>> just accept a keyring that is just a bunch of keys put into one file.
>>
>> The remaining issues is the install script of the actual package. Atm I
>> run "pacman-key --init" on install and "--populate" on upgrade. Is there
>> a scenario where running init might not be a good idea? It wont increase
>> security to let users do this manually; even worse: people might just
>> not do it then. So I am going with a "works out-of-the-box" experience
>> here.
>
> There have been so many issues with people not generating enough entropy
> to generate the initial key with "pacman-key --init" that I am not so
> sure that this is a good idea.

I don't know. This is a problem on servers and VMs. But yes, I can also
just remove the --init part so people have to call it manually the first
time.

> Not that the revoke file is optional so you do not need to provide an
> empty one.

Probably a matter of taste, but I thought it might be good to be
explicit here and ship an empty file.

>> There are at least two problems with using pacman-key: It is extremely
>> verbose and it requires the keyring to be signed which will lead to a
>> bootstrapping problem. I started a thread about this on pacman-dev; so
>> if you have ideas why this signature check might not be useless let me
>> know there.
>
> I will discuss pacman-key in the other thread. But we still have a
> bootstrap issues here... What key is the package signed by? Users
> will need to verify that key. I think this is the only case where a
> package should be signed by one (or more) of the master keys.
>
> I am finding it difficult to see how turning on signing in a current
> system can be done both automatically and securely (with a new install,
> setting up the keyring can be automatically done during install under
> the assumption that the user verified the install media...). Telling
> users to install a package that sets up their keyring without verifying
> the signature of the package first seems like a failure at step one.

I thought about this and came to the same conclusion as you at first.
One problem is that you simply cannot switch from an untrusted system to
a trusted one. If your system is alreaady compromized you can verify as
much as you like; the only way is to reinstall from scratch. So security
wise it does note make sense to treat that keyring package any different
than the ones you already have installed. If we make this step
artificially hard most people will just disable signature checks and
that is most likely not what we wanted.

So my suggestion is to make it reasonable easy to install the keyring
package but most important document how it works and what the security
issues are. And yes, we should also include some brief steps to verify
the signature of the keyring package itself for those who care about
that. We can also describe how to isntall and verify the master keys
manually.

Using the master keys to sign the keyring package is probably not a
good idea. Technically it is not needed as pacman will accept it if it's
just signed by one of the or by a packager key. It just complicates our
maintenance a lot.

Summing up: I think we should make it as easy as possible for users to
setup their keyring, but also be very transparent about what is going on
and how to optionally verify each step manually. A good measure to
decide if a certain step in the process is reasonable to increase
security or just annoying to the user is to ask yourself if a malicious
package would have to do it as well.

Greetings,

Pierre

--
Pierre Schmitz, http://pierre-schmitz.com
 
Old 04-07-2012, 06:25 PM
Pierre Schmitz
 
Default Keyring package for real

Hi all,

with pacman 4.0.3 in [testing] and as all repos are now completely
signed we should have everything we need to finalize the keyring
package. The archlinux-keyring package in [testing] should update your
pacman keyring or ask you to initialize it first. It will then ask you
for each master key to confirm it's trust.

What is left to do?
* Maybe have pacman depend on archlinux.keyring
* Set "SigLevel = Required" for all our repos in our default
pacman.conf
* Write a news item which describes the steps how to setup your pacman
keyring (entropy problem should be covered) and how to install our
keyring package
* Think about if we should advice to start with a new keyring for those
who already had used "SigLevel = TrustedOnly" and therefor imported and
trusted individual keys. E.g. what happens if we revoke just a key etc..

PS: If you like to test several scenarios you can simply move
/etc/pacman.d/gnupg.

Greetings,

Pierre

--
Pierre Schmitz, https://pierre-schmitz.com
 

Thread Tools




All times are GMT. The time now is 11:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org