Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
01_sni.patch | [PATCH] use SNI when connecting with SSL imap.gmail.com doesn't accept connections without SNI anymore. Without this extension, it returns a self-signed certificate and mbsync is unable to complete: $ openssl s_client -connect imap.gmail.com:993 -noservername CONNECTED(00000005) depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid verify error:num=18:self signed certificate verify return:1 depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid verify return:1 --- Certificate chain 0 s:OU = "No SNI provided; please fix your client.", CN = invalid2.invalid i:OU = "No SNI provided; please fix your client.", CN = invalid2.invalid This commit configure the SSL connection to transmit the hostname through SNI. This has been tested with both GMail (which requires SNI) and Fastmail (which doesn't require SNI). |
Vincent Bernat <vincent@bernat.ch> | no | 2018-08-22 | ||
reject-funny-mailbox-names--1.3.patch | [PATCH] CVE-2021-20247: reject funny mailbox names from IMAP LIST/LSUB in particular, '..' in the name could be used to escape the Path/Inbox of a Maildir Store, which could be exploited for stealing or deleting data, or staging a (mild) DoS attack. |
Oswald Buddenhagen <ossi@users.sf.net> | no | 2021-02-14 | ||
fix-handling-of-unexpected-APPENDUID-response-code--1.3.patch | [PATCH] fix handling of unexpected APPENDUID response code if the code was sent in response to anything but a STORE, we'd overwrite a data pointer in one of our imap_cmd subclasses, an allocator data structure, or the start of the next allocation, with an int that was completely under the server's control. it's plausible that this could be exploited for remote code execution. to avoid this, we could ensure that the object is of the right type prior to casting, by using a new flag in the parameter block. but it's easier to just dispose of the out_uid field altogether and reuse the uid field that is present in the parameter block anyway, but was used only for FETCH commands so far. this problem was found by Lukas Braun <koomi@moshbit.net> using a fuzzer. |
Oswald Buddenhagen <ossi@users.sf.net> | no | 2021-04-14 | ||
CVE-2021-3657-buffer-overflows-on-big-1.3.patch | [PATCH] CVE-2021-3657: security fixes unlike in the 1.4 branch, we use signed ints for offsets and lengths, so many of the qualifying statements from the 1.4 series don't apply. |
Oswald Buddenhagen <ossi@users.sf.net> | no | 2021-11-24 |