Signal for linux

Hardware Librem 5
21

Here is a link to an already existing stand alone Signal app for Ubuntu Touch.
Anyone want to talk to this guy and see what he can do for the project?:sunglasses:
https://open.uappexplorer.com/app/textsecure.nanuc
Info:
Author: Aaron Kimmig
Packager/Publisher: Aaron
Support: https://github.com/nanu-c/textsecure-qml/issues
Source: https://github.com/nanu-c/textsecure-qml
License: GNU GPL v3

22

Hi @Seven,

I already investigate porting a Signal app for the Librem 5 using their guidelines :wink:

Basically that would be a client based on AsmaK’s signal-cli, using D-Bus signals and methods to be fully integrated into PureOS mobile Features. That would most probably be shipped in a Flatpack.

There only are a few methods to write to complete the D-Bus support, plus probably a bit of rewiring when the Features specifications are done :slight_smile:

1 Like
23

Hi Thib,
So how much effort would this take overall?

24

Not much actually, you can alreay send and receive messages and group messages using the daemon and D-Bus.

A few methods are left to add in this interface and in this class. I conctacted AsamK who’s okay with his project being used as a base for the Librem 5 Signal client. Moxie is aware of signal-cli and seems not to have done anything to stop it.

The whole shipping issue is different though. It is not technically complicated, but Moxie is against a packaging of signal-cli’s dependencies as .deb packages.

25

Any reason why Moxie is against the packaging?

26

See the following issue comment for more details :slight_smile:

27

Well I wouldn’t want to make things difficult lol. I did make another post offering an alternative. Let me know what you think :sunglasses:

28

Is the encryption done in the Java layer? If so, the traffic is in the clear on dbus, which is not ideal.

29

Hi @fabrice,

Yes the encryption is done in the Java layer.

I am not a DBus expert, especially regarding security issues.
That said, there are two security elements that seem reasonable to me:

  • The bus used by the daemon will be session bus, and not system bus
  • The policy regarding the signals and methods will be deny-by-default and allowed only for the user who needs to access such information. In the context of an integration with the Librem 5, I can’t say yet which user will be used by the Features frontend. See dbus doc, policy section for more information

If you think of anything that would help harden the application, please speak :slight_smile: