* Move apks back from the archive repo (e.g. if builds are disabled thus the
number of apks on the main repo decreases)
* Also move apk signatures back and forth
This allows us to fetch strings like the following:
<string name="app_name">foo <xliff:g>bar</xliff:g></string>
Up until now, using .text would only return "foo ", but if we use .tostring()
with the text method, it converts everything into plain text for us resulting
in "foo bar".
8k is too small, e.g. when make -jN errors or when there are a lot of scanner
errors and warnings. 16k should be better. Also, use "[...]" to make it
obvious that the output is truncated.
Up until now, if it was thrown, fdroid would crash with a full stacktrace as
if the program had stopped unexpectedly. Now it just prints the metadata
error, as intended.
Looks to me like we were using SHA1withRSA all along. Tested that everything
still works with a test repo.
As Hans reports, SHA1withRSA has been the default on Android tools for a long
time and it's supported on all Android versions.
Add asynchronous filereader, fix python3 lockups
with the current implementation of AsynchronousFileReader with Python 3 FDroidPopen deadlocks with 100% CPU-utilization
The code is from https://github.com/soxofaan/asynchronousfilereader
I hope the MIT-Licence makes no problems
See merge request !80
Added support for gradle flavor specific dependencies in usual suspects check
When you have flavor specific dependencies in your project, you specify them in the build.gradle file with a prefixed *compile* command:
```
compile 'normal dependency'
myflavorCompile 'only for myflavor'
```
The usual suspects check just searches for some often used library names in the whole build.gradle file. I added another condition, so dependencies for not build flavors are not checked.
See merge request !77
This is much closer to what we did before with mimetypes. Using a whitelist
turns out to be a bad idea since repositories seem to be randomly filled with
executable images and documents, which trigger the scanner.
In an ideal world the scanner would complain about all of those. For now, just
warn about the possibility of them being hidden binaries.
Initially, the scanner used libmagic which used magic numbers in the file's
content to detect what kind of file it appears to be. Since that library isn't
available on all systems, we added support for two other libraries, mimetypes
amongst them.
The issue with mimetypes is that it only uses the file's extension, not its
actual content. So this ends in variable behaviour depending on what system
you're using fdroidserver on. For example, an executable binary without
extension would be ignored if mimetypes was being used.
We now drop all libraries - mimetypes too as it depends on the system's
mime.types file - and instead check extensions ourselves. On top of that, do
a simple binary content check to find binary executables that don't have an
extension.
The new in-house code without any dependencies doesn't add any new checks, so
no builds should break. The current checks still work:
% fdroid scanner app.openconnect:1029
[...]
Found executable binary at assets/raw/armeabi/curl
Found executable binary at assets/raw/mips/curl
Found executable binary at assets/raw/x86/curl
Found JAR file at lib/XposedBridgeApi-54.jar
Found JAR file at libs/acra-4.5.0.jar
Found JAR file at libs/openconnect-wrapper.jar
Found JAR file at libs/stoken-wrapper.jar
Found shared library at libs/armeabi/libopenconnect.so
Found shared library at libs/armeabi/libstoken.so
Found shared library at libs/mips/libopenconnect.so
Found shared library at libs/mips/libstoken.so
Found shared library at libs/x86/libopenconnect.so
Found shared library at libs/x86/libstoken.so
