Client will not connect unless E2E has previously been set up

tabp0le commented 6 years ago

OK, so here's a weird one.

Expected Behavior

Add account to Nextcloud and have it start syncing immediately

Actual Behavior

Client initially authenticates, adds account, allows folder selection.
After wizard, it shows as disconnected.

Logs https://pastebin.com/N6DfdRsa

Affected Platforms Linux, Windows, (probably macOS)

OpenSSL Version: 1.10h QT Version: 5.11.1 Nextcloud Branch: master

To get it to actually work, and add the account, I had to:

Go into the Android app
Add encrypted folder
Set up initial encryption and get pneumonic
Go back to nc desktop client and remove, then add account again.
At this point, it popped up with the enter e2e pneumonic phrase prompt.
Enter e2e phrase, and hit ok
Client syncs successfully

camilasan commented 6 years ago

how did you build it? Is it Debug or Release?

tabp0le commented 6 years ago

My apologies, the issue exists in both Debug and Release @camilasan

tabp0le commented 6 years ago

So by random happy accident, I decided to try compiling with clang 6. I looked at my compiler right when the part that is giving the issue was being compiled. It so happens, that there is a build warning in regards to this. (when using clang) (not sure about gcc)

/mnt/ubuntu-home/tab/SpryDev/sprycloud-client-git/src/sprycloud-client/src/libsync/clientsideencryption.cpp:749:48: warning: lambda capture 'this' is not used [-Wunused-lambda-capture] connect(job, &WritePasswordJob::finished, [this](Job incoming) { ^ /mnt/ubuntu-home/tab/SpryDev/sprycloud-client-git/src/sprycloud-client/src/libsync/clientsideencryption.cpp:767:48: warning: lambda capture 'this' is not used [-Wunused-lambda-capture] connect(job, &WritePasswordJob::finished, [this](Job incoming) { ^ /mnt/ubuntu-home/tab/SpryDev/sprycloud-client-git/src/sprycloud-client/src/libsync/clientsideencryption.cpp:785:48: warning: lambda capture 'this' is not used [-Wunused-lambda-capture] connect(job, &WritePasswordJob::finished, [this](Job *incoming) {

tabp0le commented 6 years ago

OpenSSL Version: 1.10h QT Version: 5.11.1

camilasan commented 6 years ago

I can't reproduce this error on Linux but I have a similar problem on Windows with Release built.

Update: after I updated to Qt 5.11.1 on Windows, I also have the issue with Debug and Release builds... but I still can't reproduce it on Linux.

tabp0le commented 6 years ago

I wonder, could having an OpenSSL version of <=1.02 on the server, have any effect on the client?

Edit: I Upgraded my OpenSSL on the server and still have the issue, so that's definitely not it.

mannp commented 6 years ago

Getting the same issue myself.

camilasan commented 6 years ago

Hi! Please try the build https://download.nextcloud.com/desktop/daily/Windows/Nextcloud-2.5.0.61352-daily-20180904.exe. This issues should be solved. Thanks!

tabp0le commented 6 years ago

I'm trying to test, but unfortunately because of https://github.com/nextcloud/desktop/issues/279 I can't :(

tabp0le commented 6 years ago

@camilasan Do you have commits i can cherry-pick so I can try my own build using old login method? I tried merging master, but I don't think your fixes are in there, as it didn't make a difference.

camilasan commented 6 years ago

No, what changed is how we build it by passing openssl and qt5keychain paths to cmake: https://github.com/nextcloud/client-building/blob/master/build.bat

tabp0le commented 6 years ago

No, what changed is how we build it by passing openssl and qt5keychain paths to cmake: https://github.com/nextcloud/client-building/blob/master/build.bat

So yeah, this is still an issue. :(

camilasan commented 6 years ago

@tabp0le Ok, I can't reproduce it anymore. Could you check for client logs?

tabp0le commented 6 years ago

@tabp0le Ok, I can't reproduce it anymore. Could you check for client logs?

I've attached a log using official nextcloud nightly. (windows) nc-client-e2e-fail.log

tabp0le commented 6 years ago

This is still an issue in https://github.com/nextcloud/desktop/releases/tag/v2.5.0-rc2 (https://github.com/nextcloud/desktop/commit/6dae188ed9828e29a73a7f6d30765a433a4a6ffb) e2e_error.log @camilasan @rullzer

hoellen commented 5 years ago

I had the same issue today, when I installed the new 2.5.0 release (from nextcloud.com) for one of my windows user. After setting up E2E on the iOS client it worked.

rugk commented 5 years ago

Can confirm this issue still exists in v2.5.0 on Fedora 29.

rugk commented 5 years ago

Indeed, this should be a high-prio issue and is totally blocking any productive use of e2e crypto yet. I think you know it really needs to be fixed. For alpha stage okay, but at least the client's e2e crypto implementation is said to be stable (v2.5.0 with that feature – and this bug – is released as stable).

mickare commented 5 years ago

Hey, could there be a problem with the CSR generator in the desktop client?

@tabp0le wrote:

To get it to actually work, and add the account, I had to:

Go into the Android app

Add encrypted folder

Set up initial encryption and get pneumonic

Go back to nc desktop client and remove, then add account again.

At this point, it popped up with the enter e2e pneumonic phrase prompt.

Enter e2e phrase, and hit ok

Client syncs successfully

From #868:

Error | end_to_end_encryption | Can't create public key: could not sign the CSR, please make sure to submit a valid CSR | 2018-11-20T21:04:42+0100
-- | -- | -- | --
Error | PHP | openssl_csr_sign():  cannot get CSR from parameter 1 at  /var/www/nuee.schlueter.is/apps/end_to_end_encryption/lib/SignatureHandler.php#60 | 2018-11-20T21:04:42+0100
Debug | no app in context | No  cache entry found for  /appdata_ocjx58mjh67j/end_to_end_encryption/public-keys/arne.public.key  (storage: local::/mnt/nextcloud/, internalPath:  appdata_ocjx58mjh67j/end_to_end_encryption/public-keys/arne.public.key) | 2018-11-20T21:04:42+0100
Debug | no app in context | No  cache entry found for  /appdata_ocjx58mjh67j/end_to_end_encryption/public-keys/arne.public.key  (storage: local::/mnt/nextcloud/, internalPath:  appdata_ocjx58mjh67j/end_to_end_encryption/public-keys/arne.public.key) | 2018-11-20T21:04:42+0100

Code:

mickare commented 5 years ago

I can confirm that the workaround proposed by @tabp0le works with: