Signal v1.15 is broken on Fedora #2662
Comments
|
For some reason I can't create a core dump. I set the max. corefile size to 8 GB, but the file created from coredumpctl is 0 bytes. The only info is signal 11 (SEGV) |
|
Reverting to 1.11.0 works, but then I'm in read-only mode :( |
|
I am running into the same issue: you can use the repo from |
|
Possibly related: #2634 |
|
Looks like my report is just a duplicate. I can't build from your spec because a "yarn" package is not found by dnf. But thanks all the same. |
|
You have to install it from here before attempting to build: https://yarnpkg.com/en/docs/install#centos-stable |
|
@github-cygwin Can you talk about your linux distribution? On linux we don't turn on our auto-upgrade system. Generally, the problems people are having with Signal Desktop v1.15+ on non-Debian platforms is due to the version of openssl we build and statically link into SQLCipher, which you can see here: https://github.com/scottnonnenberg-signal/node-sqlcipher/commits/updates |
|
My distro is Fedora 28, nothing special otherwise. I'm updating Signal-desktop usually by downloading the deb file, unpacking and untaring it (an officlal Signal-desktop rpm is long overdue). IMHO, linking statically against any OS-provided lib is a mistake. The problem is that you create an update which doesn't work on all distros while at the same time disabling older versions. You're leaving people stranded that way. |
scottnonnenberg-signal
changed the title
|
This issue is still set to "need info". What kind of info are you still missing? |
|
And while we're at it, is there some still working pre-1.15 version available for download? Disabling 1.11 left me with no offical working version at all. |
|
Same on arch (artix)... please don't use static links... |
|
version 1.15.5 seems to work for me again. |
|
1.15.5 still doesn't work for me. Same SEGV as in my OP. I tried with removed ~/.config/Signal, too, but to no avail. |
|
I'm curious. Do the Snaps or the Flatpaks work? |
|
Snaps == Developer snapshots? Where do I find them? The unofficially provided signal-desktop from https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/ works, so we really just need official rpms not linking statically against arbitrary libs. |
|
This still has the tag |
|
Trying to update from $ /opt/Signal\ Beta/signal-desktop-beta --disable-gpu
Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop-beta' }
NODE_ENV production
NODE_CONFIG_DIR /opt/Signal Beta/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME undefined
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
userData: /home/christian/.config/Signal Beta
config/get: Successfully read user config file
config/get: Successfully read ephemeral config file
making app single instance
config/set: Saving user config to disk
config/set: Saving ephemeral config to disk
{"name":"log","hostname":"horus","pid":4495,"level":30,"msg":"app ready","time":"2018-10-20T06:31:01.597Z","v":0}
{"name":"log","hostname":"horus","pid":4495,"level":30,"msg":"updateSchema: Current schema version: 0; Most recent schema version: 4; SQLite version: 3.20.1; SQLCipher version: 3.4.2;","time":"2018-10-20T06:31:01.604Z","v":0}
{"name":"log","hostname":"horus","pid":4495,"level":30,"msg":"updateToSchemaVersion1: starting...","time":"2018-10-20T06:31:01.604Z","v":0}
The coredump is 569 MB in size but lacks some debug info. |
|
I will definitely 2nd the notion that statically linking against libcrypt or openssl is a really bad idea! If you do this because of particular package dependencies then you really ought to rethink those dependencies. Vulnerabilities do occur and responding to them quickly is very beneficial! Having to additionally update apps that were statically linked against some old vulnerable version is bad practice and will just invite hackers to target your app (knowing that there are likely older versions that don't get updated). This would then force you to immediately deprecate any older version that has a known vulnerability, thus making the end-user experience much more unpleasant. To have this attitude/policy for what is supposed to be a "secure" private messaging app makes me very sad. |
|
Signal v1.18.0-beta.3 is still crashing on Fedora 28. Bisecting was impossible so far because of intermittent build-failures, but the error seem to have been introduced somewhere between v1.15.0-beta.5 (good) and v1.16.0 (bad) -- with 148 commits inbetween :-\ Core was generated by `/opt/Signal Beta/signal-desktop-beta --disable-gpu'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fba6914d029 in EVP_MD_CTX_clear_flags (ctx=ctx@entry=0x0, flags=flags@entry=2) at crypto/evp/evp_lib.c:479 479 crypto/evp/evp_lib.c: No such file or directory. [Current thread is 1 (Thread 0x7fba37d93700 (LWP 2700))] [...] (gdb) bt #0 0x00007fba6914d029 in EVP_MD_CTX_clear_flags (ctx=ctx@entry=0x0, flags=flags@entry=2) at crypto/evp/evp_lib.c:479 #1 0x00007fba6913d1c1 in EVP_DigestInit_ex (ctx=0x0, type=0x7fba69465cc0 , impl=0x0) at crypto/evp/digest.c:66 #2 0x00007fba6915b20a in HMAC_Init_ex (ctx=0x3c19c544b120, key=, len=, md=, impl=0x0) at crypto/hmac/hmac.c:70 #3 0x00007fba556e5b4a in sqlcipher_openssl_hmac () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #4 0x00007fba557096d3 in sqlcipher_page_cipher () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #5 0x00007fba5571fa96 in sqlite3Codec () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #6 0x00007fba55740cc7 in pager_write_pagelist () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #7 0x00007fba55750bd1 in sqlite3PagerCommitPhaseOne.part.573 () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #8 0x00007fba55751118 in sqlite3BtreeCommitPhaseOne.part.574 () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #9 0x00007fba5576e4c4 in sqlite3VdbeHalt () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #10 0x00007fba5578a0aa in sqlite3VdbeExec () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #11 0x00007fba55791a38 in sqlite3_step () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #12 0x00007fba556d2b99 in node_sqlite3::Statement::Work_Run(uv_work_s*) () from /tmp/user/1000/.org.chromium.Chromium.MRV96d #13 0x00007fba77f4df5e in ?? () from /opt/Signal Beta/libnode.so #14 0x00007fba76b45594 in start_thread (arg=) at pthread_create.c:463 #15 0x00007fba6ffbde6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 |
|
OK, so not being able to (only) remove these "statically link openssl" commits that seem to be intertwined with the switch to node-sqlcipher I switched to the original (?) node-sqlite3 module and with that I'm finally able to run diff --git a/app/sql.js b/app/sql.js
index 57cea050..b6a95290 100644
--- a/app/sql.js
+++ b/app/sql.js
@@ -1,7 +1,7 @@
const path = require('path');
const mkdirp = require('mkdirp');
const rimraf = require('rimraf');
-const sql = require('@journeyapps/sqlcipher');
+const sql = require('@mapbox/node-sqlite3');
const pify = require('pify');
const uuidv4 = require('uuid/v4');
const { map, isString, fromPairs, forEach, last } = require('lodash');
diff --git a/package.json b/package.json
index cbd503b0..b8f5e60b 100644
--- a/package.json
+++ b/package.json
@@ -41,7 +41,7 @@
"styleguide": "styleguidist server"
},
"dependencies": {
- "@journeyapps/sqlcipher": "https://github.com/scottnonnenberg-signal/node-sqlcipher.git#ed4f4d179ac010c6347b291cbd4c2ebe5c773741",
+ "@mapbox/node-sqlite3": "https://github.com/mapbox/node-sqlite3.git",
"@sindresorhus/is": "^0.8.0",
"archiver": "^2.1.1",
"backbone": "^1.3.3",
@@ -258,7 +258,7 @@
"!**/{.DS_Store,.git,.hg,.svn,CVS,RCS,SCCS,__pycache__,thumbs.db,.gitignore,.gitattributes,.editorconfig,.flowconfig,.yarn-metadata.json,.idea,appveyor.yml,.travis.yml,circle.yml,npm-debug.log,.nyc_output,yarn.lock,.yarn-integrity}",
"node_modules/spellchecker/build/Release/*.node",
"node_modules/websocket/build/Release/*.node",
- "!node_modules/@journeyapps/sqlcipher/deps/*"
+ "node_modules/@mapbox/node-sqlite3/deps/*"
]
}
}
It's a workaround of course and I fear it'll break again soon, depending on Signal's use of |
|
For instructions on how to "hack" and re-build node-sqlcipher to utilize the dynamically linked OS's openssl library and not include a statically linked openssl library, then go see this issue: 2634 (it's really just a matter of deleting the pre-packaged binaries that come with node-sqlcipher and then rebuilding that package). |
|
At least there are only 2 CVE's for 1.0.2o... https://www.cvedetails.com/version/258285/Openssl-Openssl-1.0.2o.html |
|
This is still happening for me on Debian Buster. |
This build worked based on comment here: signalapp#2662 (comment) Runs from commandline in linux-unpacked. However, rpm won't install. Haven't tried AppImage.
This build worked based on comment here: signalapp#2662 (comment) Runs from commandline in linux-unpacked. However, rpm won't install. Haven't tried AppImage.
Signal is currently using a forked version of node-sqlcipher. I'm not entirely sure as to all the motivations for forking, but it seems that one reason may have been because upstream didn't support FTS5. This reason is no longer relevant because of this PR [^1], which adds FTS5 support upstream. Another reason for the forked version of node-sqlcipher may be to bundle libcrypto. This is causing problems with many Linux users, especially those who are not using Ubuntu [^2][^3]. It seems to me that statically linking is not generally considered to be a best practice on Linux. The upstream project's README [^4] seems to have a sensible policy: bundling OpenSSL on Windows and OS X platforms and dynamically linking to the system's library on Linux platforms. This PR moves away from the forked node-sqlcipher and returns back to upstream. This seems to fix OpenSSL problems on non-Ubuntu Linux distributions. [^1]: journeyapps/node-sqlcipher#17 [^2]: signalapp#2634 [^3]: signalapp#2662 [^4]: https://github.com/journeyapps/node-sqlcipher#openssl
Enforced update from my former Signal version 1.11.0 to 1.15.4 renders Signal
unusable. The update worked but now Signal just crashes:
The text was updated successfully, but these errors were encountered: