This updates to the latest version. According to the changelog 0.5.12
was skipped. The changes in this release are required to be compatible
with the latest dovecot release.
Changes:
- duplicate: The test was handled badly in a multiscript (sieve_before,
sieve_after) scenario in which an earlier script in the sequence with
a duplicate test succeeded, while a later script caused a runtime
failure. In that case, the message is recorded for duplicate tracking,
while the message may not actually have been delivered in the end.
- editheader: Sieve interpreter entered infinite loop at startup when
the "editheader" configuration listed an invalid header name. This
problem can only be triggered by the administrator.
- relational: The Sieve relational extension can cause a segfault at
compile time. This is triggered by invalid script syntax. The segfault
happens when this match type is the last argument of the test command.
This situation is not possible in a valid script; positional arguments
are normally present after that, which would prevent the segfault.
- sieve: For some Sieve commands the provided mailbox name is not
properly checked for UTF-8 validity, which can cause assert crashes at
runtime when an invalid mailbox name is encountered. This can be
caused by the user by writing a bad Sieve script involving the
affected commands ("mailboxexists", "specialuse_exists").
This can be triggered by the remote sender only when the user has
written a Sieve script that passes message content to one of the
affected commands.
- sieve: Large sequences of 8-bit octets passed to certain Sieve
commands that create or modify message headers that allow UTF-8 text
(vacation, notify and addheader) can cause the delivery or IMAP
process (when IMAPSieve is used) to enter a memory-consuming
semi-infinite loop that ends when the process exceeds its memory
limits. Logged in users can cause these hangs only for their own
processes.
While we already had some test we might as well add the test for that
exact package to the tests attribute set. After all that should be what
(primarily) tests dovecot.
This fixes CVE_2020-24386, CVE-2020-25725 and a bunch of regular bugs
[1].
* CVE-2020-24386: Specially crafted command can cause IMAP hibernate to
allow logged in user to access other people's emails and filesystem
information.
* CVE-2020-25275: Mail delivery / parsing crashed when the 10 000th MIME part was
message/rfc822 (or if parent was multipart/digest). This happened
due to earlier MIME parsing changes for CVE-2020-12100.
[1] https://raw.githubusercontent.com/dovecot/core/2.3.13/NEWS
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
- Drop unused arguments.
- Do not use both php and phpPackages since those can have different PHP versions.
- Do not use with statement just for a single composer package.
- Add phase hooks so that one can easily customize the derivation.
- Clarify license to gpl-2.0-only.
- Add jtojnar to maintainers.
this feature already gets enabled when the environment is not darwin (see line 202), keeping it in the 'standard features' breaks the build for darwin currently.
When cross-compiling, pulseaudio seems to not find some m4 macro
providing GSETTINGS_RULES.
However, apart from the obviously missing gsettings support, this works
just fine.
This package[1] is a replacement for the old phantomjs-integration[2]
which is practically EOL. It is basically used to render PNGs of panels
that triggered an alert in Grafana.
This package internally uses `puppeteer`[3] to control a headless
Chromium instance. Even though puppeteer recommends to use a fixed
revision of `chromium`, I checked that our default `pkgs.chromium` works
fine as well. Also, I don't think it's a good idea to use outdated
browser versions[4].
I used the latest revision from `master` on purpose since compiling the
code with `tsc` from `v2.0` didn't work and I couldn't figure out why.
[1] https://grafana.com/grafana/plugins/grafana-image-renderer
[2] https://grafana.com/blog/2020/05/07/grafana-7.0-preview-new-image-renderer-plugin-to-replace-phantomjs/
[3] https://github.com/puppeteer/puppeteer
[4] currently, puppeteer v2.0.0 is used which recommends revision 706915
(v79.0.3945.130).
This reverts commit f19b7b03a0, reversing
changes made to 572a864d02.
Sorry. I pushed the wrong staging-next (the one that had my master
merged in). This was not intended.
This contains the base infrastructure (including a basic update script)
for maintaining Grafana plugins inside Nix, which, in a subsequent
commit, will be used for allowing the NixOS Grafana module to
automatically install plugins.
This release contains official support for TimescaleDB 2.0 (single-node) as well as various bug fixes and code cleanup.
Please note that multinode support is still in alpha and automatic upgrades of multinode deployments to future versions is not yet guaranteed (we hope to support this starting with the next release). Please only use multimode deployments for testing only.
Notes for people upgrading from 0.1.3:
- The dropChunk property in the Promscale Helm chart is renamed to maintenance. The drop-chunks CRON job is now renamed to maintenance, you will need to replace the dropChunk.schedule value with maintenance.schedule.
Notes for multinode deployments
- This should only be used for testing, not production deployments
- In particular, we are not guaranteeing upgrades from 0.1.4 to future versions in multinode deployments.
- All nodes have to be added to the cluster before starting Promscale; adding nodes afterwards is not yet supported.
* update two explicit references to jdk14 to just jdk, which no longer
points at jdk8 after #89731.
* patch an explicit -XX:+UseConcMarkSweepGC to -XX:UseG1GC, as the
former now throws an error (after having been deprecated since jdk 9)
Apparently the handling of `buildFlagsArray` in `buildGo*` is blatantly
broken since it doesn't quote flags specified as list elements properly.
Because of that, the `-ldflags` are not interpreted properly and
`prometheus --version` doesn't output anything useful. By specifying
flags in both `buildFlags` and `buildFlagsArray` the issue gets fixed
since both variables are passed to `go install`.
