signed/encrypted tagging in crypto branch [was: Re: [Review] Re: new "crypto" branch providing full PGP/MIME support]

[Jameson Rollins]

Hey, folks.  I just pushed a couple of patches to my "crypto" branch [0]
that add support for auto-tagging of multipart/signed and
multipart/encrypted messages with the "signed" and "encrypted" tags
respectively.  Only new messages are thus tagged, so a database rebuild
is required to auto-tag old messages.

To be clear, after the previous discussion, these tags indicate nothing
about the validity of signatures or the decryptability of encrypted
messages.  They only indicate that a message contains a signed or
encrypted part according to the self-declared mime type.

This certainly makes it easier to find crypto messages, and it should
allow people to highlight signed or encrypted messages in the search
output using the "notmuch-search-lines-faces" customization variable
[1].

jamie.

[0] git://finestructure.net/notmuch
[1] The notmuch-search-lines-faces variable needs to be rewritten to
allow for full face customization support, but it also needs to continue
to specify a tag/face mapping.  Any elisp experts out there have any
good suggestions how to fix this?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

signed/encrypted tagging in crypto branch [was: Re: [Review] Re: new crypto branch providing full PGP/MIME support]

[Jameson Rollins]

Hey, folks.  I just pushed a couple of patches to my crypto branch [0]
that add support for auto-tagging of multipart/signed and
multipart/encrypted messages with the signed and encrypted tags
respectively.  Only new messages are thus tagged, so a database rebuild
is required to auto-tag old messages.

To be clear, after the previous discussion, these tags indicate nothing
about the validity of signatures or the decryptability of encrypted
messages.  They only indicate that a message contains a signed or
encrypted part according to the self-declared mime type.

This certainly makes it easier to find crypto messages, and it should
allow people to highlight signed or encrypted messages in the search
output using the notmuch-search-lines-faces customization variable
[1].

jamie.

[0] git://finestructure.net/notmuch
[1] The notmuch-search-lines-faces variable needs to be rewritten to
allow for full face customization support, but it also needs to continue
to specify a tag/face mapping.  Any elisp experts out there have any
good suggestions how to fix this?


pgpoI349yCViC.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Simon Fondrie-Teitler]

On Mon, 28 Feb 2011 14:24:03 +0100, Sebastian Spaeth  
wrote:
> On Sun, 27 Feb 2011 10:41:48 +, Darren McGuicken  fernseed.info> wrote:
> I also run the crypto branch since it has been published and it is
> working just  fine.

I have just started using the crypto branch, and after a few misteps on
my part it is working. It works great. 

 --Simon
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Rob Browning]

Jameson Rollins  writes:

> If folks have suggestions for disambiguating tag names that don't
> themselves create further confusion on some other front, then I'm
> inclined to just go with the simplest and most straightforward tag name.

Are persistent tags required here?  The original question at least,
seemed to just be asking for a visual indicator that a message has
encrypted or signed bits.  So I wondered if that might be accomplished
without actual tags.

Just curious.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Mon, 28 Feb 2011 21:16:13 -0600, Rob Browning  
wrote:
> Are persistent tags required here?  The original question at least,
> seemed to just be asking for a visual indicator that a message has
> encrypted or signed bits.  So I wondered if that might be accomplished
> without actual tags.

Hey, Rob.  It probably could, but given that we already have
infrastructure for modifying the face of lines in the search output
based on tags, it therefore seems like the easiest way to achieve the
indicator that Ross was interested in would also be via a tag.  Any
other method would probably require extra hacking of the search
function, and hacking of the emacs interface to parse it and act on it.

To me personally the issue was more about wanting to be able to easily
find signed or encrypted messages.  The easiest way to do that would be
with a tag also, since that's kind of what they're for (again I can
imagine some other sort of internal flag in the database, but that seems
like it would be a lot more work).

Given that it should be fairly easy to tag these messages during notmuch
new, and that tags can be easily leveraged by existing functions, tags
seem to me to be the way to go.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Mon, 28 Feb 2011 15:08:39 -0500, Daniel Kahn Gillmor  wrote:
> The outstanding question in my mind is whether those tags could be
> mistaken by a na?ve user for meaning one of the other concepts.  Is
> there a way to name the tags to minimize that kind of confusion?

I think that would be difficult without using a long and cumbersome tag
name ("signed-but-not-verified"??).  But I think it might be a bit of a
moot point, since I kind of think that any user that actually
understands what a signature is, and what signature verification means,
is sophisticated enough to understand that the mere presence of a
signature does not mean it's been verified.  I could be wrong, though.

If folks have suggestions for disambiguating tag names that don't
themselves create further confusion on some other front, then I'm
inclined to just go with the simplest and most straightforward tag name.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Daniel Kahn Gillmor]

On 02/28/2011 02:56 PM, Jameson Rollins wrote:
> On Mon, 28 Feb 2011 13:59:54 -0500, Daniel Kahn Gillmor  fifthhorseman.net> wrote:
>> But: what does the "signed" tag mean? i wouldn't want to necessarily
>> conflate these four ideas:
> 
> These are good points, Daniel.  However, I had actually just been
> thinking of something much simpler, along the lines of just tagging
> "signed" any message with a "multipart/signed" part, and "encrypted" any
> message with a "multipart/encrypted" part.

this is a fair answer to my questions, not an evasion -- you're
selecting level 0 in both tracks, which is not a bad thing (it's
certainly simpler to get right!)

The outstanding question in my mind is whether those tags could be
mistaken by a na?ve user for meaning one of the other concepts.  Is
there a way to name the tags to minimize that kind of confusion?

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Sebastian Spaeth]

On Sun, 27 Feb 2011 10:41:48 +, Darren McGuicken  wrote:
> If feedback is needed here then likewise, I've been running the crypto
> branch since it was made available.  The only strangeness I've seen was
> that which was reported in id:"87sjw2h6xy.fsf at bookbinder.fernseed.info"
> for expired keys.

I also run the crypto branch since it has been published and it is
working just  fine.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Daniel Kahn Gillmor]

On 02/28/2011 01:25 PM, Jameson Rollins wrote:
> On Mon, 28 Feb 2011 08:52:45 -0500, Ross Glover  
> wrote:
>> I too am now running the crypto branch and find it quite amazing.  The
>> one feature I would like added, though, is some face color or
>> auto-tagging in the search buffer for mail with encrypted mime parts.
>> It seems like this could be achieved with notmuch effort (by someone
>> notme) by adding similar functionality to that of attachments in
>> index.cc.
> 
> Yes, this is a good idea, Ross, and one that I've actually been wanting
> to implement.  I was thinking of auto-tagging messages with signed parts
> with something like "signed", and encrypted messages with "encrypted".
> Do people like those tags, or would they prefer to see something
> different?  Or more specific, like "pgp-signed"?

i don't care much about the difference between PGP/MIME and S/MIME
message formats, so i prefer the term "signed" to "pgp-signed" and
"encrypted" to "pgp-encrypted".

  

But: what does the "signed" tag mean? i wouldn't want to necessarily
conflate these four ideas:

 0) "this message claims to be cryptographically-signed"

 1) "we have verified a cryptographic signature over this message"

 2) "we have verified a cryptographic signature over this message from a
known key (that is, we believe we know who the key belongs to)"

 3) "we have verified a cryptographic signature on this message from the
sender claimed in the From: line"

3 implies 2, 2 implies 1, and 1 implies 0, of course.  But which level
would a "signed" tag signify?

I'll also note that signed+encrypted messages would not get tagged with
"signed" unless the recipient has successfully decrypted them.  And
then, it's possible that some sub-parts of a message are signed, and
others are not.  Would the tags indicate the maximum "level" found? or
the minimum?  something else?

  

For that matter, what would an automatically-placed "encrypted" tag
mean?  i can think of a few different approaches:

 0) some part of this message is wrapped in an encrypted MIME block

 1) some part of this message is wrapped in an encrypted MIME block that
claims to be decryptable by a key you control

 2) some part of this message is wrapped in an encrypted MIME block and
you can actually decrypt it (have decrypted it in the past?).

2 in particular couldn't be auto-assigned without having access to the
user's secret key material in the first place, but maybe it could be
assigned after a decryption succeeds?


--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Mon, 28 Feb 2011 13:59:54 -0500, Daniel Kahn Gillmor  wrote:
> But: what does the "signed" tag mean? i wouldn't want to necessarily
> conflate these four ideas:

These are good points, Daniel.  However, I had actually just been
thinking of something much simpler, along the lines of just tagging
"signed" any message with a "multipart/signed" part, and "encrypted" any
message with a "multipart/encrypted" part.

This simpler approach would certainly satisfy my needs, without having
to get into sorting out all the complicated details in the points you
brought up.

Does that sound like it would work for folks, or would they like to see
a more nuanced approach to handling tagging of signed/encrypted
messages?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Mon, 28 Feb 2011 08:52:45 -0500, Ross Glover  
wrote:
> I too am now running the crypto branch and find it quite amazing.  The
> one feature I would like added, though, is some face color or
> auto-tagging in the search buffer for mail with encrypted mime parts.
> It seems like this could be achieved with notmuch effort (by someone
> notme) by adding similar functionality to that of attachments in
> index.cc.

Yes, this is a good idea, Ross, and one that I've actually been wanting
to implement.  I was thinking of auto-tagging messages with signed parts
with something like "signed", and encrypted messages with "encrypted".
Do people like those tags, or would they prefer to see something
different?  Or more specific, like "pgp-signed"?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Ross Glover]

I too am now running the crypto branch and find it quite amazing.  The
one feature I would like added, though, is some face color or
auto-tagging in the search buffer for mail with encrypted mime parts.
It seems like this could be achieved with notmuch effort (by someone
notme) by adding similar functionality to that of attachments in
index.cc.

ross

-- 


Sent from an Emacs buffer.

Re: [Review] Re: new crypto branch providing full PGP/MIME support

[Sebastian Spaeth]

On Sun, 27 Feb 2011 10:41:48 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 If feedback is needed here then likewise, I've been running the crypto
 branch since it was made available.  The only strangeness I've seen was
 that which was reported in id:87sjw2h6xy@bookbinder.fernseed.info
 for expired keys.

I also run the crypto branch since it has been published and it is
working just  fine.

Sebastian


pgpG32EW429Vz.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Review] Re: new crypto branch providing full PGP/MIME support

[Jameson Rollins]

On Mon, 28 Feb 2011 13:59:54 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 But: what does the signed tag mean? i wouldn't want to necessarily
 conflate these four ideas:

These are good points, Daniel.  However, I had actually just been
thinking of something much simpler, along the lines of just tagging
signed any message with a multipart/signed part, and encrypted any
message with a multipart/encrypted part.

This simpler approach would certainly satisfy my needs, without having
to get into sorting out all the complicated details in the points you
brought up.

Does that sound like it would work for folks, or would they like to see
a more nuanced approach to handling tagging of signed/encrypted
messages?

jamie.


pgpZh63tduyBT.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Review] Re: new crypto branch providing full PGP/MIME support

[Rob Browning]

Jameson Rollins jroll...@finestructure.net writes:

 If folks have suggestions for disambiguating tag names that don't
 themselves create further confusion on some other front, then I'm
 inclined to just go with the simplest and most straightforward tag name.

Are persistent tags required here?  The original question at least,
seemed to just be asking for a visual indicator that a message has
encrypted or signed bits.  So I wondered if that might be accomplished
without actual tags.

Just curious.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Review] Re: new "crypto" branch providing full PGP/MIME support

[Darren McGuicken]

On Sat, 26 Feb 2011 20:45:15 -0400, David Bremner  wrote:
> Further to our discussion on IRC the other day about providing
> feedback on patches, I have run these patches pretty much all of
> February with no glitches.  I am running them on 3 different machines,
> although they are all Debian AMD64 boxes.

If feedback is needed here then likewise, I've been running the crypto
branch since it was made available.  The only strangeness I've seen was
that which was reported in id:"87sjw2h6xy.fsf at bookbinder.fernseed.info"
for expired keys.

Even with that glitch, I really can't see me going back to vanilla
notmuch until these patches are pulled.  They're just ridiculously
useful.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[Review] Re: new "crypto" branch providing full PGP/MIME support

[David Bremner]

On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins  wrote:
> Hi, all.  I have pushed a new branch called "crypto" to my notmuch
> repository [0].  This branch provides full support for PGP/MIME signed
> and encrypted messages, including emacs UI support.  It has been applied
> on top of cworth's current master (21e97c50).  It includes the
> following:
> 

Further to our discussion on IRC the other day about providing feedback
on patches, I have run these patches pretty much all of February with
no glitches.  I am running them on 3 different machines, although they
are all Debian AMD64 boxes.

David

P.S. I also started the (possibly goofy) idea of putting [Review] in the
subject to highlight the fact there is feedback on the patches.

[Review] Re: new crypto branch providing full PGP/MIME support

[David Bremner]

On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins 
jroll...@finestructure.net wrote:
 Hi, all.  I have pushed a new branch called crypto to my notmuch
 repository [0].  This branch provides full support for PGP/MIME signed
 and encrypted messages, including emacs UI support.  It has been applied
 on top of cworth's current master (21e97c50).  It includes the
 following:
 

Further to our discussion on IRC the other day about providing feedback
on patches, I have run these patches pretty much all of February with
no glitches.  I am running them on 3 different machines, although they
are all Debian AMD64 boxes.

David

P.S. I also started the (possibly goofy) idea of putting [Review] in the
subject to highlight the fact there is feedback on the patches.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch