Hi,
This is an "important fixes only" release in case you don't want to upgrade to v2.3.15. There is no matching Pigeonhole release - use the same v2.3.14 instead.
https://dovecot.org/releases/2.3/dovecot-2.3.14.1.tar.gz <https://dovecot.org/releases/2.3/dovecot-2.3.14.1.tar.gz> https://dovecot.org/releases/2.3/dovecot-2.3.14.1.tar.gz.sig <https://dovecot.org/releases/2.3/dovecot-2.3.14.1.tar.gz.sig>
Binary packages in https://repo.dovecot.org/ <https://repo.dovecot.org/> Docker images in https://hub.docker.com/r/dovecot/dovecot <https://hub.docker.com/r/dovecot/dovecot>
- CVE-2021-29157: Dovecot does not correctly escape kid and azp fields in JWT tokens. This may be used to supply attacker controlled keys to validate tokens, if attacker has local access.
- CVE-2021-33515: On-path attacker could have injected plaintext commands before STARTTLS negotiation that would be executed after STARTTLS finished with the client.
- lib-index: Corrupted mime.parts in dovecot.index.cache may have resulted in Panic: file imap-bodystructure.c: line 206 (part_write_body): assertion failed: (text == ((part->flags & MESSAGE_PART_FLAG_TEXT) != 0))
- imap: SETMETADATA could not be used to unset metadata values. Instead NIL was handled as a "NIL" string. v2.3.14 regression.
On Jun 21, 2021, at 7:21 AM, Timo Sirainen <timo@sirainen.com> wrote:
This is an "important fixes only" release in case you don't want to upgrade to v2.3.15. There is no matching Pigeonhole release - use the same v2.3.14 instead.
Need this small patch to build on newer MacOS: --- src/lib/ioloop-notify-kqueue.c.orig 2021-06-14 07:56:46.000000000 -0400 +++ src/lib/ioloop-notify-kqueue.c 2021-06-21 12:10:16.000000000 -0400 @@ -11,6 +11,7 @@ #include "ioloop-private.h" #include "llist.h" +#include "time-util.h" #include <unistd.h> #include <fcntl.h> #include <sys/types.h> or it will error with: ioloop-notify-kqueue.c:70:2: error: implicit declaration of function 'i_gettimeofday' is invalid in C99 [-Werror,-Wimplicit-function-declaration] i_gettimeofday(&ioloop_timeval); ^ -- Daniel J. Luke
On Mon, Jun 21, 2021 at 1:24 PM Timo Sirainen <timo@sirainen.com> wrote:
Binary packages in https://repo.dovecot.org/
The repository https://repo.dovecot.org/ce-2.3.14 does not contain the
latest binary package for version 2.3.14.1, as one would expect. The
only way to get this package seems to be by changing to the more
specific repository ce-2.3.14.1? ce-2.3-latest only provides
2.3.15, so using that repository with pinning also does not seem like
an alternative.
Will 2.3.14.1 become available in https://repo.dovecot.org/ce-2.3.14 or is there another repository one should use if you want security updates whilst staying on a specific version?
- Eirik
On 23. Jun 2021, at 13.17, Eirik Rye <rye@trojka.no> wrote:
On Mon, Jun 21, 2021 at 1:24 PM Timo Sirainen <timo@sirainen.com> wrote:
Binary packages in https://repo.dovecot.org/
The repository https://repo.dovecot.org/ce-2.3.14 does not contain the latest binary package for version 2.3.14.1, as one would expect. The only way to get this package seems to be by changing to the more specific repository
ce-2.3.14.1?ce-2.3-latestonly provides 2.3.15, so using that repository with pinning also does not seem like an alternative.Will 2.3.14.1 become available in https://repo.dovecot.org/ce-2.3.14 or is there another repository one should use if you want security updates whilst staying on a specific version?
Hmm. That kind of symlinks haven't been done before either, so it's not at least a change from previous Dovecot repository behavior. Also it would be a bit tricky - how would you install 2.3.14 specifically if it became a symlink? I guess we could always make it 2.3.14.0 and add 2.3.14 symlink to it, but that also feels a bit wrong since there never was 2.3.14.0 release exactly.
On Wed, Jun 23, 2021 at 5:03 PM Timo Sirainen <timo@sirainen.com> wrote:
Hmm. That kind of symlinks haven't been done before either, so it's not at least a change from previous Dovecot repository behavior. Also it would be a bit tricky - how would you install 2.3.14 specifically if it became a symlink? I guess we could always make it 2.3.14.0 and add 2.3.14 symlink to it, but that also feels a bit wrong since there never was 2.3.14.0 release exactly.
I would expect *all* versions starting with "2.3.14" to be in the
ce-2.3.14 repository. In this case, the packages for 2.3.14 and
2.3.14.1 would be in ce-2.3.14. Then we let the package manager work
its magic to ensure we have the latest patch/security version
installed. The way it is now, there is literally no way to receive the
2.3.14.1 security update without manually updating your apt source
lists to ce-2.3.14.1 which makes me question the value of using a
repo in the first place.
If someone, for some reason, specifically wants to install the
previous 2.3.14 release, they can pin that version or do apt-get install dovecot-core=2.3.14 && apt-mark hold dovecot-core
The same would go for ce-2.3-latest, which would contain binary
packages for 2.3.14, 2.3.14.1, 2.3.15, and any future versions.
Regular users would get the latest 2.3.15 release as normal, but
advanced users can pin to a specific version prefix, e.g.:
Package: dovecot-core Pin: version 2:2.3.14* Pin-Priority: 1000
For reference, look at Google's Kubernetes repository (https://packages.cloud.google.com/apt/). They provide every historical version in a single repository. I think this is an intuitive way of doing it, that also allows (and suggests) the user to use apt's somewhat powerful pinning mechanisms to select desired versions.
- Eirik
participants (3)
-
Daniel J. Luke
-
Eirik Rye
-
Timo Sirainen