[PATCH] new: read db_files and db_subdirs if mtime changed

2011-02-04 Thread Karel Zak
The db_files and db_subdirs are unnecessary for unchanged directories.

maildir with 1 e-mails:

old version:
$ time ./notmuch new
No new mail.

real0m0.053s
user0m0.028s
sys 0m0.026s

new version:
$ time ./notmuch new
No new mail.

real0m0.032s
user0m0.009s
sys 0m0.023s

Signed-off-by: Karel Zak 
---
 notmuch-new.c |   15 ++-
 1 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index 941f9d6..31d4553 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -247,15 +247,7 @@ add_files_recursive (notmuch_database_t *notmuch,
 directory = notmuch_database_get_directory (notmuch, path);
 db_mtime = notmuch_directory_get_mtime (directory);

-if (db_mtime == 0) {
-   new_directory = TRUE;
-   db_files = NULL;
-   db_subdirs = NULL;
-} else {
-   new_directory = FALSE;
-   db_files = notmuch_directory_get_child_files (directory);
-   db_subdirs = notmuch_directory_get_child_directories (directory);
-}
+new_directory = db_mtime ? FALSE : TRUE;

 /* If the database knows about this directory, then we sort based
  * on strcmp to match the database sorting. Otherwise, we can do
@@ -328,6 +320,11 @@ add_files_recursive (notmuch_database_t *notmuch,
 if (fs_mtime == db_mtime)
goto DONE;

+if (!new_directory) {
+   db_files = notmuch_directory_get_child_files (directory);
+   db_subdirs = notmuch_directory_get_child_directories (directory);
+}
+
 /* Pass 2: Scan for new files, removed files, and removed directories. */
 for (i = 0; i < num_fs_entries; i++)
 {
-- 
1.7.3.4



always encrypting messages to self [was: Re: new "crypto" branch providing full PGP/MIME support]

2011-02-04 Thread Sebastian Spaeth

I just love seeing all those yellow signatures. It reminds me to meet
you all in real life to verify your keys :-).

Thanks for implementing this, the whole lot of you. It works really
well.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/66dd73ea/attachment.pgp>


no quoted messages if fcc folder cannot be created.

2011-02-04 Thread Daniel Kahn Gillmor
i tried running

 emacs -Q -f notmuch

and replying to a message.

Since i didn't have my emacs config, it wanted to create the default
sent folder in ~/mail/sent

if i told it "no, don't create it" when prompted (during the setup of
the reply message) then the body of the replied-to message doesn't show up.

If ~/mail/sent is actually a file (not a folder) so that the fcc folder
cannot be created, then i get the same problem (the replied-to message
doesn't show up quoted in the body of the new *mail* buffer).

sorry i haven't been able to track it down more than that.

to replicate:

 mv ~/mail/sent ~/mail/sent.bak
 touch ~/mail/sent
 emacs -Q -f notmuch

   

hth,

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/bef43091/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread David Bremner
On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins  wrote:
> 
> Please test and provide feedback.  I would really like to see this
> series merged into the mainline for the next release, if at all
> possible.

I reported some pretty weird experiences yesterday on IRC with replies
not working. It turns out they were caused by having old versions of
xapian installed in /usr/local (which I think might have caused some
mixup with headers and libraries being different versions).

The decryption is working ok for me now (aside from the issue I
mentioned already with unknown encrypted+signed).

d

tl;dr: yesterdays weirdness was not the fault of J. Rollins.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/6e9accc7/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread Jameson Rollins
Hey, folks.  I've pushed some improvements to the "crypto" branch that:

* add support for replying to encrypted messages
* don't show sigstatus button for unsigned encrypted messages

As always, please let me know encounter any problems.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/074cd771/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread Daniel Kahn Gillmor
On 02/04/2011 11:59 AM, micah anderson wrote:
> On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor  fifthhorseman.net> wrote:
>> when you say "encrypted by" do you mean "encrypted to"?  do you have
>> access to the corresponding secret key?
> 
> If I open a message that was sent to me and was encrypted by the sender
> using a key that they have since revoked, or has expired, I saw this.

so you hold key A, the sender holds key B, they encrypt the message with
B, and then revoke key B, and then you try to read the message (without
holding key B)?

or are you saying you hold key A, sender holds key B, they encrypt to A,
*sign* the message with B, and then revoke B?  If it's this case, does
the same thing happen even if the message is not encrypted?

Sorry for the nit-picking pedantry here -- I'm trying to get a clear
workflow for a test case.

> Most humans I know reference their key by the keyid, where keyid means
> the 8 character representation of their key. When they need to ensure
> that their key is not being spoofed they either rely on the tools to do
> cryptographic verification, or inspect the fingerprint. I dont think
> moving towards using a longer format of the keyid helps here. The key is
> unknown, and to get it known requires going through a key signing
> process, or fingerprint verification, which isn't aided by having a
> longer form keyid. 
> 
> If I am presented with a short form keyid, and I go and try and receive
> that key from the keyservers and then I am presented with two different
> options, then I'm going to inspect the two and determine then which one
> is the right one. I dont need to front-load that knowledge in the
> interface.

and if you're presented with only one key, you will just accept that
one?  that puts you at the mercy of the network (or the keyserver
operator at least, and we can't all have the luxury of being or knowing
the keyserver operator directly).

If you're arguing "i would like to be able to recognize the key by
32-bit key ID" i don't think it's actually possible to do so because of
the spoofability; a tool that provides cryptographic assurances should
discourage attempts to make the user vulnerable to spoofing.

If you're saying we should remove the 64-bit keyID entirely and just say
"signature from unknown, non-validated key", i think that's a defensible
position, though it's not one i would take.

>> is this really a use case worth bothering with?
> 
> No.

:)

>> do you have a suggestion for how you think it should behave
>> differently?
> 
> I think my suggestion was already made: short form.

and as i said above, i think this is a mistake if we're trying to
provide tools that give cryptographic assurances.

thanks for the testing and the corner cases!

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/344de8a8/attachment-0001.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread Darren McGuicken
On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins  wrote:
> > Can we pass the decrypted text to message mode on a reply?
> Yeah, some folks pointed this out on #notmuch this morning.  The
> decryption is only happening in notmuch-show, but we need to do it in
> notmuch-reply as well for the decrypted text to show up in the reply.
> I'm working on it now.

Great news, thanks!

Also: another confirmation for the revoked/expired key behaviour.  Emacs
UI just reports:

  json-read-string: Wrong type argument: characterp, :json-eof

Let me know if you need any samples of misbehaving mails.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/e63c87db/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread micah anderson
On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor  wrote:

> On 02/03/2011 11:25 AM, micah anderson wrote:
> > 1. I personally think notmuch-show-process-pgpmime should default to
> > true
> 
> note that with it set to false, you can still M-RET (instead of RET) on
> an item in the summary window to have it set for that particular view.

Yes, that is true. However, I still think the default should be
on. Especially considering all three people (myself included) who I've
seen try this have been puzzled by why it wasn't working and had to be
told that they needed to turn it on.

> > 3. i'm not sure expired/revoked keys are handled properly - tested on a
> > message that was encrypted by a key that was revoked and got "End of
> > file during parsing"
> 
> when you say "encrypted by" do you mean "encrypted to"?  do you have
> access to the corresponding secret key?

If I open a message that was sent to me and was encrypted by the sender
using a key that they have since revoked, or has expired, I saw this.

> > 5. unknown keys are represented in a long format,
> > eg. '0x5585F58CC827A062' when most tools represent them just with their
> > shortened keyid (in this case this one would be: 0xC827A062), is there a
> > particular reason for this?
> 
> Short keyIDs are easily spoofable; believing anything based on a matched
> short keyID is a mistake. 

Most humans I know reference their key by the keyid, where keyid means
the 8 character representation of their key. When they need to ensure
that their key is not being spoofed they either rely on the tools to do
cryptographic verification, or inspect the fingerprint. I dont think
moving towards using a longer format of the keyid helps here. The key is
unknown, and to get it known requires going through a key signing
process, or fingerprint verification, which isn't aided by having a
longer form keyid. 

If I am presented with a short form keyid, and I go and try and receive
that key from the keyservers and then I am presented with two different
options, then I'm going to inspect the two and determine then which one
is the right one. I dont need to front-load that knowledge in the
interface.

> > I recognize some people's keyids in the
> > short form, but do not in the longform.
> 
> You can derive the short form from the long form by ignoring
> everything but the last 8 hex characters.

Yes, I know that, but my brain parser looks at '0x5585F58CC827A062' and
has to squint to try and ignore the last 8 characters. In fact, its
often quicker for me to use my cursor to go up there and count backwards
8 characters and then hit a space so I can visually separate it. Visual
interface parse failure with long form.

> But if you actually recognize the short form, i'd expect you to have
> the relevant key in your keyring;

Not always true. In fact the parse error I was discussing above was
about a key I used to use, but have removed from my keyring, and my
secret keyring. In the long form, I did *not* recognize it. If it were
simply 1CF2D62A I would have instantly recognized it as my old key that
I've revoked.

> is this really a use case worth bothering with?

No.

> do you have a suggestion for how you think it should behave
> differently?

I think my suggestion was already made: short form.

m
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/d3180abd/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 13:12:27 -0400, David Bremner  wrote:
> I reported some pretty weird experiences yesterday on IRC with replies
> not working. It turns out they were caused by having old versions of
> xapian installed in /usr/local (which I think might have caused some
> mixup with headers and libraries being different versions).
> 
> The decryption is working ok for me now (aside from the issue I
> mentioned already with unknown encrypted+signed).
...
> tl;dr: yesterdays weirdness was not the fault of J. Rollins.

phew!  Although there remains the issue of replying to encrypted
messages, since notmuch-reply was not modified to decrypt messages
before replying.  I'm working on that now.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/dbef16ec/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 12:09:48 +, Darren McGuicken  wrote:
> On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins  finestructure.net> wrote:
> > > Can we pass the decrypted text to message mode on a reply?
> > Yeah, some folks pointed this out on #notmuch this morning.  The
> > decryption is only happening in notmuch-show, but we need to do it in
> > notmuch-reply as well for the decrypted text to show up in the reply.
> > I'm working on it now.
> 
> Great news, thanks!

Thanks for the feedback!

> Also: another confirmation for the revoked/expired key behaviour.  Emacs
> UI just reports:
> 
>   json-read-string: Wrong type argument: characterp, :json-eof
> 
> Let me know if you need any samples of misbehaving mails.

Yeah, I've found some emails that are doing this as well.  I'm looking
in to what we can do to mitigate the problem, which I think is
ultimately a problem in GMime.  The json output should not be breaking,
though, so that I will definitely fix.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/a14fe560/attachment.pgp>


always encrypting messages to self [was: Re: new "crypto" branch providing full PGP/MIME support]

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 14:04:23 +0100, Sebastian Spaeth  
wrote:
> I just love seeing all those yellow signatures. It reminds me to meet
> you all in real life to verify your keys :-).
> 
> Thanks for implementing this, the whole lot of you. It works really
> well.

Yes!  I'm really glad you're finding it useful.  Hopefully you're seeing
some green fully-valid-userid sigs in there as well...

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/985058d7/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 08:24:38 -0400, David Bremner  wrote:
> On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins  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:
> > 
> 
> For a signed and encrypted message, if the signing key can't be found,
> one just gets:
> 
>  [ multipart/encrypted: decryption error ]
> 
> which is a bit mystifying.  At least gpg on the command line will
> decrypt the message and print a warning about the signature.

So I need to look at this closer, but I think this is a GMime problem.
That error message is generated when the GMime decryption code returns
NULL for the decrypted part.  I'll try to make a test case for this, and
file a bug with GMime upstream.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/ce9426d4/attachment.pgp>


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread 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:
> 

For a signed and encrypted message, if the signing key can't be found,
one just gets:

 [ multipart/encrypted: decryption error ]

which is a bit mystifying.  At least gpg on the command line will
decrypt the message and print a warning about the signature.

All the best, and thanks for working on this, 

d

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110204/92235fa5/attachment-0001.pgp>


Re: always encrypting messages to self [was: Re: new crypto branch providing full PGP/MIME support]

2011-02-04 Thread Sebastian Spaeth

I just love seeing all those yellow signatures. It reminds me to meet
you all in real life to verify your keys :-).

Thanks for implementing this, the whole lot of you. It works really
well.

Sebastian


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


Re: new crypto branch providing full PGP/MIME support

2011-02-04 Thread micah anderson
On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:

 On 02/03/2011 11:25 AM, micah anderson wrote:
  1. I personally think notmuch-show-process-pgpmime should default to
  true
 
 note that with it set to false, you can still M-RET (instead of RET) on
 an item in the summary window to have it set for that particular view.

Yes, that is true. However, I still think the default should be
on. Especially considering all three people (myself included) who I've
seen try this have been puzzled by why it wasn't working and had to be
told that they needed to turn it on.

  3. i'm not sure expired/revoked keys are handled properly - tested on a
  message that was encrypted by a key that was revoked and got End of
  file during parsing
 
 when you say encrypted by do you mean encrypted to?  do you have
 access to the corresponding secret key?

If I open a message that was sent to me and was encrypted by the sender
using a key that they have since revoked, or has expired, I saw this.

  5. unknown keys are represented in a long format,
  eg. '0x5585F58CC827A062' when most tools represent them just with their
  shortened keyid (in this case this one would be: 0xC827A062), is there a
  particular reason for this?
 
 Short keyIDs are easily spoofable; believing anything based on a matched
 short keyID is a mistake. 

Most humans I know reference their key by the keyid, where keyid means
the 8 character representation of their key. When they need to ensure
that their key is not being spoofed they either rely on the tools to do
cryptographic verification, or inspect the fingerprint. I dont think
moving towards using a longer format of the keyid helps here. The key is
unknown, and to get it known requires going through a key signing
process, or fingerprint verification, which isn't aided by having a
longer form keyid. 

If I am presented with a short form keyid, and I go and try and receive
that key from the keyservers and then I am presented with two different
options, then I'm going to inspect the two and determine then which one
is the right one. I dont need to front-load that knowledge in the
interface.

  I recognize some people's keyids in the
  short form, but do not in the longform.
 
 You can derive the short form from the long form by ignoring
 everything but the last 8 hex characters.

Yes, I know that, but my brain parser looks at '0x5585F58CC827A062' and
has to squint to try and ignore the last 8 characters. In fact, its
often quicker for me to use my cursor to go up there and count backwards
8 characters and then hit a space so I can visually separate it. Visual
interface parse failure with long form.

 But if you actually recognize the short form, i'd expect you to have
 the relevant key in your keyring;

Not always true. In fact the parse error I was discussing above was
about a key I used to use, but have removed from my keyring, and my
secret keyring. In the long form, I did *not* recognize it. If it were
simply 1CF2D62A I would have instantly recognized it as my old key that
I've revoked.

 is this really a use case worth bothering with?

No.

 do you have a suggestion for how you think it should behave
 differently?

I think my suggestion was already made: short form.

m


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


Re: new crypto branch providing full PGP/MIME support

2011-02-04 Thread David Bremner
On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins 
jroll...@finestructure.net wrote:
 
 Please test and provide feedback.  I would really like to see this
 series merged into the mainline for the next release, if at all
 possible.

I reported some pretty weird experiences yesterday on IRC with replies
not working. It turns out they were caused by having old versions of
xapian installed in /usr/local (which I think might have caused some
mixup with headers and libraries being different versions).

The decryption is working ok for me now (aside from the issue I
mentioned already with unknown encrypted+signed).

d

tl;dr: yesterdays weirdness was not the fault of J. Rollins.


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


Re: new crypto branch providing full PGP/MIME support

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 08:24:38 -0400, David Bremner brem...@unb.ca wrote:
 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:
  
 
 For a signed and encrypted message, if the signing key can't be found,
 one just gets:
 
  [ multipart/encrypted: decryption error ]
 
 which is a bit mystifying.  At least gpg on the command line will
 decrypt the message and print a warning about the signature.

So I need to look at this closer, but I think this is a GMime problem.
That error message is generated when the GMime decryption code returns
NULL for the decrypted part.  I'll try to make a test case for this, and
file a bug with GMime upstream.

jamie.


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


Re: always encrypting messages to self [was: Re: new crypto branch providing full PGP/MIME support]

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 14:04:23 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 I just love seeing all those yellow signatures. It reminds me to meet
 you all in real life to verify your keys :-).
 
 Thanks for implementing this, the whole lot of you. It works really
 well.

Yes!  I'm really glad you're finding it useful.  Hopefully you're seeing
some green fully-valid-userid sigs in there as well...

jamie.


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


Re: new crypto branch providing full PGP/MIME support

2011-02-04 Thread Daniel Kahn Gillmor
On 02/04/2011 11:59 AM, micah anderson wrote:
 On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor 
 d...@fifthhorseman.net wrote:
 when you say encrypted by do you mean encrypted to?  do you have
 access to the corresponding secret key?
 
 If I open a message that was sent to me and was encrypted by the sender
 using a key that they have since revoked, or has expired, I saw this.

so you hold key A, the sender holds key B, they encrypt the message with
B, and then revoke key B, and then you try to read the message (without
holding key B)?

or are you saying you hold key A, sender holds key B, they encrypt to A,
*sign* the message with B, and then revoke B?  If it's this case, does
the same thing happen even if the message is not encrypted?

Sorry for the nit-picking pedantry here -- I'm trying to get a clear
workflow for a test case.

 Most humans I know reference their key by the keyid, where keyid means
 the 8 character representation of their key. When they need to ensure
 that their key is not being spoofed they either rely on the tools to do
 cryptographic verification, or inspect the fingerprint. I dont think
 moving towards using a longer format of the keyid helps here. The key is
 unknown, and to get it known requires going through a key signing
 process, or fingerprint verification, which isn't aided by having a
 longer form keyid. 
 
 If I am presented with a short form keyid, and I go and try and receive
 that key from the keyservers and then I am presented with two different
 options, then I'm going to inspect the two and determine then which one
 is the right one. I dont need to front-load that knowledge in the
 interface.

and if you're presented with only one key, you will just accept that
one?  that puts you at the mercy of the network (or the keyserver
operator at least, and we can't all have the luxury of being or knowing
the keyserver operator directly).

If you're arguing i would like to be able to recognize the key by
32-bit key ID i don't think it's actually possible to do so because of
the spoofability; a tool that provides cryptographic assurances should
discourage attempts to make the user vulnerable to spoofing.

If you're saying we should remove the 64-bit keyID entirely and just say
signature from unknown, non-validated key, i think that's a defensible
position, though it's not one i would take.

 is this really a use case worth bothering with?
 
 No.

:)

 do you have a suggestion for how you think it should behave
 differently?
 
 I think my suggestion was already made: short form.

and as i said above, i think this is a mistake if we're trying to
provide tools that give cryptographic assurances.

thanks for the testing and the corner cases!

--dkg



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: new crypto branch providing full PGP/MIME support

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 12:09:48 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins 
 jroll...@finestructure.net wrote:
   Can we pass the decrypted text to message mode on a reply?
  Yeah, some folks pointed this out on #notmuch this morning.  The
  decryption is only happening in notmuch-show, but we need to do it in
  notmuch-reply as well for the decrypted text to show up in the reply.
  I'm working on it now.
 
 Great news, thanks!

Thanks for the feedback!

 Also: another confirmation for the revoked/expired key behaviour.  Emacs
 UI just reports:
 
   json-read-string: Wrong type argument: characterp, :json-eof
 
 Let me know if you need any samples of misbehaving mails.

Yeah, I've found some emails that are doing this as well.  I'm looking
in to what we can do to mitigate the problem, which I think is
ultimately a problem in GMime.  The json output should not be breaking,
though, so that I will definitely fix.

jamie.


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


Re: new crypto branch providing full PGP/MIME support

2011-02-04 Thread Jameson Rollins
On Fri, 04 Feb 2011 13:12:27 -0400, David Bremner brem...@unb.ca wrote:
 I reported some pretty weird experiences yesterday on IRC with replies
 not working. It turns out they were caused by having old versions of
 xapian installed in /usr/local (which I think might have caused some
 mixup with headers and libraries being different versions).
 
 The decryption is working ok for me now (aside from the issue I
 mentioned already with unknown encrypted+signed).
...
 tl;dr: yesterdays weirdness was not the fault of J. Rollins.

phew!  Although there remains the issue of replying to encrypted
messages, since notmuch-reply was not modified to decrypt messages
before replying.  I'm working on that now.

jamie.


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


no quoted messages if fcc folder cannot be created.

2011-02-04 Thread Daniel Kahn Gillmor
i tried running

 emacs -Q -f notmuch

and replying to a message.

Since i didn't have my emacs config, it wanted to create the default
sent folder in ~/mail/sent

if i told it no, don't create it when prompted (during the setup of
the reply message) then the body of the replied-to message doesn't show up.

If ~/mail/sent is actually a file (not a folder) so that the fcc folder
cannot be created, then i get the same problem (the replied-to message
doesn't show up quoted in the body of the new *mail* buffer).

sorry i haven't been able to track it down more than that.

to replicate:

 mv ~/mail/sent ~/mail/sent.bak
 touch ~/mail/sent
 emacs -Q -f notmuch

   find a message, hit 'r'

hth,

--dkg



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch