* Re: Linux 3.1-rc5
2011-09-05 20:26 ` Linux 3.1-rc5 Mauro Carvalho Chehab
@ 2011-09-06 7:23 ` Michael J Gruber
2011-09-07 1:37 ` Henrique de Moraes Holschuh
1 sibling, 0 replies; 3+ messages in thread
From: Michael J Gruber @ 2011-09-06 7:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linus Torvalds, Linux Kernel Mailing List, git
Mauro Carvalho Chehab venit, vidit, dixit 05.09.2011 22:26:
> Em 04-09-2011 20:27, Linus Torvalds escreveu:
>
>> One thing to note: If you just do
>>
>> git pull https://github.com/torvalds/linux.git
>>
>> you probably won't get the tags, since it's not your origin branch. So do
>>
>> git fetch --tags<...>
>>
>> too, so that you get not only the actual changes, but the tag that you
>> can verify too.
>>
>
> It would be great if "git remote update" could also verify the tag
> signature (if present), as most of us just do a "git remote update".
...when you should "git fetch --all" ;)
> Maybe an extra parameter for git config remote.tagopt?
>
> Ok, if in doubt, we can always use git tag -v <new tag>, but doing
> it automagically would help us to detect if a git tag got mangled
> by some at the moment we update our trees, with seems to be
> a good idea.
The update hook (if you want to reject falsified tags) or post-update
hook (if you want to be warned) is the perfect place for this. It would
be worth amending the standard update hook, me thinks, after removing
its insisting on a project description, and maybe switching the defaults.
Michael
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Linux 3.1-rc5
2011-09-05 20:26 ` Linux 3.1-rc5 Mauro Carvalho Chehab
2011-09-06 7:23 ` Michael J Gruber
@ 2011-09-07 1:37 ` Henrique de Moraes Holschuh
1 sibling, 0 replies; 3+ messages in thread
From: Henrique de Moraes Holschuh @ 2011-09-07 1:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linus Torvalds, Linux Kernel Mailing List, git
On Mon, 05 Sep 2011, Mauro Carvalho Chehab wrote:
> It would be great if "git remote update" could also verify the tag
> signature (if present), as most of us just do a "git remote update".
That helps, and it really should be all that matter for a power-end-user
that just wants to build his kernel from a git tree.
However, one can still try to trick someone to base the tree he's going to
use for a future pull request on a tree with a rogue commit, in order to
try to get the rogue commit into mainline through an indirect path, for
example.
Yeah, it is very obvious, and not a real major point of concern around
LKML: we all check the diff, log or shortlog between the tree we're
offering upstream to pull from) and the current upstream tree for any
stray commits after all (if only to avoid embarassing mistakes). And
upstream does his/her own checks before keeping the merged tree, and so
forth.
It's just that the security of the kernel source trees are not a simple
consequence of how git works: the workflow matters. I feel that point
deserves to be stressed every once in a while, however obvious it might
be.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 3+ messages in thread