* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Jeff Garzik @ 2011-10-31 23:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, Linus Torvalds, git, James Bottomley,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On 10/31/2011 06:44 PM, Junio C Hamano wrote:
> "H. Peter Anvin"<hpa@zytor.com> writes:
>
>> On 10/31/2011 03:30 PM, Linus Torvalds wrote:
>>>
>>> But if you do the normal "git pull git://git.kernel.org/name/of/repo"
>>> - which is how things happen as a result of a pull request - you won't
>>> get tags at all - you have to ask for them by name or use "--tags" to
>>> get them all.
>>>
>>
>> Didn't realize that... I guess I'm too used to named remotes.
>>
>> If so, just using a tag should be fine, no?
>
> So nobody is worried about this (quoting from my earlier message)?
>
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine.
>
> A signed emphemeral tag is usable as means to verify authenticity in a
> hop-by-hop fashion, but that does not leave a permanent trail that can be
> used for auditing.
The main worry is Linus ($human_who_pulls) gets
cryptographically-verified data at the time he pulls. Once Linus
republishes his tree (git push), there will be few, if any, wanting to
verify Jeff Garzik's signature.
So no, I don't see that as a _driving_ need in the kernel's case.
And IMO the kernel will be a mix of signed and unsigned content for a
while, possibly forever.
And Linus wrote:
> [ Example gpg-signed small block that the attached patch adds to the
> pull request: ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Commit be3fa9125e708348c7baf04ebe9507a72a9d1800
> from git.kernel.org/pub/git
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
>
> iQEcBAEBAgAGBQJOrsILAAoJEHm+PkMAQRiGxZcH/31e0RrBitXUPKxHJajD58yh
> SIEe/7i6E2RUSFva3KybEuFslcR8p8DYzDQTPLejStvnkO8v0lXu9s9R53tvjLMF
> aaQXLOgrOC2RqvzP4F27O972h32YpLBkwIdWQGAhYcUOdKYDZ9RfgEgtdJwSYuL+
> oJ7TjLrtkcILaFmr9nYZC+0Fh7z+84R8kR53v0iBHJQOFfssuMjUWCoj9aEY12t+
> pywXuVk2FsuYvhniCAcyU6Y1K9aXaf6w5iOY2hx/ysXtUBnv92F7lcathxQkvgjO
> fA7/TXEcummOv5KQFc9vckd5Z1gN2ync5jhfnmlT2uiobE6mNdCbOVlCOpsKQkU=
> =l5PG
> -----END PGP SIGNATURE-----
This is my preference for kernel pull requests at the moment. That has
one advantage over Junio's "git pull --require-signature" and signed
commits, notably, the URL is signed.
But in general signed commits would be nice, too. pull-generated merge
requests would need to be signed, potentially introducing an additional
interactive step (GPG passphrase request) into an automated process.
Jeff
^ permalink raw reply
* Re: git rev-parse --since=1970-01-01 does not work reliably
From: Nguyen Thai Ngoc Duy @ 2011-10-31 23:13 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: git
In-Reply-To: <20111031161708.GA29924@altlinux.org>
On Mon, Oct 31, 2011 at 08:17:09PM +0400, Dmitry V. Levin wrote:
> Hi,
>
> git rev-parse --since=1970-01-01 (and other git commands that take
> date string arguments like --since) may fail when --since=1970-01-01 is
> given. Whether it fails or not depends on current time and timezone data.
> For example, "TZ=Europe/Paris git rev-parse --since=1970-01-01" fails two
> hours a day (between 00:00 and 02:00 CET), and those who use more eastern
> timezones are even less lucky. In artificial timezones like UTC-24 it
> always fails:
>
> $ TZ=UTC-24 git rev-parse --since=1970-01-01
> --max-age=18446744073709523490
Out of curiosity, why do you need to work with a time so close to that
date?
> The problem is that several internal git functions implicitly convert
> time_t to unsigned long, so when time_t gets negative, all date string
> processing breaks.
I don't think it's worth supporting negative time_t, but we should at
least avoid misconversion.
-- 8< --
Subject: [PATCH] Do not accept negative time_t
We use unsigned long internally to present time, negative value just
breaks thing.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
date.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/date.c b/date.c
index 353e0a5..9cbd521 100644
--- a/date.c
+++ b/date.c
@@ -653,8 +653,12 @@ int parse_date_basic(const char *date, unsigned long *timestamp, int *offset)
if (*timestamp == -1)
return -1;
- if (!tm_gmt)
+ if (!tm_gmt) {
+ if ((time_t)*timestamp < (time_t)*offset * 60)
+ die("unsupported time before Epoch");
*timestamp -= *offset * 60;
+ }
+
return 0; /* success */
}
@@ -722,6 +726,8 @@ static unsigned long update_tm(struct tm *tm, struct tm *now, unsigned long sec)
n = mktime(tm) - sec;
localtime_r(&n, tm);
+ if (n < 0)
+ die("unsupported time before Epoch");
return n;
}
--
1.7.4.74.g639db
-- 8< --
^ permalink raw reply related
* git-p4: problem with commit 97a21ca50ef8
From: Michael Wookey @ 2011-10-31 23:11 UTC (permalink / raw)
To: Git Mailing List, Pete Wyckoff, Luke Diamand
[ please CC me as I am not subscribed to the list ]
Hi,
Commit 97a21ca50ef893a171a50c863fe21a924935fd2a "git-p4: stop ignoring
apple filetype" isn't correct. Without knowing too much about how
git-p4 works, it appears that the "apple" filetype includes the
resource fork, and the "p4 print" that is used to obtain the content
from the perforce server doesn't take this into account, or maybe some
post processing of the file needs to be done to include the data, but
not the resource fork, before inclusion into the git repo.
With the above commit, a binary blob that literally contains the
resource fork and data is included within the git repo. Of course,
without the above commit, the intended file was never included in the
git repo at all. Perhaps the resource fork issue was a known problem
by the original git-p4 author.
A sample file that that demonstrates what the above commit produces is
here (use curl/wget):
http://dl.dropbox.com/u/1006983/sample_image_fail.png
This is literally a binary blob with about 110 KiB of resource fork
plus the PNG data. The same image, minus about 110 KiB of resource
fork is here:
http://dl.dropbox.com/u/1006983/sample_image_correct.png
I'm happy to test patches as we have a perforce repository with files
of the "apple" filetype.
Thanks
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 23:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vvcr4ojvp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> ...
> As I already said, I do not think notes is a good match as a tool to do
> this.
>
>> matters is that "git push" and "git pull" would JustWork(tm), and
>> check the signature if one exists, without having to cut-and-paste
>> data that simply shouldn't be visible to the user.
>>
>> I abhor the interface Ingo suggested, for example....
>
> Some cut-and-paste (or piping the e-mail to a command) would be necessary
> evil, though, as you would have GPG keys from more than one trusted person
> in your keyring, and when you are responding to a pull-request from person
> A, finding a valid commit signed by person B should not be a success, but
> at least should raise a warning.
So here is a quick hack that does not involve cut-and-paste (it depends on
the signed-commit topic in 'next').
$ git pull --require-signature
would trigger signature verification and stops you after fetching but
before merging.
git-pull.sh | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 9868a0b..f3b4c93 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -39,7 +39,7 @@ test -z "$(git ls-files -u)" || die_conflict
test -f "$GIT_DIR/MERGE_HEAD" && die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
-log_arg= verbosity= progress= recurse_submodules=
+log_arg= verbosity= progress= recurse_submodules= must_be_signed=
merge_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short="${curr_branch#refs/heads/}"
@@ -60,6 +60,8 @@ do
diffstat=--no-stat ;;
--stat|--summary)
diffstat=--stat ;;
+ --require-signature)
+ must_be_signed=yes ;;
--log|--no-log)
log_arg=$1 ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
@@ -208,6 +210,27 @@ orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
test -z "$dry_run" || exit 0
+if test -n "$must_be_signed"
+then
+ signature=$(git show -s --format='%G?' FETCH_HEAD)
+ case "$signature" in
+ G)
+ case "$verbosity" in
+ *' '-v*)
+ git show -s --show-signature FETCH_HEAD ;;
+ esac
+ ;;
+ B)
+ echo >&2 "Bad signature on the tip commit"
+ exit 1
+ ;;
+ *)
+ echo >&2 "Tip commit must be signed"
+ exit 1
+ ;;
+ fi
+fi
+
curr_head=$(git rev-parse -q --verify HEAD)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
then
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 23:03 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF2724.8040001@zytor.com>
On Mon, Oct 31, 2011 at 3:54 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 10/31/2011 03:52 PM, Linus Torvalds wrote:
>>
>> Save it in the commit we generate. BAM! Useful, readable, permanent,
>> and independently verifiable.
>>
>
> Note: this means creating a commit even for a fast-forward merge. Not
> that there is any technical problem with that, of course.
Well, only for the signed case, but yes. And for that case it's likely
a good thing.
In fact, even without signing, some projects always use --no-ff,
because they want the merge messages with the nice summary in them.
I've played around with it too, but haven't generally found it to be
worth it, and tend to think that it aggrandizes the merger too much.
It generates nice merge summaries, and it can look nice, but if the
*only* upside is the merge summary I think it's borderline worth it.
But with a signature, it would suddenly actually contain real
information, and I think that changes the equation.
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vvcr4ojvp.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Some cut-and-paste (or piping the e-mail to a command) would be necessary
> evil, though, as you would have GPG keys from more than one trusted person
> in your keyring, and when you are responding to a pull-request from person
> A, finding a valid commit signed by person B should not be a success, but
> at least should raise a warning.
Why?
The signer of the message needs to be printed out *anyway*. I can
match that up with the pull request, the same way I already match up
diffstat information.
So any extra cut-and-paste is (a) stupid, (b) unnecessary and (c) annoying.
It's also "bad user interface". The whole point is that we should make
the user interface *good*. Which means that the pushing side should
only need to add a "-s" to ask for signing, have to type his
passphrase (and even that would go away when using gpg-agent or
something), and perhaps a message (which would not be about the
signing, but about something that could be added to the merge commit.
And the receiving side would just do the "git pull" and automatically
just get notified that "Yes, this push has been signed by key Xyz
Abcdef"
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFwnVZ-mK3FChvFn778Z-cT107f4v-h0CDmwkP88=Z9aHA@mail.gmail.com>
On 10/31/2011 03:52 PM, Linus Torvalds wrote:
>
> Save it in the commit we generate. BAM! Useful, readable, permanent,
> and independently verifiable.
>
Note: this means creating a commit even for a fast-forward merge. Not
that there is any technical problem with that, of course.
-hpa
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> So nobody is worried about this (quoting from my earlier message)?
No, because you haven't been reading what we write.
The tag is useless.
The information *in* the tag is not. But it shouldn't be saved in the
tag (or note, or whatever). Because that's just an annoying place for
it to be, with no upside.
Save it in the commit we generate. BAM! Useful, readable, permanent,
and independently verifiable.
And the advantage is that we can make that same mechanism add
"maintainer notes" to the merge message too. Right now some
maintainers write good notes about what the merge will bring in, but
they are basically lost, because git is so good at merging and doesn't
even stop to ask people to edit the merge message.
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:51 UTC (permalink / raw)
To: Ted Ts'o, Junio C Hamano, Linus Torvalds, git,
James Bottomley
In-Reply-To: <20111031224905.GQ16825@thunk.org>
On 10/31/2011 03:49 PM, Ted Ts'o wrote:
> On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:
>> So nobody is worried about this (quoting from my earlier message)?
>>
>> On the other hand, the consumers of "Linus kernel" may want to say that
>> they trust your tree and your tags because they can verify them with your
>> GPG signature, but also they can independently verify the lieutenants'
>> trees you pulled from are genuine.
>>
>> A signed emphemeral tag is usable as means to verify authenticity in a
>> hop-by-hop fashion, but that does not leave a permanent trail that can be
>> used for auditing.
>
> Oh, there are definitely people who worry about this. They tend to be
> security poeple, though, so the goal is how do we leave the permanent
> trail in a way that doesn't generate too much noise or otherwise makes
> life difficult for developers who don't care.
>
Could we introduce a tag namespace that doesn't show up in gitweb by
default, and perhaps doesn't resolve in abbreviated form?
This is basically what Linus suggested, as far as I understand:
something like refs/pulls/hpa/tip-123-456 which is otherwise a normal
tag object?
-hpa
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 22:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFzedaAzzWfzhqVf8y8ZW0jeb56hZwdV3UodSp8Q_Qhc2A@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But seriously, I don't care about the *implementation* all that much.
> If people want to use the crazy git "notes" capability, you can do
> that too, although quite frankly, I don't see the point.
As I already said, I do not think notes is a good match as a tool to do
this.
> matters is that "git push" and "git pull" would JustWork(tm), and
> check the signature if one exists, without having to cut-and-paste
> data that simply shouldn't be visible to the user.
>
> I abhor the interface Ingo suggested, for example....
Some cut-and-paste (or piping the e-mail to a command) would be necessary
evil, though, as you would have GPG keys from more than one trusted person
in your keyring, and when you are responding to a pull-request from person
A, finding a valid commit signed by person B should not be a success, but
at least should raise a warning.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ted Ts'o @ 2011-10-31 22:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, Linus Torvalds, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 03:44:25PM -0700, Junio C Hamano wrote:
> So nobody is worried about this (quoting from my earlier message)?
>
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine.
>
> A signed emphemeral tag is usable as means to verify authenticity in a
> hop-by-hop fashion, but that does not leave a permanent trail that can be
> used for auditing.
Oh, there are definitely people who worry about this. They tend to be
security poeple, though, so the goal is how do we leave the permanent
trail in a way that doesn't generate too much noise or otherwise makes
life difficult for developers who don't care.
- Ted
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vzkggok6u.fsf@alter.siamese.dyndns.org>
On 10/31/2011 03:44 PM, Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> On 10/31/2011 03:30 PM, Linus Torvalds wrote:
>>>
>>> But if you do the normal "git pull git://git.kernel.org/name/of/repo"
>>> - which is how things happen as a result of a pull request - you won't
>>> get tags at all - you have to ask for them by name or use "--tags" to
>>> get them all.
>>>
>>
>> Didn't realize that... I guess I'm too used to named remotes.
>>
>> If so, just using a tag should be fine, no?
>
> So nobody is worried about this (quoting from my earlier message)?
>
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine.
>
> A signed emphemeral tag is usable as means to verify authenticity in a
> hop-by-hop fashion, but that does not leave a permanent trail that can be
> used for auditing.
>
Well, the permanent trail is in the maintainer's tree, but that might
still be suboptimal. The problem with Linus pulling those tags I assume
that it makes the tree too noisy?
-hpa
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 22:44 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF2245.90308@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> On 10/31/2011 03:30 PM, Linus Torvalds wrote:
>>
>> But if you do the normal "git pull git://git.kernel.org/name/of/repo"
>> - which is how things happen as a result of a pull request - you won't
>> get tags at all - you have to ask for them by name or use "--tags" to
>> get them all.
>>
>
> Didn't realize that... I guess I'm too used to named remotes.
>
> If so, just using a tag should be fine, no?
So nobody is worried about this (quoting from my earlier message)?
On the other hand, the consumers of "Linus kernel" may want to say that
they trust your tree and your tags because they can verify them with your
GPG signature, but also they can independently verify the lieutenants'
trees you pulled from are genuine.
A signed emphemeral tag is usable as means to verify authenticity in a
hop-by-hop fashion, but that does not leave a permanent trail that can be
used for auditing.
^ permalink raw reply
* [PATCH] svn: Quote repository root in regex match
From: Ted Percival @ 2011-10-31 22:37 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Ted Percival
Fixes a problem matching repository URLs, especially those with a '+' in
the URL, such as svn+ssh:// URLs. Parts of the URL were interpreted as
special characters by the regex matching.
Signed-off-by: Ted Percival <ted.percival@quest.com>
---
git-svn.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 351e743..4e95450 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -629,7 +629,7 @@ sub populate_merge_info {
fatal "merge commit $d has ancestor $parent, but that change "
."does not have git-svn metadata!";
}
- unless ($branchurl =~ /^$rooturl(.*)/) {
+ unless ($branchurl =~ /^\Q$rooturl\E(.*)/) {
fatal "commit $parent git-svn metadata changed mid-run!";
}
my $branchpath = $1;
@@ -791,7 +791,7 @@ sub cmd_dcommit {
."has uuid $uuid!";
}
- unless ($branchurl =~ /^$rooturl(.*)/) {
+ unless ($branchurl =~ /^\Q$rooturl\E(.*)/) {
# This branch is very strange indeed.
fatal "merge parent $parent for $d is on branch "
."$branchurl, which is not under the "
--
1.7.7
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:38 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF2245.90308@zytor.com>
On Mon, Oct 31, 2011 at 3:33 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Didn't realize that... I guess I'm too used to named remotes.
>
> If so, just using a tag should be fine, no?
Yes, that's what I think. But the argument for using a separate
namespace is that
(a) you never get confused
(b) it would make it easier to make the 1:1 relationship between
branch names and these "pull request signature tags" without limiting
the naming of *normal* tags in any way
(c) they do have separate lifetimes from "real" tags.
But seriously, I don't care about the *implementation* all that much.
If people want to use the crazy git "notes" capability, you can do
that too, although quite frankly, I don't see the point. What actually
matters is that "git push" and "git pull" would JustWork(tm), and
check the signature if one exists, without having to cut-and-paste
data that simply shouldn't be visible to the user.
I abhor the interface Ingo suggested, for example. Why would we have
stupid command line options that we should cut-and-paste? Automation
is for computers, not for people.
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFxprv9JR4gtt_UDXheHR5G8PrUA3-Mj0CPsU6E5EzNYeg@mail.gmail.com>
On 10/31/2011 03:30 PM, Linus Torvalds wrote:
>
> But if you do the normal "git pull git://git.kernel.org/name/of/repo"
> - which is how things happen as a result of a pull request - you won't
> get tags at all - you have to ask for them by name or use "--tags" to
> get them all.
>
Didn't realize that... I guess I'm too used to named remotes.
If so, just using a tag should be fine, no?
-hpa
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Jiri Kosina @ 2011-10-31 22:33 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Junio C Hamano, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <4EAF1F40.3030907@zytor.com>
On Mon, 31 Oct 2011, H. Peter Anvin wrote:
> Perhaps we should introduce the notion of a "private tag" or something
> along those lines? (I guess that would still have to be possible to
> push it, but not pull it by default...)
That's exactly what git does now, right? (unless you pull from a very
specific remote).
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:30 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF1F40.3030907@zytor.com>
On Mon, Oct 31, 2011 at 3:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Perhaps we should introduce the notion of a "private tag" or something
> along those lines? (I guess that would still have to be possible to
> push it, but not pull it by default...)
All tags are private by default.
We actually *only* fetch tags if somebody explicitly asks for them
(--tags), or when fetching from a named remote (and even then it will
only fetch tags that point to objects you fetched by default iirc -
you have to mark the remote specially to get *all* tags).
But if you do the normal "git pull git://git.kernel.org/name/of/repo"
- which is how things happen as a result of a pull request - you won't
get tags at all - you have to ask for them by name or use "--tags" to
get them all.
Linus
^ permalink raw reply
* [PATCH v2] Display change history as a diff between two dirs
From: Roland Kaufmann @ 2011-10-31 22:21 UTC (permalink / raw)
To: gitster; +Cc: git
Watching patches serially it can be difficult to get an overview of how
a pervasive change is distributed through-out different modules. Thus;
Extract snapshots of the files that have changed between two revisions
into temporary directories and launch a graphical tool to show the diff
between them.
Use existing functionality in git-diff to get the files themselves, and
git-difftool to launch the diff viewer.
Based on a script called 'git-diffc' by Nitin Gupta.
Signed-off-by: Roland Kaufmann <rlndkfmn+git@gmail.com>
---
Following issues are addressed in this revised patch:
* Test explicitly for errors. Use `die` to show messages and exit.
However, I assume that git, mkdir and cp are capable of producing
sensible messages themselves, and in those cases just exit.
* Temporary directory is created using mktemp using the -d option which
is usable on most modern platforms. On more crippled platforms, I
revert to using Perl, since it has the best chance of being available
(if not, then I reckon there are larger parts of Git that won't work).
I have tested this approach with msysGit. Unfortunately, I don't have
testing capabilities for Solaris, HP-UX or AIX.
* Snapshots are taken using only one invocation of `git diff`; no
separate listing of files processed.
* If there are no files in either snapshots (i.e. you are comparing two
empty directories), then don't launch the diff-viewer. This takes
care of many cases where it is invoked with options that are really
not applicable.
* Scripts and manpage are put in contrib/ to gather feedback about the
usefulness and design issues before I make a go at adding it as an
option to git-diff itself. (README tells how to install since it is
not in the main Makefile).
contrib/dirdiff/README | 10 +++++
contrib/dirdiff/git-dirdiff--helper.sh | 37 ++++++++++++++++++++
contrib/dirdiff/git-dirdiff.sh | 58 ++++++++++++++++++++++++++++++++
contrib/dirdiff/git-dirdiff.txt | 55 ++++++++++++++++++++++++++++++
4 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 contrib/dirdiff/README
create mode 100755 contrib/dirdiff/git-dirdiff--helper.sh
create mode 100755 contrib/dirdiff/git-dirdiff.sh
create mode 100644 contrib/dirdiff/git-dirdiff.txt
diff --git a/contrib/dirdiff/README b/contrib/dirdiff/README
new file mode 100644
index 0000000..d06461a
--- /dev/null
+++ b/contrib/dirdiff/README
@@ -0,0 +1,10 @@
+# install on GNU, BSD:
+for f in "" "--helper"; do
+ b=git-dirdiff$f
+ sudo install -m 0755 contrib/dirdiff/$b.sh $(git --exec-path)/$b
+done
+
+# install on Windows
+for /f %a in ('git --exec-path') do set GIT_PATH=%a
+set GIT_PATH=%GIT_PATH:/=\%
+for %a in ("" "--helper") do copy contrib\dirdiff\git-dirdiff%~a.sh "%GIT_PATH%\%~a" /y
diff --git a/contrib/dirdiff/git-dirdiff--helper.sh b/contrib/dirdiff/git-dirdiff--helper.sh
new file mode 100755
index 0000000..8ff0124
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff--helper.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+# Accumulate files in a changeset into a pre-defined directory.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# check that we are called by git-dirdiff
+test -z "$__GIT_DIFF_DIR" &&
+ die Error: Do not call $(basename "$0") directly
+
+# what is the directory name of the file that has changed
+RELDIR=$(dirname "$1") ||
+ exit $?
+
+# don't attempt to copy new or removed files
+if test "$2" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/old/$RELDIR" ||
+ exit $?
+ cp "$2" "$__GIT_DIFF_DIR/old/$1" ||
+ exit $?
+fi
+if test "$5" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/new/$RELDIR" ||
+ exit $?
+ cp "$5" "$__GIT_DIFF_DIR/new/$1" ||
+ exit $?
+fi
diff --git a/contrib/dirdiff/git-dirdiff.sh b/contrib/dirdiff/git-dirdiff.sh
new file mode 100755
index 0000000..faf2f00
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+#
+# Display differences between two commits with a directory comparison.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# TMPDIR points to the designated space for temporary files; only if
+# not set use /tmp (MSYS even mounts %TEMP% to there)
+test -z "$TMPDIR" && TMPDIR=/tmp
+
+# create a temporary directory to hold snapshots of changed files
+# note that SunOS and MSYS do not have mktemp (but GnuWin32 has!)
+case $(uname -s) in
+MINGW* | SunOS* | HP-UX* | AIX*)
+ __GIT_DIFF_DIR=$(perl -e "use File::Temp qw/tempdir/; print tempdir(\"git-dirdiff.XXXXXX\", DIR=>\"$TMPDIR\")")
+ ;;
+*)
+ __GIT_DIFF_DIR=$(mktemp -d "$TMPDIR/git-dirdiff.XXXXXX")
+ ;;
+esac
+test -d "$__GIT_DIFF_DIR" -a -w "$__GIT_DIFF_DIR" ||
+ die Error: Could not create a temporary subdir in $TMPDIR
+
+# cleanup after we're done
+trap 'rm -rf $__GIT_DIFF_DIR' 0
+
+# export this variable so that scripts called indirectly can access it
+export __GIT_DIFF_DIR
+
+# let the helper script accumulate all changed files into the temporary
+# directory letting 'git diff' do all the heavy lifting
+GIT_EXTERNAL_DIFF=git-dirdiff--helper git --no-pager diff "$@" ||
+ exit $?
+
+# if there are only hidden files, then the first argument will be the
+# wildcard, and $2 and $3 will be the special directory files . and ..
+isempty () {
+ set - $1/* $1/.*
+ test ! \( -f "$1" -o -f "$4" \)
+}
+
+# no-op if no files were changed
+isempty "$__GIT_DIFF_DIR/old" && isempty "$__GIT_DIFF_DIR/new" &&
+ exit 0
+
+# run original diff program, reckoning it will understand directories
+# modes and shas does not apply to the root directories so submit dummy
+# values for those, hoping that the diff tool does not use them.
+git-difftool--helper - "$__GIT_DIFF_DIR/old" deadbeef 0755 "$__GIT_DIFF_DIR/new" babeface 0755 ||
+ exit $?
diff --git a/contrib/dirdiff/git-dirdiff.txt b/contrib/dirdiff/git-dirdiff.txt
new file mode 100644
index 0000000..bdd2581
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.txt
@@ -0,0 +1,55 @@
+git-dirdiff(1)
+==============
+
+NAME
+----
+git-dirdiff - Show changes using directory compare
+
+SYNOPSIS
+--------
+[verse]
+'git dirdiff' [<options>] [<commit> [<commit>]] [--] [<path>...]
+
+DESCRIPTION
+-----------
+'git dirdiff' is a git command that allows you to compare revisions
+as a difference between two directories. 'git dirdiff' is a frontend
+to linkgit:git-diff[1].
+
+OPTIONS
+-------
+See linkgit:git-diff[1] for the list of supported options.
+
+CONFIG VARIABLES
+----------------
+'git dirdiff' uses the same config variables as linkgit:git-difftool[1]
+to determine which difftool should be used.
+
+TEMPORARY FILES
+---------------
+'git dirdiff' creates a directory with 'mktemp' to hold snapshots of the
+files which are different in the two revisions. This directory is removed
+when the diff viewer terminates.
+
+NOTES
+-----
+The diff viewer must support being passed directories instead of files
+as its arguments.
++
+Files that are not put under version control are not included when
+viewing the difference between a revision and the working directory.
+
+SEE ALSO
+--------
+linkgit:git-diff[1]::
+ Show changes between commits, commit and working tree, etc
+
+linkgit:git-difftool[1]::
+ Show changes using common diff tools
+
+linkgit:git-config[1]::
+ Get and set repository or global options
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.7.1
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-10-31 22:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFwL_s=DcT46dprcYVWEAm_=WkuTV6K9dAn3wc_bDQU8vA@mail.gmail.com>
On 10/31/2011 03:18 PM, Linus Torvalds wrote:
> On Mon, Oct 31, 2011 at 11:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> It certainly lets you run "git tag --verify" after you pulled and will
>> give you assurance that you pulled the right thing from the right person,
>> but what do you plan to do to the tag from your lieutenants after you
>> fetched and verified? I count 379 merges by you between 3.0 (2011-07-21)
>> and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on
>> average. Will these tags be pushed out to your public history?
>
> No, you misunderstand.
>
> I can do that kind of "crazy manual check of a tag" today. And it's
> too painful to be useful in the long run (or even the short run - I'd
> much prefer the pgp signature in the email which is easier to check
> and more visible anyway). Fetching a tag by name and saving it as a
> tag is indeed pointless.
>
> But what would be nice is that "git pull" would fetch the tag (based
> on name) *automatically*, and not actually create a tag in my
> repository at all. Instead, if would use the tag to check the
> signature, and - if we do this right - also use the tag contents to
> populate the merge commit message.
>
> In other words, no actual tag would ever be left around as a turd, it
> would simply be used as an automatic communication channel between the
> "git push -s" of the submitter and my subsequent "git pull". Neither
> side would have to do anything special, and the tag would never show
> up in any relevant tree (it could even be in a totally separate
> namespace like "refs/pullmarker/<branchname>" or something).
>
Perhaps we should introduce the notion of a "private tag" or something
along those lines? (I guess that would still have to be possible to
push it, but not pull it by default...)
-hpa
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 22:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <7vy5w1ow90.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 11:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> It certainly lets you run "git tag --verify" after you pulled and will
> give you assurance that you pulled the right thing from the right person,
> but what do you plan to do to the tag from your lieutenants after you
> fetched and verified? I count 379 merges by you between 3.0 (2011-07-21)
> and 3.1 (2011-10-24), which would mean you would see 4-5 tags per day on
> average. Will these tags be pushed out to your public history?
No, you misunderstand.
I can do that kind of "crazy manual check of a tag" today. And it's
too painful to be useful in the long run (or even the short run - I'd
much prefer the pgp signature in the email which is easier to check
and more visible anyway). Fetching a tag by name and saving it as a
tag is indeed pointless.
But what would be nice is that "git pull" would fetch the tag (based
on name) *automatically*, and not actually create a tag in my
repository at all. Instead, if would use the tag to check the
signature, and - if we do this right - also use the tag contents to
populate the merge commit message.
In other words, no actual tag would ever be left around as a turd, it
would simply be used as an automatic communication channel between the
"git push -s" of the submitter and my subsequent "git pull". Neither
side would have to do anything special, and the tag would never show
up in any relevant tree (it could even be in a totally separate
namespace like "refs/pullmarker/<branchname>" or something).
Linus
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 22:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: git, Linus Torvalds, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <20111031084048.GA11807__21610.4542407722$1320051469$gmane$org@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> That said, even the "BEGIN PGP SIGNED MESSAGE" things are a massive
>> pain in the butt. We need to automate this some sane way, both for
>> the sender and for the recipient.
>
> The most practical form would be if Git supported such oneliner pull
> requests:
>
> git pull git://foo.com bar.branch \
> --pull-sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \
> --gpg-by: "Ingo Molnar <mingo@kernel.org>" \
> --gpg-sig: 8a6f134afd1d212fe21345
>
> maintainers could just paste them into a shell and it would abort if
> it's not trusted. The maintainer verifies the visible, 'Ingo Molnar'
> bit. The 8a6f134afd1d212fe21345 is a signed-by-Ingo-Molnar version of
> this content:
>
> git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4
As a command line syntax, I think the new "--flag"s should all come
before non flag options to the "pull" subcommand, i.e.
git pull --sha1 0acf00014bcfd71090c3b0d43c98e970108064e4 \
--gpg-by "Ingo Molnar <mingo@kernel.org>" \
git://foo.com bar.branch
I do not understand what you meant by that "8a6f13...". When I run
$ echo "git://foo.com bar.branch 0acf00014bcfd71090c3b0d43c98e970108064e4" |
gpg -sa
I would get about 20 lines of solid gibberish, nothing close to that
clean and concise 20-or-so character sequence.
In any case, I do not think that "this site, that branch" information is
essential for the purpose of validation. I think I saw Linus responding to
a pull request saying "Your pull request says master but I found nothing
there; I assume you meant for-linus branch" or something similar, and as
long as that matches the expectation of the contributor, especially if you
specify "I want you to get _this_ commit" in your request-pull message, it
should not matter how/where Linus gets the history leading to that commit.
As "git-pull" is still a scripted Porcelain, interested people should be
able to experiment this idea by doing something like this:
1. The requestor signs the tip commit to be fetched with the version of
git from the "next" branch, i.e. "git commit -S", and pushes it to his
publishing location;
2. Around line 207, "git pull" spawns "git fetch", stops if dry-run. At
that point, you can:
- parse FETCH_HEAD and verify the SHA-1 matches what you got from the
command line;
- run "git show -s --show-signature FETCH_HEAD" (again, use the
version of git from the "next" branch) to let GPG parse the
signature.
and stop if either test fails.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 20:53 UTC (permalink / raw)
To: Ted Ts'o
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton
In-Reply-To: <20111031203059.GJ16825@thunk.org>
Ted Ts'o <tytso@mit.edu> writes:
> Suppose the project wasn't Linus, but some other project, say, a
> ...
> this, and are good (Kevin Mitnick or better) at social engineering
> attacks.
>
> In this sort of scenario, it's useful if *other* people could
> independently verify the Troll3 git tree via the crypto signatures,
> even though the central maintainer couldn't be bothered to check the
> crypto signatures.
I think we are in total agreement here ;-)
> Here's an idea.... what if the "signed push" information could be
> embedded into the merge commit's description? That is, the
> information could sent via a signed git tag, or some other mechanism,...
I think you described what the signed-commit series that is cooking in
'next' is about way better than I have done so far ;-)
The contributors sign the tips of their histories (which can independently
be validated), the integrator pulls and can choose to bother or not to
bother the tips s/he obtains, and the integrator signs his/her tip before
s/he pushes the integration result out for general consumption.
> ...
> The problem with notes and tags is that they have to be pushed
> separately, and might get lost; where as if they are stored in the
> merge commit's description, they will always be there.
Exactly.
^ permalink raw reply
* Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-10-31 20:34 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, kusmabite, ramsay, msysgit, gitster
In-Reply-To: <1320088364-25916-1-git-send-email-vfr@lyx.org>
Thanks. The patch looks good from a POSIX person's point of view, and I do
not immediately see how this would break other variants of Windows build
at least from the code inspection.
So I'll queue this, but I'll leave it to you and msysgit folks to decide
if this topic should be merged to 1.7.8-rc1, as I do not have equipment,
expertise, nor time to judge it myself (other than the code inspection we
have already done here).
Please give me an Ack or two by the end of this week. Thanks.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ted Ts'o @ 2011-10-31 20:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton
In-Reply-To: <7vy5w1ow90.fsf@alter.siamese.dyndns.org>
(removing linux-ide and linux-kernel)
On Mon, Oct 31, 2011 at 11:23:55AM -0700, Junio C Hamano wrote:
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine. Keeping signed tags and publishing them
> is one way to make it possible, but 400 extra tags in 3 months feels like
> an approach with too much downside (i.e. noise) for that benefit.
I wouldn't put it as "we don't trust Linus's tree", because it's not
true. In general, we do trust Linus's tree. On the other hand, it's
useful if the proof which was submitted at the time of the push could
be verified by third parties.
Suppose the project wasn't Linus, but some other project, say, a
hypothetical Desktop system called Troll3. Let's assume that it's run
by a sole dictator, S. Crew Powerusers, who blindly assumes that any
tree on github is secure, and is confident he or she can detect social
engineering attacks caused by a bad guy grabbing a developer's SSH key
used to push to github, and who can fake a pull request to Linus that
looks real but is really originated by the bad guy. Let's assume
further that the pull request has a signed tag which could be used to
detect such forgeries, but because Mr. Powerusers can't be bothered to
check the tag, because he can't figure out how to update his GPG
keyring and besides, he hates crypto stuff --- and the bad guys know
this, and are good (Kevin Mitnick or better) at social engineering
attacks.
In this sort of scenario, it's useful if *other* people could
independently verify the Troll3 git tree via the crypto signatures,
even though the central maintainer couldn't be bothered to check the
crypto signatures.
Here's an idea.... what if the "signed push" information could be
embedded into the merge commit's description? That is, the
information could sent via a signed git tag, or some other mechanism,
but then part of the git merge would incorporate the GPG signature
into the merge commit's description field (and we could always create
a merge commit so there's a place to put the digital siganture). That
way, it's mostly out of the way, but it's in a well-defined place
where it will always easy to have a third party independently verify
the source of a set of commits in the git tree.
The problem with notes and tags is that they have to be pushed
separately, and might get lost; where as if they are stored in the
merge commit's description, they will always be there.
- Ted
^ 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