Re: [Enigmail] Weird behaviour using "Import Key" button
On 16.09.15 19:56, Alexander Buchner wrote: > Thanks for looking into this! > I now updated to a nightly build and I can confirm that the bug is fixed > there. :-) Thanks for reporting! > By the way: Is there already a planned release schedule for a next > stable version? https://sourceforge.net/p/enigmail/wiki/Planning%20for%20version%201.9/ Note the "tentative". Ludwig signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Weird behaviour using "Import Key" button
On 16.09.2015 17:49, Patrick Brunschwig wrote: > I got the debug log. The behavior is a bug in Enigmail 1.8.2 that has > been fixed a while ago (that is, I can reproduce it in 1.8.2, but not > with nightly builds of Enigmail). > > The problem is not related to the "import key" function, but to > interpreting the verification result from a signed message unambiguously. > > -Patrick Thanks for looking into this! I now updated to a nightly build and I can confirm that the bug is fixed there. By the way: Is there already a planned release schedule for a next stable version? signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Weird behaviour using "Import Key" button
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 How do we turn on support for encrypted subject and other headers in the nightly build of V1.9 support encrypted subject and other headers [[Done]] -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJV+cyBAAoJEMULjwHW7pSQWnUP+wcGdYjtEpLWutas3XeSYkrq gXUvC5uLWhcCxichXrEl54+XVrmpNzc+dpviskap0ZH4pYzuW3jK1qRemTzPrFUI 79YOVk6G1MxTqvCCxUZMGjRowWXgynzjYHtOpJ5x9GmNepxbpYJ9YK9e+3weB0+I Tk3t9iDGG1Fb6up6W8Dr6v6jAz8kdRazHONU9bRZHt0F1bQoErfy22JlquAcphn6 TLKvfHbNSRwXsYaam4gvntdMNPzQT0AYEVf79DCHRhs+0ENWEVSRdLzufe99fTY3 5t+nUkHv9EucmxEXO1J4yPIiiIbnZZ8EVwAM0/UtxyIw/D/4h+54ba1VHNML8N4l eafASVcWpD3kbv+u6yw02lSyeAOKNy7yTqllatX08NXTZAyZhR0qCxL0d+72nwni 2Nr13sQAxhz1Fa73glcQ8J4HnVjb6bULpMjlFeTK8+4807w5hkFOPE7852o+o6qC 0QNqQl5laVtF0rwnLEGfrBH04F2Z0lUlj+jHBMRiL4m72nf2tuBac/iHocUeBBOr reOsVt99aTqbGKpmC99E8uPjwx+NTswcf69pCUGKcXRhpWkaUIPJAkSNE0lzjbZt PKJ9OYywfzP4hArTSOUG787qzS6R7LuAPOEVR1MyjCZy29B2CNXbBDsV+UQdxwYR wpOT/8gF0hhEhvTktpM7 =Hrb0 -END PGP SIGNATURE- ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key Management Owner Trust
On Wed 2015-09-16 16:21:12 -0400, Phil Stracchino wrote: > While your point is in general valid, I suggest that if you KNOW > something is in flux and do not know yet what its final form will be, it > is prudent to wait until you know what it's going to look like before > you rewrite code against it. Rewriting the same body of code twice > doubles the number of opportunities to introduce bugs. The Enigmail team is part of these discussions, and the discussions are not active enough. Enigmail has an opportunity to stake out space with reasonable choices. "What its final form will be" will depend on the information that feeds into the discussion, including information derived from actual implementers working on improving their actual software with an eye toward vocab consistency and UI/UX improvements :) Without these kind of real-world contributions, the discussion won't reach nearly as fruitful a conclusion (if indeed it ever concludes -- hopefully the discussion will be ongoing as more improvements are found). --dkg ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key Management Owner Trust
On 09/16/15 20:09, Daniel Kahn Gillmor wrote: > On Wed 2015-09-16 16:21:12 -0400, Phil Stracchino wrote: >> While your point is in general valid, I suggest that if you KNOW >> something is in flux and do not know yet what its final form will be, it >> is prudent to wait until you know what it's going to look like before >> you rewrite code against it. Rewriting the same body of code twice >> doubles the number of opportunities to introduce bugs. > > The Enigmail team is part of these discussions, and the discussions are > not active enough. Enigmail has an opportunity to stake out space with > reasonable choices. "What its final form will be" will depend on the > information that feeds into the discussion, including information > derived from actual implementers working on improving their actual > software with an eye toward vocab consistency and UI/UX improvements :) > > Without these kind of real-world contributions, the discussion won't > reach nearly as fruitful a conclusion (if indeed it ever concludes -- > hopefully the discussion will be ongoing as more improvements are > found). By all means discuss, contribute and suggest. :) All I'm saying is that writing code against other code that you know is about to change is usually a bad plan until you know what it's changing to. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: 603.293.8485 signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
[Enigmail] Enigmail V1.9
http://sourceforge.net/p/enigmail/wiki/Planning%20for%20version%201.9/ How do we turn on support for encrypted subject and other headers in the nightly build of V1.9 support encrypted subject and other headers [[Done]] ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key Management Owner Trust
On Wed 2015-09-16 21:40:22 -0400, Phil Stracchino wrote: > By all means discuss, contribute and suggest. :) All I'm saying is > that writing code against other code that you know is about to change is > usually a bad plan until you know what it's changing to. What "other code" are you referring to? The discussion Robert was talking about is a higher-level, non-code discussion, afaict, where implementers of OpenPGP tools are trying to come to consensus around shared terminology so that we can confuse our users less. We currently confuse our users a lot with our scattered/difficult terminology, as this thread shows :) --dkg ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key Management Owner Trust
On 09/16/15 22:10, Daniel Kahn Gillmor wrote: > On Wed 2015-09-16 21:40:22 -0400, Phil Stracchino wrote: >> By all means discuss, contribute and suggest. :) All I'm saying is >> that writing code against other code that you know is about to change is >> usually a bad plan until you know what it's changing to. > > What "other code" are you referring to? The discussion Robert was > talking about is a higher-level, non-code discussion, afaict, where > implementers of OpenPGP tools are trying to come to consensus around > shared terminology so that we can confuse our users less. I was speaking in general principles. The principle still applies, though with a terminology discussion you can to some extent apply individual terminology changes as they are agreed upon. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: 603.293.8485 signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key Management Owner Trust
On 17.09.15 05:30, Robert J. Hansen wrote: >> Alternately, we *know* that the existing language confuses a lot of >> people, and enigmail has an opportunity to drive the language >> regularization process by using a reasonable, clean vocabulary >> itself. > > It sounds a lot like the "something must be done; this is something; > ergo we must do it" fallacy. > > Enigmail is used in a lot of places, and there's an entire community of > trainers who teach it to others. Changing the terminology on them once > is understandable, especially if it fixes problems. Changing it twice > in quick succession seems rude to the trainers, who will have to adapt > their teaching materials, FAQs, manuals, webpages, etc., twice. > >> I don't think that any enigmail development should wait on results >> -- enigmail should help make the results happen. > > I emphatically disagree. Could we please take this discussion to another, more appropriate place? GnuPG-devel or GnuPG-users appear to be better suited to me. Ludwig signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key Management Owner Trust
> Alternately, we *know* that the existing language confuses a lot of > people, and enigmail has an opportunity to drive the language > regularization process by using a reasonable, clean vocabulary > itself. It sounds a lot like the "something must be done; this is something; ergo we must do it" fallacy. Enigmail is used in a lot of places, and there's an entire community of trainers who teach it to others. Changing the terminology on them once is understandable, especially if it fixes problems. Changing it twice in quick succession seems rude to the trainers, who will have to adapt their teaching materials, FAQs, manuals, webpages, etc., twice. > I don't think that any enigmail development should wait on results > -- enigmail should help make the results happen. I emphatically disagree. ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
Re: [Enigmail] Key Management Owner Trust
On 16.09.15 01:15, Jacob L Anawalt wrote: (...) > My observation with my keyring has been that "Display invalid keys" > only hides revoked and expired keys from my list. It may do more than > that for a keyring with keys in more states than mine. Like your > experience, I still have a lot of keys with "-" or "unknown" in the > Key Validity column with that filter turned off. Keys with validity hidden when "Display invalid keys" unchecked: 'i':invalid 'e':expired 'r':revoked 'D':disabled > (...) > Viewing a sampling of the keys using gpg, the "stuck" ones that say > "unknown" in the Owner Trust column of Enigmail say "trust: undefined" > in the gpg output. The key I have set to trusted in Enigmail says > "trust: full" in gpg. My default key that says ultimate in Enigmail > says "trust: ultimate" in gpg. The rest of the keys that show "-" in > Enigmail say "trust: unknown" in gpg: > > Owner Trust mapping > Enigmail GnuPG trust value > ultimate ultimate6 > trusted full5 > marginal marginal4 > untrusted never 3 > unknown undefined 2 > - unknown Thanks for looking this up! > I got the trust values from gpg --export-ownertrust. The entries that > show up as "-" in Enigmail and "unknown" in GnuPG don't export. I > expect this is because an ownertrust was never assigned to those keys. > Keys in that state stay out of the trusted keys list, but once > assigned via Enigmail or gpg to a trust value of 2, 4, 5, or 6 they > show up in the list. > > I think that a key with trust a value of 2 should not be in the list, > just like ones without a trust value assignment and the ones with > trust value of 3. Enigmail does not use the --export-ownertrust, but instead it uses --list-keys and --with-colons. The documentation of all output is in the doc/Details of GnuPG source code, which for "Ownertrust" is quite fuzzy compared with the rest. Enigmail should hide the following codes if "Display untrusted keys" is unchecked: - / Unknown (i.e. no value assigned) n / Untrusted I think we should both hide the "unknown"/"undefined" and "untrusted/never". I don't think, we should change the labelling before the OpenPGP summit comes up with a new unified language. Ludwig signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
