git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Linux 3.1-rc5
       [not found] <CA+55aFxDjVJwbpP5YT4o=qud=OcxtT3Ry4HfCtW-FvNdj+RFeQ@mail.gmail.com>
@ 2011-09-05 20:26 ` Mauro Carvalho Chehab
  2011-09-06  7:23   ` Michael J Gruber
  2011-09-07  1:37   ` Henrique de Moraes Holschuh
  0 siblings, 2 replies; 3+ messages in thread
From: Mauro Carvalho Chehab @ 2011-09-05 20:26 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, git

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

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

^ 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: 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

end of thread, other threads:[~2011-09-07  1:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CA+55aFxDjVJwbpP5YT4o=qud=OcxtT3Ry4HfCtW-FvNdj+RFeQ@mail.gmail.com>
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).