blob: 0d0b15ee291adb218b162fc43da19bc0ea347de9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
{
lib,
stdenv,
fetchFromGitLab,
cmake,
}:
stdenv.mkDerivation (finalAttrs: {
pname = "olm";
version = "3.2.16";
__structuredAttrs = true;
strictDeps = true;
src = fetchFromGitLab {
domain = "gitlab.matrix.org";
owner = "matrix-org";
repo = "olm";
tag = finalAttrs.version;
hash = "sha256-JX20mpuLO+UoNc8iQlXEHAbH9sfblkBbM1gE27Ve0ac=";
};
nativeBuildInputs = [ cmake ];
doCheck = true;
postPatch = ''
substituteInPlace olm.pc.in \
--replace '$'{exec_prefix}/@CMAKE_INSTALL_LIBDIR@ @CMAKE_INSTALL_FULL_LIBDIR@ \
--replace '$'{prefix}/@CMAKE_INSTALL_INCLUDEDIR@ @CMAKE_INSTALL_FULL_INCLUDEDIR@
substituteInPlace CMakeLists.txt \
--replace-fail \
'cmake_minimum_required(VERSION 3.4)' \
'cmake_minimum_required(VERSION 3.10)'
''
# Clang 19 has become more strict about assigning to const variables
# Patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281497
+ lib.optionalString (stdenv.cc.isClang && lib.versionAtLeast stdenv.cc.version "19") ''
substituteInPlace include/olm/list.hh \
--replace-fail "T * const other_pos = other._data;" "T const * other_pos = other._data;"
'';
meta = {
description = "Implements double cryptographic ratchet and Megolm ratchet";
homepage = "https://gitlab.matrix.org/matrix-org/olm";
license = lib.licenses.asl20;
maintainers = with lib.maintainers; [
tilpner
];
knownVulnerabilities = [
''
The libolm end‐to‐end encryption library used in many Matrix
clients and Jitsi Meet has been deprecated upstream, and relies
on a cryptography library that has known side‐channel issues and
disclaims that its implementations are not cryptographically secure
and should not be used when cryptographic security is required.
It is not known if the issues can be exploited over the network in
practical conditions. Upstream does not believe such an attack is
feasible, but has stated that the library should not be used going
forward, and there are no plans to move to another cryptography
implementation or otherwise further maintain the library at all.
You should make an informed decision about whether to override this
security warning, especially if you critically rely on end‐to‐end
encryption. If you don’t care about that, or don’t use the Matrix
functionality of a multi‐protocol client depending on libolm,
then there should be no additional risk.
Some clients are investigating migrating away from libolm to maintained
libraries without known vulnerabilities.
For further information, see:
* The CVE records for the known vulnerabilities:
* CVE-2024-45191
* CVE-2024-45192
* CVE-2024-45193
* The libolm deprecation notice:
<https://gitlab.matrix.org/matrix-org/olm/-/blob/6d4b5b07887821a95b144091c8497d09d377f985/README.md#important-libolm-is-now-deprecated>
* The warning from the cryptography code used by libolm:
<https://gitlab.matrix.org/matrix-org/olm/-/blob/6d4b5b07887821a95b144091c8497d09d377f985/lib/crypto-algorithms/README.md>
* The blog post disclosing the details of the known vulnerabilities:
<https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/>
* The statement about the deprecation and vulnerabilities from the
Matrix.org Foundation:
<https://matrix.org/blog/2024/08/libolm-deprecation/>
* A (likely incomplete) aggregation of client tracking issue links:
<https://github.com/NixOS/nixpkgs/pull/334638#issuecomment-2289025802>
''
];
};
})
|
