* 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
* Re: Git-commits mailing list feed.
From: Jan Harkes @ 2005-04-23 18:46 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, Apr 23, 2005 at 11:30:36AM -0700, Linus Torvalds wrote:
> 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.
It is a bit more messy, but it can be done with a detached signature.
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 -
Jan
^ permalink raw reply
* git-changes-script to show inter tree changes
From: James Bottomley @ 2005-04-23 18:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
One of the features I found most useful about bk changes was the ability
to see changes in my tree that weren't in the other tree (I use this to
keep track of what patches I actually have).
I've modified the gitlog script to take the -L and -R options (local
directories only; won't work on remotes like bk changes would) to add
this functionality.
James
#!/bin/bash
#
# Make a log of changes in a GIT branch.
#
# This script was originally written by (c) Ross Vandegrift.
# Adapted to his scripts set by (c) Petr Baudis, 2005.
# Major optimizations by (c) Phillip Lougher.
# Rendered trivial by Linus Torvalds.
# Added -L|-R option by James Bottomley
#
# options:
# script [-L <dir> | -R <dir> |-r <from_sha1> [ -r <to_sha1] ] [<sha1>]
#
# With no options shows all the revisions from HEAD to the root
# -L shows all the changes in the local tree compared to the tree at <dir>
# -R shows all the changes in the remote tree at <dir> compared to the local
# -r shows all the changes in one commit or between two
tmpfile=/tmp/git_changes.$$
r1=
r2=
showcommit() {
commit="$1"
echo commit ${commit%:*};
cat-file commit $commit | \
while read key rest; do
case "$key" in
"author"|"committer")
date=(${rest#*> })
sec=${date[0]};
pdate="$(date -Rd "1970-01-01 UTC + $sec sec" 2>/dev/null)"
if [ "$pdate" ]; then
echo $key $rest | sed "s/>.*/> ${pdate/+0000/$tz}/"
else
echo $key $rest
fi
;;
"")
echo; cat
;;
*)
echo $key $rest
;;
esac
done
}
while true; do
case "$1" in
-R) shift;
diffsearch=+
remote="$1"
shift;;
-L) shift;
diffsearch=-
remote="$1"
shift;;
-r) shift;
if [ -z "$r1" ]; then
r1="$1"
else
r2="$1"
fi
shift;;
*) base="$1"
break;;
esac
done
if [ -n "$r1" ]; then
if [ -z "$r2" ]; then
showcommit $r1
exit 0
fi
diffsearch=+
remote=`pwd`;
tobase="$r2";
base="$r1"
fi
if [ -z "$base" ]; then
base=$(cat .git/HEAD) || exit 1
fi
rev-tree $base | sort -rn > ${tmpfile}.base
if [ -n "$remote" ]; then
[ -d $remote/.git ] || exit 1
if [ -z "$tobase" ]; then
tobase=$(cat $remote/.git/HEAD) || exit 1
fi
pushd $remote > /dev/null
rev-tree $tobase | sort -rn > ${tmpfile}.remote
diff -u ${tmpfile}.base ${tmpfile}.remote | grep "^${diffsearch}[^${diffsearch}]" | cut -c 1- > ${tmpfile}.diff
rm -f ${tmpfile}.base ${tmpfile}.remote
mv ${tmpfile}.diff ${tmpfile}.base
if [ $diffsearch = "-" ]; then
popd > /dev/null
fi
fi
[ -s "${tmpfile}.base" ] || exit 0
cat ${tmpfile}.base | while read time commit parents; do
showcommit $commit
echo -e "\n--------------------------"
done
rm -f ${tmpfile}.base
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Jan Harkes @ 2005-04-23 18:34 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, Apr 23, 2005 at 10:31:28AM -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 see how we can use such a tag object to find a specific commit object
in the tree. But if you put the tag objects in the tree as well we now
have to figure out a way to find the tag objects.
Why not keep the tags object outside of the tree in the tags/ directory.
That way it is easy to find them, and simple to validate all tags or
update the signatures if you lost your key.
> 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).
Others already mentioned the gpg clearsign and verify options, to find a
public key that you haven't seen before it is probably easiest to use a
keyserver. If verify complains that it doesn't know a key it will print
a key-id that identifies it. That id can then be looked up as follows,
gpg --keyserver wwwkeys.pgp.net --search-keys 0xA86B35C5
gpg: searching for "0xA86B35C5" from hkp server wwwkeys.pgp.net
(1) Linus Torvalds <Linus.Torvalds@Helsinki.FI>
1024 bit RSA key A86B35C5, created: 1996-06-08
Keys 1-1 of 1 for "0xA86B35C5". Enter number(s), N)ext, or Q)uit > q
Ofcourse trusting a key obtained this way is another thing altogether,
and would probably depend on who signed it and such.
Jan
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 18:30 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <20050423175422.GA7100@cip.informatik.uni-erlangen.de>
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
^ 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