Shouldn't there have been an announcement to inform users what has been leaked and under which circumstances?
How can user A send an image to user B that neither of them took? Isn't everything end-2-end encrypted? Then how can unencrypted data from user C end up on the device of user B?
If I understand the issue [0] correctly, these two commits should be the fix:
https://github.com/signalapp/Signal-Android/commit/e90fa05d6...
https://github.com/signalapp/Signal-Android/commit/b9657208f...
The former updates how recipients (or really threads, I suppose) are merged (the issue occurred when trimming threads) and the latter changes the way how thread ids are generated (now automatically incremented). Together they should prevent unrelated recipients (threads) from being merged.
[0]: https://github.com/signalapp/Signal-Android/issues/10247#iss...
I do have to say though, the commit messages are very barren and barely any reference an issue directly. My guess is that they develop on private branches with an internal issue tracker and decide not to reference issues as that would be confusing. It would help a bunch if they referenced the public issues and made it clear which issues they're working on. They don't seem to use Github Projects [2].
All in all, the communication / transparency of the project is lacking - even though I'm glad they're providing something usable. Hopefully Matrix will be able to provide something as easily usable as well.
[0]: https://github.com/signalapp/Signal-Android/issues/10247#iss...
[1]: https://github.com/signalapp/Signal-Android/commit/83086a5a2...
and no PR from OP in the opensource part of the server https://github.com/signalapp/Signal-Server/pulls?q=is%3Apr+i...
The child comment to your comment is deleted, but I think autoincrement IDs shouldn't be used under an ambient authority context.
It would make more sense to have IDs based on an LSF or Feistel sequence, perhaps split into a master ID and a conversation sequence.
Autoincrement on this field makes it easy for off by one errors. Even just moving to guids and maintaining a proper parent child relationship would have prevented this.
Or maybe there should be a database per conversation (set of all parties).
https://github.com/signalapp/Signal-Android/commit/83086a5a2...
https://github.com/signalapp/Signal-Android/commit/b9657208f...
Row IDs shouldn't have so much power.
Doing homegrown ID generation is how such bugs are being introduced in the first place. Your application level trigger got bypassed, oops. Your check was experimentally disabled and left like that for a year until people started noticing, oops.
If you make an SQLite-backed application and it has a bug like this, I can safely bet $500 it's not going to be SQLite that has the bug.
Just don't expose the numeric IDs in links, and generate your UUIDs in tables where you need to point to rows in an outside-accessible link. This is database 101, for crying out loud.