--On Friday, July 02, 2010 09:55:16 AM +0100 Darren J Moffat
<[email protected]> wrote:
On 02/07/2010 02:55, Brock Pytlik wrote:
As for which digests we support. I'd like to understand better why we
would ever want to forbid a user from using a particular digest which we
could support. I would've though providing a sane default would be
enough. Further, if openssl decides to remove sha1, for example, I
didn't want to be in a situation where we had promised a bug-for-bug
substitute for the removed functionality.
Actually, you do. If OpenSSL descides to remove sha1, then you have the
choice of either breaking all the existing signed manifests out there or
finding some other place to get that functionality. The choice of
supported hashes is part of the interface, and it should be determined
explicitly.
I'd be happy to document our suggestions (like "While openssl currently
supports the md2, md4, md5, and sha1 hashing algorithms, we strongly
recommend against using them.") If a user/publisher is making a
conscious decision to use a different algorithm, should we breaking them
when we could do what they want?
Users shouldn't be making that choice because they don't know what they
are doing in this area most of the time.
That's a little strong, but yes. You shouldn't support MD2 and MD4 because
the only possible reason to support them is for backward compatibility with
old signatures, and there _aren't_ any old signatures. And at this point
in time, the same applies to MD5 -- given that SHA-1 is supported, there's
no good reason for a new protocol (and really, that's what this is(*)) to
support MD5.
It's also important to have a sane policy by default, and for that policy
to evolve over time by default. Today, you may want to support SHA-1 by
default, but at some point the correct default will be to stop supporting
it, even on existing systems that take upgrades.
(*) Actually, that's another good argument for not delegating the question
of which algorithms to support to OpenSSL or anyone else. You're
essentially defining a protocol here, and interoperability demands that you
be explicit about what algorithms are supported.
Given that in this case there are no backwards compatibility issues
really the only acceptable choices are sha256/384/512 and personally I
don't see much need for anything other than sha256.
Actually, you're right... Even SHA-1 may be a bit silly in a new protocol
like this.
I very strongly recommend against mentioning anything about OpenSSL - it
is an implementation detail not part of the interface of pkg(5).
+1
-- Jeff
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
