Reason: Fixes CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
Description:
It is possible for a local attacker without access to the Apache Cassandra
process or configuration files to manipulate the RMI registry to perform a
man-in-the-middle attack and capture user names and passwords used to access
the JMX interface. The attacker can then use these credentials to access
the JMX interface and perform unauthorised operations.
Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables
this issue to be exploited remotely.
3.0.x users should upgrade to 3.0.22
Reason: Fixes CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
Description:
It is possible for a local attacker without access to the Apache Cassandra
process or configuration files to manipulate the RMI registry to perform a
man-in-the-middle attack and capture user names and passwords used to access
the JMX interface. The attacker can then use these credentials to access
the JMX interface and perform unauthorised operations.
Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables
this issue to be exploited remotely.
2.2.x users should upgrade to 2.2.18
Reason: Fixes CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
Description:
It is possible for a local attacker without access to the Apache Cassandra
process or configuration files to manipulate the RMI registry to perform a
man-in-the-middle attack and capture user names and passwords used to access
the JMX interface. The attacker can then use these credentials to access
the JMX interface and perform unauthorised operations.
Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables
this issue to be exploited remotely.
2.1.x users should upgrade to 2.1.22
Reason: Fixes CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
Description:
It is possible for a local attacker without access to the Apache Cassandra
process or configuration files to manipulate the RMI registry to perform a
man-in-the-middle attack and capture user names and passwords used to access
the JMX interface. The attacker can then use these credentials to access
the JMX interface and perform unauthorised operations.
Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables
this issue to be exploited remotely.
3.11.x users should upgrade to 3.11.8
Update patch that prevents making V8 snapshots, as those segfault.
Fix build by building only the database server. Other make targets fetch
dependencies at build time and this behaviour cannot be overriden.
Therefore, the clients and web interface are no longer built. See
rethinkdb/rethinkdb#6867.
Not strictly an upgrade, but adds a new mongodb-4_2 target with the
current mongodb from that branch.
Use matching client and server versions in mongodb tests- tests were
using the mongo 3.4 client to connect, and this finally doesn't work
with server 4.2.
Per reviewer suggestion, adding myself as cheetah3 maintainer.
Additionally, reestore comments describing the purpose of the
build-dependencies patch
================================================================================
Redis 6.0.3 Released Sat May 16 18:10:21 CEST 2020
================================================================================
Upgrade urgency CRITICAL: a crash introduced in 6.0.2 is now fixed.
1eab62f7e Remove the client from CLOSE_ASAP list before caching the master.
================================================================================
Redis 6.0.2 Released Fri May 15 22:24:36 CEST 2020
================================================================================
Upgrade urgency MODERATE: many not critical bugfixes in different areas.
Critical fix to client side caching when
keys are evicted from the tracking table but
no notifications are sent.
The following are the most serious fix:
* XPENDING should not update consumer's seen-time
* optimize memory usage of deferred replies - fixed
* Fix CRC64 initialization outside the Redis server itself.
* stringmatchlen() should not expect null terminated strings.
* Cluster nodes availability checks improved when there is
high Pub/Sub load on the cluster bus.
* Redis Benchmark: Fix coredump because of double free
* Tracking: send eviction messages when evicting entries.
* rax.c updated from upstream antirez/rax.
* fix redis 6.0 not freeing closed connections during loading.
New features:
* Support setcpuaffinity on linux/bsd
* Client Side Caching: Add Tracking Prefix Number Stats in Server Info
* Add --user argument to redis-benchmark.c (ACL)
The 6.0 changelog notes that systemd support was rewritten. The effects
of that seem to be twofold:
* Redis will silently fail to sd_notify if not built with libsystemd,
breaking our unit configuration.
* It also appears to misbehave if told to daemonize when running under
systemd -- note that upstream's sample unit configuration does not
daemonize:
https://github.com/antirez/redis/blob/unstable/utils/systemd-redis_server.service
fix: Adding libtool to allow darwin compiles
Libtool seems to be required for mongodb to compile on darwin.
fix: Marking MongoDB as broken on aarch64
fix: Adding libtools to the pkg imports
Update mongodb to 4.0.4
**Note**: This makes redis use libc malloc when cross-compiling to
ARM. This may or may not degrade performance.
The reason for this is vendored jemalloc with Redis' patches. The
makefile for deps has hardcoded configure flags for jemalloc, and as a
result, it is unable to cross-compile it.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
Would previously overwrite the binary with the wrapper and thus wrap
itself (resulting in an infinite recursion on execution) for the
binaries in /bin.t
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
He prefers to contribute to his own nixpkgs fork triton.
Since he is still marked as maintainer in many packages
this leaves the wrong impression he still maintains those.
