Not going back to Jerboa unless the basic feature of searching contents other than just communities is implemented. I find this fundamental feature sorely lacking in Jerboa while every other app around there have this.
\
https://github.com/LemmyNet/jerboa/issues/27
\
Kind of surprising, because this is pretty basic feature, and has been open for over two years.
Getting “Posts failed loading, retry” button after scrolling to the end of Subscribed feed (does not matter if Scaled, New).
Verified across multiple instances.
E: And the button does nothing, specifically, after clicking it it vanishes and comes back (the loading bar does not appear). No problem in All.I see that also, its a bug.
k, just did a release with this fixed, thanks to mv-gh for this one.
Was just checking the issue out and seeing MV-GH had a fix ready, awesome work and thanks for the quick release!
Is there a way to revert to an old version of the app? This issue is annoying enough for me that I’m now temporarily on Voyager. I don’t hate it, but I’d rather be on Jerboa.
If you installed through f-droid, you can install older versions.
Okay, thank you.
Update plugin com.android.test to v8.5.0 by @renovate in #1561
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.