Android: End to End Encryption - Wrong user agent string

[schiessle]

Tested with the Android App 3.0.2 from F-Droid.

Steps to reproduce:

1. Mark a folder as e2ee
2. upload a file
3. download a file (until now it works, but maybe it is still cached on the client)
4. restart the android client
5. navigate to the e2ee folder
6. try to open the file again (I see a message at the bottom that the file can't be synced, then it opens the cached version)

On the server log I see:

{"reqId":"OHO7HQwYR7poYhKdy07n","level":4,"time":"2018-03-07T17:15:28+00:00","remoteAddr":"192.168.178.22","user":"admin","app":"webdav","method":"PROPFIND","url":"\/remote.php\/webdav\/Enc\/e53e80eb4cab42e6aa613dea3627daa5","message":"Exception: {\"Exception\":\"OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Exception\\\\Forbidden\",\"Message\":\"client \\\"Mozilla\\\/5.0 (Android) ownCloud-android\\\/3.0.2\\\" is not allowed to access end-to-end encrypted content\",\"Code\":0,\"Trace\":\"#0 \\\/home\\\/schiesbn\\\/Repos\\\/nextcloud\\\/server\\\/apps\\\/end_to_end_encryption\\\/lib\\\/Connector\\\/Sabre\\\/LockPlugin.php(125): OCA\\\\EndToEndEncryption\\\\Connector\\\\Sabre\\\\LockPlugin->checkUserAgent('Mozilla\\\/5.0 (An...', '\\\/Enc\\\/e53e80eb4c...')\\n#1 [internal function]: OCA\\\\EndToEndEncryption\\\\Connector\\\\Sabre\\\\LockPlugin->checkLock(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#2 \\\/home\\\/schiesbn\\\/Repos\\\/nextcloud\\\/server\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#3 \\\/home\\\/schiesbn\\\/Repos\\\/nextcloud\\\/server\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter->emit('beforeMethod', Array)\\n#4 \\\/home\\\/schiesbn\\\/Repos\\\/nextcloud\\\/server\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#5 \\\/home\\\/schiesbn\\\/Repos\\\/nextcloud\\\/server\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(80): Sabre\\\\DAV\\\\Server->exec()\\n#6 \\\/home\\\/schiesbn\\\/Repos\\\/nextcloud\\\/server\\\/remote.php(164): require_once('\\\/home\\\/schiesbn\\\/...')\\n#7 {main}\",\"File\":\"\\\/home\\\/schiesbn\\\/Repos\\\/nextcloud\\\/server\\\/apps\\\/end_to_end_encryption\\\/lib\\\/Connector\\\/Sabre\\\/LockPlugin.php\",\"Line\":170}","userAgent":"Mozilla\/5.0 (Android) ownCloud-android\/3.0.2","version":"14.0.0.1"}

I used the E2EE Server app from master, this is the same as 1.0.4 beside that I improved the error message to display the user agent string. As you can see the client sends "Mozilla/5.0 (Android) ownCloud-android/3.0.2" while we expect "Mozilla/5.0 (Android) Nextcloud-android/3.0.2"

Maybe this is fixed with 3.0.3? Maybe @tobiasKaminsky can test it... unfortunately 3.0.3 is not yet available via f-droid

for reference: https://github.com/nextcloud/end_to_end_encryption/issues/65

[tigernero79]

Which reason is it that pushes to use nextcloud on f-droid stopped at version 3.0.2 compared to 3.0.3 of the Google play store?

[xXSTrikeXx]

@tigernero79 F-Droid needs 24 hours to validate the app. So it takes a day or more ;)

[tigernero79]

@xXSTrikeXx I understand, but why not then download version 3.0.3 in the meantime from the google play store and test it?

[xXSTrikeXx]

@tigernero79 Because some people want to go away from world biggest data collector google.
DE: https://f-droid.org/de/docs/Inclusion_How-To/
English: https://f-droid.org/en/docs/Inclusion_How-To/

Quote

What to Expect

When your application metadata is approved and accepted into the fdroiddata git repository on GitLab, it won’t immediately appear in the main F-Droid repository.

Provided that your application does not have any build problems, it would takes somewhere around 24 to 48 hours from fdroiddata merge until the application to appears in the main repository.1 This timing limitation is due to the APK signing part of the build process, which requires human intervention on keystore access step.2

Nevertheless, your application will not appear in f-droid.org’s Lastest Apps list just yet, even though people can now already search and download it: Once the application appeared in the main F-D

But everyone can build the app on their own Computer with Android Studio and can install it over adb install ;)

[tigernero79]

@xXSTrikeXx It is a battle already lost at the start, I understand the reasons but I do not share personally.
However it was enough to ask a friend who has trust in google :-D the apk file is install from resource management of your smartphone. so as not to wait for 48 hours of f-droid.
I repeat, I understand, but it seems very stupid to me to fight a giant like google.

Thanks anyway for the explanation

as you see there is also the problem of same application errors repeated several times because users of f-droid do not receive the version immediately, and create post-duplicates with the same error.

[xXSTrikeXx]

@tigernero79 You could also think about Dropbox this way. But now there is Onedrive Google Drive and so on. I think having monopolies in the world would be the biggest loss in terms of privacy and freedom. So yes of course, I don´t share it, too. But today google is no longer what it used to do. Today it´s selling products by the way you can use it costless. But you have to think about it what the product is (like the 'free Windows 10'). Today you can´t buy the product, you are the product!
Post-duplicates is the result of my last quote ;)

EDIT: I forgot to mention bing, duckduckgo and so on 😆
@schiessle sorry about discussing off-topic: But what do you think? 😃

[schiessle]

I repeat, I understand, but it seems very stupid to me to fight a giant like google.

Sometimes it can be worth to be a little bit stupid... See the success of Free Software over the last 35 years or what we achieve with Nextcloud by fighting against the giants like Google, iCloud, Dropbox, Microsoft & Co.... If you fight you may lose but if you don't fight you already lost. Anyway let's stick to the topic here. The forum is a better place for general discussions.

[vincentadultman]

Having tested with 3.0.3 from the google play store, this is unfortunately still happening.

[AndyScherzinger]

cc @tobiasKaminsky

[mannp]

@schiessle I cannot tell if your change is working as I have too many locked files, and nc clients are complaining at 12 files being locked which are not part of E2EE.

That said the correct password is not accepted by 3.0.3 client when I select an encrypted directory.

Until I understand why they have not gotten locked I cannot issolate this one issue out.

It seems it may be a wider issue I am having with E2EE interferring in none E2EE syncs?

#8756

If its not related then apologies, but I have disabled E2EE today and all my syncs are working again, with no locks or conflicts.

[t-m-w]

UPDATE: Turns out, I'm still getting "OCA\DAV\Connector\Sabre\Exception\Forbidden: client not allowed to access end-to-end encrypted content" a lot. Just not all the time.
/var/snap/nextcloud/5685/nextcloud/extra-apps/end_to_end_encryption/lib/Connector/Sabre/LockPlugin.php - line 125: OCA\EndToEndEncryption\Connector\Sabre\LockPlugin->checkUserAgent('Mozilla/5.0 (An...', '/Tunes') [internal function] OCA\EndToEndEncryption\Connector\Sabre\LockPlugin->checkLock(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response)) /snap/nextcloud/5685/htdocs/3rdparty/sabre/event/lib/EventEmitterTrait.php - line 105: call_user_func_array(Array, Array) /snap/nextcloud/5685/htdocs/3rdparty/sabre/dav/lib/DAV/Server.php - line 466: Sabre\Event\EventEmitter->emit('beforeMethod', Array) /snap/nextcloud/5685/htdocs/3rdparty/sabre/dav/lib/DAV/Server.php - line 254: Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response)) /snap/nextcloud/5685/htdocs/apps/dav/appinfo/v1/webdav.php - line 80: Sabre\DAV\Server->exec() /snap/nextcloud/5685/htdocs/remote.php - line 164: require_once('/snap/nextcloud...')

ORIGINAL POST: I'm not sure if it's related, but 3.0.3 fixed the basic inability to interact with encrypted folders and view the files inside, for me. That said, I still have the "file is locked" issue you linked to that makes E2EE unusable the vast majority of the time.

[schiessle]

@mannp I'm sure that is also part of the broken user agent string, that locks couldn't be removed. I suggest to focus on getting the user agent string right and then see if other problems still exists.

[mannp]

@schiessle Ok thanks, but I am not sure how to resolve the file locking with e2ee enabled.

I am trying it on a production system and have removed it and will try it again later on a purely beta test system.

Since I disabled e2ee I have had no files locked in 3 days, so am not rushing to re-enable it on this system.

If there is a potential solution you know of I will re-enable and try it though.

[schiessle]

@mannp if the lock wasn't removed from the same client who created the lock we can never be 100% sure if you payload and the meta data are in sync. But for testing purpose on a test system you can try to remove the lock from the database. All locks are stored in the oc_e2e_encryption_lock table.

[mannp]

@schiessle I am not sure it was file related as I had 12 files locked with e2ee enabled and after no changes except for removing e2ee all of the locked files synced correctly.

I tried deleting the contents of that table based on a thread elsewhere, but that had no affect to my situation.

Even changing to redis as the locking mechanism the files still remained locked with e2ee enabled.

[stale[bot]]

This request did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!