[Question] Authenticating with yowsup-cli

[heeplr]

Currently I'm using transwhat that was authenticated with yowsup-cli using voice mode. I'm not sure how to authenticate that account using an android device + QR code.

Is there a way I could manually import auth data from yowsup-cli into the purple-gowhatsapp db?

[hoehermann]

I had no idea yowsup lives again. Last time I checked, it was stuck on the old protocol which does not support multiple devices. Which forks are you using? https://github.com/stv0g/transwhat and https://github.com/tgalal/yowsup seem to be dead.

[heeplr]

Yes, transwhat is archived and broken, hence I'd like to switch to purple-gowhatsapp. Tgalal's yowsup3 still works (tho people need to update the environment manually).

I'm only using one device (my spectrum instance) and a phone number that can't receive SMS.

It's been a long time since I used the official whatsapp client. I suppose I could just install it on any android device, use that old phone number and authenticate with voice using the official client? I'm not sure and I'd prefer to import yowsup-cli keys. If that's not possible, I'd get some clean dummy device to do the QR code thing.

[hoehermann]

I can feel you. I was happily using yowsup, too. Until it broke down for me completely sometime 2018, see https://github.com/hoehermann/wxpyWha/issues/17. I started using the official app within an emulator. That is working okay for me – even with a number that cannot receive SMS. I encourage you to try that.

According to https://github.com/tgalal/yowsup/issues/3173, yowsup cannot be used to link a secondary device.

Even if yowsup offered linking, the currently maintained whatsmeow branch of this plugin uses the new "Signal" protocol from 2021. Looking at https://github.com/tgalal/yowsup/issues/3126, it seems yowsup has not switched to the new protocol, yet. If my assumptions are correct, yowsup 3 and whatsmeow are incompatible. I am sorry. In theory, you can try and fiddle around with the deprecated gowhatsapp branch, extract the keys from the yowsup config and feed them into the database somehow, but it will be quite tedious and very unreliable.

[heeplr]

I see. I'll try with the official client + QR code. Thank you very much for clarification (and all your work on this!) Closing this.

[hoehermann]

I just remembered that the other day a user reported the plugin was generating the QR-code, but spectrum would not show the QR code to the XMPP frontend. It was working reliably in the past. If you can provide some information as you try, it would be of great help for me. So far I did not succeed in setting up a local Spectrum instance for debugging purposes.

[heeplr]

I planned to use pidgin for registering and then copy the config/db file to the spectrum gateway but I will try directly with spectrum now. Will comment in #5 about my findings.

[heeplr]

(i'm currently having a hard time writing a gentoo ebuild for lack of a vendor tarball for the go modules and the way, "go mod tidy" is called by cmake to install dependencies as network connections aren't allowed in the sandbox. I'm trying to find a fix for this in the next weeks so I can get integration into my gentoo setup without manual compiling updates).

[hoehermann]

Indeed, the go philosophy "download all dependencies, then build one static executable" clashes with some distributions (Alpine Linux experiences some issues, too).

According to the Gentoo Forums, this seems to be a common problem and basis for a number of discussions.

For this project, I recommend creating the build directory manually after changing to directory src/go:

mkdir -p ../../build/src/go/go
GOPATH=$(pwd)/../../build/src/go/go go mod tidy

This will handle the download. You can then proceed with the actual build without the need for a download.

A word of warning, though: WhatsApp frequently makes changes to their client, so whatsmeow and its dependencies need to be downloaded quite often.

[heeplr]

Thank you a ton for clarification & all your work on this project.

Coming back after I've tried get a clean install with portage. It seems the only viable way would be, if you'd provide a vendor package with all dependencies for every release.

For this project, I recommend creating the build directory manually after changing to directory src/go

That won't work with secure package managers, since sideloading of anything during the build-phase is a security risk since it's not possible for the package manager to control it or even hash it.

Currently people are hosting their own vendor package which I think is suboptimal, since it adds a random 3rd party to the trust chain.

Regarding my original problem: I tried to use an emulator but official WhatsApp needs access to the call-log when verifying with a call and not with SMS. Naturally, the emulator can't receive calls either.

Yowsup can still verify using a phone call (you answer, and you hear an automated voice telling you the digits). Do you know if this is even possible with the new protocol? Since "verify by phone" in the official app doesn't seem to work by answering the call but just by checking the calling number in the call-log (?)

[hoehermann]

Thank you a ton

Thank you. :)

(…) portage (…) vendor package (…) secure package managers (…) trust chain

I do not know gentoo at all. Please do not take this as a critique. I appreciate your efforts to install this plug-in "the right way". I think I need to unterstand the gentoo philosophy, for I tend to lean towards "usability over security". Is it possible, at all, in gentoo, to build the plug-in manually on the command line, then move the resulting shared object file to ~/.purple/plugins/?

official WhatsApp needs access to the call-log

I am using the official WhatsApp version 2.22.24.78. It asks for access to the contact list and telephony functions, but I can deny the permission. Afterwards, the app happily waits for a manually entered verification code. I am currently using my land-line. Maybe it is a restriction enforced by newer versions of WhatsApp. Can you try the old version mentioned above?

[heeplr]

I tend to lean towards "usability over security"

Me too. But manually installing & getting updates is a bad compromise in my humble opinion. A decently packaged app (called "ebuilds" in gentoo lingo) in the official main tree repository (provided by the gentoo organization) can be compiled & installed systemwide by just running "emerge purple-gowhatsapp" as privileged user.

There also are so called "overlays" where people can use/publish their own trees with their own ebuilds using a simple tool (layman). The problem with go apps is, that most projects don't release a vendor package so some random guy needs to build that and upload it somewhere. There are additional security mechanisms but in the light of supply chain attacks becoming more widespread, that's far from ideal imho.

This problem applies to all source distributions not only gentoo. (Basically keep a list of dependencies and a URL to the tarball or git repo. Then check for every dependency if it's installed. If not, compile the dependency (and their dependencies recursively). Each dependency needs it's own ebuild.) Go, Rust, Node.js etc. reinvented their own package managers with all resulting problems which were solved by traditional package managers long ago and thus are generally frowned upon in the community of source based distributions.

It could be solved if every go project provided a vendor package, but I see that's a lot to ask from a developer. It seems it is possible to do dynamically linked builds with go but it is so uncommon, I didn't even look into it.

Is it possible, at all, in gentoo, to build the plug-in manually on the command line

Yes. When go is installed, this is straight forward. It's actually the way I'm currently playing with purple-gowhatsapp but for day-to-day use it's pretty cumbersome to track releases and keep up to date.

Can you try the old version mentioned above?

EDIT: s. next comment

I just did but there is no difference. How do you actually get the verification code?

This is the dialog I get:

The part with "manage this call so we ... can end the call automatically" and "acces your call log so we can confirm that you received the call." won't work with a landline number that doesn't make my mobile ring.

Do you maybe forward calls to your mobile number? This just came to my mind. It might be a working solution.

When I'm denying access to permissions, I get a toast "Sending SMS" and this dialog:

Maybe I'm doing something wrong?

[heeplr]

Turns out I did something wrong :) This version offers me an option "Call me" after clicking "Didn't receive code". This calls the number and reads the code like expected. Thank you for pointing out the older App version.

[salykingleb]

Friends, I am also working on this, but in another newer library, if you are interested in joining forces, write to me

[hoehermann]

Thank you for the suggestion. Since this is an open-source project, I prefer to keep the discussion open, too. Unfortunately, I have no resources to work on another project. In case your project reaches maturity, feel free to reference its sources here.

[hoehermann]

It could be solved if every go project provided a vendor package, but I see that's a lot to ask from a developer.

Thank you for your understanding. Ideally, I would also release .deb files for the Debian folks and their family, but that is way out of scope for one person acting in his spare time.

Dynamically linked builds sound interesting. Could work for Alpine Linux, too. #119 One day, I might overhaul the build instructions and try dynamic linking in the process. The currently employed approach is rather non-standard.

[heeplr]

Ideally, I would also release .deb files

There's already a request for a package. I wonder what is debian maintainers holding back. It might be the missing vendor package aswell.

for one person acting in his spare time

Tell me... :) But otoh the full testing/build/package/release process should be automated anyways.

Dynamically linked builds sound interesting.

It's totally not the Go-way and would be only a workaround at best (And the feature is only available for x86_64 platforms iirc). All go-apps I encountered were statically linked.

I'll play around with vendoring in the next weeks, maybe it's just a small PR + some Github Action needed to make maintainers' lifes easier.