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
Mauro Carvalho Chehab venit, vidit, dixit 05.09.2011 22:26:
Em 04-09-2011 20:27, Linus Torvalds escreveu:
quoted
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
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