On Mon, 30 Sep 2019 10:58, Roland Siemons said:
> 4/ Here is my proposal:
> 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not Enigmail,
Enigmail folks won't like that suggestion. Users need to install a
second tool which behaves different (because Enigmail implements parts
of GnuPG on its own).
I agree with you and, although I sometimes hack on GPA, I would suggest
Kleopatra. On Windows Kleopatra and the Explorer plugin do actually do
what you suggest and we LOTS of folks using Gpg4win. Be it for plain
file encryption or for its Outlook plugin.
> 4.2/ Ensure that, when generating a keypair, GnuPG creates one directory
> "Secretkeys", and one directory "Publickeys". Make GnuPG to store the public
> part and the secret part separately in those directories. If GnuPG needs also
> keypairs in a single file, store that under Secretkeys.
That are all internals of GnuPG (except for the revocations directory)
and should not be touched by most users. The problem is that there are
so many howtos and tutorials floating around which suggest to modify
this or that or to do that. In most cases this is not appropriate.
gpg --import and --export are the interfaces which users need to know
about - iff they really want to use the gpg _tool_. See your first point.
> 4.3/ Get rid of the confusing menu/Exportkeys/ vs. menu/Exportsecretkey. etc.
Exporting public keys is an important operation for everyone and thus it
needs to be prominent. Exporting secret keys should come with a strong
warning or better be removed and replaced by a sync-with-other-device
feature.
If you have concrete suggestions for Kleopatra, I am sure Andre will
listen to you. For GPA it is unlikely that we put a lot work into it -
it is these days mostly a test bench for my changes to GPGME.
> 4.5/ Get rid of the options to NOT publish keys on keyservers. Just work the
> opt-in alternative: If you want to publish to keyservers, make that a separate
> action that requires some effort.
No. Despite the current problems with keyservers, we like keyservers
because they make public key encryption easier. Deployment of the Web
Key Directory is still rare and some mail providers will never deploy
that. Thus the second best option is to send initially a signed mail and
the recipient can then reply encrypted - this works by looking up the
signature key on a keyserver and use that for encryption. We are
currently in the process of tweaking this so that we can eventually
make this again the default behaviour.
Shalom-Salam,
Werner
p.s. I took the freedom to change the subject to better reflect what
your suggestion is about.
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
> 4/ Here is my proposal:
> 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not Enigmail,
Enigmail folks won't like that suggestion. Users need to install a
second tool which behaves different (because Enigmail implements parts
of GnuPG on its own).
I agree with you and, although I sometimes hack on GPA, I would suggest
Kleopatra. On Windows Kleopatra and the Explorer plugin do actually do
what you suggest and we LOTS of folks using Gpg4win. Be it for plain
file encryption or for its Outlook plugin.
> 4.2/ Ensure that, when generating a keypair, GnuPG creates one directory
> "Secretkeys", and one directory "Publickeys". Make GnuPG to store the public
> part and the secret part separately in those directories. If GnuPG needs also
> keypairs in a single file, store that under Secretkeys.
That are all internals of GnuPG (except for the revocations directory)
and should not be touched by most users. The problem is that there are
so many howtos and tutorials floating around which suggest to modify
this or that or to do that. In most cases this is not appropriate.
gpg --import and --export are the interfaces which users need to know
about - iff they really want to use the gpg _tool_. See your first point.
> 4.3/ Get rid of the confusing menu/Exportkeys/ vs. menu/Exportsecretkey. etc.
Exporting public keys is an important operation for everyone and thus it
needs to be prominent. Exporting secret keys should come with a strong
warning or better be removed and replaced by a sync-with-other-device
feature.
If you have concrete suggestions for Kleopatra, I am sure Andre will
listen to you. For GPA it is unlikely that we put a lot work into it -
it is these days mostly a test bench for my changes to GPGME.
> 4.5/ Get rid of the options to NOT publish keys on keyservers. Just work the
> opt-in alternative: If you want to publish to keyservers, make that a separate
> action that requires some effort.
No. Despite the current problems with keyservers, we like keyservers
because they make public key encryption easier. Deployment of the Web
Key Directory is still rare and some mail providers will never deploy
that. Thus the second best option is to send initially a signed mail and
the recipient can then reply encrypted - this works by looking up the
signature key on a keyserver and use that for encryption. We are
currently in the process of tweaking this so that we can eventually
make this again the default behaviour.
Shalom-Salam,
Werner
p.s. I took the freedom to change the subject to better reflect what
your suggestion is about.
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Attached Files:
-
signature.asc (0.22 KB)