git/gpg-interface.c, branch v2.16.2

tempfile: auto-allocate tempfiles on heap

2017-09-06T08:19:54Z

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 Signed-off-by: Junio C Hamano

tempfile: do not delete tempfile on failed close

2017-09-06T08:19:53Z

When close_tempfile() fails, we delete the tempfile and reset the fields of the tempfile struct. This makes it easier for callers to return without cleaning up, but it also makes this common pattern: if (close_tempfile(tempfile)) return error_errno("error closing %s", tempfile->filename.buf); wrong, because the "filename" field has been reset after the failed close. And it's not easy to fix, as in many cases we don't have another copy of the filename (e.g., if it was created via one of the mks_tempfile functions, and we just have the original template string). Let's drop the feature that a failed close automatically deletes the file. This puts the burden on the caller to do the deletion themselves, but this isn't that big a deal. Callers which do: if (write(...) || close_tempfile(...)) { delete_tempfile(...); return -1; } already had to call delete when the write() failed, and so aren't affected. Likewise, any caller which just calls die() in the error path is OK; we'll delete the tempfile during the atexit handler. Because this patch changes the semantics of close_tempfile() without changing its signature, all callers need to be manually checked and converted to the new scheme. This patch covers all in-tree callers, but there may be others for not-yet-merged topics. To catch these, we rename the function to close_tempfile_gently(), which will attract compile-time attention to new callers. (Technically the original could be considered "gentle" already in that it didn't die() on errors, but this one is even more so). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

always check return value of close_tempfile

2017-09-06T08:19:53Z

If close_tempfile() encounters an error, then it deletes the tempfile and resets the "struct tempfile". But many code paths ignore the return value and continue to use the tempfile. Instead, we should generally treat this the same as a write() error. Note that in the postimage of some of these cases our error message will be bogus after a failed close because we look at tempfile->filename (either directly or via get_tempfile_path). But after the failed close resets the tempfile object, this is guaranteed to be the empty string. That will be addressed in a future patch (because there are many more cases of the same problem than just these instances). Note also in the hunk in gpg-interface.c that it's fine to call delete_tempfile() in the error path, even if close_tempfile() failed and already deleted the file. The tempfile code is smart enough to know the second deletion is a noop. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

verify_signed_buffer: prefer close_tempfile() to close()

2017-09-06T08:19:52Z

We do a manual close() on the descriptor provided to us by mks_tempfile. But this runs contrary to the advice in tempfile.h, which notes that you should always use close_tempfile(). Otherwise the descriptor may be reused without the tempfile object knowing it, and the later call to delete_tempfile() could close a random descriptor. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ab/free-and-null'

2017-06-24T21:28:41Z

A common pattern to free a piece of memory and assign NULL to the pointer that used to point at it has been replaced with a new FREE_AND_NULL() macro. * ab/free-and-null: *.[ch] refactoring: make use of the FREE_AND_NULL() macro coccinelle: make use of the "expression" FREE_AND_NULL() rule coccinelle: add a rule to make "expression" code use FREE_AND_NULL() coccinelle: make use of the "type" FREE_AND_NULL() rule coccinelle: add a rule to make "type" code use FREE_AND_NULL() git-compat-util: add a FREE_AND_NULL() wrapper around free(ptr); ptr = NULL

*.[ch] refactoring: make use of the FREE_AND_NULL() macro

2017-06-16T19:44:09Z

Replace occurrences of `free(ptr); ptr = NULL` which weren't caught by the coccinelle rule. These fall into two categories: - free/NULL assignments one after the other which coccinelle all put on one line, which is functionally equivalent code, but very ugly. - manually spotted occurrences where the NULL assignment isn't right after the free() call. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

config: don't include config.h by default

2017-06-15T19:56:22Z

Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

gpg-interface: use more status letters

2016-10-12T17:41:59Z

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 Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

Merge branch 'lt/gpg-show-long-key-in-signature-verification-maint' into lt/gpg-show-long-key-in-signature-verification

2016-08-16T22:04:13Z

Linus's original was rebased to apply to the maintenance track just in case binary distributors that are stuck in the past want to take it to their older codebase. Let's merge it up to more modern codebase that has Peff's gpg-interface clean-up topic that appeared after Git 2.9 was tagged. * lt/gpg-show-long-key-in-signature-verification-maint: gpg-interface: prefer "long" key format output when verifying pgp signatures

gpg-interface: prefer "long" key format output when verifying pgp signatures

2016-08-16T22:02:22Z

Yes, gpg2 already uses the long format by default, but most distributions seem to still have "gpg" be the older 1.x version due to compatibility reasons. And older versions of gpg only show the 32-bit short ID, which is quite insecure. This doesn't actually matter for the _verification_ itself: if the verification passes, the pgp signature is good. But if you don't actually have the key yet, and want to fetch it, or you want to check exactly which key was used for verification and want to check it, we should specify the key with more precision. In fact, we should preferentially specify the whole key fingerprint, but gpg doesn't actually support that. Which is really quite sad. Showing the "long" format improves things to at least show 64 bits of the fingerprint. That's a lot better, even if it's not perfect. This change the log format for "git log --show-signature" from commit 2376d31787760af598db23bb3982a57419854e5c merged tag 'v2.9.3' gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT using RSA key ID 96AFE6CB gpg: Good signature from "Junio C Hamano " gpg: aka "Junio C Hamano " gpg: aka "Junio C Hamano " Merge: 2807cd7b25af e0c1ceafc5be Author: Junio C Hamano Date: Fri Aug 12 10:02:18 2016 -0700 to commit 2376d31787760af598db23bb3982a57419854e5c merged tag 'v2.9.3' gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT gpg: using RSA key B0B5E88696AFE6CB gpg: Good signature from "Junio C Hamano " gpg: aka "Junio C Hamano " gpg: aka "Junio C Hamano " Merge: 2807cd7b25af e0c1ceafc5be Author: Junio C Hamano Date: Fri Aug 12 10:02:18 2016 -0700 (note the longer key ID, but also the reflowing of the text) and also changes the format in the merge messages when merging a signed tag. If you already use gpg2 (either because it's installed by default, or because you have set your gpg_program configuration to point to gpg2), that already used the long format, you'll also see a change: it will now have the same formatting as gpg 1.x, and the verification string looks something like gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT gpg: using RSA key 79BE3E4300411886 gpg: Good signature from "Linus Torvalds " [ultimate] where it used to be on one line: gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT using RSA key ID 79BE3E4300411886 gpg: Good signature from "Linus Torvalds " [ultimate] so there is certainly a chance this could break some automated scripting. But the 32-bit key ID's really are broken. Also note that because of the differences between gpg-1.x and gpg-2.x, hopefully any scripted key ID parsing code (if such code exists) is already flexible enough to not care. This was triggered by the fact that the "evil32" project keys ended up leaking to the public key servers, so now there are 32-bit aliases for just about every open source developer that you can easily get by mistake if you use the 32-bit short ID format. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano