On Thu, Jul 08, 2010 at 02:58:06PM -0700, Brock Pytlik wrote:
> On 07/ 8/10 02:54 PM, [email protected] wrote:
> >On Thu, Jul 08, 2010 at 02:40:00PM -0700, Brock Pytlik wrote:
> >>On 07/ 8/10 02:12 AM, Darren J Moffat wrote:
> >>>On 07/07/2010 23:43, Brock Pytlik wrote:
> >>>[snip]
> >>>If the intent is that the signature section only exists in signed
> >>>packages you just need pkg.sigalg=rsa-sha256, you don't need a
> >>>pkg.hashalg as well.
> >>>
> >>>However if the intent is to have pkg.hashalg be used for non
> >>>signed packages then having both pkg.hashalg and pkg.sigalg
> >>>present when they are signed is fine too.
> >>>
> >>I feel like we're talking past each other here, so I'm going to try
> >>and rephrase the question I have.
> >>
> >>You keep saying that pkg.sigalg should be something like
> >>"rsa-sha256." I'm asking why it's not possible to construct that
> >>value from two pieces, pkg.hashalg, which has values like "sha256",
> >>"sha512", and pkg.foo (for now let's just call it pkg.foo), which
> >>has values like "rsa", "dsa", "ecdsa", etc...
> >>
> >>I haven't seen any reason yet why that's not a rational thing to do.
> >>If it is a rational thing to do, then I'm suggesting that pkg.foo
> >>actually be called pkg.sigalg. Having these two pieces which, to me
> >>at least, seem orthogonal, stored in separate places and then
> >>combined makes more sense to me than storing x^2 long strings.
> >Not to confuse the matter further, but I thought that we already had a
> >longstanding proposal for how to encode the hashing algorithms used to
> >identify package content.
> >
> >https://defect.opensolaris.org/bz/show_bug.cgi?id=8
>
> Note that that's for content hash. While it would be nice if the
> content hash and signature hashes aligned, that is not necessarily
> the case. That's one reason per Tim's suggestion we'll actually be
> using pkg.sig_hashalg. Note that the issue of collisions isn't one
> that matters to us in this use case.
Ok, just double-checking. However, you didn't answer Darren's question
about whether a signature algorithm attribute should be present if a
package isn't signed. My guess is no, but I'm curious what the answer
is too.
Your other question: why not have a separate sigalg and hashalg?
According to most other conventions, the two are kept together in one
string.
OpenSSL uses this approach:
http://www.openssl.org/docs/apps/ciphers.html
Sendmail uses a similar approach, but spells out the hash bits
explicitly in the header:
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
I think the real question is why should you add an extraneous attribute
when you can legibly capture all of the information about the algorithm
in one string, whose format is relatively well established?
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
