On 07/ 8/10 03:22 PM, [email protected] wrote:
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.
That was because I didn't understand what was meant by a signature
section. If the question is, "if we're only doing the digest version of
signature actions, is the pkg.sigalg attribute present" then the answer
is I don't think it would be.
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?
I've looked @ the openssl and the sendmail example you've provide and
I'd certainly take issue with your description of them as legible.
Setting that aside, the reason I'd use two attributes is because, at
package signing time, the package signer has (potentially) two
decisions, the hash algorithm to use, and the signing algorithm to
apply. Representing those two decisions as separate attributes seems
obvious to me.
I could ask the same question about the mode and path of out file
actions. Why do we separate them into two attributes when theres a well
known convention (the output of ls -l) which provides that information
in a single string. The answer for the file action, and for the
signature action, is that they're two orthogonal (or nearly orthogonal)
bits of information that would have to be split apart by the consumer to
use.
To me, the most compelling reason for two attributes, and the reason
that I'm going with two separate attributes is that the places where I
use the information they provide is located in two separate places. I
would need to take the single long string and parse it to find the
information I was looking for (rsa vs dsa or sha256 vs sha512). Since
there's no harm in storing the information in two separate attributes,
and it makes life easier, and in my opinion clearer to the user, I think
that's what I'll do.
Brock
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
