On 2016-03-29 01:02, Thomas Penteker wrote:
Hello,
On 28.03.2016 19:50, rain1@openmailbox.org wrote:
On 2016-03-23 06:38, Erich Eckner wrote:
On 21.03.2016 21:36, Dutch Ingraham wrote:
On Mon, Mar 21, 2016 at 08:31:00AM +0100, Thomas Penteker wrote:
To fill the missing link to providing integrity and confidentiality, we should start cryptographically signing ports on the maintainer's side and check these signatures before building/downloading anything.
regards, Thomas
Yes, please.[1]
[1] blog.linuxmint.com/?paged=2 (...) I would like to recommend the signify tool: http://www.openbsd.org/papers/bsdcan-signify.html
It's very high quality and simple. Could be useful for building this package signing system.
I put up a proposal/implementation documentation of my efforts to bring signed ports to CRUX using signify. It can be found at https://crux.nu/Wiki/SignedPorts which also containts the steps required to test drive the new functionality.
I'd like to move quickly as things look pretty usable and stable, also please comment.
best regards, Thomas _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
Nice to use signify and sha256, good strong primitives. A shame to have to manage a fork of signify, I wonder if the openbsd project would accept the changes to allow that program to become portable to both openbsd and linux? I agree that integrity and authenticity are the important security goals here. Often you would think of a person having a key. The proposal here is that the repo itself has a key, I think that is a good idea because it's important that the keys be rotated instead of lasting for very long periods of time. This could be done in the same way as explained in the BSD whitepaper - A key is invalidated after 2 releases. New keys are included in each release which establishes a trust chain. It might be good to have one 'master key' which signs all of the subkeys. Is that what core does? This lets us reduce all the trust chains down to one. That way the public key for that can be posted to various places (e.g. separate sites, included in emails, each extra way it is shared decreases the chance of it being substituted by an attacker) and we don't need to rely on HTTPS alone. One thing sounds a little dangerous "ignoring md5sums but falling back to these if no .signature file is present." This might open up to a downgrade attack unless it is just a temporary measure for transitioning to signing? Best of luck with rolling this out! It sounds like a really good improvement.