Whisperfish EOL

[aebruno]

Unfortunately, I don't have the necessary time to commit to this project and want to ensure new users do not perceive this as being a stable or usable client. I will be archiving this project soon. Thanks to all who contributed and provided valuable feedback! I've updated the README with the following message:

WARNING - DO NOT USE THIS CLIENT

Unfortunately I am no longer able to maintain this project and can not recommend anyone continue using Whisperfish. The code base is far from complete and does not implement the latest features of the Signal protocol. It's just a matter of time before this just completely stops working. Rather than wait until that time, I'm archiving this project and recommend any remaining users switch to another client. This repository is archived and here for historical purposes only.

Thanks to all who contributed and provided valuable feedback.

Cheers!

WARNING - DO NOT USE THIS CLIENT

[marxistvegan]

Thanks for the effort you put in, hopefully another community member can pick it up.

[mschilli87]

Any recommendet alternatives?

[bonanza123]

Maybe we should raise that issue here https://together.jolla.com/question/195152/adopting-abandoned-apps/ to find someone who can jump in.

[mkaluscha]

What a pity :-( . I really like this app and will continue using it as long as possible. There are no alternatives but the android version and that's a pain in the a... on my J1. Maybe bonanza123's post at together.jolla gets a positive reaction.

[mschilli87]

I'm running the community port on the Fairphone 2, so anything Android is not an option at all, even if I wanted.

[dragonchaser]

That's a pity :/ This moves all of us one step further away from ditching alien dalvik.

[mjtorn]

Thank you @aebruno for your work!

Could write a few words, into the readme or otherwise, on what a possible future maintainer would need to know or do? It appears https://github.com/janimo/textsecure hasn't been updated in a while and https://github.com/aebruno/textsecure might be out of date as well.

Is it a correct assumption both projects are dead as well?

Of course it's sad that a lot of people are bound to using a ticking timebomb now, with no proper alternative, so any help in how to detect and keep up with protocol changes etc would be welcome!

[Nokius]

its sad to hear this, once again Thanks to @aebruno for the work!

If anyone is interested in working on this clinet or new one. I offer to this person a brand new boxed Jolla1 (loaned) as development device.

Thanks in advanced for your work!

[creich]

Thank you very much @aebruno for the efford so far :)

how much time did you put into this project more or less? why did you write the go library instead of using the c-library offered directly within the signalapp repos on github -> https://github.com/signalapp/libsignal-protocol-c?

[rubdos]

Someone interested in helping to port the whole thing to the libsignal-protocol-c library and "standard" Qt/C++? I feel like maintenance will become a little easier when it's on the "official" code base.

EDIT: let's coordinate on #sailfishos on Freenode, feel free to ping me if you're interested.

[mjtorn]

@rubdos I would certainly test such a client. Do you have a repo already?

Also, how would you deal with accessing Whisperfish conversations? I doubt the Whisperfish codebase can be gradually moved from Go, so are you re-implementing the startup password and whatever? That would be nice, as maybe we could just copy whatever dot-path database stuff from Whisperfish to your client and have a fairly seamless migration. Or import feature from your client, even! ;)

[rubdos]

On 7/23/19 11:03 AM, Markus Törnqvist wrote:

@rubdos I would certainly test such a client. Do you have a repo already?

Check out my fork at the libsignal branch.

Also, how would you deal with accessing Whisperfish conversations? I doubt the Whisperfish codebase can be gradually moved from Go, so are you re-implementing the startup password and whatever? That would be nice, as maybe we could just copy whatever dot-path database stuff from Whisperfish to your client and have a fairly seamless migration. Or import feature from your client, even! ;)

It cannot be gradually moved in a way without going insane I think. I've removed the Go bindings (code is still there), and I'd just rewrite everything from there. It's gonna be quite something to write though.

[mjtorn]

Looking at https://github.com/rubdos/whisperfish/tree/libsignal it does seem you have a commendable and clean start, very nice! Added it to my "watching" repos :)

Work-wise I'm so sorry I can't help with the code (lack of time, no Go experience, C++ skills grown rusty but weren't spectacular to start with), though I would love to help with testing. I have a second Sailfish phone currently with no Whisperfish, so I could do clean testing on it.

Can you re-use the design from the Go code? That should make it a lot easier to go about, although you might go a bit insane rewriting file-for-file and then kicking off testing.

For people interested in testing, it would also be nice to document how to make backups of the Go version's data and such, just in case, when the libsignal version seems stable enough to upgrade to.

Thanks a lot for your effort, let's make this happen somehow!

[rubdos]

On 7/23/19 12:16 PM, Markus Törnqvist wrote:

Looking at https://github.com/rubdos/whisperfish/tree/libsignal it does seem you have a commendable and clean start, very nice! Added it to my "watching" repos :)

Thanks! :-)

Work-wise I'm so sorry I can't help with the code (lack of time, no Go experience, C++ skills grown rusty but weren't spectacular to start with), though I would love to help with testing. I have a second Sailfish phone currently with no Whisperfish, so I could do clean testing on it.

No worries. I hope to find someone with some time though. My C++ has gone Rusty, and Go is non-existent... but I guess I'll be alright, aside from some memory-leak induced headaches.

Can you re-use the design from the Go code? That should make it a lot easier to go about, although you might go a bit insane rewriting file-for-file and then kicking off testing.

I'll be using the design of the Go code, then see what I can simplify is a migration. Ideally, I'd get "whisperfish 0.6.0" out as a C++ rewrite of the same thing (hopefully fixing some issues already), and then really rewrite things that came out nasty with a "migration release" 0.7 or something.

For people interested in testing, it would also be nice to document how to make backups of the Go version's data and such, just in case, when the libsignal version seems stable enough to upgrade to.

Roger that. I might setup a Gitlab repo to track my fork and the related issues.

Thanks a lot for your effort, let's make this happen somehow!

I'm not promising anything, but let this be a start :-)

[mkaluscha]

Hope is back :-). Unfortunately I can't help with code, but if some translation is needed (englisch -> german), I'm happy to do that.

[mjtorn]

but I guess I'll be alright, aside from some memory-leak induced headaches

Does Valgrind work for Sailfish/QT? I have written just a bit of QT, but for the life of me can't remember if I had to debug memory issues. Good thing, either way, there's QT to watch your back just a bit, instead of manually tracking mallocs behind pointers to pointers :D

Ideally, I'd get "whisperfish 0.6.0" out as a C++ rewrite of the same thing (hopefully fixing some issues already), and then really rewrite things that came out nasty with a "migration release" 0.7 or something.

This sounds like a very reasonable roadmap, hope there isn't a lot of nasty for 0.7.0! I skimmed through some of the Go code and it actually looks pretty readable; fingers crossed.

I might setup a Gitlab repo to track my fork and the related issues.

If you wish. I love Gitlab but I'd be too lazy to move a GitHub fork :D

[rubdos]

but I guess I'll be alright, aside from some memory-leak induced headaches

Does Valgrind work for Sailfish/QT? I have written just a bit of QT, but for the life of me can't remember if I had to debug memory issues. Good thing, either way, there's QT to watch your back just a bit, instead of manually tracking mallocs behind pointers to pointers :D

Sure, it's just Linux :-)

Ideally, I'd get "whisperfish 0.6.0" out as a C++ rewrite of the same thing (hopefully fixing some issues already), and then really rewrite things that came out nasty with a "migration release" 0.7 or something.

This sounds like a very reasonable roadmap, hope there isn't a lot of nasty for 0.7.0! I skimmed through some of the Go code and it actually looks pretty readable; fingers crossed.

Thanks.

I might setup a Gitlab repo to track my fork and the related issues.

If you wish. I love Gitlab but I'd be too lazy to move a GitHub fork :D

I opened a Gitlab repository. The C porting process can be followed here. If you don't have a GItlab account and want to contribute, feel free to email me your merge requests!

[aebruno]

I'm not promising anything, but let this be a start :-)

@rubdos Thanks for offering to breathe some life into this project! Feel free to reach out if you hit any snags. I'm also happy to update the README file in this repo to point to your fork once you get something going. Just let me know. Best of luck!

[Nokius]

@rubdos If you lie to receive a loaned Jolla 1 let me know I will send it over asap. Many Thanks for you work!

[rubdos]

@rubdos If you lie to receive a loaned Jolla 1 let me know I will send it over asap. Many Thanks for you work!

I'm torturing myself to get it working asap by developing on my daily Moto Z Play. If the torture gets too heavy, I'll reach out! :-)

@rubdos Thanks for offering to breathe some life into this project! Feel free to reach out if you hit any snags. I'm also happy to update the README file in this repo to point to your fork once you get something going. Just let me know. Best of luck!

Thanks a lot, that means a lot for me. I'll send you a note if I get it working!

[mjtorn]

I opened a Gitlab repository.

Very cool! I have a work-identity Gitlab account, and now I have a reason to eventually make another one just to see if I can watch/track/whatever that repo. For the time being I'll keep an eye out manually ;)

Thanks and thanks to @aebruno as well!

[rubdos]

Since d9717d3c, the GUI starts cleanly without any errors. Actual implementation work can start from here.

I have CI setup (nightly RPM builds, yay), the C library compiles with a near-default SDK.

I've mirrored my Gitlab repo to my Github fork.

[mjtorn]

@rubdos though I still haven't got around to making that Gitlab account, I have been checking it out and wish to congratulate and commend you on a good start :)

Do you take roadmap suggestions? I can't remember if I had to re-register when moving from the Android client to Whisperfish, but I would really love to try to register my second phone using your code, even if nothing else would work.

Still happy about all of this :)

[rubdos]

On 7/27/19 10:36 PM, Markus Törnqvist wrote:

@rubdos though I still haven't got around to making that Gitlab account, I have checked in and wish to congratulate and commend you on a good start :)

Do you take roadmap suggestions? I can't remember if I had to re-register when moving from the Android client to Whisperfish, but I would really love to try to register my second phone using your code, even if nothing else would work.

I'll probably do the registration as one of the very last things - unless this is really something you want already. Reason is: I'd like to chat with my family and friends again first thing :-)

I'm able to decrypt the identity keys (and validate the MAC) using openssl and Qt in C++ now. I should soon be able to authenticate the WebSocket.

[mjtorn]

That's a fair incentivizer :)

I was mostly thinking that I could test the registration code by registering my other phone and work from there, as I'm not sure if registration can be tested another time, if I now do it with the Go version.

6/16 items done, with quite a few of the remaining ones non-functional changes; things at least look good :)

[rubdos]

I was mostly thinking that I could test the registration code by registering my other phone and work from there, as I'm not sure if registration can be tested another time, if I now do it with the Go version.

Fair point. I'd like to at least have some other working requests to the REST endpoint before I implement registration though; then you at least have a good chance at success

Iirc, the Go version of the registration was once broken; not sure if that has been fixed.

6/16 items done, with quite a few of the remaining ones non-functional changes; things at least look good

I'm sadly adding items as I go and see fit... It's quite a bit more work than I thought, since the libsignal-protocol-c stuff doesn't implement the networking code. It's only the high level cryptographic stuff (I have to supply a MAC and encrypt function myself, I use OpenSSL from the repos) and the serialization through protobufs.

[mkaluscha]

@mjtorn

I can't remember if I had to re-register when moving from the Android client to Whisperfish, ...

I do remember I had to re-register and I lost membership in all groups by doing that. Had to ask my friends to add me to those groups again - annoying but not tragic.

[mjtorn]

@rubdos as it's been a while, is there something anyone can do to help? Testing, anything?

[rubdos]

@rubdos as it's been a while, is there something anyone can do to help? Testing, anything?

Porting code, mostly :-)

I've been busy the last few weeks, I hope to pick it up again soon™. Discussion and MR's are always welcome to the libsignal branch. Btw, it seems that libsignal-c doesn't implement a ton of stuff (i.e., it only implements the ratchet and crypto stuff). Networking still needs to be ported over to Qt/C++.

[mjtorn]

I thought I replied to this but obviously didn't. It does seem like the networking part could be tough, but is there any help to be had on together.maemo.org or somewhere? I'm kinda useless to help out with it, and even organizing that collaboration would be tough considering how busy my family and work keeps me, but there should be people who are interested and have time.

Exactly what is the biggest hurdle? Like do you need to open a raw TCP socket and draw the rest of the fscking owl from there or is there a library that would help with it?

[rubdos]

I thought I replied to this but obviously didn't. It does seem like the networking part could be tough, but is there any help to be had on together.maemo.org or somewhere?

Not sure. I could post what I have over there, do you think there'd be any help? Or maybe TJC?

I'm kinda useless to help out with it, and even organizing that collaboration would be tough considering how busy my family and work keeps me, but there should be people who are interested and have time.

I know the feeling, I'm pretty busy at the uni atm. Once the year started again, I think I'll have some calmer periods.

Exactly what is the biggest hurdle? Like do you need to open a raw TCP socket and draw the rest of the fscking owl from there or is there a library that would help with it?

It's a WebSocket, and that's supported by Qt5 already (upstream for Jolla/SFOS too). Apart from the WebSocket and the fscking owl that comes with it (pushing and pulling JSON should™ be easy enough), there's a separate REST API (which is also JSON I think) to exchange and register keys. I am not familiar enough yet with how Signal works to actually implement both at this point, so documenting the two protocols (or finding documentation) would be really useful already.

[mjtorn]

@rubdos I'm sure you could try a post on either or both sites! There's very little to lose :)

The Signal documentation is a bit ... weird. I tried writing a client of my own quite a few years ago and wanted to run the server locally for testing. There are two real reasons I gave up; I got assigned to a project at work and lost all hobby time and documentation issues. I kept trying to figure out how to best run the server and keep the documentation on a wiki, maybe even OWS' wiki, but it kept getting deleted.

I've heard elsewhere as well that Moxie really wants to discourage people from running their own servers, maybe because of support issues if people really did fork it or something, so I kinda gave up. It wasn't super difficult to get running, though, and might be useful for development here as well!

When you say WebSocket is supported in upstream, does that mean it'll be in the next SFOS version or that it's available as an opt-in dependency or what? That's probably something you wouldn't want to do from scratch.

[rubdos]

I've heard elsewhere as well that Moxie really wants to discourage people from running their own servers, maybe because of support issues if people really did fork it or something, so I kinda gave up. It wasn't super difficult to get running, though, and might be useful for development here as well!

I don't really mind debugging it with upstream, since I have the Go library as example code, and most of the time I'm not far off the right implementation :-)

Moxie indeed tries to avoid the distributed approach, since then Signal servers don't communicate with each other, and there's ecosystem diaspora. He wants to avoid "my Signal doesn't communicate with your Signal".

When you say WebSocket is supported in upstream, does that mean it'll be in the next SFOS version or that it's available as an opt-in dependency or what? That's probably something you wouldn't want to do from scratch.

Current SFOS packages the qt5-websockets RPM. Currently, the WebSocket is implemented in Go, and I've already setup the connection to the right web service at Signal's side. So it's not from scratch! :-)

[Nokius]

@rubdos What is the current status of your fork, can I somehow support you? Beer, money or something else?

[mschilli87]

@Nokius: https://gitlab.com/rubdos/whisperfish

[rubdos]

@Nokius: https://gitlab.com/rubdos/whisperfish

More specifically: https://gitlab.com/rubdos/whisperfish/merge_requests/1

The TODO list is at that merge request. If there's a way to donate me time, that would be great. Otherwise, code is the only thing that really needed... Currently quite busy starting up a bunch of master thesis students, I hope I'll have some evenings in November.

I think maybe implementing the REST interface (as a state machine in C++ or something along those lines) is the next step, and probably not too difficult either.

Crazy idea: if you folks have idea's for thesis topics around Whisperfish, i.e. something with an academic smell, I might be able to dedicate some time to it during daytime.

[sfbg]

Thesis topics, no problem :man_scientist: :smiley: :

• Factors for establishing user trust in a 3rd party secure messaging client app
• Takeover and technology stack refactoring of an abandoned open-source app - an empiric study
• Drivers for community retention for an adopted open-source application