repos providing only md5 sums
Hello, I noticed that crux mirrors only provide md5 hashes for verification. I recommend moving to sha256 which is a secure hash function. md5 is not a secure hash function any longer as it has several weaknesses that are not expected of a hash [1]. There are a couple instances of it being exploited in serious situations in the real world, for example [2] and [3]. Collisions can be forged on a home computer today [4]. These sort of attacks do not directly affect the way the hash is used in crux but they do demonstrate weakness in md5. I think this gives a strong case for depreciating its usage. There was a bug report about this 8 years ago which was closed <https://crux.nu/bugs/index.php?do=details&task_id=223>. If people agree in this thread then maybe that bug report could be re-opened. Thank you * [1] https://www.kb.cert.org/vuls/id/836068 * [2] https://www.win.tue.nl/hashclash/rogue-ca/ * [3] https://www.trailofbits.com/resources/flame-md5.pdf * [4] http://natmchugh.blogspot.co.uk/2014/10/how-i-created-two-images-with-same-m...
On Sun, Mar 20, 2016 at 4:34 AM, <rain1@openmailbox.org> wrote:
These sort of attacks do not directly affect the way the hash is used in crux but they do demonstrate weakness in md5. I think this gives a strong case for depreciating its usage.
This is exactly why it's "okay" to continue to use MD5 hashing in this particular use-case. It is only used to verify the integrity of sources of a port as specified in a Pkgfile. Whilst changing to sha256sums is probably trivial; it probably doesn't really buy much in terms of "security" (since we're not using md5 for security purposes). cheers James James Mills / prologic E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au
On 21.03.2016 04:27, James Mills wrote:
Whilst changing to sha256sums is probably trivial; it probably doesn't really buy much in terms of "security" (since we're not using md5 for security purposes).
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
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
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
Hi, I think, we should definitely allow for signing and verification. However: what's a useful approach for checking Pkgfiles? It's not pkgmk's job, because we want to be able to edit the file. So I think, "ports -u" should check the signature of Pkgfile and pkgmk the ones of the sources? On the other hand: I just noticed, that '--no-check-certificate' is passed as an argument to wget. Why isn't assumed, that a proper certificate is installed? Can this be configured somewhere? cheers, Erich
On Wed, Mar 23, 2016 at 07:38:37AM +0100, 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.
I think, we should definitely allow for signing and verification. However: what's a useful approach for checking Pkgfiles? It's not pkgmk's job, because we want to be able to edit the file. So I think, "ports -u" should check the signature of Pkgfile and pkgmk the ones of the sources?
The current idea is to have git commits signed. This would sign the sha256 checksum and a "trusted" chain is established. we will obviously lose this when syncing ports with rsync since only files are synced. This needs to be solved.
On the other hand: I just noticed, that '--no-check-certificate' is passed as an argument to wget. Why isn't assumed, that a proper certificate is installed? Can this be configured somewhere?
Iirc thats not a default setting. It can be changed in /etc/pkgmk.conf: PKGMK_WGET_OPTS="" -- Fredrik Rinnestam
On 23.03.2016 09:58, Fredrik Rinnestam wrote:
On Wed, Mar 23, 2016 at 07:38:37AM +0100, 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.
I think, we should definitely allow for signing and verification. However: what's a useful approach for checking Pkgfiles? It's not pkgmk's job, because we want to be able to edit the file. So I think, "ports -u" should check the signature of Pkgfile and pkgmk the ones of the sources?
The current idea is to have git commits signed. This would sign the sha256 checksum and a "trusted" chain is established.
This sounds like a much cleaner solution than signing every individual file.
we will obviously lose this when syncing ports with rsync since only files are synced. This needs to be solved.
Maybe, the hash and signature can be added to the synced files (of course not versioned in git). I don't know the details of the hashing in git, but in the end it's a hash of hashes of the files (and file permissions, locations, ...) and some extra information like commit message and parents? So given the extra info, one would be able to calculate the hash "by hand" and verify the signature? I know, it sounds hackish - probably not a good idea :-/
On the other hand: I just noticed, that '--no-check-certificate' is passed as an argument to wget. Why isn't assumed, that a proper certificate is installed? Can this be configured somewhere?
Iirc thats not a default setting. It can be changed in /etc/pkgmk.conf: PKGMK_WGET_OPTS=""
I didn't have any PKGMK_WGET_OPTS defined in /etc/pkgmk.conf (nor in the Pkgfile), also setting PKGMK_WGET_OPTS="" explicitely didn't change anything :-/ cheers, Erich
On Wed, Mar 23, 2016 at 10:29:44AM +0100, Erich Eckner wrote:
On 23.03.2016 09:58, Fredrik Rinnestam wrote:
On Wed, Mar 23, 2016 at 07:38:37AM +0100, 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.
I think, we should definitely allow for signing and verification. However: what's a useful approach for checking Pkgfiles? It's not pkgmk's job, because we want to be able to edit the file. So I think, "ports -u" should check the signature of Pkgfile and pkgmk the ones of the sources?
The current idea is to have git commits signed. This would sign the sha256 checksum and a "trusted" chain is established.
This sounds like a much cleaner solution than signing every individual file.
we will obviously lose this when syncing ports with rsync since only files are synced. This needs to be solved.
Maybe, the hash and signature can be added to the synced files (of course not versioned in git). I don't know the details of the hashing in git, but in the end it's a hash of hashes of the files (and file permissions, locations, ...) and some extra information like commit message and parents? So given the extra info, one would be able to calculate the hash "by hand" and verify the signature?
I know, it sounds hackish - probably not a good idea :-/
On the other hand: I just noticed, that '--no-check-certificate' is passed as an argument to wget. Why isn't assumed, that a proper certificate is installed? Can this be configured somewhere?
Iirc thats not a default setting. It can be changed in /etc/pkgmk.conf: PKGMK_WGET_OPTS=""
I didn't have any PKGMK_WGET_OPTS defined in /etc/pkgmk.conf (nor in the Pkgfile), also setting PKGMK_WGET_OPTS="" explicitely didn't change anything :-/
cheers, Erich
Yeah I just noticed its hard-coded in pkgmk. You could switch to curl instead - dont think it's hardcoded there. I'll open up a bugreport for the wget issue -- Fredrik Rinnestam
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
Hi,
I think, we should definitely allow for signing and verification. However: what's a useful approach for checking Pkgfiles? It's not pkgmk's job, because we want to be able to edit the file. So I think, "ports -u" should check the signature of Pkgfile and pkgmk the ones of the sources?
On the other hand: I just noticed, that '--no-check-certificate' is passed as an argument to wget. Why isn't assumed, that a proper certificate is installed? Can this be configured somewhere?
cheers, Erich _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
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.
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
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.
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? 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. 3. There is no key revocation support - what happens if the repo key is compromised? 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? I think at the moment I like the idea of git signed commits a little better, but it would require ports to be distributed via git rather than rsync. Perhaps I just don't fully understand the signify model yet. rmull
On Mon, 28 Mar 2016 21:30:23 -0400 Ryan Mullen <rmmullen@gmail.com> 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?
https://github.com/chneukirchen/signify I haven't tested it yet, but I've had good luck with his cwm port in the past. Cheers, John
On 2016-03-31 13:46, John Vogel wrote:
On Mon, 28 Mar 2016 21:30:23 -0400 Ryan Mullen <rmmullen@gmail.com> 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?
https://github.com/chneukirchen/signify
I haven't tested it yet, but I've had good luck with his cwm port in the past.
Cheers, John _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
There are a lot of ports of signify to linux (also a reimplementation in Go and a 'mini' version): * https://github.com/aperezdc/signify * https://github.com/vstakhov/asignify * https://github.com/ebfe/signify * https://github.com/chneukirchen/signify * https://github.com/Blitznote/signify * https://github.com/nurse/signify * https://github.com/vstakhov/asignify * https://github.com/stoeckmann/signify-windows * https://www.fefe.de/signify/ * https://jedisct1.github.io/minisign/ Distros seem to have (unofficial) packages that point to aperezdc's version: * https://aur.archlinux.org/packages/signify/ * https://packages.debian.org/source/sid/signify-openbsd * https://gpo.zugaina.org/app-crypt/signify The version by chneukirchen looks good - especially because it was pulling in all the new changes from upstream, aperezdc did not seem to do that? - although he just recently marked it as unmaintained and is now: * https://github.com/chneukirchen/outils The situation is still not ideal but using outils seems like a fine idea for now.
On Tue, 29 Mar 2016 01:58:22 +0100 rain1@openmailbox.org wrote:
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?
Minisign (https://jedisct1.github.io/minisign/) is compatible with signify, but it depends on libsodium and cmake. Syntax and usage is pretty much the same, afaict. " Compatibility with OpenBSD signify Signature written by minisign can be verified using OpenBSD's signify tool: public key files and signature files are compatible. However, minisign uses a slightly different format to store secret keys. Minisign signatures include trusted comments in addition to untrusted comments. Trusted comments are signed, thus verified, before being displayed. This adds two lines to the signature files, that signify silently ignores. " Pedja
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
* Thomas Penteker (tek@serverop.de) wrote:
Hello, (...)
I forgot to add, that we can make core/ports download the keys on each build to make sure that they are current (vs. distributing them via the ports tree). This assumes that they are sent via a host with a valid certificate. We could also add multiple sources and compare multiple versions but paranoia can get really messy really soon (what about modified cat/sha*/md5sum binaries during comparison etc.). regards, Thomas
participants (9)
-
Dutch Ingraham -
Erich Eckner -
Fredrik Rinnestam -
James Mills -
John Vogel -
Predrag Ivanovic -
rain1＠openmailbox.org -
Ryan Mullen -
Thomas Penteker