Hi,
Although I have created new ticket[1], I get no response yet. Can anyone take a look, or how long should I wait?
[1] https://fedorahosted.org/fpc/ticket/407
Thanks,
Kenjiro
Kenjiro Nakayama knakayam@redhat.com GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9 Red Hat K.K. Ebisu Neonato 8F, 1-18 Ebisu 4-chome, Shibuya-ku, Tokyo, Japan 150-0013
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/24/2014 10:14 PM, Kenjiro Nakayama wrote:
Hi,
Although I have created new ticket[1], I get no response yet. Can anyone take a look, or how long should I wait?
I'm not speaking for the FPC (I'm not a member), but in general, it's preferred to modify the package to consume one of the approved crypto libraries if at all possible. It's very dangerous to allow bundled crypto implementations in the system because there are no guarantees that flaws will be fixed in a timely manner.
Looking at the package you're trying to add, my guess is that is needs the SHA1 implementation for use in a checksumming/validation routine for apt. Given the possibility that a flaw in the SHA1 implementation *could* conceivably mean being able to sneak arbitrary packages onto a target system, I'd personally prefer to see this package linked against openssl, mozilla-nss or gnutls.
My (perhaps incorrect) understanding about the MD5 exception is that it exists pretty much only because 1) MD5 is a very simple algorithm, 2) MD5 is no longer used for anything sensitive because the algorithm is known to have been broken and 3) MD5 bundling was so ubiquitous that it became clear that efforts to separate it were more effort than they were worth.
None of those three conditions is true about SHA1; it's a very complicated, security-sensitive algorithm that historically has not been reimplemented in many places because linking to existing crypto libraries has usually been easier than rewriting it.
Thank you for your comment, Stephen.
I understand.
OK, altough I will wait for the FPC's comment, I try to use and test SHA1 which is included in Open SSL.
target system, I'd personally prefer to see this package linked against openssl, mozilla-nss or gnutls.
Yes, I agree with you.
Kenjiro
Kenjiro Nakayama knakayam@redhat.com GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9 Red Hat K.K. Ebisu Neonato 8F, 1-18 Ebisu 4-chome, Shibuya-ku, Tokyo, Japan 150-0013
----- 元のメッセージ ----- 差出人: "Stephen Gallagher" sgallagh@redhat.com 宛先: "Discussion of RPM packaging standards and practices for Fedora" packaging@lists.fedoraproject.org 送信済み: 2014年3月25日, 火曜日 午後 9:18:08 件名: Re: [Fedora-packaging] No responce to new ticket #407
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/24/2014 10:14 PM, Kenjiro Nakayama wrote:
Hi,
Although I have created new ticket[1], I get no response yet. Can anyone take a look, or how long should I wait?
I'm not speaking for the FPC (I'm not a member), but in general, it's preferred to modify the package to consume one of the approved crypto libraries if at all possible. It's very dangerous to allow bundled crypto implementations in the system because there are no guarantees that flaws will be fixed in a timely manner.
Looking at the package you're trying to add, my guess is that is needs the SHA1 implementation for use in a checksumming/validation routine for apt. Given the possibility that a flaw in the SHA1 implementation *could* conceivably mean being able to sneak arbitrary packages onto a target system, I'd personally prefer to see this package linked against openssl, mozilla-nss or gnutls.
My (perhaps incorrect) understanding about the MD5 exception is that it exists pretty much only because 1) MD5 is a very simple algorithm, 2) MD5 is no longer used for anything sensitive because the algorithm is known to have been broken and 3) MD5 bundling was so ubiquitous that it became clear that efforts to separate it were more effort than they were worth.
None of those three conditions is true about SHA1; it's a very complicated, security-sensitive algorithm that historically has not been reimplemented in many places because linking to existing crypto libraries has usually been easier than rewriting it.
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On 03/25/2014 01:18 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/24/2014 10:14 PM, Kenjiro Nakayama wrote:
Hi,
Although I have created new ticket[1], I get no response yet. Can anyone take a look, or how long should I wait?
I'm not speaking for the FPC (I'm not a member),
I am a member of the FPC, but am only speaking for myself, here ...
but in general, it's preferred to modify the package to consume one of the approved crypto libraries if at all possible. It's very dangerous to allow bundled crypto implementations in the system because there are no guarantees that flaws will be fixed in a timely manner.
... I concur with you.
These days, bundling any cryptography related routines (and static linkage against libs containing cryptographic routines) has become hardly acceptable and hardly tolerable.
That said, I am in favor of FPC to ban any bundled encryption routines, aiming at trying to concentrate such routines into very few packages/libraries. I am aware, enforcing this will likely be tedious, but I feel it's the only alternative Fedora has to keep the risks of users being endangered by compromised cryptography low.
Ralf
On Tue, Mar 25, 2014 at 08:18:08AM -0400, Stephen Gallagher wrote:
First, historical notes:
My (perhaps incorrect) understanding about the MD5 exception is that it exists pretty much only because 1) MD5 is a very simple algorithm, 2) MD5 is no longer used for anything sensitive because the algorithm is known to have been broken and
Neither of these two was a consideration :-(
- MD5 bundling was so ubiquitous
that it became clear that efforts to separate it were more effort than they were worth.
this is probably the closest to the rationale we currently have. The bundling guidelines do allow FPC to ban bundling of items due to security concerns but in practice we want to accomodate people who want to get their software in so we are constantly trying to find reasons to justify being more lenient rather than being stricter.
on the basis of precedent we probably wouldn't keep bundling of a sha1 implementation out of Fedora unless there was a library that implemented that API already available. If you do a web search for the copyright holders of this implementation and sha1 you'll find that the code is being used in several different modified forms in a variety of projects but not as a standalone library :-(
If there was a library that made just sha1 (or even just hashes) available we might consider it -- I know when we've discussed md5 before we've lamented the fact that there's no libmd5 that was lightweight, had a simple API, and in Fedora, that we could tell people to look into using instead. But due to the lack of such a library we've never had to set precedent on whether to force maintainers to do that port instead of bundling.
OTOH, if a package maintainer wants to perform such a port, we certainly won't object :-)
-Toshio
On Thu, Mar 27, 2014 at 1:48 AM, Toshio Kuratomi a.badger@gmail.com wrote:
If there was a library that made just sha1 (or even just hashes) available we might consider it -- I know when we've discussed md5 before we've lamented the fact that there's no libmd5 that was lightweight, had a simple API, and in Fedora, that we could tell people to look into using instead. But due to the lack of such a library we've never had to set precedent on whether to force maintainers to do that port instead of bundling.
gnulib provides sha1.c/des.c/md5.c and so on.
My opinion is that we should encourage using such files from gnulib at least and state Provides: bundeld(gnulib) only instead of providing more and more Provides: bundled([cryptotype]-[authors])
Thanks.
Yours sincerely, Christopher Meng
Noob here.
packaging@lists.fedoraproject.org
-
Christopher Meng -
Kenjiro Nakayama -
Ralf Corsepius -
Stephen Gallagher -
Toshio Kuratomi