On 11/16/2010 03:06 PM, Daniel Kahn Gillmor wrote:
> On 11/16/2010 02:47 PM, Carl Worth wrote:
>> The current linearization of parts is a bug that should be fixed. And I
>> think several aspects of your proposal are effectively workarounds for
>> this bug. So I'd rather we fix the json output to em
On 11/16/2010 03:06 PM, Daniel Kahn Gillmor wrote:
> On 11/16/2010 02:47 PM, Carl Worth wrote:
>> The current linearization of parts is a bug that should be fixed. And I
>> think several aspects of your proposal are effectively workarounds for
>> this bug. So I'd rather we fix the json output to em
On 11/16/2010 03:44 PM, Jameson Rollins wrote:
> Aren't clients going to have to interpret/display the output regardless
> of it's been verified or not? It seems to me that understanding how to
> display the verified output is really not that much more difficult than
> understanding how to display
On Tue, 16 Nov 2010 15:22:49 -0500, Daniel Kahn Gillmor wrote:
> For clients that do not know how to interpret/display the verification
> results, i don't want the backend to incur the cost of verification that
> will be thrown away.
Aren't clients going to have to interpret/display the output re
On 11/16/2010 03:10 PM, Jameson Rollins wrote:
> I would almost say that --verify should be the
> default, with a --no-verify option. It will make things much easier for
> all the UIs if notmuch handles the verification and just outputs the
> result.
For clients that do not know how to interpret/
On Tue, 16 Nov 2010 11:47:13 -0800, Carl Worth wrote:
> The only other piece I think I'd like to see is actually making the
> content of the signature pieces available in the json output. Then, a
> client could do its own verification.
>
> Then if we had that would we not want to add the --verify
On 11/16/2010 02:47 PM, Carl Worth wrote:
> The current linearization of parts is a bug that should be fixed. And I
> think several aspects of your proposal are effectively workarounds for
> this bug. So I'd rather we fix the json output to emit the tree
> structure first, and then see what parts o
On 11/16/2010 03:44 PM, Jameson Rollins wrote:
> Aren't clients going to have to interpret/display the output regardless
> of it's been verified or not? It seems to me that understanding how to
> display the verified output is really not that much more difficult than
> understanding how to display
On Tue, 16 Nov 2010 15:22:49 -0500, Daniel Kahn Gillmor
wrote:
> For clients that do not know how to interpret/display the verification
> results, i don't want the backend to incur the cost of verification that
> will be thrown away.
Aren't clients going to have to interpret/display the output r
On 11/16/2010 03:10 PM, Jameson Rollins wrote:
> I would almost say that --verify should be the
> default, with a --no-verify option. It will make things much easier for
> all the UIs if notmuch handles the verification and just outputs the
> result.
For clients that do not know how to interpret/
On Tue, 16 Nov 2010 11:47:13 -0800, Carl Worth wrote:
> The only other piece I think I'd like to see is actually making the
> content of the signature pieces available in the json output. Then, a
> client could do its own verification.
>
> Then if we had that would we not want to add the --verify
On 11/16/2010 02:47 PM, Carl Worth wrote:
> The current linearization of parts is a bug that should be fixed. And I
> think several aspects of your proposal are effectively workarounds for
> this bug. So I'd rather we fix the json output to emit the tree
> structure first, and then see what parts o
On Sat, 13 Nov 2010 02:55:50 -0500, Daniel Kahn Gillmor
wrote:
> i've been trying to wrap my head around how to get notmuch to support
> verifying cryptographically-signed mail. i'm afraid my current
> understanding of the problem space is that it is neither pretty nor
> clean. Sorry for the le
On Sat, 13 Nov 2010 02:55:50 -0500, Daniel Kahn Gillmor wrote:
> i've been trying to wrap my head around how to get notmuch to support
> verifying cryptographically-signed mail. i'm afraid my current
> understanding of the problem space is that it is neither pretty nor
> clean. Sorry for the len
On 11/15/2010 05:23 AM, David Edmondson wrote:
> i.e. the existence of the multipart/signed wrapper should be
> explicit. In general, all MIME parts should be visible.
thanks, this makes sense to me.
> Changing the JSON output in this way would not materially affect your
> proposal, I believe. T
On Sat, 13 Nov 2010 02:55:50 -0500, Daniel Kahn Gillmor wrote:
> It would end up like this (without the --verify flag):
>
> ---
> "body": [
> {
> "content": "here is a test message i signed on 2010-11-11.\n\n
> --dkg\n\n",
> "content-type": "text/p
On 11/15/2010 05:23 AM, David Edmondson wrote:
> i.e. the existence of the multipart/signed wrapper should be
> explicit. In general, all MIME parts should be visible.
thanks, this makes sense to me.
> Changing the JSON output in this way would not materially affect your
> proposal, I believe. T
On Sat, 13 Nov 2010 02:55:50 -0500, Daniel Kahn Gillmor
wrote:
> It would end up like this (without the --verify flag):
>
> ---
> "body": [
> {
> "content": "here is a test message i signed on 2010-11-11.\n\n
> --dkg\n\n",
> "content-type": "text/
Thanks for the reply, David!
On 11/13/2010 06:40 AM, David Bremner wrote:
> Are both the forward and backward pointers needed?
Technically, only the "signs" pointer is needed, i guess. I had
included the "signedby" pointer so that frontends which process the list
linearly know that a signed part
Thanks for the reply, David!
On 11/13/2010 06:40 AM, David Bremner wrote:
> Are both the forward and backward pointers needed?
Technically, only the "signs" pointer is needed, i guess. I had
included the "signedby" pointer so that frontends which process the list
linearly know that a signed part
On Sat, 13 Nov 2010 02:55:50 -0500, Daniel Kahn Gillmor wrote:
> A signed MIME part will contain a new element "signedby", which is a
> list of part numbers identifying signatures that cover this part.
>
> Signature parts (Content-Type: application/pgp-signature) will contain a
> new element "si
On Sat, 13 Nov 2010 02:55:50 -0500, Daniel Kahn Gillmor
wrote:
> A signed MIME part will contain a new element "signedby", which is a
> list of part numbers identifying signatures that cover this part.
>
> Signature parts (Content-Type: application/pgp-signature) will contain a
> new element "s
hi notmuch folks--
i've been trying to wrap my head around how to get notmuch to support
verifying cryptographically-signed mail. i'm afraid my current
understanding of the problem space is that it is neither pretty nor
clean. Sorry for the length of this message.
Scope:
--
I'm focusing in
hi notmuch folks--
i've been trying to wrap my head around how to get notmuch to support
verifying cryptographically-signed mail. i'm afraid my current
understanding of the problem space is that it is neither pretty nor
clean. Sorry for the length of this message.
Scope:
--
I'm focusing in
24 matches
Mail list logo
