Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All exported data (messages + attachments) are *NOT* encrypted on Disk during (and after) the upgrade process! #2815

Closed
1 task
msuiche opened this issue Oct 22, 2018 · 6 comments

Comments

@msuiche
Copy link

msuiche commented Oct 22, 2018

  • I have searched open and closed issues for duplicates

Bug description

Steps to reproduce

  1. Use Signal Desktop on macOS
  2. Run an outdated version of Signal which will require upgrade and to export your messages/attachements
  3. Browse the exported folder (!!!!!)

Actual result:

This is insane! All the data is not encrypted!!!!!

Expected result:

This should be encrypted and safely deleted once the upgrade process is over!

Screenshots

image

image

image

Platform info

Signal version:

Currently running v1.16.3. Not sure what was my version before that.

Operating System:

macOS (A Chrome app)?

Linked device version:

Link to debug log

@msuiche
Copy link
Author

msuiche commented Oct 22, 2018

@jomo
Copy link

jomo commented Oct 22, 2018

Actual result: All the data is encrypted
Expected result: This should be encrypted

I think you meant is unencrypted? The title is also confusing.

@msuiche msuiche changed the title All exported data (messages + attachments) are encrypted on Disk during (and after) the upgrade process! All exported data (messages + attachments) are *NOT* encrypted on Disk during (and after) the upgrade process! Oct 22, 2018
@ikkisoft
Copy link

Did you have to manually export the messages? Meaning, the app prompted to export and upgrade?
It must have been a very very old version, which was built on a complete different tech stack AFAIR...

@diracdeltas
Copy link

Messages and attachments are not meaningfully encrypted on-disk in the latest Signal Desktop even without exporting/upgrading, so i'm not sure this violates the intended threat model of Signal

in your APPDATA directory (~//Library/Application Support/Signal on mac):

  • sql/db.sqlite contains the messages. this file is encrypted but the decryption key is in plaintext in config.json.
  • attachments.noindex/ contains the attachments in plaintext.

i'm not a signal dev and do not intend to support or refute their choices, just noting an observation.

@akutuzov
Copy link

I agree that it's not Signal's task to encrypt messages on-disk.
At the same time, it is probably a good idea to notify users (at the time of upgrade or fresh installation) about the threats related to storing message logs in plain text.

@scottnonnenberg-signal
Copy link
Contributor

Google announced that they were deprecating support for Chrome Apps over two years ago. Users have not been able to search for the legacy Signal Desktop app in the Chrome Web Store since mid-December 2017, and we officially deprecated the legacy version in October 2017.

At some point in the near future we will be unable to ship updates to the small number of remaining legacy users. We need to provide a data portability option and export process in order to facilitate a short, one-time move from the Chrome App to the more up-to-date standalone version of Signal Desktop.

It's important to be cautious about how and when any migration data is removed in case legacy users encounter errors or issues during the process. We were already planning on a second phase that will include instructions for how to remove the legacy Chrome App and the related migration data.

At-rest encryption is not something that Signal Desktop is currently trying to provide or has ever claimed to provide. Full-disk encryption can be enabled at the OS level on most desktop platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

6 participants