Re: [Enigmail] jsunit updates and distribution

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