Re: Git-commits mailing list feed.

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
On Sat, 23 Apr 2005, Linus Torvalds wrote:

> NO.
>
> Guys, I will say this once more: git will not look at the signature.
>
> That means that we don't "strip them off", because dammit, they DO NOT
> EXIST as far as git is concerned. This is why a tag-file will _always_
> start with
>
> commit <commit-sha1>
> tag <tag-name>
>
> because that way we can use fsck and validate reachability and have
> things that want trees (or commits) take tag-files instead, and git
> will automatically look up the associated tree/commit. And it will
> do so _without_ having to understand about signing, since signing
> is for trust between _people_ not for git.

> And that is why I from the very beginning tried to make ti very
> clear that the signature goes at the end. Not at the beginning, not
> in the middle, and not in a different file. IT GOES AT THE END.

Actually, can you make the signature be detached and a seperate
object? Ie, add a signature object in its own right, distinct from
tag. They could then:

- be used to sign any kind of object
- allow objects to be signed by multiple people

Ideally, there'd be an index of signature objects by the SHA-1 sum of
the object they sign, as the signed object should not refer to the
signature (or the second of the above is not possible).

The latter of the two points would, in combination with the former,
allow for cryptographic 'signed-off-by' chains. If a 'commit' is
signed by $RANDOM_CONTRIBUTOR and $SUBSYSTEM_MAINTAINER and $ANDREW,
you know its time to pull it. Would also work for things like "fixes
only" trees, where (say) a change must be approved by X/2+1 of a
group of X hacker providing oversight -> looking up the commit
object's signatures would tell you whether it was approved.

No idea whether this is possible or practical. :) But it would be
good for future flexibility to avoid including the signature in the
object being signed.

regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
You give me space to belong to myself yet without separating me
from your own life.  May it all turn out to your happiness.
  -- Goethe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
On Mon, 25 Apr 2005, Paul Jakma wrote:

> Ideally, there'd be an index of signature objects by the SHA-1 sum of the
> object they sign, as the signed object should not refer to the signature (or
> the second of the above is not possible).

Ah, this could (obviously) be done generally by providing a general
index of 'referals' (if desirable).

I have no idea whether git already does this, I havn't checked it out
yet but I'm very interested to see how git will mature and have been
trying to follow its progress - I'm a frustrated admin of a CVS
repository..

regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
Does the name Pavlov ring a bell?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

David A. Wheeler
In reply to this post by Paul Jakma



On Sat, 23 Apr 2005, Linus Torvalds wrote:

>> That means that we don't "strip them off", because dammit, they DO NOT
>> EXIST as far as git is concerned. This is why a tag-file will _always_
>> start with
>>
>>     commit <commit-sha1>
>>     tag <tag-name>
>>
>> because that way we can use fsck and validate reachability and have
>> things that want trees (or commits) take tag-files instead, and git
>> will automatically look up the associated tree/commit. And it will do
>> so _without_ having to understand about signing, since signing is for
>> trust between _people_ not for git.
 >
 >> And that is why I from the very beginning tried to make ti very clear
 >> that the signature goes at the end. Not at the beginning, not in the
 >> middle, and not in a different file. IT GOES AT THE END.

It may be better to have them as simple detached signatures, which are
completely separate files (see gpg --detached).
Yeah, gpg currently implements detached signatures
by repeating what gets signed, which is unfortunate,
but the _idea_ is the right one.


Paul Jakma wrote:
> Ideally, there'd be an index of signature objects by the SHA-1 sum of
> the object they sign, as the signed object should not refer to the
> signature (or the second of the above is not possible).

Yes, and see my earlier posting.  It'd be easy to store signatures in
the current objects directory, of course.  The trick is to be able
to go from signed-object to the signature; this could be done
just by creating a subdirectory using a variant of
the name of the signed-object's file, and in that directory store the
hash values of the signatures.  E.G.:
  00/
     3b128932189018329839019          <- object to sign
     3b128932189018329839019.d/
     0143709289032890234323451
  01/
     43709289032890234323451          <- signature

> The latter of the two points would, in combination with the former,
> allow for cryptographic 'signed-off-by' chains. If a 'commit' is signed
> by $RANDOM_CONTRIBUTOR and $SUBSYSTEM_MAINTAINER and $ANDREW, you know
> its time to pull it. Would also work for things like "fixes only" trees,
> where (say) a change must be approved by X/2+1 of a group of X hacker
> providing oversight -> looking up the commit object's signatures would
> tell you whether it was approved.

Right.  Lots of tricks you can do once the signatures are there,
such as checking to counter repository subversion
(did everything get signed), finding out who introduced a malicious
line of code (& "proving" what key signed it first), etc.
There are LOTS of reasons for storing signatures so that they can
be checked later on, just like there are lots of reasons for storing
old code... they give you evidence that the reputed history is true
(and if you doubt it, they give you a way to limit the doubt).

--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

David Woodhouse
In reply to this post by Paul Jakma
On Sat, 2005-04-23 at 10:31 -0700, Linus Torvalds wrote:
> In other words, I actually want to create "tag objects", the same way we
> have "commit objects". A tag object points to a commit object, but in
> addition it contains the tag name _and_ the digital signature of whoever
> created the tag.

I'm slightly concerned that to find a given tag by its name if we do
_just_ the above would be a fairly slow process. I suspect you'll want
a .git/tags/ directory _anyway_, but with named files which refer to tag
objects, instead of directly to commit objects as in Petr's current
implementation.

Other operations we might want to be at least _reasonably_ efficient
would include 'show me the latest tag from Linus' and 'show me all
extant tags'.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
In reply to this post by David A. Wheeler
On Sun, 24 Apr 2005, David A. Wheeler wrote:

> It may be better to have them as simple detached signatures, which
> are completely separate files (see gpg --detached). Yeah, gpg
> currently implements detached signatures by repeating what gets
> signed, which is unfortunate, but the _idea_ is the right one.

Hmm, what do you mean by "repeating what gets signed"?

> Yes, and see my earlier posting.  It'd be easy to store signatures in
> the current objects directory, of course.  The trick is to be able
> to go from signed-object to the signature;

Two ways:

1. An index of sigs to signed-object.

(or more generally: objects to referring-objects)

2. Just give people the URI of the signature, let them (or their
    tools) follow the 'parent' link to the object of interest

> this could be done just by creating a subdirectory using a variant
> of the name of the signed-object's file, and in that directory
> store the hash values of the signatures.  E.G.:

> 00/
>    3b128932189018329839019          <- object to sign
>    3b128932189018329839019.d/
>    0143709289032890234323451
> 01/
>    43709289032890234323451          <- signature

You could hack it in to the namespace somehow I guess. I'm not sure
hacking it in would be a good thing though.

I think it might be more useful just to provide a general index to
lookup 'referring' objects (if git does not already - I dont think it
does, but I dont know enough to know for sure). So you could ask
"which {commit,tag,signature,tree}(s) refer(s) to this object?" -
that general concept will always work. If you wanted to make the
implementation of this index use some kind of sub directory as in the
above, fine..

See also method 2 above. Which would be more efficient for tools if,
within a project, some developers sign their 'updates' and some
dont.. (you never need to check whether there's a signature or not -
you'll know it from the URI automatically).

> There are LOTS of reasons for storing signatures so that they can
> be checked later on, just like there are lots of reasons for
> storing old code... they give you evidence that the reputed history
> is true (and if you doubt it, they give you a way to limit the
> doubt).

Indeed.

Anyway, we shall see what Linus does. :)

(But I do hope at least that signatures are /not/ included inline
using BEGIN PGP.. in the object that is signed.)

regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
To err is human, to purr feline.
To err is human, two curs canine.
To err is human, to moo bovine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Linus Torvalds
In reply to this post by David A. Wheeler


On Sun, 24 Apr 2005, David A. Wheeler wrote:
>
> It may be better to have them as simple detached signatures, which are
> completely separate files (see gpg --detached).
> Yeah, gpg currently implements detached signatures
> by repeating what gets signed, which is unfortunate,
> but the _idea_ is the right one.

Actually, if we do totally separate files, then the detached thing is ok,
and we migth decide to not call the objects at all, since that seems to be
unnecessarily complex.

Maybe we'll just have signed tags by doing exactly that: just a collection
of detached signature files. The question becomes one of how to name such
things in a distributed tree. That is the thing that using an object for
them would have solved very naturally.

                Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

David A. Wheeler
In reply to this post by Paul Jakma
Paul Jakma wrote:
> On Sun, 24 Apr 2005, David A. Wheeler wrote:
> Hmm, what do you mean by "repeating what gets signed"?

Forget it, irrelevant.  I vaguely remembered some problem with
gpg's detached signatures, but it was probably either a really
early alpha version or someone was using "--clearsign" instead
of "--armor".  I just did a quick check with:
  gpg --armor --detach -o junk.sig junk.c
and it worked "as expected"; no repeat of the data.

>> Yes, and see my earlier posting.  It'd be easy to store signatures in
>> the current objects directory, of course.  The trick is to be able
>> to go from signed-object to the signature;
> Two ways:
> 1. An index of sigs to signed-object.
> (or more generally: objects to referring-objects)

Right.  I suggested putting it in the same directory as the objects,
so that rsync users get them "for free", but a separate directory
has its own advantages & that'd be fine too.
In fact, the more I think about it, I think it'd be cleaner
to have it separate.   You could prepend on top of the signature
(if signatures are separate from assertions) WHAT got signed so
that the index could be recreated from scratch when desired.

> 2. Just give people the URI of the signature, let them (or their
>    tools) follow the 'parent' link to the object of interest

If you mean "the signatures aren't stored with the objects", NO.
Please don't! If the signatures are not stored in the database,
then over time they'll get lost.  It's important to me to
store the record of trust, as well as what changed, so that
ANYONE can later go back and verify that things are as they're
supposed to be, or exactly who trusted what.

> I think it might be more useful just to provide a general index to
> lookup 'referring' objects (if git does not already - I dont think it
> does, but I dont know enough to know for sure).

git definitely doesn't have this currently, though you could run the
fsck tools which end up creating a lot of the info (but it's then
thrown away).

 > So you could ask "which
> {commit,tag,signature,tree}(s) refer(s) to this object?" - that general
> concept will always work.

Yes. The problem is that maintaining the index is a pain.
It's probably worth it for signatures, because the primary use
is the other direction ("who signed this?"); it's not clear that
the other direction is common for other data.

--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Fabian Franz
In reply to this post by Linus Torvalds
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 25. April 2005 03:50 schrieb Linus Torvalds:

> Maybe we'll just have signed tags by doing exactly that: just a collection
> of detached signature files. The question becomes one of how to name such
> things in a distributed tree. That is the thing that using an object for
> them would have solved very naturally.

What about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?

Or would this violate the concept of the object database to just contain
hashes?

cu

Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCbFMsI0lSH7CXz7MRAof0AKCILjPE/M72cMSVNDC/DWYSzmrU/ACggOuS
ogNPwUf2ASAwmbwixzSTuPs=
=pW5D
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Matt Domsch
In reply to this post by David A. Wheeler
On Sun, Apr 24, 2005 at 09:01:28PM -0400, David A. Wheeler wrote:
> It may be better to have them as simple detached signatures, which are
> completely separate files (see gpg --detached).
> Yeah, gpg currently implements detached signatures
> by repeating what gets signed, which is unfortunate,
> but the _idea_ is the right one.

I solve this with two simple scripts, "sign" calls "cutsig".

--------------
sign

#!/bin/sh

DEFAULT_KEY="my-private-key-string"
CUTSIG=~/bin/cutsig.pl
usage()
{
    echo "usage: $0 filename"
    echo " produces filename.sign"
}

if [ $# -lt 1 ]; then
   usage
   exit 1;
fi

gpg --armor --clearsign --detach-sign --default-key "${DEFAULT_KEY} -v -v -o - ${1} | \
${CUTSIG} > ${1}.sign

exit 0


-----------------
cutsig


#!/usr/bin/perl -w

do {
    $line = <STDIN>;
} until $line =~ "-----BEGIN PGP SIGNATURE-----";


print $line;
while ( $line = <STDIN>) {
    print $line;
}

exit 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Jan Harkes
On Sun, Apr 24, 2005 at 09:34:20PM -0500, Matt Domsch wrote:
> On Sun, Apr 24, 2005 at 09:01:28PM -0400, David A. Wheeler wrote:
> > It may be better to have them as simple detached signatures, which are
> > completely separate files (see gpg --detached).
> > Yeah, gpg currently implements detached signatures
> > by repeating what gets signed, which is unfortunate,
> > but the _idea_ is the right one.
>
> I solve this with two simple scripts, "sign" calls "cutsig".
...
> gpg --armor --clearsign --detach-sign --default-key "${DEFAULT_KEY} -v -v -o - ${1} | \
> ${CUTSIG} > ${1}.sign

You could also just leave out the --clearsign option and it will DTRT.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Linus Torvalds
In reply to this post by Fabian Franz


On Mon, 25 Apr 2005, Fabian Franz wrote:
>
> What about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?

Well, the SHA1 of an object really is not a very good name, unless you
have something to manage it with. Again, the object database has something
to manage and find those objects with - things like .git/HEAD, but also
"fsck" to find dangling and unnamed objects.

Maybe we'll never have so many tags that we need to manage them, and yes,
if so, we can just have ".git/signatures" be a directory with objects that
are just named for their content SHA1, the same way the object database
is, but separately (and probably just using a flat file structure, no need
for the subdirectory fan-out that the object directory has).

No need for a ".sig" thing, since they'd be defined to be signatures just
from their location.

> Or would this violate the concept of the object database to just contain
> hashes?

This wouldn't be an object at all in that case, they'd be totally outside
the scope of the git object model.

And yes, if they were to be git objects, they'd follow totally different
rules: they'd have to have the "tag+length+'\0'" format, and they would be
zlib-compressed.

If they are totally outside of git, then I don't care what the object
format is, and then it could be just a regular text-file with a signature
and content, and just happen to be named for the SHA1 hash so that there
is no confusion about what happens when multiple people happen to create
different tags with the same name.

                Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
In reply to this post by David A. Wheeler
On Sun, 24 Apr 2005, David A. Wheeler wrote:

> Right.  I suggested putting it in the same directory as the
> objects, so that rsync users get them "for free", but a separate
> directory has its own advantages & that'd be fine too. In fact, the
> more I think about it, I think it'd be cleaner to have it separate.
> You could prepend on top of the signature (if signatures are
> separate from assertions) WHAT got signed so that the index could
> be recreated from scratch when desired.

Well, i'm trying to play with git right now to see what would fit
with how it abstracts things.

I think possibly:

- add the 'signature object' to the respository after the signed
   object

So a 'signed commit' turns into the

- tool preparing the commit object,
  - get the user to sign it
  - save the detached signature for later
- adding the commit object to the repository
- prepare the signing object and add to repository

The repository head then refers then to signature object, which could
(handwaving) look something like:

  Object Signature
  Signing <object ID, in this case of the commit object>
  Sign-type GPG

  <signature data>

Tools should then treat signature objects as 'stand ins' for the
object they are signing (verify the signature - if desired - and then
just retrieve the 'Signing' object ID and use that further).

I have no working knowledge of git though, other than following this
list. So I have no idea whether above is at all appropriate or
workable.

> If you mean "the signatures aren't stored with the objects", NO.
> Please don't! If the signatures are not stored in the database,
> then over time they'll get lost.

No more lost than anything else in the git 'fs'.

If someone prunes old objects, they'll lose the signed objects along
with the signatures. If those files weren't replicated anywhere else,
well they've just blown away history for good, both the history of
the source and corresponding signatures.

> It's important to me to store the record of trust, as well as what
> changed, so that ANYONE can later go back and verify that things
> are as they're supposed to be, or exactly who trusted what.

See above.

> git definitely doesn't have this currently, though you could run
> the fsck tools which end up creating a lot of the info (but it's
> then thrown away).

Well, it could be retained then.

> Yes. The problem is that maintaining the index is a pain.

Possibly.

> It's probably worth it for signatures, because the primary use is
> the other direction ("who signed this?"); it's not clear that the
> other direction is common for other data.

In CVS it is. If you 'cvs log' a file, you can get a report on which
revisions of the file belong to which tags (which can be useful
information sometimes: "ah, so that release had the buggy version"
type of thing. Or as a sanity check to make sure you got a tag right
- particularly when you have to move a wrong tag[1]). So, in addition
to signatures, a general 'referrers of this object' index could be
useful for reports.

1. This might be just a CVS thing, and not wanted for git -> the
ability to tag historical revisions and indeed change what tags refer
to.

regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
Decaffeinated coffee?  Just Say No.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
Ah, to add to below..

If one wished, one could optionally store the actual signature data
as a seperate blob object and refer to it in the signing object. Not
needed really for a GPG ASCII clear-signed detached signature (tiny
and they're ASCII obviously :) ), but who knows.

On Mon, 25 Apr 2005, Paul Jakma wrote:

> - add the 'signature object' to the respository after the signed
>  object
>
> So a 'signed commit' turns into the
>
> - tool preparing the commit object,
> - get the user to sign it
> - save the detached signature for later
> - adding the commit object to the repository

   - adding the signature blob, if it is to stored as a blob

> - prepare the signing object and add to repository

> The repository head then refers then to signature object, which could
> (handwaving) look something like:
>
> Object Signature
> Signing <object ID, in this case of the commit object>
> Sign-type GPG

With either a 'Signature  <ID of signature data blob>' or else:

> <signature data>


regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
May you have many beautiful and obedient daughters.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

David A. Wheeler
In reply to this post by Linus Torvalds
Linus Torvalds wrote:

>
> On Sun, 24 Apr 2005, David A. Wheeler wrote:
>
>>It may be better to have them as simple detached signatures, which are
>>completely separate files (see gpg --detached).
>
> Actually, if we do totally separate files, then the detached thing is ok,
> and we migth decide to not call the objects at all, since that seems to be
> unnecessarily complex.
>
> Maybe we'll just have signed tags by doing exactly that: just a collection
> of detached signature files. The question becomes one of how to name such
> things in a distributed tree. That is the thing that using an object for
> them would have solved very naturally.

I agree, naming signatures using the same way other objects are named
would be very clean.  So, why not? It's perfectly reasonable to
just store detached signatures as hashed objects, just like the rest;
just create a new object type ("signature").
If 3 different keys are used to sign the same object, the detached
signatures will have different hash values, so they'll get named easily.

Now you just have to FIND the signature of a signed object,
i.e. efficiently go the "other way" from signed object to detached
signature.  A separate directory with this mapping, or embedding the
mapping inside the object directory (HASH.d/<list>) both solve it.

The more I think about it, the more I think a separate "reverse"
index directory would be a better idea. It just needs to from
"me" to "who references me", at least so that you can quickly
find all signatures of a given object. If the reverse directory
gets wonky, anyone can just delete the reverse index directory
at any time & reconstruct it by iterating the objects.
Before "-----BEGIN PGP SIGNATURE-----" you should add:
  signatureof HASHVALUE
to make reconstruction easy; PGP processors ignore stuff
before "-----".  The PGP data does include a hash, but it's not
easy to get it out (I don't see a way to do it in gpg from the
command line), and it's quite possible that a signer won't
use SHA-1 when they sign something (they may not even
realize it; it depends on their implementation's configuration).
Better to include something about what was signed with the signature.

Hmm, probably worth backtracking to see what's needed.
There needs to be a way to identify tags, and a way to sign that
tag so that you can decide to trust some tags & not others.
There needs to be a way to sign commits, and store that info
for later.  And really, these are special cases of general
assertions about other things; you might want someone to be
able to make other signed assertions (e.g., that it
passed test suite XYZ).

If tags & commits are all you plan to sign for now, well, you
already have commits.  You can just add a "tag" type and a
"signature" type of object (the "signature" is just a detached
OpenPGP signature).  "signature" can sign tag or commit types.
I still like the idea of a more general "assertion" type, esp.
for assertions that something passed a test suite on a certain date
or was reviewed at a certain date by someone, but admittedly
that could be added later in the same manner.

Then you need to be able to quickly find a signature, given a
commit or tag.  A "reverse" directory then does that nicely,
and if you put enough information in front of the signature,
you can regenerate the reverse directory whenever you wish.

--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
On Sun, 24 Apr 2005, David A. Wheeler wrote:

> Now you just have to FIND the signature of a signed object, i.e.
> efficiently go the "other way" from signed object to detached
> signature.  A separate directory with this mapping, or embedding
> the mapping inside the object directory (HASH.d/<list>) both solve
> it.

You dont even need it, see my other mail. If:

- the signature is an object and added after the commit object

- tools know that signatures are 'proxies of' or precursors to the
   objects they are signing (which makes sense, a signature by
   definition refers to something else)

- the signature object refers to the object it is signing (eg a
   'Signing <object ID>' header)

Then head can simply be the signature object and tools can find the
commit by following the 'Signing' field of the signature (they dont
even need to check the signature is valid). No index lookup needed.

You only need the index for historical verification really, and you
can always generate an index if needs be. (and have the tools
maintain it).

> The more I think about it, the more I think a separate "reverse"
> index directory would be a better idea. It just needs to from
> "me" to "who references me", at least so that you can quickly
> find all signatures of a given object. If the reverse directory
> gets wonky, anyone can just delete the reverse index directory
> at any time & reconstruct it by iterating the objects.
> Before "-----BEGIN PGP SIGNATURE-----" you should add:
> signatureof HASHVALUE
> to make reconstruction easy; PGP processors ignore stuff
> before "-----".

Oof, dont do this:

- makes assumptions about the format of the signature
  - that it is ASCII
  - that you can change it

Just add a git header which is independent of the signature data.

In lieu of the 'signature object as precursor' approach above, just
have the tools maintain an index. It can be maintained as objects as
added, and can always be blown away and recreated by inspection of
the repository data.

regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
To doubt everything or to believe everything are two equally convenient
solutions; both dispense with the necessity of reflection.
  -- H. Poincar'e
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

David A. Wheeler
In reply to this post by Linus Torvalds
On Mon, 25 Apr 2005, Fabian Franz wrote:
 >> What about just <sha1 hash of object>.sig or <sha1 hash of object>.asc?

If you mean "hash of object being signed", the problem is that
there may be more than one signature of a given object.
Keys get stolen, for example, so you want to re-sign the objects.
Yes, you could replace the files, but it's nicer to make it
so there's never a need to replace files in the first place.
That's one of the nice properties of the git object database;
so if we can have that property everywhere, I think we should.

Instead, store the signatures in the normal object database, &
give it type "signature".  To speed access FROM a commit or tag
to a signature (and FROM a commit to a tag), create a
separate reverse directory that tells you what objects reference
a given object.  Like this:
.git/
   objects/
     00/
       0195297c2a6336c2007548f909769e0862b509  <= a commit object
     02/
       0395297c2a6336c2007548f909769e0862b509  <= signature of commit
     04/
       0595297c2a6336c2007548f909769e0862b509  <= a tag
     06/
       0795297c2a6336c2007548f909769e0862b509  <= signature of tag
   reverse/
     00/
       0195297c2a6336c2007548f909769e0862b509/
         020395297c2a6336c2007548f909769e0862b509  "this signs commit"
         .... other later signatures of this commit go here.
     04/
       0595297c2a6336c2007548f909769e0862b509/
         060795297c2a6336c2007548f909769e0862b509
         .... other later signatures of this tag go here.

The reverse directory's contents are basically the filenames.
The files themselves could be symlinks back up, or not.
Content-free files are probably more portable across filesystems,
and it's probably also good for space efficiency
(though I haven't examined that carefully).

"git"'s knowledge of signatures should be VERY limited, and
not dependent on PGP.  I think that'd be easy.
You could prepend some signature data into the "signature" file to
make it much easier to reconstruct the reverse directory and
to make it easy to check things WITHOUT knowledge of PGP or whatever.

Here's potential output:

$ cat-file commit 000195297c2a6336c2007548f909769e0862b509
tree 2aaf94eae20acc451553766f3c063bc46cfa75c6
parent dc459bf85b3ff97333e759d641c5d18f4dad470d
author Petr Baudis <[hidden email]> 1114303479 +0200
committer Petr Baudis <[hidden email]> 1114303479 +0200

    Added the whatsit flag.


$ cat-file signature 000195297c2a6336c2007548f909769e0862b509
signatureof commit 000195297c2a6336c2007548f909769e0862b509
signer Petr Baudis <[hidden email]>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBCbFaRCxlT/+f+SU4RAgYSAKCWpPNlDKDkxuuA649zJop7WkQPnACdF1Fg
JgXatbJU8YJ7JHqvgyGepRU=
=Kttg
-----END PGP SIGNATURE-----


$

--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
In reply to this post by Paul Jakma
On Mon, 25 Apr 2005, Paul Jakma wrote:

> You dont even need it, see my other mail. If:
>
> - the signature is an object and added after the commit object
>
> - tools know that signatures are 'proxies of' or precursors to the
>  objects they are signing (which makes sense, a signature by
>  definition refers to something else)
>
> - the signature object refers to the object it is signing (eg a
>  'Signing <object ID>' header)
>
> Then head can simply be the signature object and tools can find the
> commit by following the 'Signing' field of the signature (they dont
> even need to check the signature is valid). No index lookup needed.

> You only need the index for historical verification really, and you can
> always generate an index if needs be. (and have the tools maintain it).

Uh, I have no idea whether verifying a signature of a commit object
is sufficient, ie equivalent to signing each file.

commit refers to tree objects, which I presume lists the SHA-1 object
IDs of files, but IIRC Linus already described why a signature of the
commit object should not be used to trust the rest of commit.. (i'll
have to find his mail). If so, an index is required.

regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
Old programmers never die, they just hit account block limit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

Paul Jakma
On Mon, 25 Apr 2005, Paul Jakma wrote:

> Uh, I have no idea whether verifying a signature of a commit object is
> sufficient, ie equivalent to signing each file.
>
> commit refers to tree objects, which I presume lists the SHA-1 object IDs of
> files, but IIRC Linus already described why a signature of the commit object
> should not be used to trust the rest of commit.. (i'll have to find his
> mail). If so, an index is required.

Ah, apparently it is sufficient:

Linus:

?Just signing the commit is indeed sufficient to just say "I trust
this commit". But I essentially what to also say what I trust it
_for_ as well.?

So this would work for commit objects.

It would also work for tag objects, if you pointed people at the signature
object rather than the actual tag object.

regards,
--
Paul Jakma [hidden email] [hidden email] Key ID: 64A2FF6A
Fortune:
Humor in the Court:
Q.  Were you aquainted with the deceased?
A.  Yes, sir.
Q.  Before or after he died?
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

David Greaves
In reply to this post by David A. Wheeler
David A. Wheeler wrote:
  > $ cat-file signature 000195297c2a6336c2007548f909769e0862b509
minor comment, cat-file gives you raw access to the object data.

better:
$ cat-file signature $(what-signs 000195297c2a6336c2007548f909769e0862b509)

> signatureof commit 000195297c2a6336c2007548f909769e0862b509
> signer Petr Baudis <[hidden email]>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQBCbFaRCxlT/+f+SU4RAgYSAKCWpPNlDKDkxuuA649zJop7WkQPnACdF1Fg
> JgXatbJU8YJ7JHqvgyGepRU=
> =Kttg
> -----END PGP SIGNATURE-----

David


--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: Git-commits mailing list feed.

7eggert (Bugzilla)
In reply to this post by Paul Jakma
Matt Domsch <[hidden email]> wrote:

> --------------
> sign

> gpg --armor --clearsign --detach-sign --default-key "${DEFAULT_KEY} -v -v -o -
> ${1} | \ ${CUTSIG} > ${1}.sign

Use quotes!

> exit 0

The exit code should reflect the status from gpg.
If gpg failed, you might also want to remove the .sign file.

--
Top 100 things you don't want the sysadmin to say:
37. What is all this I here about static charges destroying computers?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/