Junio C Hamano [off-list ref] writes:
Deskin Miller [off-list ref] writes:
quoted
It struck me a while back when I fetched a new tagged release from git.git that
if I wanted to verify the tag's signature, I'd have to issue another command to
do so. Shouldn't git be able to do that for me automatically, when it fetches
signed tags? Now it does. Also, 'git remote update' gets this for free.
I think this should be done inside your own hook. Not interested at all
in a solution to touch builtin-fetch.c, unless if the patch is about
adding a new hook so that people with other needs can use it as well.
... or a much stronger case can be made why this shouldn't be done in a
hook.
I realize "not interested at all" was a bit too strong, so I am trying to
rephrase it here. The cycle that begins with an RFC that leads to
discussion and review is about clarifying the rationale and design
incrementally, so please do not get offended by my no, and sorry for using
unnecessarily strong wording.
What I meant was more like "The justification as given in the message does
not interest me in the patch at all as it stands. I do not understand why
this has to be done as a patch to git-fetch itself, not in a hook script,
or why doing it inside git-fetch is a better approach than doing it in a
hook (if there already is a hook mechanism to do this)".
On Sun, Nov 23, 2008 at 09:30:56PM -0800, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
Deskin Miller [off-list ref] writes:
quoted
It struck me a while back when I fetched a new tagged release from git.git that
if I wanted to verify the tag's signature, I'd have to issue another command to
do so. Shouldn't git be able to do that for me automatically, when it fetches
signed tags? Now it does. Also, 'git remote update' gets this for free.
I think this should be done inside your own hook. Not interested at all
in a solution to touch builtin-fetch.c, unless if the patch is about
adding a new hook so that people with other needs can use it as well.
... or a much stronger case can be made why this shouldn't be done in a
hook.
I realize "not interested at all" was a bit too strong, so I am trying to
rephrase it here. The cycle that begins with an RFC that leads to
discussion and review is about clarifying the rationale and design
incrementally, so please do not get offended by my no, and sorry for using
unnecessarily strong wording.
What I meant was more like "The justification as given in the message does
not interest me in the patch at all as it stands. I do not understand why
this has to be done as a patch to git-fetch itself, not in a hook script,
or why doing it inside git-fetch is a better approach than doing it in a
hook (if there already is a hook mechanism to do this)".
Let's try this then:
-----
Despite core git's built-in support of cryptographic authentication and
integrity verification through the use of signed tags, git still fails
to provide a good first line of defense against malicious entities
hijacking repositories and disseminating arbitrary code, since git does
not try to verify signed tags at the time they are fetched. If such a
compromise occurred, the prospect of even one individual who did not
verify the newly-fetched tag prior to use gives this a large potential
value to attackers, and represents a commensurate risk to the git-using
community.
This patch series mitigates this risk by trying to verify each signed
tag when it is first fetched. Since, however, not everyone is concerned
with the security of signed tags, this feature tries to be conservative
insofar as signatures with public keys which are missing from the user's
keyring do not cause anything to be said about the tag's validity;
furthermore, a configuration variable exists to disable these checks
entirely, if desired.
-----
*the RFC patch series v1 does not include such a configuration variable.
I appreciate that such verification could be accomplished by the
as-yet-nonexistent post-fetch hook, and if that hook existed, I probably
would have done this in that hook. With that said, I do feel like this
feature merits consideration for inclusion in the builtin fetch code.
First, I very much agree with what Dscho said in his review of patch 1,
that hooks represent a rather more advanced feature of git than most
users are willing to investigate.
So the question, then, is whether this feature is important enough to
include in core git. I of course think that it is important enough.
Given that we have git-tag installed by default when one builds git,
there is a certain commitment to supporting the use of signed tags; and
I see verifying them when first fetched as a logical continuation of
this support. As such, a hook seems an unsuitable approach to provide
support for this new use of signed tags.
I'm happy to ask what suggestions you have for someone intending to
implement hooks around fetch; I've not looked at the code in this light,
but someone's got to do it sooner or later.
Deskin Miller
Hi,
On Thu, 27 Nov 2008, Deskin Miller wrote:
This patch series mitigates this risk by trying to verify each signed
tag when it is first fetched. Since, however, not everyone is concerned
with the security of signed tags, this feature tries to be conservative
insofar as signatures with public keys which are missing from the user's
keyring do not cause anything to be said about the tag's validity;
Now, in the context of security, this is not conservative. Conservative
would be to fail as soon as a signature could not be verified, be it that
there is no key to match against, or that the signature is corrupt.
Your notion to fail silently if the necessary keys were not found makes
your patch series rather useless, no?
After all, the whole idea is to let Git check if every signature is
correct, and when Git does not fail, rely on them being valid.
So I think that the _only_ thing that would make sense is to fail _unless_
all the signatures were verified to be correct.
_That_ is why I want this feature to be off by default.
Ciao,
Dscho