On 08/10/12 16:09, anonym wrote:
> 07/10/12 01:00, sajolida@??? wrote:
>>
>> Today I worked on the documentation of the new Tails gpgApplet. (I
>> wondered whether giving it a name without camel case.)
>>
>> You can find most of the work in commits 1c3c5bc..94e4fb4, but those are
>> a bit hardcore so you might rather look directly at the result on those
>> four pages:
>>
>> [1] /doc/encryption_and_privacy/gpgapplet
>> [2] /doc/encryption_and_privacy/gpgapplet/passphrase_encryption
>> [3] /doc/encryption_and_privacy/gpgapplet/public-key_encryption
>> [4] /doc/encryption_and_privacy/gpgapplet/decrypt_verify
>
> Nice work!
>
>> I have a couple of questions and bug reports, though.
>>
>> First, I was wondering about the warning "message was not integrity
>> protected" when using passphrase encryption. Does it always appears? Is
>> there no way of providing integrity when using a passphrase? See what
>> I'm saying about it on line 73 of
>> /doc/encryption_and_privacy/gpgapplet/decrypt_verify.mdwn
>
> gpg's default symmetric cipher, CAST5, has MDC integrity protection off
> by default. One can add it by issuing `--force-mdc`, or by switching
> cipher to e.g. AES. [1]
>
> One can make gpg ignore the warning with `--no-mdc-warning`, but that's
> a bad idea. Another thing to consider is that using CAST5 with
> `--force-mdc` may be unusual, which would make symmetrically encrypted
> messages stand out. The same may be true for using AES128/256 (which has
> MDC integrity protection on by default). Hence I'm not sure we want to
> do anything about this.
>
> [1] http://lists.gnupg.org/pipermail/gnupg-users/2006-April/028398.html
I remove my line about this message in the documentation. I think it's
find to stay with the default cipher and so have the message printed.
>> Then, I'm still sticking to documenting Tails gpgApplet and not
>> documenting more generally OpenPGP or GnuPG in Tails (Seahorse, Claws
>> mail, etc.) so for example I'm not mentioning the “Manage keys” feature.
>> Tell me if I should and I will. By the way the menu item “Manage keys”
>> is not capitalized as the others.
>
> Capitalization fixed in commit 41db0fc.
>
>> And now the bug reports:
>>
>> 1. When decrypting a text encrypted using passphrase encryption, if you
>> enter a bad passphrase you have to select the text again to try another
>> passphrase. The encrypted text should be kept in the clipboard even if
>> the given passphrase is bad, no?
>
> Note that this has been the case since the beginning of gpgApplet, so
> it's not a regression. I'd rather have this reported in a TODO which can
> be fixed at a later date.
I'm creating todo/gpgapplet\:_do_not_erase_clipboard_after_bad_passphrase.
>> 2. When encrypting using several public keys that are not trusted, the
>> warning message only mentions one. It should either mention each key in
>> a separate dialog box, or all of them in a single dialog box.
>
> The warning dialog should list all untrusted keys that were selected in
> a line-break separated "list". I just did a test with a few untrusted
> keys, and all were listed. Are you sure about your results? Steps to
> reproduce?
There's no bug indeed: one of the public key was from a key pair I had,
so it was trusted automatically ;)
>> On the same topic, shall I explain that this message appears when keys
>> are not signed by the user, and how they can sign them? I would say this
>> is off-topic for now.
>
> Leave that for now. I prefer linking our users to a good external guide
> about gpg's WoT rather than writing our own. I looked at the GNU Privacy
> handbook (the gnupg-doc package) but the corresponding section [1]
> contains to much CLI stuff that it likely will only lead to confusion.
>
> [1] file:///usr/share/doc/gnupg-doc/GNU_Privacy_Handbook/html/x335.htm
I'm creating todo/improve_openpgp_documentation.
>> 3. I found two phrases of the GUI that need to be rephrased.
>>
>> “Here is the GnuPG output:” → “Output of GnuPG:”
>>
>> See GDP [5]: 4.3 How to Write for Translation, Topic 13
>> « Replace the genitive construction with an of structure. »
>>
>> “While it were at it, GnuPG also mentionned in passing:” → “Other
>> messages provided by GnuPG:”
>>
>> See GDP [5]: 1.3 Tone
>> « Avoid colloquial language. Colloquial language is difficult to
>> translate and usually culture-specific. Stay neutral. »
>
> Agreeing on both counts. Fixed in commit 69e08be.
Cool. Can you take care of the required merge in the appropriate branch
before the freeze? I think I won't be able to do them.
