repos providing only md5 sums

Thomas Penteker tek at
Fri Apr 1 23:00:36 UTC 2016


thanks for all the suggestions and effor all of you put into this 
I newly created please review at your
convenience, as the previous version was lost in the fire.

On 29.03.2016 03:30, Ryan Mullen wrote:
> A few questions:
> 1. Signify currently produces a build warning about an implicit
> declaration of function 'getentropy.' Am I missing something? Surely
> the crux fork is not the only portable fork of signify - what are we
> doing in ours that's special and requires a custom fork?

I fixed the other ones but was to lazy to fix that, too. It does not do 
and may be eliminated later.

> 2. I think I feel a little strange about the inability to navigate the
> web of trust using signify keys. With this model, there is a master
> private key that is shared by all with repo commit access or
> administrative access to the crux server. This is a liability in that
> now there are many people who could potentially mishandle the key.
> With standard PGP keys, devs need only be responsible for their own
> keys, and we could generate a web of trust by which users can be sure
> that their packages were actually signed by a trusted dev. A single
> compromised developer key doesn't automatically compromise every
> single package in a repo with multiple committers. With signify, it
> seems like the user can be sure that their packages were signed by
> whoever controls the crux server, but that may not necessarily be a
> friendly individual.

There is no web of trust because there are two parties involved (per 
This buys us the huge advantage of not having to carry that large 
called gnupg and all its dependencies with us.

I fully trust the people with access to the official repos and or the 
to handle things carefully. Key sharing is necessary in the sense that 
we may
have changing committers per port (for core or vacation subtitutes 
etc.). If
you truest dev A's and B's anyway, where is the point to signing 
in one repo? Key rolling is thought through and planned as described in 
my new
wiki post.
Also note, that we split keys on a per repo basis.

> 3. There is no key revocation support - what happens if the repo key
> is compromised?

Ports updates will revoke keys. And yes, core/ports is implicitly 
trusted. We
could sign that with a dedicated key that will be switched only manually 
on due notice. I do not really like that process because it requires
intervention. Revocation is described in the wiki.

> 4. How might 3rd-party repos set up signed packages for themselves?
> Would it just be a matter of figuring out how to distribute their
> repo's pubkey? How can they reliably rotate the keys, if they can't
> get their keys into the core port?

Just as we did for the official repos and by sending the public key to 
portdb mainainters (compare to Uses then can 
the key file and put it in /etc/ports.

Wrt minisign, I am happy with the current state of my signify fork and 
as long
as it stays compatible, we can switch to it later, if circumstances may
require such a switch later on.

best regards,

More information about the CRUX mailing list