On Tue, Jan 26, 2016 at 01:13:16PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
> >
> >> > If you cannot trust those with write access to a repo that you are
> >> > pulling and installing from you might want to re-check wh
Hello, sorry for being MIA yesterday among all this movement...
On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
> Jeff King venit, vidit, dixit 27.01.2016 08:33:
> > On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:
> >
> >>> Tag objects already have a "tag" head
On Wed, Jan 27, 2016 at 09:09:31PM +0100, Michael J Gruber wrote:
> "subkey" and "uid" are different things. You bind a subkey to your
> primary key with that self-signature. subkeys don't carry any other
> signatures.
>
> A primary key "carries" the uids, and whenever someone "signs your key"
>
Junio C Hamano venit, vidit, dixit 27.01.2016 19:10:
> Michael J Gruber writes:
>
>> Jeff King venit, vidit, dixit 27.01.2016 09:09:
>>
>>> The bigger issue is that gpg seems to give us only _one_ uid, when there
>>> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
>>> sub-k
Michael J Gruber writes:
> Jeff King venit, vidit, dixit 27.01.2016 09:09:
>
>> The bigger issue is that gpg seems to give us only _one_ uid, when there
>> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
>> sub-key that has several uids associated with it. The one that "git
Jeff King venit, vidit, dixit 27.01.2016 09:09:
> On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
>
>>> Yeah, definitely. My thinking was that `verify-tag` could learn a series
>>> of optional consistency checks, enabled by command line options, and
>>> verifying programs (or hum
On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
> > Yeah, definitely. My thinking was that `verify-tag` could learn a series
> > of optional consistency checks, enabled by command line options, and
> > verifying programs (or humans) could turn them on to avoid having to
> > repli
Jeff King venit, vidit, dixit 27.01.2016 08:33:
> On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:
>
>>> Tag objects already have a "tag" header, which is part of the signed
>>> content. If you use "git verify-tag -v", you can check both that the
>>> signature is valid and that th
On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:
> > Tag objects already have a "tag" header, which is part of the signed
> > content. If you use "git verify-tag -v", you can check both that the
> > signature is valid and that the tag is the one you are expecting.
>
> Yes, that's
Jeff King venit, vidit, dixit 26.01.2016 21:26:
> On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
>
>>> If you cannot trust those with write access to a repo that you are
>>> pulling and installing from you might want to re-check where you are
>>> pulling or installing from ;)
>>
Jeff King writes:
>> I don't think that an addition like this would get in the way of any
>> existing git workflow, and should be backwards-compatible right?
>
> Doesn't this already exist?
>
> $ git cat-file tag v2.0.0
> object e156455ea49124c140a67623f22a393db62d5d98
> type commit
> tag
On Tue, Jan 26, 2016 at 03:26:51PM -0500, Jeff King wrote:
> On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
>
> > > If you cannot trust those with write access to a repo that you are
> > > pulling and installing from you might want to re-check where you are
> > > pulling or insta
Jeff King writes:
> On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
>
>> > If you cannot trust those with write access to a repo that you are
>> > pulling and installing from you might want to re-check where you are
>> > pulling or installing from ;)
>>
>> Yeah, I see your point
On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
> > If you cannot trust those with write access to a repo that you are
> > pulling and installing from you might want to re-check where you are
> > pulling or installing from ;)
>
> Yeah, I see your point, but mechanisms to ensure t
On Tue, Jan 26, 2016 at 10:35:34AM +0100, Michael J Gruber wrote:
> Santiago Torres venit, vidit, dixit 25.01.2016 22:22:
> > Hello everyone.
> >
> > I've done some further research on the security properties of git
> > metadata and I think I've identified something that might be worth
> > discuss
Santiago Torres venit, vidit, dixit 25.01.2016 22:22:
> Hello everyone.
>
> I've done some further research on the security properties of git
> metadata and I think I've identified something that might be worth
> discussing. In this case, The issue is related to the refs that point to
> git tag ob
Hello everyone.
I've done some further research on the security properties of git
metadata and I think I've identified something that might be worth
discussing. In this case, The issue is related to the refs that point to
git tag objects. Specifically, the "loose" nature of tag refs might
possibly
17 matches
Mail list logo
