I already use Joplin on my Linux Mint and Android mobile. I've tried to use on my Ubuntu 20.04.2 LTS, but I didn't succeed to sync it to my dropbox account.
What I did:
Clicked on "synchronize"
Clicked on the link provided in the next screen.
Got an "Dropbox 400 error: Missing client_id.
I'd like to use the same account that I use in my Linux Mint and Mobile.
I got the same problem and resolved it by uninstalling the version in the software centre (2.18) and installing by entering the instructions on the website into terminal, which installed 2.19 and worked as expected:
On Linux , the recommended way is to use the following installation script as it will handle the desktop icon too:
Sorry for being late to respond here but I've been particularly busy irl the past few weeks and at first this didn't look relevant to me.
This seems to be a problem exclusive to the snap version of Joplin, the problem is that for whatever reason clicking on the URL to open the browser is stripping some of the parameters.
For the time being it can be worked around by simply copy and pasting the URL in full into the browser.
I'm unsure what the exact problem is and at first glace it doesn't appear to be something with the Joplin snap itself but perhaps the wider ecosystem, so could take a while to determine what's at fault.
As you can see above the client_id parameter is just missing when opened directly. This behaviour appears to be new because it's never been mentioned in the past year.
I'm reasonably confident this is a problem entirely on the snap end and not the Joplin end, and the implications are how we'd professionally say, concerning, I'll be looking into it with some importance.
So having looked into this, this is a none exploitable security vulnerability in version 2.1.8 of the snap, as a result of the changes here
The gist of the bug comes down to the use of child_process.exec which runs in a Bash shell. As such, it interprets bash syntax (the &client_id=foobar literally runs as a bash expression). The fix is to instead use child_process.execFile()
From testing, user generated links did not use the same effected code path, so there's no possibility for e.g a maliciously crafted link to run arbitrary bash commands. Since the only effected links come from Joplin itself, they aren't malicious and don't have any impact (aside from not working for their intended purpose such as the Dropbox signup link).
This is embarassing for myself and I apologise for the last few weeks it means that the Dropbox authentication hasn't been working. Fortunately, the security concerns are at least eliminated (and there's a lot of defense in depth with the other aspects of the sandboxing that would have mitigated concerns if it came to), and going forward that same mistake won't be made twice.
2.1.9 will be rolling out in the next hour which fixes the problem and allows Dropbox to authenticate properly again.
