What's Changed
Fix initial page_cursor by @MV-GH in #1553
Removing renovate schedule. by @dessalines in #1555
Update plugin com.android.test to v8.5.0 by @renovate in #1561
Update plugin com.andro...
There were dozens of dependency upgrades in this release, I have no idea why you think this specific one has security issues. Either way we don’t have time to read through every line of code of every dep update, but here’s the source code: https://android.googlesource.com/platform/tools/base
If you find something, you might want to submit a PR as it would affect not just ours, but a lot of android projects.
Reading through the code of the dependency is not required. What is required is reading through the merge request to see if the dependency isn’t used for malicious or wasteful purposes. Checking on the authenticity of the dependency is a good idea too.
It’s not the dependency itself that concerns me. It’s the usage of it in the app. As we already know, it’s easy to insert trojan code in testing procedures.
I’m worried about that one specifically. Dependencies in general can be suspicious if they come from untrusted sources but in that case it’s suspicious by being related to testing (like the xz thing was) that shouldn’t even be in a released app anyways.
Was it properly checked for backdoor injections?
What is the “proper” way?
Check the code for suspicious lines and then check the compiled app for network traffic etc
There were dozens of dependency upgrades in this release, I have no idea why you think this specific one has security issues. Either way we don’t have time to read through every line of code of every dep update, but here’s the source code: https://android.googlesource.com/platform/tools/base
If you find something, you might want to submit a PR as it would affect not just ours, but a lot of android projects.
Reading through the code of the dependency is not required. What is required is reading through the merge request to see if the dependency isn’t used for malicious or wasteful purposes. Checking on the authenticity of the dependency is a good idea too.
Open up an issue for your concerns on the google issue tracker, here it is linked for you: https://android.googlesource.com/platform/tools/base
It’s not the dependency itself that concerns me. It’s the usage of it in the app. As we already know, it’s easy to insert trojan code in testing procedures.
Is there a reason you’re suspicious about that particular dependency, or are you just asking about dependencies in general?
I’m worried about that one specifically. Dependencies in general can be suspicious if they come from untrusted sources but in that case it’s suspicious by being related to testing (like the xz thing was) that shouldn’t even be in a released app anyways.
It’s not included in the final build artifact. It’s a Gradle plugin.
If you have a security concern you should raise this with Google using a minimal working example to demonstrate yourself.
Do you have a genuine concern and can you provide a working example of the attack surface in a repository that you can share?
What’s the context there? We update dependencies very frequently.
The context is the name of the dependency and its very questionable purpose.
I have no idea what this means. Why is the android testing dependency is less secure than all the other android deps we’ve updated?