2011-09-08 04:19:47 +00:00
|
|
|
#include "cache.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2011-09-08 04:19:47 +00:00
|
|
|
#include "run-command.h"
|
|
|
|
#include "strbuf.h"
|
|
|
|
#include "gpg-interface.h"
|
|
|
|
#include "sigchain.h"
|
2016-06-17 23:38:43 +00:00
|
|
|
#include "tempfile.h"
|
2011-09-08 04:19:47 +00:00
|
|
|
|
|
|
|
static char *configured_signing_key;
|
2011-11-29 20:29:48 +00:00
|
|
|
static const char *gpg_program = "gpg";
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2014-08-19 20:18:07 +00:00
|
|
|
#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
|
|
|
|
#define PGP_MESSAGE "-----BEGIN PGP MESSAGE-----"
|
|
|
|
|
2014-06-23 07:05:47 +00:00
|
|
|
void signature_check_clear(struct signature_check *sigc)
|
|
|
|
{
|
2017-06-15 23:15:49 +00:00
|
|
|
FREE_AND_NULL(sigc->payload);
|
|
|
|
FREE_AND_NULL(sigc->gpg_output);
|
|
|
|
FREE_AND_NULL(sigc->gpg_status);
|
|
|
|
FREE_AND_NULL(sigc->signer);
|
|
|
|
FREE_AND_NULL(sigc->key);
|
2014-06-23 07:05:47 +00:00
|
|
|
}
|
|
|
|
|
2014-08-14 22:31:13 +00:00
|
|
|
static struct {
|
|
|
|
char result;
|
|
|
|
const char *check;
|
|
|
|
} sigcheck_gpg_status[] = {
|
|
|
|
{ 'G', "\n[GNUPG:] GOODSIG " },
|
|
|
|
{ 'B', "\n[GNUPG:] BADSIG " },
|
|
|
|
{ 'U', "\n[GNUPG:] TRUST_NEVER" },
|
|
|
|
{ 'U', "\n[GNUPG:] TRUST_UNDEFINED" },
|
gpg-interface: use more status letters
According to gpg2's doc/DETAILS:
For each signature only one of the codes GOODSIG, BADSIG,
EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.
gpg1 ("classic") behaves the same (although doc/DETAILS differs).
Currently, we parse gpg's status output for GOODSIG, BADSIG and
trust information and translate that into status codes G, B, U, N
for the %G? format specifier.
git-verify-* returns success in the GOODSIG case only. This is
somewhat in disagreement with gpg, which considers the first 5 of
the 6 above as VALIDSIG, but we err on the very safe side.
Introduce additional status codes E, X, Y, R for ERRSIG, EXPSIG,
EXPKEYSIG, and REVKEYSIG so that a user of %G? gets more information
about the absence of a 'G' on first glance.
Requested-by: Alex <agrambot@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-12 13:04:15 +00:00
|
|
|
{ 'E', "\n[GNUPG:] ERRSIG "},
|
|
|
|
{ 'X', "\n[GNUPG:] EXPSIG "},
|
|
|
|
{ 'Y', "\n[GNUPG:] EXPKEYSIG "},
|
|
|
|
{ 'R', "\n[GNUPG:] REVKEYSIG "},
|
2014-08-14 22:31:13 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
void parse_gpg_output(struct signature_check *sigc)
|
|
|
|
{
|
|
|
|
const char *buf = sigc->gpg_status;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Iterate over all search strings */
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
|
|
|
|
const char *found, *next;
|
|
|
|
|
|
|
|
if (!skip_prefix(buf, sigcheck_gpg_status[i].check + 1, &found)) {
|
|
|
|
found = strstr(buf, sigcheck_gpg_status[i].check);
|
|
|
|
if (!found)
|
|
|
|
continue;
|
|
|
|
found += strlen(sigcheck_gpg_status[i].check);
|
|
|
|
}
|
|
|
|
sigc->result = sigcheck_gpg_status[i].result;
|
|
|
|
/* The trust messages are not followed by key/signer information */
|
|
|
|
if (sigc->result != 'U') {
|
|
|
|
sigc->key = xmemdupz(found, 16);
|
gpg-interface: use more status letters
According to gpg2's doc/DETAILS:
For each signature only one of the codes GOODSIG, BADSIG,
EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.
gpg1 ("classic") behaves the same (although doc/DETAILS differs).
Currently, we parse gpg's status output for GOODSIG, BADSIG and
trust information and translate that into status codes G, B, U, N
for the %G? format specifier.
git-verify-* returns success in the GOODSIG case only. This is
somewhat in disagreement with gpg, which considers the first 5 of
the 6 above as VALIDSIG, but we err on the very safe side.
Introduce additional status codes E, X, Y, R for ERRSIG, EXPSIG,
EXPKEYSIG, and REVKEYSIG so that a user of %G? gets more information
about the absence of a 'G' on first glance.
Requested-by: Alex <agrambot@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-12 13:04:15 +00:00
|
|
|
/* The ERRSIG message is not followed by signer information */
|
|
|
|
if (sigc-> result != 'E') {
|
|
|
|
found += 17;
|
|
|
|
next = strchrnul(found, '\n');
|
|
|
|
sigc->signer = xmemdupz(found, next - found);
|
|
|
|
}
|
2014-08-14 22:31:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-21 23:14:40 +00:00
|
|
|
int check_signature(const char *payload, size_t plen, const char *signature,
|
2015-06-21 23:14:38 +00:00
|
|
|
size_t slen, struct signature_check *sigc)
|
|
|
|
{
|
|
|
|
struct strbuf gpg_output = STRBUF_INIT;
|
|
|
|
struct strbuf gpg_status = STRBUF_INIT;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
sigc->result = 'N';
|
|
|
|
|
|
|
|
status = verify_signed_buffer(payload, plen, signature, slen,
|
|
|
|
&gpg_output, &gpg_status);
|
|
|
|
if (status && !gpg_output.len)
|
|
|
|
goto out;
|
|
|
|
sigc->payload = xmemdupz(payload, plen);
|
|
|
|
sigc->gpg_output = strbuf_detach(&gpg_output, NULL);
|
|
|
|
sigc->gpg_status = strbuf_detach(&gpg_status, NULL);
|
|
|
|
parse_gpg_output(sigc);
|
|
|
|
|
|
|
|
out:
|
|
|
|
strbuf_release(&gpg_status);
|
|
|
|
strbuf_release(&gpg_output);
|
2015-06-21 23:14:40 +00:00
|
|
|
|
|
|
|
return sigc->result != 'G' && sigc->result != 'U';
|
2015-06-21 23:14:38 +00:00
|
|
|
}
|
|
|
|
|
2015-06-21 23:14:41 +00:00
|
|
|
void print_signature_buffer(const struct signature_check *sigc, unsigned flags)
|
|
|
|
{
|
2015-06-21 23:14:42 +00:00
|
|
|
const char *output = flags & GPG_VERIFY_RAW ?
|
|
|
|
sigc->gpg_status : sigc->gpg_output;
|
|
|
|
|
2015-06-21 23:14:41 +00:00
|
|
|
if (flags & GPG_VERIFY_VERBOSE && sigc->payload)
|
|
|
|
fputs(sigc->payload, stdout);
|
|
|
|
|
2015-06-21 23:14:42 +00:00
|
|
|
if (output)
|
|
|
|
fputs(output, stderr);
|
2015-06-21 23:14:41 +00:00
|
|
|
}
|
|
|
|
|
2014-08-19 20:18:07 +00:00
|
|
|
size_t parse_signature(const char *buf, unsigned long size)
|
|
|
|
{
|
|
|
|
char *eol;
|
|
|
|
size_t len = 0;
|
|
|
|
while (len < size && !starts_with(buf + len, PGP_SIGNATURE) &&
|
|
|
|
!starts_with(buf + len, PGP_MESSAGE)) {
|
|
|
|
eol = memchr(buf + len, '\n', size - len);
|
|
|
|
len += eol ? eol - (buf + len) + 1 : size - len;
|
|
|
|
}
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
void set_signing_key(const char *key)
|
|
|
|
{
|
|
|
|
free(configured_signing_key);
|
|
|
|
configured_signing_key = xstrdup(key);
|
|
|
|
}
|
|
|
|
|
|
|
|
int git_gpg_config(const char *var, const char *value, void *cb)
|
|
|
|
{
|
|
|
|
if (!strcmp(var, "user.signingkey")) {
|
2018-04-13 21:18:30 +00:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2011-11-29 20:29:48 +00:00
|
|
|
set_signing_key(value);
|
2018-04-13 21:18:30 +00:00
|
|
|
return 0;
|
2011-11-29 20:29:48 +00:00
|
|
|
}
|
2018-04-13 21:18:30 +00:00
|
|
|
|
2011-11-29 20:29:48 +00:00
|
|
|
if (!strcmp(var, "gpg.program")) {
|
2011-09-08 04:19:47 +00:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2011-11-29 20:29:48 +00:00
|
|
|
gpg_program = xstrdup(value);
|
2018-04-13 21:18:30 +00:00
|
|
|
return 0;
|
2011-09-08 04:19:47 +00:00
|
|
|
}
|
2018-04-13 21:18:30 +00:00
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *get_signing_key(void)
|
|
|
|
{
|
|
|
|
if (configured_signing_key)
|
|
|
|
return configured_signing_key;
|
2012-05-24 23:28:40 +00:00
|
|
|
return git_committer_info(IDENT_STRICT|IDENT_NO_DATE);
|
2011-09-08 04:19:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *signing_key)
|
|
|
|
{
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process gpg = CHILD_PROCESS_INIT;
|
sign_buffer: use pipe_command
Similar to the prior commit for verify_signed_buffer, the
motivation here is both to make the code simpler, and to
avoid any possible deadlocks with gpg.
In this case we have the same "write to stdin, then read
from stdout" that the verify case had. This is unlikely to
be a problem in practice, since stdout has the detached
signature, which it cannot compute until it has read all of
stdin (if it were a non-detached signature, that would be a
problem, though).
We don't read from stderr at all currently. However, we will
want to in a future patch, so this also prepares us there
(and in that case gpg _does_ write before reading all of the
input, though again, it is unlikely that a key uid will fill
up a pipe buffer).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 23:38:55 +00:00
|
|
|
int ret;
|
2011-09-08 04:19:47 +00:00
|
|
|
size_t i, j, bottom;
|
2016-06-17 23:38:59 +00:00
|
|
|
struct strbuf gpg_status = STRBUF_INIT;
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2016-06-17 23:38:35 +00:00
|
|
|
argv_array_pushl(&gpg.args,
|
|
|
|
gpg_program,
|
2016-06-17 23:38:59 +00:00
|
|
|
"--status-fd=2",
|
2016-06-17 23:38:35 +00:00
|
|
|
"-bsau", signing_key,
|
|
|
|
NULL);
|
2011-09-08 04:19:47 +00:00
|
|
|
|
sign_buffer: use pipe_command
Similar to the prior commit for verify_signed_buffer, the
motivation here is both to make the code simpler, and to
avoid any possible deadlocks with gpg.
In this case we have the same "write to stdin, then read
from stdout" that the verify case had. This is unlikely to
be a problem in practice, since stdout has the detached
signature, which it cannot compute until it has read all of
stdin (if it were a non-detached signature, that would be a
problem, though).
We don't read from stderr at all currently. However, we will
want to in a future patch, so this also prepares us there
(and in that case gpg _does_ write before reading all of the
input, though again, it is unlikely that a key uid will fill
up a pipe buffer).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 23:38:55 +00:00
|
|
|
bottom = signature->len;
|
2011-09-08 04:19:47 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When the username signingkey is bad, program could be terminated
|
|
|
|
* because gpg exits without reading and then write gets SIGPIPE.
|
|
|
|
*/
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
sign_buffer: use pipe_command
Similar to the prior commit for verify_signed_buffer, the
motivation here is both to make the code simpler, and to
avoid any possible deadlocks with gpg.
In this case we have the same "write to stdin, then read
from stdout" that the verify case had. This is unlikely to
be a problem in practice, since stdout has the detached
signature, which it cannot compute until it has read all of
stdin (if it were a non-detached signature, that would be a
problem, though).
We don't read from stderr at all currently. However, we will
want to in a future patch, so this also prepares us there
(and in that case gpg _does_ write before reading all of the
input, though again, it is unlikely that a key uid will fill
up a pipe buffer).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 23:38:55 +00:00
|
|
|
ret = pipe_command(&gpg, buffer->buf, buffer->len,
|
2016-06-17 23:38:59 +00:00
|
|
|
signature, 1024, &gpg_status, 0);
|
2011-09-08 04:19:47 +00:00
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
2016-06-17 23:38:59 +00:00
|
|
|
ret |= !strstr(gpg_status.buf, "\n[GNUPG:] SIG_CREATED ");
|
|
|
|
strbuf_release(&gpg_status);
|
|
|
|
if (ret)
|
2011-09-08 04:19:47 +00:00
|
|
|
return error(_("gpg failed to sign the data"));
|
|
|
|
|
|
|
|
/* Strip CR from the line endings, in case we are on Windows. */
|
|
|
|
for (i = j = bottom; i < signature->len; i++)
|
|
|
|
if (signature->buf[i] != '\r') {
|
|
|
|
if (i != j)
|
|
|
|
signature->buf[j] = signature->buf[i];
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
strbuf_setlen(signature, j);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int verify_signed_buffer(const char *payload, size_t payload_size,
|
|
|
|
const char *signature, size_t signature_size,
|
2013-02-14 16:04:44 +00:00
|
|
|
struct strbuf *gpg_output, struct strbuf *gpg_status)
|
2011-09-08 04:19:47 +00:00
|
|
|
{
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process gpg = CHILD_PROCESS_INIT;
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 12:15:08 +00:00
|
|
|
struct tempfile *temp;
|
|
|
|
int ret;
|
2013-02-14 16:04:42 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2011-09-08 04:19:47 +00:00
|
|
|
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 12:15:08 +00:00
|
|
|
temp = mks_tempfile_t(".git_vtag_tmpXXXXXX");
|
|
|
|
if (!temp)
|
2016-06-17 23:38:43 +00:00
|
|
|
return error_errno(_("could not create temporary file"));
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 12:15:08 +00:00
|
|
|
if (write_in_full(temp->fd, signature, signature_size) < 0 ||
|
|
|
|
close_tempfile_gently(temp) < 0) {
|
2016-06-17 23:38:43 +00:00
|
|
|
error_errno(_("failed writing detached signature to '%s'"),
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 12:15:08 +00:00
|
|
|
temp->filename.buf);
|
2016-06-17 23:38:43 +00:00
|
|
|
delete_tempfile(&temp);
|
|
|
|
return -1;
|
|
|
|
}
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2016-06-17 23:38:35 +00:00
|
|
|
argv_array_pushl(&gpg.args,
|
|
|
|
gpg_program,
|
|
|
|
"--status-fd=1",
|
2016-08-16 22:04:13 +00:00
|
|
|
"--keyid-format=long",
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 12:15:08 +00:00
|
|
|
"--verify", temp->filename.buf, "-",
|
2016-06-17 23:38:35 +00:00
|
|
|
NULL);
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2016-06-17 23:38:39 +00:00
|
|
|
if (!gpg_status)
|
|
|
|
gpg_status = &buf;
|
2013-02-14 16:04:42 +00:00
|
|
|
|
verify_signed_buffer: use pipe_command
This is shorter and should make the function easier to
follow. But more importantly, it removes the possibility of
any deadlocks based on reading or writing to gpg.
It's not clear if such a deadlock is possible in practice.
We do write the whole payload before reading anything, so we
could deadlock there. However, in practice gpg will need to
read our whole input to verify the signature, so it will
drain our payload first. It could write an error to stderr
before reading, but it's unlikely that such an error
wouldn't be followed by it immediately exiting, or that the
error would actually be larger than a pipe buffer.
On the writing side, we drain stderr (with the
human-readable output) in its entirety before reading stdout
(with the status-fd data). Running strace on "gpg --verify"
does show interleaved output on the two descriptors:
write(2, "gpg: ", 5) = 5
write(2, "Signature made Thu 16 Jun 2016 0"..., 73) = 73
write(1, "[GNUPG:] SIG_ID tQw8KGcs9rBfLvAj"..., 66) = 66
write(1, "[GNUPG:] GOODSIG 69808639F9430ED"..., 60) = 60
write(2, "gpg: ", 5) = 5
write(2, "Good signature from \"Jeff King <"..., 47) = 47
write(2, "\n", 1) = 1
write(2, "gpg: ", 5) = 5
write(2, " aka \"Jeff King <"..., 49) = 49
write(2, "\n", 1) = 1
write(1, "[GNUPG:] VALIDSIG C49CE24156AF08"..., 135) = 135
write(1, "[GNUPG:] TRUST_ULTIMATE\n", 24) = 24
The second line written to stdout there contains the
signer's UID, which can be arbitrarily long. If it fills the
pipe buffer, then gpg would block writing to its stdout,
while we are blocked trying to read its stderr.
In practice, GPG seems to limit UIDs to 2048 bytes, so
unless your pipe buffer size is quite small, or unless gpg
does not enforce the limit under some conditions, this seems
unlikely in practice.
Still, it is not hard for us to be cautious and just use
pipe_command.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 23:38:52 +00:00
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
|
|
|
ret = pipe_command(&gpg, payload, payload_size,
|
|
|
|
gpg_status, 0, gpg_output, 0);
|
2016-04-05 16:07:24 +00:00
|
|
|
sigchain_pop(SIGPIPE);
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2016-06-17 23:38:43 +00:00
|
|
|
delete_tempfile(&temp);
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2016-06-17 23:38:39 +00:00
|
|
|
ret |= !strstr(gpg_status->buf, "\n[GNUPG:] GOODSIG ");
|
2013-02-14 16:04:44 +00:00
|
|
|
strbuf_release(&buf); /* no matter it was used or not */
|
2013-02-14 16:04:42 +00:00
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
return ret;
|
|
|
|
}
|