repos providing only md5 sums
tek at serverop.de
Fri Apr 1 23:00:36 UTC 2016
thanks for all the suggestions and effor all of you put into this
I newly created https://crux.nu/Wiki/SignedPorts 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
have changing committers per port (for core or vacation subtitutes
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
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
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 https://crux.nu/portdb). 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 it stays compatible, we can switch to it later, if circumstances may
require such a switch later on.
More information about the CRUX