On Sat 06 Aug 2016 09:52, Andreas Enge writes:
> I am not very happy about such a policy; if I sign a commit, I am only
> signing my commit, and not all of its history
For what it's worth, this is not quite true. The SHA1 hashes of parent
commits are part of the commit object itself, so if you
On Sat 06 Aug 2016 04:07, Leo Famulari writes:
> But, I also think the primary point of signing the commits is to record
> the identity of the person responsible for the commit, and so I think
> the policy should be to sign each commit. [0]
To me this is not the value that signing brings; rather
On Thu, Aug 04, 2016 at 17:06:15 +0200, Andy Wingo wrote:
> What's the rationale for requiring non-HEAD commits to be signed when
> pushing? For me a signed HEAD implicitly signs all parent comments, in
> my mental trust model anyway :)
That could be a potentially daunting/impossible task for the
On Fri, Aug 05, 2016 at 08:59:32PM -0400, Mark H Weaver wrote:
> I haven't thought deeply on this, but it seems to me that Andy's
> suggestion has a lot of merit. We could choose to decide, as a matter
> of policy, that if you sign a commit with unsigned ancestor commit(s),
> you are effectively v
On Fri, Aug 05, 2016 at 08:59:32PM -0400, Mark H Weaver wrote:
> Leo Famulari writes:
> > If I push A-B-C with a signed HEAD immediately after somebody pushes a
> > forged D, won't it look like I vouch for D?
>
> This can't happen unless D is already in your local repo before you
> commit locally
Leo Famulari writes:
> On Fri, Aug 05, 2016 at 06:50:30PM +0200, Andy Wingo wrote:
>> Why would you sign a commit if you don't attest to intermediate unsigned
>> commits?
>
> If I push A-B-C with a signed HEAD immediately after somebody pushes a
> forged D, won't it look like I vouch for D?
This
On Fri, Aug 05, 2016 at 06:50:30PM +0200, Andy Wingo wrote:
> Why would you sign a commit if you don't attest to intermediate unsigned
> commits?
If I push A-B-C with a signed HEAD immediately after somebody pushes a
forged D, won't it look like I vouch for D? How could a 3rd party tell
whether D
On Fri 05 Aug 2016 16:59, Leo Famulari writes:
> On Fri, Aug 05, 2016 at 09:35:59AM +0200, Andy Wingo wrote:
>> Yeah. I guess I don't see see "author misattribution on unsigned
>> commits" as part of the threat model.
>>
>> My mental model is that if you have a signed commit A with unsigned
>>
On Fri, Aug 05, 2016 at 09:35:59AM +0200, Andy Wingo wrote:
> Yeah. I guess I don't see see "author misattribution on unsigned
> commits" as part of the threat model.
>
> My mental model is that if you have a signed commit A with unsigned
> parents B, C, ..., that it's the person who signed commi
On Thu 04 Aug 2016 22:05, Leo Famulari writes:
> On Thu, Aug 04, 2016 at 06:55:34PM +0200, Andy Wingo wrote:
>> On Thu 04 Aug 2016 18:44, Leo Famulari writes:
>>
>> > How would the rest of us distinguish between
>> >
>> > 1) a range of your commits with a signed HEAD
>> > 2) a range of your com
On Thu, Aug 04, 2016 at 06:55:34PM +0200, Andy Wingo wrote:
> On Thu 04 Aug 2016 18:44, Leo Famulari writes:
>
> > How would the rest of us distinguish between
> >
> > 1) a range of your commits with a signed HEAD
> > 2) a range of your commits with a signed HEAD that you pushed after I
> > pushe
On Thu, Aug 04, 2016 at 08:32:42PM +0200, Andreas Enge wrote:
> On Thu, Aug 04, 2016 at 12:37:07PM -0400, Leo Famulari wrote:
> > git rebase "$range" --exec "git commit --amend --no-edit --gpg-sign" ||
> > git rebase --abort
>
> So it is not enough to just do a
>git rebase -S
> ? I though
On Thu, Aug 04, 2016 at 04:45:56PM +0200, Mathieu Lirzin wrote:
> With gpg-agent and git properly setup, signing every local commit is not
> that inconvenient IME.
> I recommend you to give a try. ;)
Ever so often I try gpg@2 (I do not remember whether 2.0 or 2.1), it works
for a while, it stops
On Thu, Aug 04, 2016 at 12:37:07PM -0400, Leo Famulari wrote:
> And if you don't want to sign every commit as you work (it can be
> tedious if your gpg-agent has a short cache lifetime), you can use
> git-rebase to sign a commit range before pushing, as in this shell
> script:
>
> git-sign () {
>
On Thu 04 Aug 2016 18:44, Leo Famulari writes:
> How would the rest of us distinguish between
>
> 1) a range of your commits with a signed HEAD
> 2) a range of your commits with a signed HEAD that you pushed after I
> pushed a commit created with `git commit --author="Andy Wingo"
I'm not sure wh
On Thu, Aug 04, 2016 at 05:06:15PM +0200, Andy Wingo wrote:
> On Thu 04 Aug 2016 14:36, Mark H Weaver writes:
>
> > Unfortunately, when I tried to push it to 'master', it was rejected
> > because of 56 unsigned commits on the 'core-updates' branch.
>
> What's the rationale for requiring non-HEAD
On Thu, Aug 04, 2016 at 04:45:56PM +0200, Mathieu Lirzin wrote:
> With gpg-agent and git properly setup, signing every local commit is not
> that inconvenient IME.
And if you don't want to sign every commit as you work (it can be
tedious if your gpg-agent has a short cache lifetime), you can use
g
On Thu 04 Aug 2016 14:36, Mark H Weaver writes:
> Unfortunately, when I tried to push it to 'master', it was rejected
> because of 56 unsigned commits on the 'core-updates' branch.
What's the rationale for requiring non-HEAD commits to be signed when
pushing? For me a signed HEAD implicitly sig
Hi,
Andreas Enge writes:
> On Thu, Aug 04, 2016 at 09:23:50AM -0400, Mark H Weaver wrote:
>> I just did this. Huge thanks to Lisa Marie Maginnis, GNU sysadmin
>> extraordinaire, for promptly responding to my plea for help :)
>
> Thanks to both of you!
>
>> However, we should take steps to avoid
On Thu, Aug 04, 2016 at 09:23:50AM -0400, Mark H Weaver wrote:
> I just did this. Huge thanks to Lisa Marie Maginnis, GNU sysadmin
> extraordinaire, for promptly responding to my plea for help :)
Thanks to both of you!
> However, we should take steps to avoid this problem in the future. The
> m
Mark H Weaver skribis:
> Leo Famulari writes:
>
>> On Thu, Aug 04, 2016 at 02:40:32PM +0200, Andreas Enge wrote:
>>> On Thu, Aug 04, 2016 at 08:36:28AM -0400, Mark H Weaver wrote:
>>> Good news, thanks for all this work!
>>
>> Indeed!
>>
>>> > Unfortunately, when I tried to push it to 'master',
Leo Famulari writes:
> On Thu, Aug 04, 2016 at 02:40:32PM +0200, Andreas Enge wrote:
>> On Thu, Aug 04, 2016 at 08:36:28AM -0400, Mark H Weaver wrote:
>> Good news, thanks for all this work!
>
> Indeed!
>
>> > Unfortunately, when I tried to push it to 'master', it was rejected
>> > because of 56
On Thu, Aug 04, 2016 at 02:40:32PM +0200, Andreas Enge wrote:
> On Thu, Aug 04, 2016 at 08:36:28AM -0400, Mark H Weaver wrote:
> Good news, thanks for all this work!
Indeed!
> > Unfortunately, when I tried to push it to 'master', it was rejected
> > because of 56 unsigned commits on the 'core-upd
On Thu, Aug 04, 2016 at 08:36:28AM -0400, Mark H Weaver wrote:
> On my local machine, I did this successfully by first reverting a couple
> of later commits, then reverting the squashed merge, then doing a proper
> merge, and finally cherry-picking the later commits. I verified that
> this sequenc
Andreas Enge writes:
> On Thu, Aug 04, 2016 at 03:50:51AM -0400, Mark H Weaver wrote:
>> How about reverting the squashed commit and then re-doing a proper merge
>> from 'core-updates-2016-08-01' into 'master'?
>
> If this is possible without too many complications, that sounds like a good
> opti
On Thu, Aug 04, 2016 at 03:50:51AM -0400, Mark H Weaver wrote:
> How about reverting the squashed commit and then re-doing a proper merge
> from 'core-updates-2016-08-01' into 'master'?
I think we should do this. It's worth a little blemish in the commit
history in order to retain the history of t
On Thu, Aug 04, 2016 at 03:50:51AM -0400, Mark H Weaver wrote:
> How about reverting the squashed commit and then re-doing a proper merge
> from 'core-updates-2016-08-01' into 'master'?
If this is possible without too many complications, that sounds like a good
option; the earlier the better, prob
Leo Famulari writes:
> On Wed, Aug 03, 2016 at 10:29:21PM +0200, Ludovic Courtès wrote:
>> In fact, commit 455859a50f88f625d13fc2f304111f02369b366b, which is the
>> core-updates merge, is *not* a merge commit. Instead it seems to be a
>> squashed commit of all of core-updates. Consequently, par
On Wed, Aug 03, 2016 at 10:29:21PM +0200, Ludovic Courtès wrote:
> In fact, commit 455859a50f88f625d13fc2f304111f02369b366b, which is the
> core-updates merge, is *not* a merge commit. Instead it seems to be a
> squashed commit of all of core-updates. Consequently, part of the
> history of the fi
29 matches
Mail list logo
