[SM-Discuss] Compromise on signatures
Jeremy Blosser (emrys)
jblosser-smgl at firinn.org
Mon Aug 29 21:29:40 EDT 2005
On Aug 29, Seth Alan Woolley [seth at positivism.org] wrote:
> On Mon, Aug 29, 2005 at 07:22:43PM -0400, Sergey A. Lipnevich wrote:
> > Hi All,
> > I can think of the following compromise that would hopefully satisfy all sides.
> > 1. Sorcery keeps support for hashes and signatures, both optional, but with
> > possibility to be restricted by users of individual systems. Here's one for the
> > choice.
> We're working on adding a number of choice features in a new sorcery
> menu for the existing system, this shouldn't be much more work.
Yes, in case this wasn't communicated well enough, we very much intend for
all these things to be information to the user. They can decide what they
want to do with it. Ignore it, require only in-person ID check-approved
upstream keys, etc.
> > This way, we will do exactly what is claimed on that Web page: sign package
> > receipt without signing the contents.
> a signature is merely an asymmetric encryption of a hash.
> What you propose is to make an asymmetric encryption of a hash which
> includes a hash.
> Is this level of indirection that meaningful to you?
> As far as your compromise, I have an implementation suggestion:
> I'm willing to add code to sorcery to check for a DETAILS.asc file (or a
> $SPELL.asc file with signatures of all files but $SPELL.asc) that uses
> the key pointed to by SPELL_GPG=blah.gpg inside the DETAILS file.
> If you're willing to sign your spells like that, that's an adequate
> compromise for me, but it would be an error if you DID NOT include
> SPELL_GPG=sergey.gpg (and an .asc file) and DID use a SOURCE_HASH in a
> spell at the same time under the new policy.
> But I don't know how other people will like it :)
I'm having trouble with this. Signing something that includes a statement
"SOURCE_HASH=sha1:1663d32bcd24fc3ec7d7168c47a44e4dcdb82266' is not
technically any different from just signing the referenced source tarball,
and if people understand the issues involved, it's not different
sociologically either. It's just obfusctation that seems most likely to
promote developers not understanding what they even are and aren't signing.
The main reason I can see it being acceptable when direct signing isn't is
because the signer is ignoring the fact they're still signing a hash that
speaks to what the proper state of the upstream tarball is. This is
difficult for me to accept because it's less clear what's going on to both
users and developers, and I don't think it's good to promote something
confusing here. Even if a particular developer has a very solid reason
they want to do it this way, it's going to take a lot to communicate that
to a user so they can decide what they want to do with the assertion being
made. I would rather we just keep SOURCE_HASH for now than implement this
kind of thing, sorry.
What do other people think?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050829/682137d9/attachment.bin
More information about the SM-Discuss