intrigeri:
> sajolida wrote (05 May 2015 11:31:24 GMT) :
>> So here is a draft of the security advisory, please review and comment:
>> https://tails.boum.org/blueprint/claws_mail_leaks_plaintext_to_imap/
>
> Thanks!
>
>> stores plaintext copies of all emails that are meant to be encrypted
>> on the remote IMAP server
>
> Perhaps instead "stores plaintext copies of all emails, including
> those that are meant to be encrypted, on the remote IMAP server"?
Done.
>> By default in Tails, drafts are not stored automatically on
>> the server.
>
> I find this part (and especially "automatically") a bit vague.
> Perhaps instead mention what can lead to drafts being stored remotely?
> I'm unsure.
So I changed this whole bullet point.
>> Unfortunately, we were not yet able to fix the problem automatically
>> and everybody.
>
> s/and everybody/and for everybody/
> or
> s/and everybody/for everybody/
> perhaps?
Sure.
>> This would likely require to either modify Claws Mail or to migrate
>> to a different application.
>
> I think we can be bold and remove "likely" here. (Technically, we
> could wrap claws-mail to fix existing configurations, but this won't
> work for new configurations created with Claws Mail's wizard.)
Done.
> Perhaps "Refer to the workarounds section" should be a link?
See later...
> I would move the "Technical details" section to the end, or at least
> to after the "Workarounds" one. Most users won't care, and it's
> largely duplicating information that's in the introduction already.
Yes, when I first wrote it the introduction was not as good as it is
right now.
So I won't put a link on "workaround section" as it would jump to the
section that's right below and most likely already visible. I personally
don't like so much when I jump around a page for little reason.
>> When sending an email through IMAP
>
> I'd rather not spread an incorrect understanding of how email works.
> Perhaps instead "When sending an email from an email account
> configured to use IMAP"?
Oops, I didn't meant to say that :)
What about "When sending an email from an IMAP account" then? It's a bit
less convoluted?
>> It connects to the IMAP server and stores a plaintext copy of the email in the Queue folder on the server.
>
> s/on the server/there/ to avoid a repetition? If you don't think
> that's clear enough, keep it as-is.
>
>> either manually, either by the autosaving feature
>
> Perhaps s/either by/or/?
I'll remove this section completely as it doesn't bring more than what's
in the intro by now.
>> Delete drafts
>
> I find it confusing to see this section (that is only about cleaning
> up *past* leaks, right?) mixed with other ones that are about
> preventing *future* leaks. So either clarify what's the expected
> result of this action (and what it is _not_), or expand it a little
> bit to cover future leaks, e.g. by pointing to the next sections.
>
> Also, this section is meant to be followed in all cases, regardless of
> the strategy chosen below, right? I think this should be made clearer,
> otherwise some users may erroneously believe that they have to pick
> among 4 options, one being "Delete drafts".
I tried to improve on this.
>> or, better, through the web interface of your email provider.
>
> I don't know why it would be better. I think I'd simply remove this
> 2nd option.
I remove the "better". I'll keep this as an option because it's what I
would do myself: as Claws Mail is known to do fishy stuff with my draft
folder, I would go to the web mail to check what's actually in there.
> s/gEdit/gedit/ (that's how it's called on the upstream website, in
> the application itself, and everywhere else in our doc).
It's so weird I did that consistently on that page :( Fixed now.
>> Use the OpenPGP Applet
>
> I have two concerns with this section:
>
> 1. The "Use local Drafts and Queue folders" option seems vastly better
> than this one in all aspects I can think of. So:
> * why do we document the OpenPGP Applet option at all?
> * why do we document it _before_ the local folders one? (I bet
> most users will just pick the first option that seems to apply
> to their use case.)
I initially decided to document this because:
1. The setup with local drafts and queue is quite messy with the need
to create a local mailbox and we know that this has been problematic wrt
persistence in the past. I also end up with *three* of each folder on my
screen when doing that on Riseup (see screenshot for both
tails@??? and tails-dev@???) but only two on pimienta.org.
Maybe there's something wrong on Riseup.
2. It might be easier to trust for the user as in this scenario the
user never inputs sensitive information directly in Claws Mail.
3. It might be easier to perform for people who are used to the
OpenPGP Applet already (maybe not that many people I reckon).
But now I removed it.
> 2. I'm a little bit wary of recommending usage of PGP/inline.
> Were these instructions tested with messages whose cleartext body
> contains non-us-ascii chars? I suspect such messages won't be
> correctly displayed, once decrypted, by a number of email clients,
> due to the lack of encoding charset information.
I tested it, and here are the results:
- The received message opens well in Claws Mail.
- The received message opens well in the applet.
- The received message doesn't open well in Icedove.
But how is this different from what we are already documenting on
https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/public-key_cryptography.html?
Because we might have to mention something on this page...
>> As for the possible long term solutions to this problem, we are considering:
>>
>> * Getting the development team of Claws Mail to fix the problem
>> upstream and release a security update for Debian
>
> There's a problem with this sentence: the way "release" is conjugated
> here, I understand that we want to get Claws Mail developers to
> release a security update for Debian, which is of course not the case.
I, of course, thought is was. Now removed.
>> We contacted them about this problem already but please help them
>> provide a technical solution if you can.
>
> I don't like "but" here. Perhaps s/already but please/already.
> Please/?
Good!
I pushed my work into doc/9161-claws-advisory. Please have a second look
if you want.
--
sajolida
