Since it is possible to check the file size and MD5 hash of the file up on
the AWS S3 bucket, `fdroid server update` can check that a file needs to be
updated before actually deleting and uploading the new file.
fixes#3137https://dev.guardianproject.info/issues/3137
This makes the AWS S3 setup dead simple: just put in a awsbucket name of
your choosing, set the AWS credentials, and it'll do the rest, whether the
bucket exists already or not. S3 buckets are trivial to delete too, in
case of error: `s3cmd rb s3://mybadbucketname`.
apache-libcloud enables uploading to basically any cloud storage service.
This is the first implementation that allows `fdroid server` to push a repo
up to a AWS S3 'bucket'. Supporting other cloud storage services should
mostly be a matter of finding the libcloud "Provider" and setting the
access creditials.
fixes#3137https://dev.guardianproject.info/issues/3137
Right now, ssh+rsync is the only supported server upload type. Things like
cloud storage services are useful storage bins for fdroid repos since they
are often not blocked while specific websites like Google Play are.
Having serverwebroot optional in `fdroid server` means that it can support
multiple methods of hosting, like cloud storage services. `fdroid server`
can also then support multiple repo hosting options at the same time.
The .fdroid.*.txt password files are only meant to be a conduit for the
passwords, so blow them away everytime. The canonical password is stored
in config.py.
It might makes sense to replace these files with env vars using
-storepass:env and -keypass:env. I figured that the passwords are already
in a file, config.py, so adding more files in the same location with the
same perms would not increase the risk at all.
* Group apk, jar and zip files in the same case
* Use regex to support more patterns and be more flexible
* Only check for usual suspects in jar files (saves time)
* Also catch unknown zip-like files as warnings
implemeted support for using a smartcard for the repo signing key
This changeset implements using a smartcard (HSM) as the keystore for the signing key. It also fixes lots of little bugs in the `fdroid init` process.
This assumes that the smartcard is already setup with a signing key. init
does not generate a key on the smartcard, and skips genkey() if things are
configured to use a smartcard.
This also does not touch APK signing because that is a much more elaborate
question, since each app is signed by its own key.
