Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android X (P) #2402

Merged
merged 7 commits into from
Feb 13, 2019
Merged

Android X (P) #2402

merged 7 commits into from
Feb 13, 2019

Conversation

hannesa2
Copy link
Contributor

@hannesa2 hannesa2 commented Dec 19, 2018

I was forced to use Android P as well, so it's the move to P as well


Edited by @davigonz

About Android P, I'm gathering some changes from here that might affect the ownCloud Android app when targeting Android P:

CC @jesmrec @hannesa2


BUGS & IMPROVEMENTS

This was referenced Dec 19, 2018
@hannesa2
Copy link
Contributor Author

hannesa2 commented Dec 19, 2018

Ok, there are some -alpha02 included, either

  • we wait till they are non alpha (just number beauty) or
  • we go with -alpha02 (my company uses it in production without any issues , 5.000.000+ installations) or
  • we uses older stable versions, not sure if it work for all libs

@davigonz
Copy link
Contributor

davigonz commented Jan 22, 2019

Thanks a lot for this contribution @hannesa2 , we'd rather not use alpha versions, would it be possible to keep using stable versions just in the alpha ones? By the way, there's some conflicts with master.

@hannesa2
Copy link
Contributor Author

I reverted to stable libs.
But I'm not convinced, because it's just number cosmetic. After 2.0.0 a 2.0.1 will come too. On the other side, using old ones means to waiver some improvement in beta

@davigonz
Copy link
Contributor

davigonz commented Jan 23, 2019

@hannesa2 apart from the requested changes above, I have compiled the code, install the app and I get the next error when checking the server in login view, which appears as Unknown error in the app, any idea?

2019-01-23 17:53:27.454 25087-25119/com.owncloud.android.debug E/GetRemoteStatusOperation: Connection check at http://192.168.0.173:10000: Unrecovered transport exception
    java.net.UnknownServiceException: CLEARTEXT communication to 192.168.0.173 not permitted by network security policy
        at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:147)
        at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:257)
        at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135)
        at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:114)
        at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)

Maybe we need a security config file now, can you try with the next code?

  • In res/xml/network_security_config.xml:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true" />
</network-security-config>
  • In AndroidManifest.xml
android:networkSecurityConfig="@xml/network_security_config"

@hannesa2
Copy link
Contributor Author

Indeed this cleartextTrafficPermitted is an issue, I didn't measured it, because I use https.
On the other hand, who uses http needs no privacy, this person can upload files to Google photos too

@hannesa2
Copy link
Contributor Author

Removing this http communication lock is a move in one direction.
But a move in the other direction could be an introduce of (dynamic) cert pinning which prevents from a man-in-the-middle attacks -just as an idea-

@michaelstingl
Copy link
Contributor

But a move in the other direction could be an introduce of (dynamic) cert pinning which prevents from a man-in-the-middle attacks -just as an idea-

👍

@hannesa2 you mean like in #934 ? Or better open another issue to discuss details?

@hannesa2
Copy link
Contributor Author

Exactly #934 ! (but I it's almost 3 years just an idea)
I will not promise anything, but maybe I can deliver something, when I generalize similar somewhere else

And one more additional step could be a 2 phase authentication, like Google does when a new IP/device tries to connect with a mail notification/confirmation. But with this, the backend needs some work. But to be honest, this needs too much live/spare time from my side.

When it comes to my focus I can open a ticket for sure, but currently my main interest is the non working (already closed) upload #2394
Btw you can open a ticket too, if you see a sense to have an additional ticket

@hannesa2
Copy link
Contributor Author

hannesa2 commented Jan 23, 2019

What should be done here ?
Allow http and be more un-secure or follow the Goggle suggestion and only allow https and do nothing ?
@davigonz @jesmrec @michaelstingl

@davigonz
Copy link
Contributor

davigonz commented Jan 24, 2019

@hannesa2 @michaelstingl @jesmrec

What should be done here ?
Allow http and be more un-secure or follow the Goggle suggestion and only allow https and do nothing ?

I would not get rid of http IMHO, is insecure for sure but ownCloud is a self-hosted solution and therefore, each end user/company should be the responsible for the security of his ownCloud instance.

Disallowing http will likely trigger complains since we are making decisions that do not belong to us.

But a move in the other direction could be an introduce of (dynamic) cert pinning which prevents from a man-in-the-middle attacks -just as an idea-

About this, I think that we are already checking the SSL certificate against a stored one, as is suggested in #934. Have a look at https://github.com/owncloud/android-library/blob/940f0b9bb042e3c318e4cbeff71782e0d8733f93/owncloudComLibrary/src/main/java/com/owncloud/android/lib/common/http/HttpClient.java#L78.

@davigonz
Copy link
Contributor

@hannesa2 can you please apply the changes about http and foreground services so we can push this to be included in 2.10.0? Thanks

@hannesa2
Copy link
Contributor Author

http :
I followed https://developer.android.com/training/articles/security-config and applied the default configuration for apps targeting Android 6.0 (API level 23) and lower

@hannesa2
Copy link
Contributor Author

Foreground Service:

I added the missing ones, but to be honest I did only code changes and didn't test it.

In following files, in my point of view, there are too much conditions to run into startForeground() but you already have it on master, so I didn't changed it.
This would be ok
Build.VERSION.SDK_INT >= Build.VERSION_CODES.O but the other ones ?

FileDownloader.java
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O && (isAvailableOfflineFile || retryDownload))

FileUploader.java
if ((createdBy == CREATED_AS_CAMERA_UPLOAD_PICTURE || createdBy == CREATED_AS_CAMERA_UPLOAD_VIDEO || isAvailableOfflineFile || isRequestedFromWifiBackEvent) && Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {

@davigonz
Copy link
Contributor

FileDownloader.java
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O && (isAvailableOfflineFile || retryDownload))

You have a comment just below that line that explains why do we need those checks. We create the service to check available offline files and retry downloads by using startForegroundService and we have to call startForeground within five seconds only for those cases.

/**
* We have to call this within five seconds after the service is created with startForegroundService when:
* - Checking available offline files in background
* - Retry downloads in background, e.g. when recovering wifi connection
*/

if ((createdBy == CREATED_AS_CAMERA_UPLOAD_PICTURE || createdBy == CREATED_AS_CAMERA_UPLOAD_VIDEO || isAvailableOfflineFile || isRequestedFromWifiBackEvent) && Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {

Have a look at the comment below:

/**
* After calling startForegroundService method from {@link TransferRequester} for camera uploads or
* available offline, we have to call this within five seconds after the service is created to avoid
* an error
*/

@hannesa2
Copy link
Contributor Author

Can you check that @jesmrec ?

My opinion is, it's just necessary to test latest commit

@davigonz
Copy link
Contributor

davigonz commented Feb 12, 2019

I agree, 72a4297 fixes now the e07901b.
I can squash (together with introduce 6dd0a4c and revert d84f0bf) it on request to summarize necessary changes, but in review you see summarize too

@hannesa2 the startForegroundService stuff is still in this PR, can you have a look at it? Thanks

@hannesa2
Copy link
Contributor Author

please test it first. Without it, we've seen a crash #2402 (comment)

@davigonz
Copy link
Contributor

please test it first. Without it, we've seen a crash #2402 (comment)

As I explained in #2402 (comment), I tested without it and I'm not getting that crash but the notification error.

@jesmrec can you please test af756ba and confirm there's no crash there? If so, we can remove the startForegroundService stuff

@jesmrec
Copy link
Collaborator

jesmrec commented Feb 12, 2019

With commit 4064941:

With commit 6ed4d30

  • Installation: OK
  • URL check and authentication: OK
  • Camera uploads: Fails. In this case, pics are not either enqueued (in the previous one, they were). I stumbled upon this trace:

2019-02-12 11:01:29.270 22838-22838/? E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.owncloud.android.debug, PID: 22838
java.lang.RuntimeException: Unable to start service com.owncloud.android.files.services.FileUploader@a120a3d with Intent { cmp=com.owncloud.android.debug/com.owncloud.android.files.services.FileUploader (has extras) }: java.lang.SecurityException: Permission Denial: startForeground from pid=22838, uid=10482 requires android.permission.FOREGROUND_SERVICE
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3687)

with commit 72a4297 (the latest one)

  • Installation: OK
  • URL check and authentication: OK
  • Camera uploads: Works fine!!!
  • Additional check: av, offline files: OK

so, good news. In any case, a deeper testing should be performed to assure all scenarios are OK, but this is out of the scope of the current one.

@jesmrec
Copy link
Collaborator

jesmrec commented Feb 12, 2019

@hannesa2 i have rechecked the whole feature by dropping the commit c2db38e, and it works properly. No crashes in authentication and uploads run correctly (camera uploads and manual uploads).

Maybe we can get rid of such commit, so it does not introduce anything sensible for the described feature, and will make a cleaner history.

Sorry for the noise.

@hannesa2
Copy link
Contributor Author

hannesa2 commented Feb 12, 2019

ok, I removed the

  • introduce
  • revert
  • re-intoduce

commit, and kept all except my fix. (To be honest, because it worked for me before, I simply followed your suggestion and didn't tested it)
@jesmrec please take over

@hannesa2 hannesa2 force-pushed the AndroidX branch 3 times, most recently from a404aeb to a111f26 Compare February 13, 2019 05:56
@jesmrec
Copy link
Collaborator

jesmrec commented Feb 13, 2019

After a new check:

  • Services job-based (camera uploads and av. offline syncing) are working properly in Android 9
  • Same checks works fine in Android 8 and 7.

We can move forward, and new checks will be performed in the following release stage.

Approved

@jesmrec jesmrec self-requested a review February 13, 2019 11:19
@jesmrec
Copy link
Collaborator

jesmrec commented Feb 13, 2019

Please, update the branch for the final merge

@hannesa2
Copy link
Contributor Author

Sounds good ! Rebase is done

@davigonz davigonz merged commit fba789e into owncloud:master Feb 13, 2019
@davigonz davigonz mentioned this pull request Feb 13, 2019
@hannesa2 hannesa2 deleted the AndroidX branch February 13, 2019 17:47
@jesmrec jesmrec mentioned this pull request Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants