threads / discuss / 28309

Re: Linux 3.1-rc5

Subject: Re: Linux 3.1-rc5

## tl;dr

3 messages between Sep 5, 2011 and Sep 7, 2011.

replies: 2people: 3as markdown or json

Mauro Carvalho Chehab· Sep 5, 2011, 20:26 UTC · lore

Em 04-09-2011 20:27, Linus Torvalds escreveu:

Show 11 quoted lines

> 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".

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.

Thanks, Mauro

Michael J Gruber· Sep 6, 2011, 07:23 UTC · re: Mauro Carvalho Chehab · lore

Mauro Carvalho Chehab venit, vidit, dixit 05.09.2011 22:26:

Show 16 quoted lines

> 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" ;)

Show 6 quoted lines

> 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

Henrique de Moraes Holschuh· Sep 7, 2011, 01:37 UTC · re: Mauro Carvalho Chehab · lore

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