* g10/verify.c (verify_files): Track the first error code.
--
It seems to be possible to play tricks with packet structures so that
log_error is not used for a bad input data. By actually checking the
return code and let the main driver in gpg call log_error, we can fix
this case.
Note that using gpg --verify-files and relying solely on gpg's return
code is at best a questionable strategy. It is for example impossible
to tell which data has been signed.
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 5681b8eaa4)
* g10/gpg.h (g10_errstr): Remove macro and change all occurrences by
gpg_strerror.
(G10ERR_): Remove all macros and change all occurrences by their
GPG_ERR_ counterparts.
Signed-off-by: Werner Koch <wk@gnupg.org>
The asymmetric quotes used by GNU in the past (`...') don't render
nicely on modern systems. We now use two \x27 characters ('...').
The proper solution would be to use the correct Unicode symmetric
quotes here. However this has the disadvantage that the system
requires Unicode support. We don't want that today. If Unicode is
available a generated po file can be used to output proper quotes. A
simple sed script like the one used for en@quote is sufficient to
change them.
The changes have been done by applying
sed -i "s/\`\([^'\`]*\)'/'\1'/g"
to most files and fixing obvious problems by hand. The msgid strings in
the po files were fixed with a similar command.
We better do this once and for all instead of cluttering all future
commits with diffs of trailing white spaces. In the majority of cases
blank or single lines are affected and thus this change won't disturb
a git blame too much. For future commits the pre-commit scripts
checks that this won't happen again.
the literals count.
* verify.c (verify_one_file), decrypt.c (decrypt_messages): Call it
here so we allow multiple literals in --multifile mode (in different
files - not concatenated together).
to libgcrypt functions, using shared error codes from libgpg-error,
replacing the old functions we used to have in ../util by those in
../jnlib and ../common, renaming the malloc functions and a couple of
types. Note, that not all changes are listed below becuause they are
too similar and done at far too many places. As of today the code
builds using the current libgcrypt from CVS but it is very unlikely
that it actually works.
Werner Koch