* 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
* 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: 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: 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
* [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: 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
* 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: 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: 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: 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: 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: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: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: 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: 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
* 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 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
* 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: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vincent van Ravesteijn, git, kusmabite, ramsay, msysgit
In-Reply-To: <7vd3dcq4s5.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 31 Oct 2011, Junio C Hamano wrote:
> 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.
As my virtual machine still ran the test suite after my latest rebasing
merge when I left work, I could not test the MSVC stuff just yet. I wanted
to do that tomorrow and either merge or come back with suggestions.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 0:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vincent van Ravesteijn, git, ramsay, msysgit
In-Reply-To: <7vd3dcq4s5.fsf@alter.siamese.dyndns.org>
On Mon, Oct 31, 2011 at 9:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
The result of applying this on top of the current master (1.7.8-rc0)
compiles and seem to runs fine for me, both with the MinGW supplied by
msysGit, and MSVC (as outlined by compat/vcbuild/README). Without the
patches, it fails to build with MSVC. In addition, the changes looks
good to me. So:
Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: H. Peter Anvin @ 2011-11-01 0:42 UTC (permalink / raw)
To: Jeff Garzik
Cc: Junio C Hamano, Linus Torvalds, git, James Bottomley,
Andrew Morton, linux-ide, LKML
In-Reply-To: <4EAF3556.3000001@garzik.org>
>
> 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.
>
I think the desire is to be able to deconstruct things if things were to
go wrong.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: git-p4: problem with commit 97a21ca50ef8
From: Pete Wyckoff @ 2011-11-01 2:08 UTC (permalink / raw)
To: Michael Wookey; +Cc: Git Mailing List, Luke Diamand
In-Reply-To: <CAOk9v+-==GwDQaZ=4BW1QfEF7+5SfhNF409Xom0bHdT_qKaiFA@mail.gmail.com>
michaelwookey@gmail.com wrote on Tue, 01 Nov 2011 10:11 +1100:
> [ 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 so much for taking the time to find this and to narrow it
down.
I found icnsutils that shows the fail.png file has a bunch of
icons glued onto the front of the correct image file.
We can certainly revert this commit, but first I'd like to
understand what the right behavior should be.
I managed to include an apple filetype in a repo from a linux box
by hacking:
$ cp /tmp/sample_image_fail.png fail.png
$ p4 add -t apple fail.png
$ p4 submit -dfail-apple
Submitting change 2.
Locking 1 files ...
add //depot/fail.png#1
Unable to read AppleDouble Header.
open for read: /home/pw/src/perforce/cli/%fail.png: No such
file or directory
Submit aborted -- fix problems then use 'p4 submit -c 2'.
Some file(s) could not be transferred from client.
Hrm. Fake it by copying your example apple file to what it asks
for:
$ cp fail.png %fail.png
$ p4 submit -c 2
Submitting change 2.
add //depot/fail.png#1
Change 2 submitted.
(But later p4 sync -f destroy both files.)
Voila:
$ p4 fstat //depot/fail.png
... depotFile //depot/fail.png
... clientFile /home/pw/src/perforce/cli/fail.png
... isMapped
... headAction add
... headType apple
... headTime 1320111844
... headRev 1
... headChange 2
... headModTime 1320111842
... haveRev 1
And git-p4 checks it out intact:
$ git p4 clone //depot
[..]
$ sha1sum depot/fail.png /tmp/sample_image_fail.png
93d175ad906147f4d75296bd2adb6d706f798c64 depot/fail.png
93d175ad906147f4d75296bd2adb6d706f798c64 /tmp/sample_image_fail.png
Which is what I thought an apple-filetype user would want.
Reverting the patch causes _no_ file to be created. Is
this better? Maybe the single-blob file, since it no longer
appears in AppleDouble format, is just as useless as no file?
The other option is to use "p4 print" without the -G, which
seems to retrieve only the data fork, and leave that in the repo.
Of course, if you change it, and submit it, it makes a mess.
Would it be good if git-p4 understood how to identify and create
AppleDouble files on Mac? If yes, eventually, we can revert the
commit and explain how this feature doesn't quite work yet.
Even if no, it seems like we should revert and complain that
this apple support is broken.
-- Pete
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 3:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Vincent van Ravesteijn, git, kusmabite, ramsay, msysgit
In-Reply-To: <alpine.DEB.1.00.1110311908240.1930@bonsai2>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> As my virtual machine still ran the test suite after my latest rebasing
> merge when I left work, I could not test the MSVC stuff just yet. I wanted
> to do that tomorrow and either merge or come back with suggestions.
Thanks.
^ permalink raw reply
* Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 3:30 UTC (permalink / raw)
To: kusmabite; +Cc: Vincent van Ravesteijn, git, ramsay, msysgit
In-Reply-To: <CABPQNSaW+ciEzAMruYVgK_y2xf=sExYiFfdbS4xonKe=h-APjA@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> The result of applying this on top of the current master (1.7.8-rc0)
> compiles and seem to runs fine for me, both with the MinGW supplied by
> msysGit, and MSVC (as outlined by compat/vcbuild/README). Without the
> patches, it fails to build with MSVC. In addition, the changes looks
> good to me. So:
>
> Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] Display change history as a diff between two dirs
From: Junio C Hamano @ 2011-11-01 3:49 UTC (permalink / raw)
To: Roland Kaufmann; +Cc: git
In-Reply-To: <4EAE688C.8010502@gmail.com>
Roland Kaufmann <rlndkfmn+git@gmail.com> writes:
>> "git diff" (and possibly even things like "git log -p") populating
>> two temporary directories (your old/ and new/) and running a custom
>> program specified by GIT_EXTERNAL_TREEDIFF environment variable,
>> instead of doing
>
> Would it be better to have yet another configuration available for
> this option instead of reusing the existing infrastructure for `git
> difftool`?
GIT_EXTERNAL_DIFF is designed to drive tools that can take a single pair
of files and compare, so it is entirely possible for people to have such
tool that would _not_ grok (as a tool named by the variable does not have
to) two directories specified by it. So yes, it is essential that the
variable not be reused.
It probably is OK for "git diff --dirdiff" to use GIT_EXTERNAL_TREEDIFF if
and only if GIT_EXTERNAL_DIFF is not defined, and use GIT_EXTERNAL_DIFF
otherwise. People who have GIT_EXTERNAL_DIFF set to a tool capable of
handing directory pair can just add "--dirdiff" to the command line, and
others can find such a tool and set it to GIT_EXTERNAL_TREEDIFF when they
do so.
>> It also is not clear what could be used in "$@". Obviously you would
>> not want things like "-U20" and "--stat" fed to the first "list of
>> paths" phase, but there may be some options you may want to give to
>> the inner "external diff" thing.
>
> Ideally, it should work the same way as `git difftool`.
I am not so sure about that; difftool is another way to drive a tool one
filepair at a time. You want to drive a tool that takes them as two _sets_
of files, one in each directory.
^ 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