Hi all,
In doing my part in getting us away from PGP, at least in areas where its use is overkill or a bad idea [1], I packaged Minisign [2] for Fedora and CentOS [3]. It is currently available in the stable repositories on Fedora >= 30 and EPEL.
The wiki currently describes the procedure to verify source downloads using PGP (GnuPG) [4]. I'd like to propose an added section/extension to also mention Minisign as a means to accomplish that. I wrote a blog post [5] on how I think it can be added to RPM spec files.
Is this something that we can add to the official Packaging documentation? I'd be willing to work on this! Any ideas, feedback?
Regards, François
[1] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html [2] https://github.com/jedisct1/minisign [3] https://apps.fedoraproject.org/packages/minisign [4] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_veri...
Hey Francois,
I suggest you bring this topic to devel@lists.fedoraproject.org first. AFAICT, not many people are subscribed here, so at devel you might catch someone's attention about this... :)
With regards,
Dee'Kej
On Mon, Aug 5, 2019 at 1:37 PM François Kooman fkooman@tuxed.net wrote:
Hi all,
In doing my part in getting us away from PGP, at least in areas where its use is overkill or a bad idea [1], I packaged Minisign [2] for Fedora and CentOS [3]. It is currently available in the stable repositories on Fedora >= 30 and EPEL.
The wiki currently describes the procedure to verify source downloads using PGP (GnuPG) [4]. I'd like to propose an added section/extension to also mention Minisign as a means to accomplish that. I wrote a blog post [5] on how I think it can be added to RPM spec files.
Is this something that we can add to the official Packaging documentation? I'd be willing to work on this! Any ideas, feedback?
Regards, François
[1] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html [2] https://github.com/jedisct1/minisign [3] https://apps.fedoraproject.org/packages/minisign [4]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_veri...
[5] https://www.tuxed.net/fkooman/blog/minisign.html _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
François Kooman wrote:
The wiki currently describes the procedure to verify source downloads using PGP (GnuPG) [4]. I'd like to propose an added section/extension to also mention Minisign as a means to accomplish that. I wrote a blog post [5] on how I think it can be added to RPM spec files.
Is this something that we can add to the official Packaging documentation? I'd be willing to work on this! Any ideas, feedback?
Do you know of any project that signs releases with Minisign? I've never seen one.
Personally, before I potentially use a new signing tool, I would like to know that some of the world's smartest cryptologists have analyzed it and found the design sound.
Björn Persson
On Thu, Aug 08, 2019 at 04:17:07PM +0200, Björn Persson wrote:
François Kooman wrote:
The wiki currently describes the procedure to verify source downloads using PGP (GnuPG) [4]. I'd like to propose an added section/extension to also mention Minisign as a means to accomplish that. I wrote a blog post [5] on how I think it can be added to RPM spec files.
Is this something that we can add to the official Packaging documentation? I'd be willing to work on this! Any ideas, feedback?
Do you know of any project that signs releases with Minisign? I've never seen one.
Personally, before I potentially use a new signing tool, I would like to know that some of the world's smartest cryptologists have analyzed it and found the design sound.
It seems to be compatible with OpenBSD's signify tool[0][1], which they have used for the past couple of releases; minisign seems to generate the same Ed25519 signatures.
Note that I'm just pointing to informational resources, not advocating for or against the use of minisign in any capacity.
G'luck, Peter
[0] https://man.openbsd.org/signify [1] https://www.openbsd.org/papers/bsdcan-signify.html
On Thu, Aug 08, 2019 at 06:19:43PM +0300, Peter Pentchev wrote:
On Thu, Aug 08, 2019 at 04:17:07PM +0200, Björn Persson wrote:
François Kooman wrote:
The wiki currently describes the procedure to verify source downloads using PGP (GnuPG) [4]. I'd like to propose an added section/extension to also mention Minisign as a means to accomplish that. I wrote a blog post [5] on how I think it can be added to RPM spec files.
Is this something that we can add to the official Packaging documentation? I'd be willing to work on this! Any ideas, feedback?
Do you know of any project that signs releases with Minisign? I've never seen one.
Personally, before I potentially use a new signing tool, I would like to know that some of the world's smartest cryptologists have analyzed it and found the design sound.
It seems to be compatible with OpenBSD's signify tool[0][1], which they have used for the past couple of releases; minisign seems to generate the same Ed25519 signatures.
Note that I'm just pointing to informational resources, not advocating for or against the use of minisign in any capacity.
G'luck, Peter
[0] https://man.openbsd.org/signify [1] https://www.openbsd.org/papers/bsdcan-signify.html
Also note that the signify tool itself, as used by OpenBSD, may be ported to Linux, or at least it has been ported to Debian: https://tracker.debian.org/pkg/signify-openbsd
G'luck, Peter
On 08.08.19 17:22, Peter Pentchev wrote:
Also note that the signify tool itself, as used by OpenBSD, may be ported to Linux, or at least it has been ported to Debian: https://tracker.debian.org/pkg/signify-openbsd
That's interesting! Didn't know that!
Note that minisign is written by the author of libsodium and the code seems simpler (but has libsodium dependency).
Cheers, François
On Thu, Aug 08, 2019 at 04:17:07PM +0200, Björn Persson wrote:
François Kooman wrote:
The wiki currently describes the procedure to verify source downloads using PGP (GnuPG) [4]. I'd like to propose an added section/extension to also mention Minisign as a means to accomplish that. I wrote a blog post [5] on how I think it can be added to RPM spec files.
Is this something that we can add to the official Packaging documentation? I'd be willing to work on this! Any ideas, feedback?
Do you know of any project that signs releases with Minisign? I've never seen one.
See the "Software projects signed with Ed25519" section in this:
https://ianix.com/pub/ed25519-deployment.html
not very many, but OpenBSD is a big one, which is not surprising as they created signify, which is what inspired minisign.
https://flak.tedunangst.com/post/signify
Personally, before I potentially use a new signing tool, I would like to know that some of the world's smartest cryptologists have analyzed it and found the design sound.
NB, cryptographers have been telling people that PGP is *unsound* for years now
https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/
IIUC, the key thing that makes signify/minisign a sound design are that they target a very narrow use case, offering just a single way to do things, using current best practice algorithms. This immediately eliminates a huge pile of historical baggage and complexity that you get in PGP impls, which have been a reliable source of security problems. It makes it easier for users to do the right thing when runnig the tools as there's much lower risk of picking bad uninformed options.
Regards, Daniel
On 08.08.19 17:35, Daniel P. Berrangé wrote:
See the "Software projects signed with Ed25519" section in this:
https://ianix.com/pub/ed25519-deployment.html
not very many, but OpenBSD is a big one, which is not surprising as they created signify, which is what inspired minisign.
I created a PR against the libsodium package in Fedora [1]. Let's see if the maintainer is interested.
Cheers, François
[1] https://src.fedoraproject.org/rpms/libsodium/pull-request/1
Daniel P. Berrangé wrote:
On Thu, Aug 08, 2019 at 04:17:07PM +0200, Björn Persson wrote:
Do you know of any project that signs releases with Minisign? I've never seen one.
See the "Software projects signed with Ed25519" section in this:
In that list I find five things that are packaged in Fedora:
· Minisign itself: Precompiled binary packages are signed, but not the source code apparently. · Sodium: There are both Minisign signatures and OpenPGP signatures. · dnscrypt-proxy: Again, precompiled binary packages are signed, but not the source code. · Radare2: I can't find any signatures. · OpenSMTPD: Signify signatures found.
So that's at least two packages that could start verifying signatures, one of which can't be verified with GnuPG. At least it wouldn't be entirely pointless to write Minisign into the guidelines.
IIUC, the key thing that makes signify/minisign a sound design are that they target a very narrow use case, offering just a single way to do things, using current best practice algorithms. This immediately eliminates a huge pile of historical baggage and complexity that you get in PGP impls, which have been a reliable source of security problems. It makes it easier for users to do the right thing when runnig the tools as there's much lower risk of picking bad uninformed options.
That's great and all, but have there been any serious attempts to trick Minisign or Signify into accepting a fake signature, by people who are experienced in such attacks?
Cryptography is tricky stuff. It's very easy to overlook some detail. Users should be wary of homegrown protocols that haven't been rigorously analyzed.
Björn Persson
On 08.08.19 21:55, Björn Persson wrote:
· Minisign itself: Precompiled binary packages are signed, but not the source code apparently.
https://github.com/jedisct1/minisign/issues/61
· Sodium: There are both Minisign signatures and OpenPGP signatures. · dnscrypt-proxy: Again, precompiled binary packages are signed, but not the source code. · Radare2: I can't find any signatures. · OpenSMTPD: Signify signatures found.
I can create issues/PRs for these one later as well!
As for packages requiring gnupg2, there are slightly more... But there may be some false positives as well...
$ repoquery -q --disablerepo='*' --enablerepo=fedora-source --enablerepo=updates-source --archlist=src --whatrequires gnupg2 --releasever=rawhide | wc 83 83 2468
That's great and all, but have there been any serious attempts to trick Minisign or Signify into accepting a fake signature, by people who are experienced in such attacks?
Not that I know of. The author is Minisign is the author of libsodium as well. So the trust is mostly based on the author's reputation, and the reputation of OpenBSD developers (signify). I did find an audit by PIA from two years ago for libsodium that was quite positive [1].
Cryptography is tricky stuff. It's very easy to overlook some detail. Users should be wary of homegrown protocols that haven't been rigorously analyzed.
As for the current status quo, i.e. PGP, see [2,3], it would be fair to hold PGP (GnuPG) to the same standards... Based on its history of vulnerabilities I don't really trust it for anything. I'm sure you can use it safely if you are an expert and don't use key servers, but well, I don't trust myself with PGP... That is also the main reason I am in the process of switching to signify/Minisign for my own projects.
Cheers, François
[1] https://www.privateinternetaccess.com/blog/2017/08/libsodium-v1-0-12-and-v1-... [2] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html [3] https://blog.trailofbits.com/2019/07/08/fuck-rsa/
On Thu, Aug 8, 2019 at 6:23 PM François Kooman fkooman@tuxed.net wrote:
As for the current status quo, i.e. PGP, see [2,3], it would be fair to hold PGP (GnuPG) to the same standards... Based on its history of vulnerabilities I don't really trust it for anything. I'm sure you can use it safely if you are an expert and don't use key servers, but well, I don't trust myself with PGP... That is also the main reason I am in the process of switching to signify/Minisign for my own projects.
Thanks for posting this. I haven't gone into the weeds regarding PGP vulnerabilities, but completely agree that PGP is absurdly complex to use. Minisign looks to be a simpler alternative that most likely will grow in popularity once people are educated about it. Seems like a good idea to also include it in the guidelines.
On Thu, Aug 08, 2019 at 04:35:47PM +0100, Daniel P. Berrangé wrote:
IIUC, the key thing that makes signify/minisign a sound design are that they target a very narrow use case, offering just a single way to do things, using current best practice algorithms. This immediately eliminates a huge pile of historical baggage and complexity that you get in PGP impls, which have been a reliable source of security problems. It makes it easier for users to do the right thing when runnig the tools as there's much lower risk of picking bad uninformed options.
You can build a one-purpose application around e.g. OpenSSL. No need for introducing yet another cryptographical library.
-- Petr
On 09.08.19 10:12, Petr Pisar wrote:
You can build a one-purpose application around e.g. OpenSSL. No need for introducing yet another cryptographical library.
Sure, someone could. Probably. However, one would need to upgrade OpenSSL in CentOS/RHEL to get modern algorithm support, i.e. Ed25519.
$ openssl genpkey -algorithm Ed25519 -out ed25519key.pem Algorithm Ed25519 not found
It seems the only thing OpenSSL should be used for is TLS [1]. Everything else crypto should avoid it...
Cheers, François
[1] https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
On Fri, Aug 09, 2019 at 11:32:25AM +0200, François Kooman wrote:
On 09.08.19 10:12, Petr Pisar wrote:
You can build a one-purpose application around e.g. OpenSSL. No need for introducing yet another cryptographical library.
Sure, someone could. Probably. However, one would need to upgrade OpenSSL in CentOS/RHEL to get modern algorithm support, i.e. Ed25519.
An algorithm that will be obsoleted by another modern algorithm in ten years. No this is not how cryptographical tools should be designed. The tool and the singature format must be agnostic to a concrete algorithm.
$ openssl genpkey -algorithm Ed25519 -out ed25519key.pem Algorithm Ed25519 not found
This is an invalid argument. You can always found an arbitrarily old distribution that does not support a feature of your choice.
And I though we are talking about Fedora. And even so it's not true. OpenSSL in RHEL 8 supports Ed25519.
It seems the only thing OpenSSL should be used for is TLS [1]. Everything else crypto should avoid it...
[1] https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
There is no explanation why. Only a "don’t use a low-level crypto library like OpenSSL or BouncyCastle" statement. Do you have any explanation? Moreover, I cannot see how TLS is relevant to a code signing.
-- Petr
On 09.08.19 12:19, Petr Pisar wrote:
An algorithm that will be obsoleted by another modern algorithm in ten years. No this is not how cryptographical tools should be designed. The tool and the singature format must be agnostic to a concrete algorithm.
Actually. It is not designed like this, see [1] for the signature/key format.
This is an invalid argument. You can always found an arbitrarily old distribution that does not support a feature of your choice.
Fair enough, it is not an argument against using OpenSSL, just against using it on RHEL/CentOS 7 assuming one wants to use Ed25519 for signatures and not RSA or ECDSA.
There is no explanation why. Only a "don’t use a low-level crypto library like OpenSSL or BouncyCastle" statement. Do you have any explanation?
Okay, we are getting a bit off-topic here :-)
Using a low level crypto library like OpenSSL is a bad idea for developers. It gives them a huge foot gun. I know enough not to want to use the OpenSSL API as a developer. I will screw it up. I'm confident I can write an application using libsodium without the crypto implementation being the weak part. I'm sure that's true for most (all?) developers that are not also OpenSSL developers...
Moreover, I cannot see how TLS is relevant to a code signing.
It is not. OpenSSL is (according to the blog post linked) only the best tool for doing TLS. For all other purposes it is not the best tool. So introducing something like libsodium for non-TLS purposes seems like a good thing to do! Especially if this means dropping the OpenSSL/GnuPG dependency...
I don't know what the reasons are for arguing against libsodium for non-TLS crypto use cases, maybe the foreseen (long term) potential costs in case libsodium would be added to RHEL, next to OpenSSL and GnuPG?
Cheers, François
On Fri, 9 Aug 2019 at 07:27, François Kooman fkooman@tuxed.net wrote:
On 09.08.19 12:19, Petr Pisar wrote:
An algorithm that will be obsoleted by another modern algorithm in ten
years. No
this is not how cryptographical tools should be designed. The tool and
the
singature format must be agnostic to a concrete algorithm.
Actually. It is not designed like this, see [1] for the signature/key format.
This is an invalid argument. You can always found an arbitrarily old distribution that does not support a feature of your choice.
Fair enough, it is not an argument against using OpenSSL, just against using it on RHEL/CentOS 7 assuming one wants to use Ed25519 for signatures and not RSA or ECDSA.
There is no explanation why. Only a "don’t use a low-level crypto
library like
OpenSSL or BouncyCastle" statement. Do you have any explanation?
Okay, we are getting a bit off-topic here :-)
Using a low level crypto library like OpenSSL is a bad idea for developers. It gives them a huge foot gun. I know enough not to want to use the OpenSSL API as a developer. I will screw it up. I'm confident I can write an application using libsodium without the crypto implementation being the weak part. I'm sure that's true for most (all?) developers that are not also OpenSSL developers...
Moreover, I cannot see how TLS is relevant to a code signing.
It is not. OpenSSL is (according to the blog post linked) only the best tool for doing TLS. For all other purposes it is not the best tool. So introducing something like libsodium for non-TLS purposes seems like a good thing to do! Especially if this means dropping the OpenSSL/GnuPG dependency...
I don't know what the reasons are for arguing against libsodium for non-TLS crypto use cases, maybe the foreseen (long term) potential costs in case libsodium would be added to RHEL, next to OpenSSL and GnuPG?
One of many arguments is that whatever protocol set used to sign artifacts has to be audited by various outside agencies in Europe/US/etc to be used on their systems. That costs time and money to do. Certain tools are already audited like openssl so using them is easier to get added to an ongoing certification than something which is not audited like libsodium. If it hasn't been part of an ongoing certification, libsodium would need to be started from the ground up and probably take 2-3 years. Until it is done, there would be considerable 'push-back' from various consumers of Fedora from just French government agencies of using it as part of something they would allow for usage. That has a pile-on effect as industries wanting to work with said agencies can't use the OS in certain places, which boils out as a 4-5 year time where the signing is in limbo.
This is the part that Petr is not diplomatically covering in that the protocol for signing needs to be past and future reliable. The tool writer needs to know that it is a long haul of working with existing crap for a long time until it can hopefully be removed in 5-10 years when whatever audits and certs are done.
Cheers, François
[1] https://jedisct1.github.io/minisign/ _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
On 09.08.19 14:06, Stephen John Smoogen wrote:
One of many arguments is that whatever protocol set used to sign artifacts has to be audited by various outside agencies in Europe/US/etc to be used on their systems. That costs time and money to do. Certain tools are already audited like openssl so using them is easier to get added to an ongoing certification than something which is not audited like libsodium. If it hasn't been part of an ongoing certification, libsodium would need to be started from the ground up and probably take 2-3 years. Until it is done, there would be considerable 'push-back' from various consumers of Fedora from just French government agencies of using it as part of something they would allow for usage. That has a pile-on effect as industries wanting to work with said agencies can't use the OS in certain places, which boils out as a 4-5 year time where the signing is in limbo.
This is the part that Petr is not diplomatically covering in that the protocol for signing needs to be past and future reliable. The tool writer needs to know that it is a long haul of working with existing crap for a long time until it can hopefully be removed in 5-10 years when whatever audits and certs are done.
Thanks for the explanation! That's unfortunate! :(
However, this only impacts RHEL/CentOS as libsodium is already packaged in Fedora and EPEL, so no problem there using Minisign for verifying file signatures using it I guess?
Replacing PGP with Minisign for RPM package signatures requires a bit more time then :-)
Cheers, François
On Fri, Aug 09, 2019 at 01:26:23PM +0200, François Kooman wrote:
On 09.08.19 12:19, Petr Pisar wrote: Using a low level crypto library like OpenSSL is a bad idea for developers.
I thought you want to start using minisign because it's easier for code signing and verification than GnuPG. But now you are talking about some developers who don't know how to use OpenSSL library. I probably miss the point.
If you want libsodium in Fedora and develop your code against it nobody prevents you from that. Just submit libsodium for a review and become its maintainer.
Moreover, I cannot see how TLS is relevant to a code signing.
It is not. OpenSSL is (according to the blog post linked) only the best tool for doing TLS. For all other purposes it is not the best tool. So introducing something like libsodium for non-TLS purposes seems like a good thing to do! Especially if this means dropping the OpenSSL/GnuPG dependency...
Except you now have to maintain yet another implementation of the eliptic curve cryptography as you already written:
I don't know what the reasons are for arguing against libsodium for non-TLS crypto use cases, maybe the foreseen (long term) potential costs in case libsodium would be added to RHEL, next to OpenSSL and GnuPG?
It's great for diversity and competitive evolution, but expensive for maintenance and required certifications when productizing it for an enterprise use. In my opinion it's cheaper to port and maintain minisign on OpenSSL than to maintain libsodium (whose only current use would be minisign). And if I (maybe worngly) assume that key and signature format of minisign is yet another format incompatible with other tools, you also lose interoperability. In my opinion for most people it's too big obstacle.
I don't tell that D.J. Bernstein and others aren't very smart people and they do not produce high-quality code. I even don't deny that simple tools with a code optimized for one purpose are less error prone and easier for auditing. However, "Yeay, a new tool, let's use it" is not a long-term sustainable approach. New tools are attractive because now they don't have to maintain a balast of backward compatibility and dead code from evolved, repurposed, and forgotten features. SSLeay/libcrypt also was like that when it was young. I only forsee that the new shiny tools once become also old and crufty. That's inevitable. Therefore I do not share you optimism regarding libsodium and minisign future. That's all.
-- Petr
On Fri, Aug 09, 2019 at 02:41:14PM +0200, Petr Pisar wrote:
On Fri, Aug 09, 2019 at 01:26:23PM +0200, François Kooman wrote:
On 09.08.19 12:19, Petr Pisar wrote: Using a low level crypto library like OpenSSL is a bad idea for developers.
I thought you want to start using minisign because it's easier for code signing and verification than GnuPG. But now you are talking about some developers who don't know how to use OpenSSL library. I probably miss the point.
If you want libsodium in Fedora and develop your code against it nobody prevents you from that. Just submit libsodium for a review and become its maintainer.
Erm... libsodium itself has been in Fedora for quite some time now:
https://apps.fedoraproject.org/packages/libsodium
This discussion should only be about a tool that uses the library.
G'luck, Peter
On Fri, Aug 09, 2019 at 04:33:23PM +0300, Peter Pentchev wrote:
On Fri, Aug 09, 2019 at 02:41:14PM +0200, Petr Pisar wrote:
On Fri, Aug 09, 2019 at 01:26:23PM +0200, François Kooman wrote:
On 09.08.19 12:19, Petr Pisar wrote: Using a low level crypto library like OpenSSL is a bad idea for developers.
I thought you want to start using minisign because it's easier for code signing and verification than GnuPG. But now you are talking about some developers who don't know how to use OpenSSL library. I probably miss the point.
If you want libsodium in Fedora and develop your code against it nobody prevents you from that. Just submit libsodium for a review and become its maintainer.
Erm... libsodium itself has been in Fedora for quite some time now:
https://apps.fedoraproject.org/packages/libsodium
This discussion should only be about a tool that uses the library.
I'm sorry, I really didn't phrase this right. Of course the discussion may also cover the aspect of a much more widespread use of the library, I was just pointing out that the library itself is not new.
G'luck, Peter
On 09.08.19 14:41, Petr Pisar wrote:
I thought you want to start using minisign because it's easier for code signing and verification than GnuPG. But now you are talking about some developers who don't know how to use OpenSSL library. I probably miss the point.
I am already using Minisign for my own release source tarballs. Using GnuPG (PGP) for signing/verifying software releases is a bad idea, as per the various links to blog posts of well known cryptography experts I included in previous mails. Also see my blog post about it [1]. If Minisign turns out to be a bad idea in x years I'll just switch to something else.
As part of working on Minsigning my software, I thought it might benefit other Fedora/CentOS packagers and/or developers to have the option to use Minisign directly through Fedora/EPEL. That's why I packaged [2] Minisign and proposed adding a section to the packaging guidelines about using Minisign, next to PGP.
Somehow I got tricked into discussing Red Hat's policy for crypto library inclusion in Red Hat Enterprise Linux. This is not really relevant for me as I am not a Red Hat employee. I do understand there are business/political/technical reasons why Red Hat may not adopt libsodium as part of RHEL, but those are not really relevant here for my contribution as they aim primarily at Fedora/EPEL. As libsodium is already part of Fedora and EPEL, whether or not to include libsodium in Fedora/EPEL is also no longer relevant...
The only thing relevant at this moment is, I think, whether or not to include Minisign in the Fedora packaging guidelines next to PGP as an option to verify source tarballs for use by packagers when upstream signs their software using signify/Minisign. That's all that needs to be discussed. As stated before, I am willing to work on this.
Cheers, François
[1] https://www.tuxed.net/fkooman/blog/minisign.html [2] https://apps.fedoraproject.org/packages/minisign
On Fri, Aug 9, 2019 at 10:49 AM François Kooman fkooman@tuxed.net wrote:
The only thing relevant at this moment is, I think, whether or not to include Minisign in the Fedora packaging guidelines next to PGP as an option to verify source tarballs for use by packagers when upstream signs their software using signify/Minisign. That's all that needs to be discussed. As stated before, I am willing to work on this.
I would agree with that. For that matter, the guideline is a "SHOULD", it's not a must - and it relies on the decision that upstream makes. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_veri...
If upstream decides to use minisign, we should accommodate that decision. I believe the goal of the guideline is to verify where possible - and shouldn't mean that if upstream doesn't use PGP, then forget about it. That, IMO would defeat the intent of the guideline.
What you should do François is simply create a DRAFT guideline using the current published as a template and then open a ticket for review with the packaging committee.
On 09.08.19 17:14, Gerald B. Cox wrote:
What you should do François is simply create a DRAFT guideline using the current published as a template and then open a ticket for review with the packaging committee.
I modified the current packaging guidelines in my own fork and created a PR for it [1]. Not sure how to move forward, but for now I'll just wait and see :-)
Thanks for your feedback/help!
Cheers, François
On Fri, 2019-08-09 at 13:26 +0200, François Kooman wrote:
On 09.08.19 12:19, Petr Pisar wrote:
An algorithm that will be obsoleted by another modern algorithm in ten years. No this is not how cryptographical tools should be designed. The tool and the singature format must be agnostic to a concrete algorithm.
Actually. It is not designed like this, see [1] for the signature/key format.
This is an invalid argument. You can always found an arbitrarily old distribution that does not support a feature of your choice.
Fair enough, it is not an argument against using OpenSSL, just against using it on RHEL/CentOS 7 assuming one wants to use Ed25519 for signatures and not RSA or ECDSA.
There is no explanation why. Only a "don’t use a low-level crypto library like OpenSSL or BouncyCastle" statement. Do you have any explanation?
Okay, we are getting a bit off-topic here :-)
Using a low level crypto library like OpenSSL is a bad idea for developers. It gives them a huge foot gun. I know enough not to want to use the OpenSSL API as a developer. I will screw it up. I'm confident I can write an application using libsodium without the crypto implementation being the weak part. I'm sure that's true for most (all?) developers that are not also OpenSSL developers...
Unless you are a crypographer you will screw it up anyway :-) And if you are targeting Fedora/RHEL libsodium is a no-go for now.
Moreover, I cannot see how TLS is relevant to a code signing.
It is not. OpenSSL is (according to the blog post linked) only the best tool for doing TLS. For all other purposes it is not the best tool.
This is sophism, what you need, if you are really writing a signing tool, is someone expert in cryptography to check your code *anyway*, because there are many, many aspects of signing you may get catastrophically wrong otherwise. And an expert will know how you should use OpenSSL correctly anyway.
TL;DR: Do not think that using some new crypto library automagically makes you write correct code when cryptography is involved, always consult and use tools provided/vetted by your experts.
So introducing something like libsodium for non-TLS purposes seems like a good thing to do! Especially if this means dropping the OpenSSL/GnuPG dependency...
No it is not a good thing for the reasons you are providing. There may be good reasons, but writing a signing tool is not one of them for sure.
And using wellknown and maintained libraries (by your distribution experts) is a better reason to use what is available than introducing a new crypto-library on the promise that it is somehow "better".
I don't know what the reasons are for arguing against libsodium for non-TLS crypto use cases, maybe the foreseen (long term) potential costs in case libsodium would be added to RHEL, next to OpenSSL and GnuPG?
There is added maintenance cost for any new package, and crypto- libraries have a steep cost because they are more critical indeed (and fewer people can properly maintain them, I hate to cite it, but I'd like to remind you the Debian maintenance snafu a few years ago with OpenSSL that was catastrophic indeed).
We already have 4 crypto-libraries in the distro, I am not against a new one if you can drop another in the process (and the process is strictly: drop before adding)
Simo.
packaging@lists.fedoraproject.org