git/imap-send.c, branch v2.50.1

curl: fix integer variable typechecks with curl_easy_setopt()

2025-06-04T21:17:53Z

As discussed in the previous commit, we should be passing long integers, not regular ones, to curl_easy_setopt(), and compiling against curl 8.14 loudly complains if we don't. That patch fixed integer constants by adding an "L". This one deals with actual variables. Arguably these variables could just be declared as "long" in the first place. But it's actually kind of awkward due to other code which uses them: - port is conceptually a short, and we even call htons() on it (though weirdly it is defined as a regular int). - ssl_verify is conceptually a bool, and we assign to it from git_config_bool(). So I think we could probably switch these out for longs without hurting anything, but it just feels a bit weird. Doubly so because if you don't set USE_CURL_FOR_IMAP_SEND set, then the current types are fine! So let's just cast these to longs in the curl calls, which makes what's going on obvious. There aren't that many spots to modify (and as you can see from the context, we already have some similar casts). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

imap-send: explicitly verify the peer certificate

2025-03-25T22:48:58Z

It is a bug to obtain the peer certificate without verifying it. Having said that, from my reading of https://www.openssl.org/docs/man1.1.1/man3/SSL_set_verify.html, it would appear that Git is saved by the fact that it calls `SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL)` already early on. In other words, that `SSL_VERIFY_PEER` combined with the `NULL` parameter (i.e. no overridden callback) would _already_ verify the peer certificate. The fact that we later call `SSL_get_peer_certificate()` is mistaken by CodeQL to mean that that peer certificate still needs to be verified, but that had already happened at that point. Nevertheless, it is better to verify the peer certificate explicitly than to rely on some side effect that is really hard to reason about (and that took me more than one business day to analyze fully). It also makes it easier for static analyzers to validate the correctness of the code. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

credential: stop using `the_repository`

2024-12-18T18:44:31Z

Stop using `the_repository` in the "credential" subsystem by passing in a repository when filling, approving or rejecting credentials. Adjust callers accordingly by using `the_repository`. While there may be some callers that have a repository available in their context, this trivial conversion allows for easier verification and bubbles up the use of `the_repository` by one level. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

global: mark code units that generate warnings with `-Wsign-compare`

2024-12-06T11:20:02Z

Mark code units that generate warnings with `-Wsign-compare`. This allows for a structured approach to get rid of all such warnings over time in a way that can be easily measured. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'bc/drop-ancient-libcurl-and-perl'

2024-12-04T01:14:48Z

Drop support for older libcURL and Perl. * bc/drop-ancient-libcurl-and-perl: gitweb: make use of s///r Require Perl 5.26.0 INSTALL: document requirement for libcurl 7.61.0 git-curl-compat: remove check for curl 7.56.0 git-curl-compat: remove check for curl 7.53.0 git-curl-compat: remove check for curl 7.52.0 git-curl-compat: remove check for curl 7.44.0 git-curl-compat: remove check for curl 7.43.0 git-curl-compat: remove check for curl 7.39.0 git-curl-compat: remove check for curl 7.34.0 git-curl-compat: remove check for curl 7.25.0 git-curl-compat: remove check for curl 7.21.5

imap: replace atoi() with strtol_i() for UIDVALIDITY and UIDNEXT parsing

2024-10-24T18:03:44Z

Replace unsafe uses of atoi() with strtol_i() to improve error handling when parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands. Invalid values, such as those with letters, now trigger error messages and prevent malformed status responses. I did not add any test for this commit as we do not have any test for git-imap-send(1) at this point. Signed-off-by: Usman Akinyemi Signed-off-by: Taylor Blau

git-curl-compat: remove check for curl 7.34.0

2024-10-23T20:16:35Z

libcurl 7.34.0 was released in December 2013, which is well over ten years ago, and no major operating system vendor is still providing security support for it. Debian 8 and Ubuntu 14.04, both of which are out of mainstream security support, have supported a newer version, and RHEL 8, which is still in support, also has a newer version. Remove the check for this version and use this functionality unconditionally. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

Merge branch 'jk/no-openssl-with-openssl-sha1'

2024-09-20T18:16:31Z

The "imap-send" now allows to be compiled with NO_OPENSSL and OPENSSL_SHA1 defined together. * jk/no-openssl-with-openssl-sha1: imap-send: handle NO_OPENSSL even when openssl exists

imap-send: handle NO_OPENSSL even when openssl exists

2024-09-12T17:24:51Z

If NO_OPENSSL is defined, then imap-send.c defines a fallback "SSL" type, which is just a void pointer that remains NULL. This works, but it has one problem: it is using the type name "SSL", which conflicts with the upstream name, if some other part of the system happens to include openssl. For example: $ make NO_OPENSSL=Nope OPENSSL_SHA1=Yes imap-send.o CC imap-send.o imap-send.c:35:15: error: conflicting types for ‘SSL’; have ‘void *’ 35 | typedef void *SSL; | ^~~ In file included from /usr/include/openssl/evp.h:26, from sha1/openssl.h:4, from hash.h:10, from object.h:4, from commit.h:4, from refs.h:4, from setup.h:4, from imap-send.c:32: /usr/include/openssl/types.h:187:23: note: previous declaration of ‘SSL’ with type ‘SSL’ {aka ‘struct ssl_st’} 187 | typedef struct ssl_st SSL; | ^~~ make: *** [Makefile:2761: imap-send.o] Error 1 This is not a terribly common combination in practice: 1. Why are we disabling openssl support but still using its sha1? The answer is that you may use the same build options across many versions, and some older versions of Git no longer build with modern versions of openssl. 2. Why are we using a totally unsafe sha1 that does not detect collisions? You're right, we shouldn't. But in preparation for using unsafe sha1 for non-cryptographic checksums, it would be nice to be able to turn it on without hassle. We can make this work by adjusting the way imap-send handles its fallback. One solution is something like this: #ifdef NO_OPENSSL #define git_SSL void * #else #define git_SSL SSL #endif But we can observe that we only need this definition in one spot: the struct which holds the variable. So rather than play around with macros that may cause unexpected effects, we can just directly use the correct type in that struct. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/mark-unused-parameters'

2024-08-26T18:32:23Z

Mark unused parameters as UNUSED to squelch -Wunused warnings. * jk/mark-unused-parameters: t-hashmap: stop calling setup() for t_intern() test scalar: mark unused parameters in dummy function daemon: mark unused parameters in non-posix fallbacks setup: mark unused parameter in config callback test-mergesort: mark unused parameters in trivial callback t-hashmap: mark unused parameters in callback function reftable: mark unused parameters in virtual functions reftable: drop obsolete test function declarations reftable: ignore unused argc/argv in test functions unit-tests: ignore unused argc/argv t/helper: mark more unused argv/argc arguments oss-fuzz: mark unused argv/argc argument refs: mark unused parameters in do_for_each_reflog_helper() refs: mark unused parameters in ref_store fsck callbacks update-ref: mark more unused parameters in parser callbacks imap-send: mark unused parameter in ssl_socket_connect() fallback