Re: revision 3: easing access to the cryptographic envelope
On Sun, May 26 2019, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> On Sun 2019-05-26 09:01:46 -0300, David Bremner wrote:
>>> Daniel Kahn Gillmor writes:
>>>
This is the third revision of the series originally posted at
id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at
id:20190520032228.27420-1-...@fifthhorseman.net)
This series addresses comments raised by David Bremner in his review.
Thanks, Bremner!
>>>
>>> I pushed this version, with 4 minor whitespace fixups (inserted spaces
>>> and/or deleted blank lines) that I missed in my previous review.
>>
>> Thanks for these fixes, Bremner. If you have a specific set of tooling
>> that you use that i can adopt to catch those kinds of coding convention
>> mishaps before submitting, i'd be happy to adopt it so things are
>> "clean". Bonus points if it integrates into emacs via .dir-locals.el or
>> something :P
>
> To be honest my main mechanism for catching those problems is Tomi
> ;).
I used to have simple trailing whitespace cleanup hook
(with its problems). Since Now 2012 I've used ethan-wspace.el which
does cleanups only initially clean content (and higlights if not --
my favorite feature). Like w/ notmuch I also use a bit different version:
localhost$ diff -u vc/ext/ethan-wspace/lisp/ethan-wspace.el
dotdir/elisp/ethan-wspace.el
--- vc/ext/ethan-wspace/lisp/ethan-wspace.el 2019-05-27 23:32:26.625456294
+0300
+++ dotdir/elisp/ethan-wspace.el 2019-05-27 23:38:34.150404797 +0300
@@ -800,8 +800,7 @@
(setq require-final-newline nil))
(when indent-tabs-mode
- (setq ethan-wspace-errors
-(remove 'tabs ethan-wspace-errors)))
+ (ethan-wspace-highlight-tabs-mode))
(run-hooks 'ethan-wspace-errors-in-buffer-hook)
(ethan-wspace-update-buffer)
zsh: exit 1 diff -u ~/vc/ext/ethan-wspace/lisp/ethan-wspace.el
(applied latest change from github just now, changed there 2019-05-21)
> There is also a reasonable uncrustify configuration that I don't use
> as often as I should, mainly because the baseline in various files is
> not there. Perhaps if we did more some global whitespace cleanup this
> would be more helpful. To try it out run
>
> % uncrustify -c devel/uncrustify.cfg --replace $files
>
> then
>
> % git diff
>
> to see what changed.
>
> % find -name .git -prune -o -type f -a -regex '.*[.]\(c\|h\|cc\)' -print
> -exec uncrustify -c devel/uncrustify.cfg --replace {} \;
>
> yields a whopping 1933 insertions and 1903 deletions. Perhaps there are
> some places where the uncrustify config needs tuning, but none of the
> output looked crazy to me. Two things I noticed causing lots of changes
>
> 1) "!foo" -> "! foo"
> 2) putting a leading * in front of multi-line comments
Last time I played w/ uncrustify it was like 2014 -- and I recall there
were things that uncrustify just could not do (more than above) -- like
indenting differently than emacs would do (and IMO something ugly way).
So I wonder if we ever can use uncrustify as tool to verify change
formatting (i.e. identical output or FAIL)...
... perhaps newer uncrustify (latest 0.69, in 2014 version was 0.60)
(with modified uncrustify.cfg) could help there (I also have done
some experiments with "uncrustify postprocessor"; I should take some
time to see how that works with latest tool...)
> If we do decide to rip off the bandage, that will cause a certain amount
> of rebasing pain for any patch series in flight; now (i.e after the
> release) is actually a pretty good time from my point of view, but
> others (e.g. you) might feel differently.
If uncrustifying can be done (even partially), IMO it could be done;
patch series authors just have to revisit their changes (keeping those
live is their duty anyway).
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
On Sun 2019-05-26 13:54:29 -0300, David Bremner wrote: > % uncrustify -c devel/uncrustify.cfg --replace $files thanks for this pointer, i will experiment with it. > If we do decide to rip off the bandage, that will cause a certain amount > of rebasing pain for any patch series in flight; now (i.e after the > release) is actually a pretty good time from my point of view, but > others (e.g. you) might feel differently. I can live with this kind of pain, if it means less frustration later, but what makes you think that "after the release" == "now" ? :P we still have ~5 days till the proposed feature freeze, right? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
Daniel Kahn Gillmor writes:
> On Sun 2019-05-26 09:01:46 -0300, David Bremner wrote:
>> Daniel Kahn Gillmor writes:
>>
>>> This is the third revision of the series originally posted at
>>> id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at
>>> id:20190520032228.27420-1-...@fifthhorseman.net)
>>>
>>> This series addresses comments raised by David Bremner in his review.
>>> Thanks, Bremner!
>>
>> I pushed this version, with 4 minor whitespace fixups (inserted spaces
>> and/or deleted blank lines) that I missed in my previous review.
>
> Thanks for these fixes, Bremner. If you have a specific set of tooling
> that you use that i can adopt to catch those kinds of coding convention
> mishaps before submitting, i'd be happy to adopt it so things are
> "clean". Bonus points if it integrates into emacs via .dir-locals.el or
> something :P
To be honest my main mechanism for catching those problems is Tomi
;). There is also a reasonable uncrustify configuration that I don't use
as often as I should, mainly because the baseline in various files is
not there. Perhaps if we did more some global whitespace cleanup this
would be more helpful. To try it out run
% uncrustify -c devel/uncrustify.cfg --replace $files
then
% git diff
to see what changed.
% find -name .git -prune -o -type f -a -regex '.*[.]\(c\|h\|cc\)' -print -exec
uncrustify -c devel/uncrustify.cfg --replace {} \;
yields a whopping 1933 insertions and 1903 deletions. Perhaps there are
some places where the uncrustify config needs tuning, but none of the
output looked crazy to me. Two things I noticed causing lots of changes
1) "!foo" -> "! foo"
2) putting a leading * in front of multi-line comments
If we do decide to rip off the bandage, that will cause a certain amount
of rebasing pain for any patch series in flight; now (i.e after the
release) is actually a pretty good time from my point of view, but
others (e.g. you) might feel differently.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
On Sun 2019-05-26 09:01:46 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> This is the third revision of the series originally posted at >> id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at >> id:20190520032228.27420-1-...@fifthhorseman.net) >> >> This series addresses comments raised by David Bremner in his review. >> Thanks, Bremner! > > I pushed this version, with 4 minor whitespace fixups (inserted spaces > and/or deleted blank lines) that I missed in my previous review. Thanks for these fixes, Bremner. If you have a specific set of tooling that you use that i can adopt to catch those kinds of coding convention mishaps before submitting, i'd be happy to adopt it so things are "clean". Bonus points if it integrates into emacs via .dir-locals.el or something :P --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: revision 3: easing access to the cryptographic envelope
Daniel Kahn Gillmor writes: > This is the third revision of the series originally posted at > id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at > id:20190520032228.27420-1-...@fifthhorseman.net) > > This series addresses comments raised by David Bremner in his review. > Thanks, Bremner! I pushed this version, with 4 minor whitespace fixups (inserted spaces and/or deleted blank lines) that I missed in my previous review. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
revision 3: easing access to the cryptographic envelope
This is the third revision of the series originally posted at id:20190424183113.29242-1-...@fifthhorseman.net (revision 2 was at id:20190520032228.27420-1-...@fifthhorseman.net) This series addresses comments raised by David Bremner in his review. Thanks, Bremner! The most significant change here is that notmuch-show in --format=json or --format=sexp now always emits a "crypto" member for every message, regardless of whether there is any cryptographic envelope. In the case where there is no cryptographic envelope, the "crypto" member will be empty. -- E-mail structures are potentially arbitrarily complicated. Cryptographic protection standards like S/MIME and OpenPGP or PGP/MIME are often applicable to some elements of some messages. Last year's "E-Fail" attacks made it clear that trying to provide normal users with cryptographic protections on piecemeal parts of an e-mail message is a recipe for disaster, both from an implementation perspective and a user experience perspective. I've argued in more detail at [0] about the need to treat cryptographic protections at the message level, rather than at the subpart level. [0] https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html This series makes "notmuch show" track and emit message-wide cryptographic state, providing an interface that simple clients that use "notmuch show" can rely on for their UI and UX. It doesn't yet apply this layer to the emacs interface, because at the moment many users of the emacs interface are nerds who are as likely to understand the intricacies of MIME structure as anyone, and for the moment, just augmenting the notmuch show schemata in a sensible way is enough of a chunk to bite off. (though i'd be happy to review and support the use of this per-message cryptographic state in notmuch-emacs if/when this lands!) I'd appreciate any review and feedback! Regards, --dkg ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
