This simplifies usage, goes from
app['Foo']
to
app.Foo
Also makes static analyzers able to detect invalid attributes as the set
is now limited in the class definition.
As a bonus, setting of the default field values is now done in the
constructor, not separately and manually.
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.
following guidelines from:
https://docs.python.org/2/library/argparse.html#upgrading-optparse-code
except, still using option = parse.parse_args() instead of args = ...
- using the following script in folder fdroidserver:
for i in *.py; do
sed -i -e 's/optparse/argparse/' \
-e 's/OptionParser/ArgumentParser/' \
-e 's/OptionError/ArgumentError/' \
-e 's/add_option/add_argument/' \
-e 's/(options, args) = parser/options = parser/' \
-e 's/options, args = parser/options = parser/' \
-e 's/Usage: %prog/%(prog)s/' $i;
done
- use ArgumentParser argument to replace (option, args) = parser.parse()
call
- use parser.error(msg) instead of raise ArgumentException as suggested
in https://docs.python.org/2/library/argparse.html#exiting-methods
- in fdroid catch ArgumentError instead of OptionError
wget's --continue makes wget not overwrite the existing file, or create a
new version with a .1 extension. Instead it tries to finish an incomplete
download, or does nothing if the download is complete and matching.
Done after verifying that they match ones built using a recipe.
Everything in the metadata should be the same as normal, with the
addition of the Binaries: directive to specify where (with pattern
substitution) to get the binaries from.
Publishing only takes place if there is a proper match. (Which seems
very unlikely to be the case unless the exact same toolchain is used, so
I would imagine that unless the person building and signing the incoming
binaries uses fdroidserver to build them, probably the exact same
buildserver id, they will not match. But at least we have the
functionality to support that.)
* E124 closing bracket does not match visual indentation
* E125 continuation line does not distinguish itself from next logical line
* E126 continuation line over-indented for hanging indent
* E127 continuation line over-indented for visual indent
* E128 continuation line under-indented for visual indent
FDroidPopen() does not have a way to send to stdin, so we will use the
password file for now. In the long run, at least the keypass should always
be sent via stdin rather than via a file. Ideally, storepass would be too,
but if they are different, then storepass is less important.
Any process can read the process table, and can therefore see the entire
command line of any other process. That means its a bad idea to ever put
passwords as part of a command line. Python is executing keytool and
jarsigner command lines here, so now instead of putting the password on the
command line, a file is passed instead with suitable file permissions.
This should reduce the exposure a lot. But still, sensitive passwords
should not be written to any text file.
This change requires OpenJDK-7 since the :file option to -storepass and
-keypass was only added in Java 7's keytool and jarsigner.
