mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-22 10:19:57 +01:00
6823ed4658
* common/sysutils.c (gnupg_fd_valid): New function. * common/sysutils.h (gnupg_fd_valid): New declaration. * common/logging.c (log_set_file): Use the new function. * g10/cpr.c (set_status_fd): Likewise. * g10/gpg.c (main): Likewise. * g10/keylist.c (read_sessionkey_from_fd): Likewise. * g10/passphrase.c (set_attrib_fd): Likewise. * tests/openpgp/Makefile.am (XTESTS): Add the new test. * tests/openpgp/issue2941.scm: New file. -- Consider a situation where the user passes "--status-fd 3" but file descriptor 3 is not open. During the course of executing the rest of the commands, it's possible that gpg itself will open some files, and file descriptor 3 will get allocated. In this situation, the status information will be appended directly to whatever file happens to have landed on fd 3 (the trustdb? the keyring?). This is a potential data destruction issue for all writable file descriptor options: --status-fd --attribute-fd --logger-fd It's also a potential issue for readable file descriptor options, but the risk is merely weird behavior, and not data corruption: --override-session-key-fd --passphrase-fd --command-fd Fixes this by checking whether the fd is valid early on before using it. GnuPG-bug-id: 2941 Signed-off-by: Justus Winter <justus@g10code.com>