On 9/18/2019 1:50 AM, Daniel Kahn Gillmor wrote:
> On Tue 2019-09-17 18:55:53 +0200, john doe wrote:
>> Do you mind explaining why you are against signing commits?
>
> I'd like to understand what your proposed use case and value proposition
> is for signed commits.
>
> I can justify my call for signed tags -- i want to have cryptographic
> provenenance for any software release that i package for debian. Note
> that i want to package a *release* though -- not just some arbitrary
> (possibly buggy) stage on the way to a release.
>
No argument there! :)
> do you believe that branch rebases ("changing history") are acceptable
> steps for free software developers to take in pursuit of a cleaner git
> history?
>
Git history is paramount, locally you can do what ever you want but
rebasing/merging on what is already pushed is a no go for me.
> Who do you expect to verify the signatures on the signed commits? when
> should they verify them? what specific tests should they perform on the
> signatures (e.g. "monotonically increasing in time", "signature timestamp
> matches commit message timestamp", "author is from specific set", "no
> existing commits ever disappear", etc)
>
I see two reasons why it would be usefull to be able to verify commit:
- Issue in tag that can be corrected by 'cherry-pick'ing a commit
While I can verify the signed tag I can not verify the 'cherry-pick'ed
commit
- Merging a local branch with upstream
The command 'git pull' will do a 'git fetch' followed by 'git merge'
I guess what I'm trying to say is that if the commit is not signed you
can't be sure who made the commit.
--
John Doe
_______________________________________________
enigmail-users mailing list
[email protected]
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
