* common/sysutils.c (gnupg_fopen) [W32]: Use _wfopen if needed. Use
new function in most places where fopen is used.
--
The config files in 2.2 are still read using fopen - we need to change
this to allow Unicode directory names. There is also one case where
files are written using the old fopen. The new option parser in 2.3
does not have this problem but at some places fopen is also still used.
GnuPG-bug-id: 5098
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/options.h (opt): Add flags.dummy_outfile.
* g10/decrypt.c (decrypt_message): Set this global flag instead of the
fucntion local flag.
* g10/plaintext.c (get_output_file): Ignore opt.output if that was
used as a dummy option aslong with --use-embedded-filename.
--
The problem here was that an explicit specified --decrypt, as
meanwhile suggested, did not work with that dangerous
--use-embedded-filename. In contrast it worked when gpg decrypted as
a side-effect of parsing the data.
GnuPG-bug-id: 4500
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/plaintext.c (get_output_file): Check and open special filename
before falling back to stdout.
--
GnuPG-bug-id: 2677
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/gpg.c (oMimemode): New.
(opts): Add --mimemode.
(main): Use --mimemode only in rfc4880bis compliance mode.
* g10/options.h (struct opt): Add field "mimemode".
* g10/build-packet.c (do_plaintext): Allow for mode 'm'.
* g10/encrypt.c (encrypt_simple, encrypt_crypt): Use 'm' if requested.
* g10/plaintext.c (handle_plaintext): Handle 'm' mode.
* g10/sign.c (write_plaintext_packet): Handle 'm' mode.
(sign_file, sign_symencrypt_file): Use 'm' if requested.
--
Thsi patch prepares for a proposed change in RFC4880bis to support a
MIME flag. A literal data packet with the mime flag set is handled
like a 't' or 'u' but CR are not removed. The PLAINTEXT status line
will also indicate a MIME content.
If --mimemode is used without --rfc4880bis 't' will be used.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/decrypt-data.c (decrypt_data): If OPT.UNWRAP_ENCRYPTION is set,
copy the data to the output file instead of continuing to process it.
* g10/gpg.c (enum cmd_and_opt_values): Add new value oUnwrap.
(opts): Handle oUnwrap.
(main): Likewise.
* g10/options.h (opt): Add field unwrap_encryption.
* g10/plaintext.c (handle_plaintext): Break the output file selection
functionality into ...
(get_output_file): ... this new function.
--
Signed-off-by: Neal H. Walfield <neal@g10code.com>
GnuPG-bug-id: 1060
Debian-bug-id: 282061
* 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>
* g10/openfile.c (open_sigfile): Factor some code out to ...
(get_matching_datafile): new function.
* g10/plaintext.c (hash_datafiles): Do not try to find matching file
in batch mode.
* g10/mainproc.c (check_sig_and_print): Print a warning if a possibly
matching data file is not used by a standard signatures.
--
Allowing to use the abbreviated form for detached signatures is a long
standing bug which has only been noticed by the public with the
release of 2.1.0. :-(
What we do is to remove the ability to check detached signature in
--batch using the one file abbreviated mode. This should exhibit
problems in scripts which use this insecure practice. We also print a
warning if a matching data file exists but was not considered because
the detached signature was actually a standard signature:
gpgv: Good signature from "Werner Koch (dist sig)"
gpgv: WARNING: not a detached signature; \
file 'gnupg-2.1.0.tar.bz2' was NOT verified!
We can only print a warning because it is possible that a standard
signature is indeed to be verified but by coincidence a file with a
matching name is stored alongside the standard signature.
Reported-by: Simon Nicolussi (to gnupg-users on Nov 7)
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.
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.
