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
> 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.
> 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?
> 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
> 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.
Cheers!
