this post was submitted on 15 Jul 2024
45 points (100.0% liked)
Jerboa
11485 readers
1 users here now
Jerboa is a native-android client for Lemmy, built using the native android framework, Jetpack Compose.
Warning: You can submit issues, but between Lemmy and lemmy-ui, I probably won't have too much time to work on them. Learn jetpack compose like I did if you want to help make this app better.
Built With
Features
- Open source, AGPL License.
Installation / Releases
Support / Donate
Jerboa is made by Lemmy's developers, and is free, open-source software, meaning no advertising, monetizing, or venture capital, ever. Your donations directly support full-time development of the project.
Crypto
- bitcoin:
1Hefs7miXS5ff5Ck5xvmjKjXf5242KzRtK - ethereum:
0x400c96c96acbC6E7B3B43B1dc1BB446540a88A01 - monero:
41taVyY6e1xApqKyMVDRVxJ76sPkfZhALLTjRvVKpaAh2pBd4wv9RgYj1tSPrx8wc6iE1uWUfjtQdTmTy2FGMeChGVKPQuV - cardano:
addr1q858t89l2ym6xmrugjs0af9cslfwvnvsh2xxp6x4dcez7pf5tushkp4wl7zxfhm2djp6gq60dk4cmc7seaza5p3slx0sakjutm
Contact
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Was it properly checked for backdoor injections?
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.
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?
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 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.