* Re: Git-commits mailing list feed.
From: Junio C Hamano @ 2005-04-23 20:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sean, Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <7vis2d2rmv.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == I said:
JCH> If that is the case, can't you do it without introducing this
JCH> new tag object, like this?
Of course It Would Not Work. I am an idiot X-<. Sorry. What I
suggested does not authenticate the tag itself.
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 20:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sean, Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <7vis2d2rmv.fsf@assigned-by-dhcp.cox.net>
On Sat, 23 Apr 2005, Junio C Hamano wrote:
>
> If that is the case, can't you do it without introducing this
> new tag object, like this?
No, because I also want to sign the _name_ I gave it.
Otherwise somebody can take my "signed commit", and claim that I called it
something else.
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.
And sure, I could make a totally bogus "commit" object that just points to
the original commit, uses the same "tree" from that original commit, and
write what I want to trust into that commit. I then sign that, and create
yet _another_ commit that has the signature (and the pointer to the just
signed commit) in its commit message, and then I point to _that_ commit.
So yes, we can certainly do this with playing games with commits. That
sounds singularly ugly, though, since just doing a "tag" object is a lot
more straightforward, and really tells the world what's going on (and
makes it easy for automated tools to just browse the object database and
see "that's a tag").
Linus
^ permalink raw reply
* Re: Humble request of 'git' developers
From: Chris Wedgwood @ 2005-04-23 20:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <426AAB65.2060401@pobox.com>
On Sat, Apr 23, 2005 at 04:09:09PM -0400, Jeff Garzik wrote:
> * flat namespaces grow cumbersome
agreed
> * if everybody uses the 'git' command, which does all the internal
> execution, then it's just namespace pollution.
sure, but not everyone body is
i agree everybody *should* and then it can go into <prefix>/libexec or
similar
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Jeff Garzik @ 2005-04-23 20:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org>
Linus Torvalds wrote:
> That was my plan, at least. But I haven't set up any signature generation
> thing, and this really isn't my area of expertise any more. But my _plan_
> literally was to have the tag object look a lot like a commit object, but
> instead of pointing to the tree and the commit parents, it would point to
> the commit you are tagging. Somehting like
>
> commit a2755a80f40e5794ddc20e00f781af9d6320fafb
> tag v2.6.12-rc3
> signer Linus Torvalds
>
> This is my official original 2.6.12-rc2 release
>
> -----BEGIN PGP SIGNATURE-----
> ....
> -----END PGP SIGNATURE-----
> with a few fixed headers and then a place for free-form commentary,
groovy
> If somebody writes a script to generate the above kind of thing (and tells
> me how to validate it), I'll do the rest, and start tagging things
> properly. Oh, and make sure the above sounds sane (ie if somebody has a
> better idea for how to more easily identify how to find the public key to
> check against, please speak up).
[tangent]
Any chance you'll have a tree tagged with older releases?
Is someone with access to BK working on that?
I do a lot of patch merges where someone sends me a 2.6.10 patch.
Presuming the fix is still valid, I'll clone to 2.6.10, merge the patch,
pull 2.6.latest into the 2.6.10-based repo, then push the whole she-bang
into one of my for-upstream repos.
Jeff
^ permalink raw reply
* Re: [PATCH] make file merging respect permissions
From: Linus Torvalds @ 2005-04-23 20:17 UTC (permalink / raw)
To: James Bottomley; +Cc: Git Mailing List
In-Reply-To: <1114280570.5068.5.camel@mulgrave>
On Sat, 23 Apr 2005, James Bottomley wrote:
>
> The attached fixes both issues
The attached patch was seriously corrupt. Did you edit it by hand? The
second chunk of the git-merge-one-file-script patch claims to have 12
source lines, but only has 11, causing patch no end of confusion.
I fixed up the line counts by hand, and the end result looked almost sane,
but when looking closer, I noticed the
+ if [ $ -ne 0 ]; then
+ echo "ERROR: Leaving conflict merge in $src2"
exit 1
which just can't be right either ("$" never equals 0, so the above will
always report an error), so I assume that whatever editing you did was
really quite corrupt. Yeah, yeah, you obviously meant "$?", but the fact
is, your patch is bogus, and I don't trust it. Can you re-send a valid one
(and sign off on it).
Linus
^ permalink raw reply
* Re: Humble request of 'git' developers
From: Jeff Garzik @ 2005-04-23 20:09 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: git
In-Reply-To: <20050423200246.GA5448@taniwha.stupidest.org>
Chris Wedgwood wrote:
> On Sat, Apr 23, 2005 at 03:58:26PM -0400, Jeff Garzik wrote:
>
>
>>Please stop filling up my /usr/local/bin :)
>
>
> why?
>
>
>>Just have one 'git' script, which looks in /usr/local/libexec/git
>>for further scripts and backends programs like write-tree and
>>diff-cache.
>
>
> how is that really any better?
Because
* flat namespaces grow cumbersome
* if everybody uses the 'git' command, which does all the internal
execution, then it's just namespace pollution.
* using a multi-level namespace allows you to create commands like "rm"
and "mv" by simply dropping that stuff into /usr/libexec/git, without
having to worry about conflicting with rm(1) and mv(1).
Jeff
^ permalink raw reply
* Re: Humble request of 'git' developers
From: Chris Wedgwood @ 2005-04-23 20:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <426AA8E2.60403@pobox.com>
On Sat, Apr 23, 2005 at 03:58:26PM -0400, Jeff Garzik wrote:
> Please stop filling up my /usr/local/bin :)
why?
> Just have one 'git' script, which looks in /usr/local/libexec/git
> for further scripts and backends programs like write-tree and
> diff-cache.
how is that really any better?
> Also, please don't assume that "." is in PATH. I think there is at
> least one invocation of commit-id with that assumption, in
> git-pasky-0.6.3.
That I'll buy. I don't know of anyone who places "." in PATH.
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 20:01 UTC (permalink / raw)
To: Jan Harkes
Cc: Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <20050423184613.GE20410@delft.aura.cs.cmu.edu>
On Sat, 23 Apr 2005, Jan Harkes wrote:
>
> It is a bit more messy, but it can be done with a detached signature.
Ok, this looks more like it.
Except:
> To sign,
> gpg -ab unsigned_commit
> cat unsigned_commit unsigned_commit.asc > signed_commit
>
> To verify,
> cat signed_commit | sed '/-----BEGIN PGP/Q' | gpg --verify signed_commit -
Except I think you'd need to searc for the "---BEGIN PGP" starting from
the end, rather than the beginning.
Anyway, that should be workable. I'll whip something up.
Linus
^ permalink raw reply
* Humble request of 'git' developers
From: Jeff Garzik @ 2005-04-23 19:58 UTC (permalink / raw)
To: git
Please stop filling up my /usr/local/bin :)
Just have one 'git' script, which looks in /usr/local/libexec/git for
further scripts and backends programs like write-tree and diff-cache.
Also, please don't assume that "." is in PATH. I think there is at
least one invocation of commit-id with that assumption, in git-pasky-0.6.3.
Jeff
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Junio C Hamano @ 2005-04-23 19:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sean, Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231234550.2344@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Guys, I will say this once more: git will not look at the signature.
LT> And that is why I from the very beginning tried to make ti very clear that
LT> the signature goes at the end. Not at the beginning, not in the middle,
LT> and not in a different file. IT GOES AT THE END.
If that is the case, can't you do it without introducing this
new tag object, like this?
1. Find existing commit-id that you want to tag.
2. Sign that commit object:
cat-file commit $commit |
gpg --detach-sign --armor -u 'Linus Torvalds' >commit.sig
3. Make another commit, making the original commit as its parent:
{
echo tag This is my tag.
cat commit.sig
} | commit-tree $(cat-file commit $commit |
sed -e 's/tree //;d') -p $commit
Then you can publish the ID of this commit object, which attests
that the original commit is what you vouch for. Am I missing
something?
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 19:58 UTC (permalink / raw)
To: Sean
Cc: Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <1907.10.10.10.24.1114281858.squirrel@linux1>
On Sat, 23 Apr 2005, Sean wrote:
>
> Okay now you're just being difficult <g> You're acting like it's
> impossible for git to grab the SHA1 out of the clear text message if there
> is signing overhead above the tag reference. That is nonesense.
No. It's not "impossible" for git to parse crap. But git won't.
There are two ways you can write programs:
- reliably
- unreliably
and I do the first one. That means that a program I write does something
_repeatable_. It does the same thing, regardless of whether a human
happened to write "REF:" in the comment section, or anything else.
The thing is, great programs come not out of great coding, but out of
great data structures. The whole git philosophy bases itself on getting
the data structure right.
And what you are asking for is doing it _wrong_. So in git I don't just
parse random free-form text and guess that a line that starts with REF: is
a reference to a commit. It has very rigid and well-specified data
structures, and that's how you make reliable programs.
I don't care what anybody else does on top of git, but dammit, I'll make
sure that the core infrastructure is designed the right way.
And that means that we don't guess, and that we don't parse random ASCII
blobs. It means that we have very very fixed formats so that programs can
either do the right thing or unambiguously say "that's crap".
I've said it before, and I'll say it again: we have enough crap that calls
itself SCM's out there already. I want git to be reliable and _simple_,
not a collection of crap that just happens to work.
Linus
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Sean @ 2005-04-23 18:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231234550.2344@ppc970.osdl.org>
On Sat, April 23, 2005 3:38 pm, Linus Torvalds said:
> On Sat, 23 Apr 2005, Sean wrote:
>>
>> A script that knows how to validate signed tags, can easly strip off all
>> the signing overhead for display. Users of scripts that don't
>> understand
>> will see the cruft, but at least it will still be usable.
>
> 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.
Yes, totally agreed.
> 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.
>
Okay now you're just being difficult <g> You're acting like it's
impossible for git to grab the SHA1 out of the clear text message if there
is signing overhead above the tag reference. That is nonesense. You
simply state that tag must include a SHA1 object reference preceded by
"REF:" in the comment. Git can surely use this regardless of what
signing overhead is above, below or beside it. The suggestion for
stripping out the signing overhead was for _human_ readability; git won't
care a gnit.
Sean
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 19:38 UTC (permalink / raw)
To: Sean
Cc: Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <2911.10.10.10.24.1114279589.squirrel@linux1>
On Sat, 23 Apr 2005, Sean wrote:
>
> A script that knows how to validate signed tags, can easly strip off all
> the signing overhead for display. Users of scripts that don't understand
> will see the cruft, but at least it will still be usable.
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.
Linus
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 19:34 UTC (permalink / raw)
To: Sean
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <2646.10.10.10.24.1114278656.squirrel@linux1>
On Sat, 23 Apr 2005, Sean wrote:
>
> Why not leave tags open to being signed or unsigned?
That is exactly what my proposal does, except I'd make the normal tags
creation always sign.
But since _git_ won't care which is why I want the signature at the _end_,
not "surrpunding" the thing, you could create a tag that just doesn't have
the signature, and git will never even notice. The people who see the tag
may say "hmm, why couldn't he be bothered to sign it", though.
Linus
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 19:30 UTC (permalink / raw)
To: Jan Harkes
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <20050423183406.GD20410@delft.aura.cs.cmu.edu>
On Sat, 23 Apr 2005, Jan Harkes wrote:
>
> Why not keep the tags object outside of the tree in the tags/ directory.
Because then you have all those special cases with fetching them and with
fsck, and with shared object directories. In other words: no.
You can have symlinks (or even better, just a single file with all the
tags listed, which you can create with "fsck", for example) from the tags/
directory, but the thing is, objects go in the object directory and
nowhere else.
Linus
^ permalink raw reply
* Suggestion: generalize signed tags into "assertion objects"
From: David A. Wheeler @ 2005-04-23 19:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Jan Dittmer, Greg KH, Git Mailing List,
Petr Baudis
In-Reply-To: <Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org>
Linus Torvalds wrote:
> The git-pasky "just remember the tag name" approach certainly works, but I
> was literally thinking o fsetting up some signing system, so that a tag
> doesn't just say "commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is
> v2.6.12-rc2", but it would actually give stronger guarantees, ie it would
> say "Linus says that commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is
> his 2.6.12-rc2 release".
>
> That's something fundamentally more powerful, and it's also something that
> I actually can integrate better into git.
>
> 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 thinking out loud here, but maybe instead of just "tag objects",
how about broadening them into "assertion objects" that include
(1) a claim and (2) a signature. Monotone, for example,
can do this -- it has a generalized mechanism for signed assertions.
A claim might be that some commit is a tag
("Linus Torvalds says this is tag 2.6.12-rc2") or even "I did this"
("Greg KH really committed this"). You could create the latter objects
when you push (just sign the head commit), and that would make it
really easy to do checks across an entire repository (who said what?).
Currently people can send signed emails that they really DID
commit something, but then that data's not available to everyone else.
Signed assertions about commits would suddenly make it possible for
arbitrary people to detect & counter subverted repositories (if they
have the public key list); fsck-cache could check signatures as it went.
With a more generalized assertion mechanism,
you could make the same assertion multiple times, e.g., if
your key gets captured, you could go back and re-sign with a new key,
simply creating a new assertion object. You can also make
assertions about multiple objects (e.g., assert some relationship
between far-removed commits). I'd expect assertion
objects to be stored by their hash, just like any other object.
> Then you just distribute these tag objects along with all the other
> objects, and fsck-cache can pick them up even without any other knowledge,
> but normally you'd actually point to them some other way too, ie you could
> have the ".git/tags/xxx" files have the pointers, but now they are
> _validated_ pointers.
Yes, that makes sense. I think .git/tags/xxx should point to
the assertion objects that claim they are tags; you can then check
if you accept the assertion object's signature when you try to use it
(and locally cache that acceptance once you've checked the signature).
For generalized assertion objects, you need a way to travel FROM
the object(s) being described TO the assertion object.
A simple method might be to create subdirectories with the name
derived from the object(s) being described, and inside the
subdirectory have a set of files that have the hashes of
the assertion objects. E.G., this kind of structure
00/
10f32aca7ba78e2cd95dcfedee0e6329edb735 (commit object)
10f32aca7ba78e2cd95dcfedee0e6329edb735.d/
1038e8b8e04b287ec876594cbab9df4af09ce131 ->
../../1038e8b8e04b287ec876594cbab9df4af09ce131
10/
38e8b8e04b287ec876594cbab9df4af09ce131 (assertion object)
There's no reason you can't point to assertions from
multiple places, which would make them cheap to find when needed.
One problem with symlinks is that some dopey filesystems
don't support them :-(. In this case, though, if they got copied
multiple times they'd just waste space & not interfere
with meaning, since they'd all be static read-only.
An alternative would be 0-length files whose names are the hashes.
...
> Somehting like
>
> commit a2755a80f40e5794ddc20e00f781af9d6320fafb
> tag v2.6.12-rc3
> signer Linus Torvalds
>
> This is my official original 2.6.12-rc2 release
>
> -----BEGIN PGP SIGNATURE-----
> ....
> -----END PGP SIGNATURE-----
--- David A. Wheeler
^ permalink raw reply
* [resend#2] [PATCH] Add -i option to cat-file to allow operation on displaced git object files
From: Jon Seymour @ 2005-04-23 18:27 UTC (permalink / raw)
To: Git Mailing List; +Cc: torvalds, jon.seymour
[PATCH] Add -i option to cat-file to allow operation on displaced git object files
For the purposes of merging the contents of remote git object repositories at the filesystem level, it would
be helpful to be able to verify the integrity of a remote git object file before it is actually
copied into the local repository.
To enable this, the option syntax for the usage of the cat-file tool is extended with a -i option, per the
modified usage string quoted below:
usage: cat-file [-t | tagname] <sha1> [ -i displaced-git-object-file ]
If the -i option is specified, cat-file uses the filename specified on the command line rather than the derived
filename to locate and process the git object file implied by the sha1 argument.
In addition, the -i option forces cat-file to check the SHA1 signature of the specified input file against
the SHA1 signature specified on the command line and report an error if there is a mismatch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Apologies for the repeated attempts to mail this patch. I'll use qmail in future!
---
Index: cache.h
=================================--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/cache.h (mode:100644 sha1:bf30ac4741d2eeeb483079f566182505898082f3)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/cache.h (mode:100644 sha1:56eacfa0ab43c93a838efedca429e865c95f16bc)
@@ -121,8 +121,9 @@
extern void * map_sha1_file(const unsigned char *sha1, unsigned long *size);
extern void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size);
extern void * read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size);
+extern void * read_displaced_sha1_file(char *type, unsigned long *size, const char *filename);
extern int write_sha1_file(char *buf, unsigned len, unsigned char *return_sha1);
-extern int check_sha1_signature(unsigned char *sha1, void *buf, unsigned long size, const char *type);
+extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
/* Read a tree into the cache */
extern int read_tree(void *buffer, unsigned long size, int stage);
Index: cat-file.c
=================================--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/cat-file.c (mode:100644 sha1:3c47d79a16305d326a65768fe9f37ee25928510b)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/cat-file.c (mode:100644 sha1:c88df7287b6ce7d6d33d016ffb524cc5a793cad2)
@@ -5,16 +5,32 @@
*/
#include "cache.h"
+static char _usage[]"cat-file [-t | tagname] <sha1> [ -i displaced-git-object-file ]";
+
int main(int argc, char **argv)
{
unsigned char sha1[20];
char type[20];
- void *buf;
+ void *buf NULL;
unsigned long size;
- if (argc ! || get_sha1_hex(argv[2], sha1))
- usage("cat-file [-t | tagname] <sha1>");
- buf read_sha1_file(sha1, type, &size);
+ if (argc < 3 || get_sha1_hex(argv[2], sha1))
+ usage(_usage);
+
+ if (argc = 3) {
+ buf read_sha1_file(sha1, type, &size);
+ } else if (argc = 5 && !strcmp(argv[3], "-i")) {
+ buf read_displaced_sha1_file(type, &size, argv[4]);
+ if (!buf)
+ die("bad file: %s", argv[4]);
+
+ if (check_sha1_signature(sha1, buf, size, type) < 0)
+ die("signature mismatch for %s", argv[4]);
+
+ } else {
+ usage(_usage);
+ }
+
if (!buf)
die("cat-file %s: bad file", argv[2]);
if (!strcmp("-t", argv[1])) {
Index: sha1_file.c
=================================--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/sha1_file.c (mode:100644 sha1:6f7228e106d4e24b18f8416cc6adc2a6fd303eb7)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/sha1_file.c (mode:100644 sha1:25e2e8b22cf9590a6df05f234ce88db8c2cd1030)
@@ -80,7 +80,7 @@
return base;
}
-int check_sha1_signature(unsigned char *sha1, void *map, unsigned long size, const char *type)
+int check_sha1_signature(const unsigned char *sha1, void *map, unsigned long size, const char *type)
{
char header[100];
unsigned char real_sha1[20];
@@ -93,13 +93,12 @@
return memcmp(sha1, real_sha1, 20) ? -1 : 0;
}
-void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
+static void *map_file(const char *filename, unsigned long *size)
{
- char *filename sha1_file_name(sha1);
- int fd open(filename, O_RDONLY);
struct stat st;
void *map;
+ int fd open(filename, O_RDONLY);
if (fd < 0) {
perror(filename);
return NULL;
@@ -116,6 +115,12 @@
return map;
}
+void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
+{
+ char *filename sha1_file_name(sha1);
+ return map_file(filename, size);
+}
+
void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size)
{
int ret, bytes;
@@ -166,6 +171,20 @@
return NULL;
}
+void * read_displaced_sha1_file(char *type, unsigned long *size, const char *filename)
+{
+ unsigned long mapsize;
+ void *map, *buf;
+
+ map map_file(filename, &mapsize);
+ if (map) {
+ buf unpack_sha1_file(map, mapsize, type, size);
+ munmap(map, mapsize);
+ return buf;
+ }
+ return NULL;
+}
+
void *read_tree_with_tree_or_commit_sha1(const unsigned char *sha1,
unsigned long *size,
unsigned char *tree_sha1_return)
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Sean @ 2005-04-23 18:14 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: Linus Torvalds, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <20050423190257.GA4194@cip.informatik.uni-erlangen.de>
On Sat, April 23, 2005 3:02 pm, Thomas Glanzmann said:
> Hello,
>
>> Why not leave tags open to being signed or unsigned?
>
> I think that this is the idea anyway.
>
>> For presentation in the log or whatever, the script can look inside the
>> clear text message, grab the SHA1 and display it in the header area;
>> even
>> though it's not really in the header, always just in the clear text
>> area.
>
> Having the SHA1 signature twice in would be confusing and error-prone
> when checking is done automated.
>
> So establishing the infrastructure is a good thing. To use it for every
> commit is another issue.
There's no need to have the SHA1 object reference twice. It will only be
in the clear text, nowhere else. Of course scripts that display the log,
could show the object reference in the header area for aesthetics.
Another nice thing is that this works no matter cleartext signing methods
emerge in the future.
Sean
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Thomas Glanzmann @ 2005-04-23 19:02 UTC (permalink / raw)
To: Sean
Cc: Linus Torvalds, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <2646.10.10.10.24.1114278656.squirrel@linux1>
Hello,
> Why not leave tags open to being signed or unsigned?
I think that this is the idea anyway.
> For presentation in the log or whatever, the script can look inside the
> clear text message, grab the SHA1 and display it in the header area; even
> though it's not really in the header, always just in the clear text area.
Having the SHA1 signature twice in would be confusing and error-prone
when checking is done automated.
So establishing the infrastructure is a good thing. To use it for every
commit is another issue.
Thomas
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Sean @ 2005-04-23 18:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org>
On Sat, April 23, 2005 2:30 pm, Linus Torvalds said:
> On Sat, 23 Apr 2005, Thomas Glanzmann wrote:
>> # This creates the signature.
>> gpg --clearsign < sign_this > signature
>
> This really doesn't work for me - I do not want to have the gpg header
above it, only the signature below. Since I want git to actually
understand the tags, but do _not_ want git to have to know about
whatever
> signing method was used, I really want the resulting file to look like
>
> commit ....
> tag ...
>
> here goes comment
> here goes signature
>
> and no headers.
>
> Whether that can be faked by always forcing SHA1 as the hash, and then
just removing the top lines, and re-inserting them when verifying, or
whether there is some mode to make gpg not do the header crud at all, I
don't know. Which is exactly why I never even got started.
Linus,
A script that knows how to validate signed tags, can easly strip off all
the signing overhead for display. Users of scripts that don't understand
will see the cruft, but at least it will still be usable.
Sean
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Junio C Hamano @ 2005-04-23 18:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I really want the resulting file to look like
LT> commit ....
LT> tag ...
LT> here goes comment
LT> here goes signature
LT> and no headers.
You can use --detach-sign with --armor, like this.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
#!/bin/sh
sq=s/\'/\''\\'\'\'/g
usage="usage: $0 [--signer=...] commit-id tag < message"
while case "$#" in 0) break;; esac
do
case "$1" in
-s=*|--s=*|--si=*|--sig=*|--sign=*|--signe=*|--signer=*)
signer=`expr "$1" : '-[^=]*=\(.*\)'` ;;
-s|--s|--si|--sig|--sign|--signe|--signer)
case "$#" in 0 | 1) echo "$usage"; exit 1 ;; esac
signer="${2?}"
shift ;;
--)
shift
break ;;
-*)
echo "$usage"
exit 1 ;;
*)
break ;;
esac
shift
done
case "$#" in 2) echo >&2 "$usage"; exit 1 ;; esac
commit="$1" tag="$2"
case "$signer" in
'') signer_arg='' ;;
?*) signer_arg="--local-user '$(echo "$signer" | sed -e "$sq")'" ;;
esac
tmp=.jit-tag.$$
trap 'rm -f $tmp-*' 0 1 2 3 15
tagblob=$tmp-tagblob
tagsign=$tmp-tagsign
case $(cat-file -t "$commit" 2>/dev/null) in
commit) ;;
*) echo >&2 "$0: $commit is not a commit object"; exit 1 ;;
esac
{
echo "commit $commit"
echo "tag $tag"
case "$signer" in
'') ;;
?*) echo "signer $signer" ;;
esac
echo
tty -s && echo >&2 "Type your tag message and end with ^D."
cat
} >$tagblob || exit
gpgcmd="gpg $signer_arg -a --output $tagsign --detach-sign $tagblob"
eval "$gpgcmd" || exit
cat $tagblob $tagsign
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Thomas Glanzmann @ 2005-04-23 18:44 UTC (permalink / raw)
To: Linus Torvalds, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <20050423183909.GC7100@cip.informatik.uni-erlangen.de>
Hello,
> # This creates only the signature in Ascii Armor.
> gpg -a --detach-sign < to_sign > signature
# And to verify:
gpg --verify signature to_sign
Thomas
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Sean @ 2005-04-23 17:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231010580.2344@ppc970.osdl.org>
On Sat, April 23, 2005 1:31 pm, Linus Torvalds said:
> If somebody writes a script to generate the above kind of thing (and
tells me how to validate it), I'll do the rest, and start tagging things
properly. Oh, and make sure the above sounds sane (ie if somebody has a
better idea for how to more easily identify how to find the public key to
> check against, please speak up).
>
Hi Linus,
Why not leave tags open to being signed or unsigned? Anyone that wants to
create a trusted tag could simply sign their cleartext entry in the tag
object.
Ideally the SHA1 tree reference would be included in the text entry
whether it was signed or not. Thus any script can pull the SHA1 out of
the text entry. And a script that understands the signing method can
verify it. But scripts that don't understand the signing method can still
use the tag.
For presentation in the log or whatever, the script can look inside the
clear text message, grab the SHA1 and display it in the header area; even
though it's not really in the header, always just in the clear text area.
Sean
^ permalink raw reply
* [resend] [PATCH] Add -i option to cat-file to allow operation on displaced git object files
From: Jon Seymour @ 2005-04-23 18:48 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205042311272baee82e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
[PATCH] Add -i option to cat-file to allow operation on displaced git
object files
For the purposes of merging the contents of remote git object
repositories at the filesystem level, it would be helpful to be able
to verify the integrity of a remote git object file before it is
actually copied into the local repository.
To enable this, the option syntax for the usage of the cat-file tool
is extended with a -i option, per the modified usage string quoted
below:
usage: cat-file [-t | tagname] <sha1> [ -i displaced-git-object-file ]
If the -i option is specified, cat-file uses the filename specified on
the command line rather than the derived filename to locate and
process the git object file implied by the sha1 argument.
In addition, the -i option forces cat-file to check the SHA1 signature
of the specified input file against the SHA1 signature specified on
the command line and report an error if there is a mismatch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Sorry, I noticed after the fact that gmail had line-wrapped my patch,
so I am resending the patch as a text attachment. If it is not
acceptable to post patches in this form please let me know.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 5261 bytes --]
[PATCH] Add -i option to cat-file to allow operation on displaced git object files
For the purposes of merging the contents of remote git object repositories at the filesystem level, it would
be helpful to be able to verify the integrity of a remote git object file before it is actually
copied into the local repository.
To enable this, the option syntax for the usage of the cat-file tool is extended with a -i option, per the
modified usage string quoted below:
usage: cat-file [-t | tagname] <sha1> [ -i displaced-git-object-file ]
If the -i option is specified, cat-file uses the filename specified on the command line rather than the derived
filename to locate and process the git object file implied by the sha1 argument.
In addition, the -i option forces cat-file to check the SHA1 signature of the specified input file against
the SHA1 signature specified on the command line and report an error if there is a mismatch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
--
Index: cache.h
===================================================================
--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/cache.h (mode:100644 sha1:bf30ac4741d2eeeb483079f566182505898082f3)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/cache.h (mode:100644 sha1:56eacfa0ab43c93a838efedca429e865c95f16bc)
@@ -121,8 +121,9 @@
extern void * map_sha1_file(const unsigned char *sha1, unsigned long *size);
extern void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size);
extern void * read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size);
+extern void * read_displaced_sha1_file(char *type, unsigned long *size, const char *filename);
extern int write_sha1_file(char *buf, unsigned len, unsigned char *return_sha1);
-extern int check_sha1_signature(unsigned char *sha1, void *buf, unsigned long size, const char *type);
+extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
/* Read a tree into the cache */
extern int read_tree(void *buffer, unsigned long size, int stage);
Index: cat-file.c
===================================================================
--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/cat-file.c (mode:100644 sha1:3c47d79a16305d326a65768fe9f37ee25928510b)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/cat-file.c (mode:100644 sha1:c88df7287b6ce7d6d33d016ffb524cc5a793cad2)
@@ -5,16 +5,32 @@
*/
#include "cache.h"
+static char _usage[]="cat-file [-t | tagname] <sha1> [ -i displaced-git-object-file ]";
+
int main(int argc, char **argv)
{
unsigned char sha1[20];
char type[20];
- void *buf;
+ void *buf = NULL;
unsigned long size;
- if (argc != 3 || get_sha1_hex(argv[2], sha1))
- usage("cat-file [-t | tagname] <sha1>");
- buf = read_sha1_file(sha1, type, &size);
+ if (argc < 3 || get_sha1_hex(argv[2], sha1))
+ usage(_usage);
+
+ if (argc == 3) {
+ buf = read_sha1_file(sha1, type, &size);
+ } else if (argc == 5 && !strcmp(argv[3], "-i")) {
+ buf = read_displaced_sha1_file(type, &size, argv[4]);
+ if (!buf)
+ die("bad file: %s", argv[4]);
+
+ if (check_sha1_signature(sha1, buf, size, type) < 0)
+ die("signature mismatch for %s", argv[4]);
+
+ } else {
+ usage(_usage);
+ }
+
if (!buf)
die("cat-file %s: bad file", argv[2]);
if (!strcmp("-t", argv[1])) {
Index: sha1_file.c
===================================================================
--- e6d3a81c30ad237102e2ca82f3dfc57d0b9f0ddf/sha1_file.c (mode:100644 sha1:6f7228e106d4e24b18f8416cc6adc2a6fd303eb7)
+++ 1b503f0571727a865b413e28641d2be09c8c3304/sha1_file.c (mode:100644 sha1:25e2e8b22cf9590a6df05f234ce88db8c2cd1030)
@@ -80,7 +80,7 @@
return base;
}
-int check_sha1_signature(unsigned char *sha1, void *map, unsigned long size, const char *type)
+int check_sha1_signature(const unsigned char *sha1, void *map, unsigned long size, const char *type)
{
char header[100];
unsigned char real_sha1[20];
@@ -93,13 +93,12 @@
return memcmp(sha1, real_sha1, 20) ? -1 : 0;
}
-void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
+static void *map_file(const char *filename, unsigned long *size)
{
- char *filename = sha1_file_name(sha1);
- int fd = open(filename, O_RDONLY);
struct stat st;
void *map;
+ int fd = open(filename, O_RDONLY);
if (fd < 0) {
perror(filename);
return NULL;
@@ -116,6 +115,12 @@
return map;
}
+void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
+{
+ char *filename = sha1_file_name(sha1);
+ return map_file(filename, size);
+}
+
void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size)
{
int ret, bytes;
@@ -166,6 +171,20 @@
return NULL;
}
+void * read_displaced_sha1_file(char *type, unsigned long *size, const char *filename)
+{
+ unsigned long mapsize;
+ void *map, *buf;
+
+ map = map_file(filename, &mapsize);
+ if (map) {
+ buf = unpack_sha1_file(map, mapsize, type, size);
+ munmap(map, mapsize);
+ return buf;
+ }
+ return NULL;
+}
+
void *read_tree_with_tree_or_commit_sha1(const unsigned char *sha1,
unsigned long *size,
unsigned char *tree_sha1_return)
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Thomas Glanzmann @ 2005-04-23 18:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231125330.2344@ppc970.osdl.org>
Hello,
> commit ....
> tag ...
> here goes comment
> here goes signature
# This creates only the signature in Ascii Armor.
gpg -a --detach-sign < to_sign > signature
Thomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox