Hello, thanks for all the suggestions and effor all of you put into this disucssion. 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 harm 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 repo). This buys us the huge advantage of not having to carry that large behemoth called gnupg and all its dependencies with us. I fully trust the people with access to the official repos and or the server 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 individually 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 and 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 the portdb mainainters (compare to https://crux.nu/portdb). Uses then can download 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, Thomas