07/10/12 01:00, [email protected] 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! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
