Debian Patches

Status for isync/1.3.0-2.2+deb11u1

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

All known versions for source package 'isync'

Links