Announcing Astroid v0.11

Announcing Astroid v0.11

[Gaute Hope]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Greetings,

Astroid v0.11 has been released!

  Astroid is a lightweight and fast graphical threads-with-tags email
  client for notmuch. Written in C++ using GTK+, WebKit and gmime.

Astroid can be acquired, along with usage and instructions for use, at:

    https://github.com/astroidmail/astroid

  once you get Astroid running press '?' to get a list of keybindings
  for the current context. For 'The Tour' check out:

    https://github.com/astroidmail/astroid/wiki


## Some of the changes since v0.10.2

* Move to the CMake build system.
* Allow HTML parts to be composed using Markdown.
* Use color to indicate whether a message is marked in thread-index.
* Always throw key-id when sending (using GMime 3)
* Bunch of minor stuff

Regards, Gaute


[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: Announcing Astroid v0.11

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

Hi Gaute--

On Sun 2018-02-04 11:46:20 +0100, Gaute Hope wrote:
> Astroid v0.11 has been released!

Congratulations -- it's great to see this progress! :)

> * Always throw key-id when sending (using GMime 3)

Can you explain this choice?  As someone who receives mail with a thrown
key-id, and as someone who has multiple secret keys, the user experience
of receiving encrypted mail like this is *terrible*.  (terrible to the
point of me wanting to ask people who do this for normal mail to just
send me mail in the clear in the future :( )

In particular: GnuPG doesn't know which key to use, so it prompts me for
passphrases for *all* of the secret keys i control, in succession.

I understand the desire to reduce metadata leakage.  But if you're
wrapping the PGP/MIME application/pgp-encrypted part in an RFC822
message that contains a header with the person's e-mail address anyway,
it's not clear that there has been a significant reduction of cleartext
metadata.  So this seems like a bad tradeoff for any case where the
recipient is explicitly specified (i.e., not in Bcc:)

Regards,

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Announcing Astroid v0.11

[Gaute Hope]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Daniel Kahn Gillmor writes on februar 4, 2018 16:37:
> On Sun 2018-02-04 11:46:20 +0100, Gaute Hope wrote:
>> * Always throw key-id when sending (using GMime 3)
> 
> Can you explain this choice?  As someone who receives mail with a thrown
> key-id, and as someone who has multiple secret keys, the user experience
> of receiving encrypted mail like this is *terrible*.  (terrible to the
> point of me wanting to ask people who do this for normal mail to just
> send me mail in the clear in the future :( )
> 
> In particular: GnuPG doesn't know which key to use, so it prompts me for
> passphrases for *all* of the secret keys i control, in succession.
> 
> I understand the desire to reduce metadata leakage.  But if you're
> wrapping the PGP/MIME application/pgp-encrypted part in an RFC822
> message that contains a header with the person's e-mail address anyway,
> it's not clear that there has been a significant reduction of cleartext
> metadata.  So this seems like a bad tradeoff for any case where the
> recipient is explicitly specified (i.e., not in Bcc:)

Hi Daniel,

This is done to hide Bcc-recipients. As you mention 
- and you know all this, but I'll list it for the sake of discussion - 
any Bcc-recipients would be listed as GPG recipients and would thus be 
exposed (which could be critical / embarassing). Of course the number 
of anonymous recipients does not match the visible receivers with 
Bcc-recipients. As a side-note it is theoretically possible to set the GPG-recipient-key to arbitrary values independent of the actual recipients. 

There has been some discussion on the issue on #astroid, and ideally we 
should make this optionable, default off (configurable) - with a warning 
before sending when Bcc-recipients are listed and keys are not thrown. 
(Note that this would also leak meta-data, since if keys are only thrown 
when there are Bcc-recipients you have another hint that there are Bcc-recipients, see above.)

As you say, GnuPG must try all the secret keys; but many 
users use some sort of keyring to unlock their keys - in which case 
the hassle is limited to a bit extra time. I don't have any stats on 
this though!

Regards, Gaute


[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: Announcing Astroid v0.11

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Sun 2018-02-04 18:52:22 +0100, Gaute Hope wrote:
> This is done to hide Bcc-recipients.

sure, but i'm wondering why you throw *all* keyids, instead of only the
key-ids of the bcc'ed people?

> As you say, GnuPG must try all the secret keys; but many 
> users use some sort of keyring to unlock their keys - in which case 
> the hassle is limited to a bit extra time. I don't have any stats on 
> this though!

right, but the sender can't know whether this is the case or not, i
think.

fwiw, i do agree with you that the onus is ultimately on the recipient's
MUA to fix this UI/UX disaster; but why force it on them in the case
where it doesn't actually eliminate any metadata leakage? (i.e., when
they're in To: or Cc: already, and not Bcc'ed)

      --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Announcing Astroid v0.11

[Gaute Hope]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

Daniel Kahn Gillmor writes on februar 4, 2018 19:32:
> On Sun 2018-02-04 18:52:22 +0100, Gaute Hope wrote:
>> This is done to hide Bcc-recipients.
> 
> sure, but i'm wondering why you throw *all* keyids, instead of only the
> key-ids of the bcc'ed people?

Because that is currently the only option when using GMime [0].
 
>> As you say, GnuPG must try all the secret keys; but many 
>> users use some sort of keyring to unlock their keys - in which case 
>> the hassle is limited to a bit extra time. I don't have any stats on 
>> this though!
> 
> right, but the sender can't know whether this is the case or not, i
> think.
> 
> fwiw, i do agree with you that the onus is ultimately on the recipient's
> MUA to fix this UI/UX disaster; but why force it on them in the case
> where it doesn't actually eliminate any metadata leakage? (i.e., when
> they're in To: or Cc: already, and not Bcc'ed)

Agreed; it should be turned off (as per the spec in my previous email) 
when there are no Bcc-recipients. The best would of course be to send 
the e-mail seperately to each Bcc-recipient, but that feels like being 
overly careful / taking on the job of the MTA.

Regards, Gaute


[0] https://developer.gnome.org/gmime/stable/GMimeMultipartEncrypted.html#g-mime-multipart-encrypted-encrypt

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: Announcing Astroid v0.11

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Sun 2018-02-04 20:10:25 +0100, Gaute Hope wrote:
> Because that is currently the only option when using GMime [0].

right, sad.  and that's likely due to the constraints of GPGME.  what a
dependency chain!

I've just opened two issues to try to push that forward:

  https://github.com/jstedfast/gmime/issues/45
  https://dev.gnupg.org/T3775

Feel free to weigh in there as another MUA developer -- if you let them
know what kind of an interface you'd prefer that would help them see
that this is a valued feature.

> Agreed; it should be turned off (as per the spec in my previous email) 
> when there are no Bcc-recipients.

right, that's a clear win over the current status quo.

> The best would of course be to send the e-mail seperately to each
> Bcc-recipient, but that feels like being overly careful / taking on
> the job of the MTA.

Well, i guess you could limit it to two copies total: one copy is to all
Bcc'ed recipients, and one copy to all non-Bcc'ed recipients.  you'd
want to make sure that you got the same Message-ID on each generated
copy, of course.

That avoids even the count of the Bcc recipients going out to the
non-bcc folks, too, which is a nice outcome.

I don't think that's too bad of an option, actually, and it's not taking
on the job of the MTA entirely.  It is a little bit strange because then
there's two ciphertexts generated that are publicly marked to have the
same cleartext (by matching Message-IDs), but that shouldn't be a
problem if the ciphers are reasonable.

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Bcc, throw-keyids, and metadata hiding [was: Re: Announcing Astroid v0.11]

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

On Sun 2018-02-04 16:18:02 -0500, Daniel Kahn Gillmor wrote:
> Well, i guess you could limit it to two copies total: one copy is to all
> Bcc'ed recipients, and one copy to all non-Bcc'ed recipients.  you'd
> want to make sure that you got the same Message-ID on each generated
> copy, of course.
>
> That avoids even the count of the Bcc recipients going out to the
> non-bcc folks, too, which is a nice outcome.

Hm, let me clarify: this only results in 2 copies total if either (a)
there is only one Bcc recipient, or (b) you actually do throw-keyids on
the Bcc'ed version, which results in the same pain for the folks
receiving the Bcc.

To avoid (b), you could do one copy of the message per Bcc'ed address,
and never throw keyids at all.

This isn't an extra metadata leak, because the bcc'ed person's e-mail
address will be put in the SMTP envelope (and, likely, in Delivered-To or
other equivalent headers appended by the MTA).

So it's N + 1 copies of the message, where N is the number of Bcc'ed
individuals.  This also removes any leak of the number of Bcc'ed
individuals from the Bcc'ed message.

i think it might be the most principled approach to metadata hiding, and
it also minimizes the pain on the receiver side.

If we ever end up with an e-mail transport that doesn't leak this
recipient metadata, then it might be worth revisiting the "throw-keyids"
situation.  but for now, it seems like the best approach really is to
have the MUA handle multiple message generation.

what do you think?

    --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Bcc, throw-keyids, and metadata hiding [was: Re: Announcing Astroid v0.11]

[Gaute Hope]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

Daniel Kahn Gillmor writes on februar 5, 2018 2:21:
> On Sun 2018-02-04 16:18:02 -0500, Daniel Kahn Gillmor wrote:
>> Well, i guess you could limit it to two copies total: one copy is to all
>> Bcc'ed recipients, and one copy to all non-Bcc'ed recipients.  you'd
>> want to make sure that you got the same Message-ID on each generated
>> copy, of course.
>>
>> That avoids even the count of the Bcc recipients going out to the
>> non-bcc folks, too, which is a nice outcome.
 
> To avoid (b), you could do one copy of the message per Bcc'ed address,
> and never throw keyids at all.
> 
> This isn't an extra metadata leak, because the bcc'ed person's e-mail
> address will be put in the SMTP envelope (and, likely, in Delivered-To or
> other equivalent headers appended by the MTA).
> 
> So it's N + 1 copies of the message, where N is the number of Bcc'ed
> individuals.  This also removes any leak of the number of Bcc'ed
> individuals from the Bcc'ed message.

Yes; this seems like the ultimate approach to this problem, unless 
it will be possible for GPG to completely hide receivers - I am guessing 
this is inherently impossible? 

A couple of concerns, some of them UI:

* What if one of the e-mails go through and not the other, especially 
  from an UI perspective - how do you modify and re-send just that copy 
  of the e-mail.

* What if you want to reply-all to your own e-mail, in notmuch land the 
  messages with the same ID will be joined together. An UI could do 
  differently, but either way all the information about receivers you 
  need is in different files.

Realistically; I think the approach using optional/configurable - and if 
possible: custom `hidden-receivers` [0] - is much faster to implement + easier 
to get right. In other words, I would very much like to see a proper 
implementation of the multiple-messages approach, but unless someone 
else is able to help out, I will probably go for the simpler approach at 
first.

Regards, Gaute

[0] https://github.com/jstedfast/gmime/issues/45


[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: Bcc, throw-keyids, and metadata hiding [was: Re: Announcing Astroid v0.11]

[Daniel Kahn Gillmor]

On Mon 2018-02-05 08:33:36 +0100, Gaute Hope wrote:
> Yes; this seems like the ultimate approach to this problem, unless 
> it will be possible for GPG to completely hide receivers - I am guessing 
> this is inherently impossible? 

I'm not sure how gpg could do that -- the metadata leak of most
recipients (To:, Cc:) is *outside* of the material that GnuPG handles,
since GnuPG doesn't see the mesage headers when it's encrypting the
body.  Maybe i'm misunderstanding you though?

> * What if one of the e-mails go through and not the other, especially 
>   from an UI perspective - how do you modify and re-send just that copy 
>   of the e-mail.

yes, this is an ugly situation, and i can understand how you're framing
it as "like taking over the job of the MTA" :/

What if you treated the message as "unsent" until *all* of the outbound
copies were successfully sent?  most MUAs have an "unsent" or "sending"
state for messages, right?  seems like it'd be the same state here.  at
worst, this means you might trigger some message redelivery if one copy
goes through clean and another copy does not.  that doesn't seem like
too bad a price to pay.

> * What if you want to reply-all to your own e-mail, in notmuch land the 
>   messages with the same ID will be joined together. An UI could do 
>   differently, but either way all the information about receivers you 
>   need is in different files.

what happens if you reply-all to your own e-mail that has a bcc
currently?  in my experience, notmuch will not show you the Bcc and you
will only be "replying all" to the visible recipients.  Since the
headers will be identical on the Bcc and non-Bcc versions of the
outbound mail, this doesn't seem to be an issue to me at all.

> Realistically; I think the approach using optional/configurable - and if 
> possible: custom `hidden-receivers` [0] - is much faster to implement + easier 
> to get right.

well, easier for the developer -- it's tough for the user to manually
flip the switches when they need to, unfortunately, even though we as
developers know how they *should* be set.

> In other words, I would very much like to see a proper implementation
> of the multiple-messages approach, but unless someone else is able to
> help out, I will probably go for the simpler approach at first.

yup, understood.  thanks for looking into this!

     --dkg

Re: Bcc, throw-keyids, and metadata hiding [was: Re: Announcing Astroid v0.11]

[Gaute Hope]

Daniel Kahn Gillmor writes on februar 5, 2018 9:33:
> On Mon 2018-02-05 08:33:36 +0100, Gaute Hope wrote:
>> Yes; this seems like the ultimate approach to this problem, unless 
>> it will be possible for GPG to completely hide receivers - I am guessing 
>> this is inherently impossible? 
> 
> I'm not sure how gpg could do that -- the metadata leak of most
> recipients (To:, Cc:) is *outside* of the material that GnuPG handles,
> since GnuPG doesn't see the mesage headers when it's encrypting the
> body.  Maybe i'm misunderstanding you though?
> 

I mean the recipient key list in the header of the encrypted 
packet [0][1]. I assume there must be a key list entry for each receiving key 
(even though it does not need to be accurate). It would be better to 
just remove the whole table of receiving keys, than setting each of them to 0.

Regards, Gaute

[0] https://www.ietf.org/rfc/rfc4880.txt
[1] https://crypto.stackexchange.com/questions/10253/why-are-the-first-few-bytes-of-a-gpg-encryption-always-the-same

Announcing Astroid v0.11.1

[Gaute Hope]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

Gaute Hope writes on februar 4, 2018 11:46:
> Greetings,
> 
> Astroid v0.11 has been released!
> 
>   Astroid is a lightweight and fast graphical threads-with-tags email
>   client for notmuch. Written in C++ using GTK+, WebKit and gmime.
> 
> Astroid can be acquired, along with usage and instructions for use, at:
> 
>     https://github.com/astroidmail/astroid
> 

Hi,

Astroid v0.11.1 has been released, CMake now automatically uses the same 
GMime version as notmuch.

Have fun - and please bug your distro to recompile packages against 
GMime 3 now that it is default. 

Regards, Gaute


[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: Announcing Astroid v0.11.1

[David Bremner]

Gaute Hope <eg@gaute.vetsj.com> writes:

>
> Hi,
>
> Astroid v0.11.1 has been released, CMake now automatically uses the same 
> GMime version as notmuch.
>

Sounds good! Thanks for cleaning this mismatch situation up.

David