> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
>
> On 04/09/18 09:52, Fiedler Roman wrote:
> > Maybe the current hammer documentation should be updated, to remove
> > the "--use-as-hammer" options? Or at least declare, that they shall not
> > be used that way. See:
> >
> > https://www.gnupg.org/gph/en/manual/r1606.html
> > https://www.gnupg.org/gph/en/manual/r1574.html
>
> Ah, but you didn't pass it a keyring, did you? You passed it an exported
> OpenPGP key, which is no longer the format of a keyring! :-)
This might be an issue, but now I tried also with the "pubring.kbx" file
from the key used to create the signature (without exporting anything)
and the error message stays completely the same. The message is quite
similar to starting gpgv without any keyring at all:
# /usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent data.gpg
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/proc/self/fd/nonexistent/trustedkeys.kbx': General
error
[GNUPG:] ERROR add_keyblock_resource 33554433
[GNUPG:] UNEXPECTED 0
gpgv: verify signatures failed: Unexpected error
So maybe the "GNUPG:] UNEXPECTED 0" (last two lines) are not related to the
keyring at all (the
first three lines are related).
BTW: what would be the recommended/most secure way to create a keyring
file with a single public key, probably without all the gpg2 overhead of
creating
home directory, searching proc to kill gpg-agent afterwards and cleaning up
the home directory in secure way afterwards?
After trying to get gnupg2 working for more than a day now, but always managing
to get only from one undocumented error message to the next, one undocumented
argument behavior to the next, I will downgrade to gnupg1. In my opinion, next
migration attempt should be started with next Ubuntu LTS 2020 earliest.
> > Werner gave a good solution in another followup message.
>
> Yes, the new option to *encrypt* to a key in a file made me forget about
> the age-old gpgv :-). I got it mixed up.
>
> > Or could I submit patches to documentation and source code (error
> handling)
> > myself? I did not find a "contribute" section on the gnupg website at a
> > first
> glance
> > (menus/FAQs), but could look into it deeper, if helpful.
>
> I'd say: definitely. I'm not a GnuPG dev, though. I think for instance
> the git repository with the man page can be reached through the web on [1].
Thanks for the reference, I will try to figure out, how gnupg development is
structured,
e.g. if patches have to be submitted to gnupg-dev first ....
> Note that if you were to carefully read the long table of contents of
> the "GnuPG manual"[2], you'd stumble upon these entries:
>
> > 8 Helper Tools
> > [...]
> > 8.2 Verify OpenPGP signatures
>
> I think your addition to the man page would be helpful, but a balance
> has to be struck between documenting what something does and what it
> does not. Writing good, clear documentation is hard. I don't think the
> current documentation is as good as it could be. The fact that there are
> so many options and commands makes it very hard to do right. In the
> current state of the documentation, I think your addition is a good one.
> More in general, I think there should be documentation that users read
> which means they wouldn't end up at the man page for the gpg
> command-line tool at all, but they would immediately have chosen gpgv in
> the first place. I hope I'm succeeding in getting my intention across,
> I'm having some trouble putting it in words :-).
>
> man pages are reference works, not user guides. You already know how to
> use something, but the details elude you for a moment? You grab a
> reference. You can't learn English from a dictionary, and you can't
> efficiently look up the spelling of a word in an English course.
>
> In this particular case, what set you off in the wrong direction was
> that you were doing something which was never *intended* to work, it
> just did. Worse, people have been telling other people that this was
> something you could do. I think it's hard to catch all these things in
> documentation when at the same time people on the interwebs are saying
> "oh you should use an exported key as keyring".
Fully agree here. There is something important in the documentation missing.
I already offered once to contribute to that part of documentation, but there
was dispute with other gnupg mailing list folks, that had quite different
understanding
of engineering-, design- and end user documentation for security critical
software.
>From my point of view following structure would improve the whole process:
1) have use-case documentation describing scenarios where gpg should be used.
Make them as distinct as possible to use-cases where gpg should NOT be used.
One use case group could be "fully automated en/decrypt and verify on devices
without permanent storage", another one "Embedded gpg for e-mail decryption"
or "gpg for command line e-mail/file encryption" ....
2) For designing GPG, derive software requirements from all usecases
3) for end user documentation, give recommended gpg configuration, command
line, reference output (for debugging) for each set of use-cases. The end user
has then to decide which set of use-cases is closest to the one he wants to use
to find the most appropriate gpg calls/config.
While documentation is structured that way, do you have to add anything to an
intermediate docu patch for [1], e.g.:
--- gpg.texi 2018-09-04 11:31:35.654503169 +0000
+++ gpg.texi 2018-09-04 11:34:42.337194756 +0000
@@ -1,5 +1,5 @@
@c Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
-@c 2008, 2009, 2010 Free Software Foundation, Inc.
+@c 2008, 2009, 2010, 2018 Free Software Foundation, Inc.
@c This is part of the GnuPG manual.
@c For copying conditions, see the file gnupg.texi.
@@ -1449,11 +1449,14 @@
Note that this adds a keyring to the current list. If the intent is to
use the specified keyring alone, use @option{--keyring} along with
-@option{--no-default-keyring}.
+@option{--no-default-keyring}. To verify a signature against only
+keys from a single keyring file "gpgv" might better suit your needs.
If the option @option{--no-keyring} has been used no keyrings will
be used at all.
+Bear in mind that valid keyring files should be created using
+@option(--import) on an empty @option(--primary-keyring) file.
@item --secret-keyring @var{file}
@opindex secret-keyring
> [1] <https://dev.gnupg.org/source/gnupg/browse/master/doc/gpg.texi>
> [2] <https://gnupg.org/documentation/manuals/gnupg/#SEC_Contents>
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
