These were both spamming the output with lots of confusing messages, even
when --verbose was not used. Jarsigner especially has confusing messages,
since it has warnings that do not pertain to APK signatures at all, like
the ones about timestamps and missing Certificate Authority.
closes#405
fd-commit and checkupdates both require that there are two name fields,
AutoName: and Name:. This is only used for the commit messages. Since the
current devs do it manually, we can remove the fd-commit shell script, then
focus on checkupdates when revamping AutoName/Name.
https://botbot.me/freenode/fdroid-dev/msg/82539152
A full run of the test suite takes quite a bit of time. This removes one
of the 3 runs from the main 'tests' job, and puts it into the Fedora job.
That test run is mostly to make sure the setup.py and source tarball are
correctly, so that doesn't affect merge requests very often.
This also tests `pip install --user`, which was not really being tested
before.
Just give a proper error message rather than this stack trace:
Traceback (most recent call last):
File "/home/hans/code/fdroid/server/fdroid", line 156, in <module>
main()
File "/home/hans/code/fdroid/server/fdroid", line 132, in main
mod.main()
File "/export/share/code/fdroid/server/fdroidserver/init.py", line 148, in main
if os.path.isfile(aapt):
File "/usr/lib/python3.5/genericpath.py", line 30, in isfile
st = os.stat(path)
This rsync hung because of an SSH unknown key prompt. Since this is just
the vm host sshing to the vm guest, it is not essential to check the host
keys.
These are only used for checking syntax in buildserver/Vagrantfile.
Not requiring ruby makes doing CI tests on lots of distros easier
and faster. dash is an 'essential' package on Debian derivs, so
those tests will always be run somewhere.
Save rsync error output and combine that with the command invocation
into an FDroidException which can be logged to the wiki.
This additionally sets -q for rsync to only print errors.
os.rename() only works if source and destination are on the same file
system, shutil.move() works across file systems.
OSError: [Errno 18] Invalid cross-device link: '/builds/eighthave/fdroidclient/app/build/outputs/apk/app-debug.apk' -> '/tmp/tmp966vh75f/tmp.apk'
This needs to use the config loading routine to find Java `keytool`, but
since it doesn't need to fully load the config, isolate that usage in the
function. Then read_config() is only ever called once, as is it meant to
be used, once the config.py is generated.
Using `from . import common; common.config = foo` will not always work,
due to some oddities to how the `from` imports work. So the full module
has to be imported in order to make sure its always properly set.
Rather than needing to run a command before and after the build, in order
to first install the debug.keystore, then after to fetch and publish the
APK, this makes `fdroid nightly` just resign the APK with the provided
debug.keystore. Then `fdroid nightly` can be run as the final step in a CI
build, and still ensure that the APKs are always signed by the provided
debug.keystore.
If we allow SSH, then we'd have to manage known_hosts.
All VCS and submodule URLs should use HTTPS. SSH URLs have security vulns:
https://blogs.msdn.microsoft.com/devops/2017/08/15/git-vulnerability-with-submodules/https://www.theregister.co.uk/2017/08/13/ssh_flaw_in_git_mercurial_svn/
CVE-2017-1000117
I did a manual scan of the setup on jenkins.debian.net to see if I could
find any suspicious URLs. Looks good so far. This is what I used:
find . -type f -print0 |xargs -0 grep -Eo 'ssh[:+][svn/]+...................'
find . -type f -print0 |xargs -0 grep -Eo 'ssh://-[^ "]+'
Also, some ssh://_ URLs in submodules might still work, because of the URL
rewriting in fdbfb4d1. But https://-oProxyCommand=pwnme does not really do
anything, unlike ssh://-oProxyCommand=pwnme
Later revisions might have removed the submodules so we want to keep
going when there are no submodules present.
We still abort when there is an error initializing submodules.
Fixesfdroid/fdroidserver#231
Something is preventing `fdroid build --all` from exiting after a long
run. @bubu, @uniqx and I think it is because of the use of
AsynchronousFileReader, somehow it's thread does not exit. So the
workaround for now is to just try a hard exit instead of waiting for
things to finish cleanly with `sys.exit(0)`.
https://jenkins.debian.net/job/reproducible_fdroid_build_apps/94/console
