-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reproducible build #272
base: master
Are you sure you want to change the base?
reproducible build #272
Conversation
Nice work! But I have some idea:
|
@0140454 thanks for your hint to the closed ticket - it contained a additional magic
please comment on your opinion on
i am giving up with the gradle/androidstudio stuff for now, input on that would be appreciated - its not clear to me where it expects the built binaries and where it puts the apk - it just fails with |
another round after the results did not match:
now two runs produce the same result:
should output "verify ok" this means boost, openssl and monero artifacts can now be verified by a third party |
|
There is a --arch commandline switch, from what i see in the release apk's all four arch's are required The |
Oh, I misunderstood your text. In addition, I modified the script according to the issues I encountered at compiling apk and created a pull request in your repository. I fix some errors and complete building apk part. |
Thanks @0140454 the apk is now being built. |
Verify build on random docker host successful |
sha256sum -c "${TMP_CHECKFILE}" \ | ||
|| die "checksum for ${FILENAME} not expected:" \ | ||
" is $(sha256sum "${FILENAME}") instead of ${SHA256SUM}" | ||
# XX todo: should also be removed on die, irrelevant in container |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid leaving temporary file, we can use pipe instead of file.
For instance, echo -n "${SHA256SUM} ${FILENAME}" | sha256sum -c -
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
|
||
|
||
BOOST_VERSION=${BOOST_VERSION:-1.58.0} | ||
# j!!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's 1.0.2o currently
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, i misunderstood your comment...
@@ -17,4 +17,4 @@ org.gradle.jvmargs=-Xmx1536m | |||
# org.gradle.parallel=true | |||
|
|||
# keep build timestamps in APK | |||
android.keepTimestampsInApk = true | |||
android.keepTimestampsInApk = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can extract apk to verify artifacts instead of adding debug.keystore or droping timestamp.
Just like f-droid verification server does [GitLab].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
timestamp dropping is a good thing imho, but the debug.keystore is annoying.
So i rewrote the artifacts-verification build and the checksum method to create checksums of the contents of the apk and verify them with a second build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reason for the timestampsInApk is that I use that option when deploying on f-droid to generate the repo metadata (i.e. to have the correct apk release date). it comes in very handy when recreating the whole repo from scratch.
a reproducible build, of course, may not have this set to true
.
root@docker-host:/xmrwallet/external-libs/build/artifacts-verification# time make artifacts-verification real 225m56.830s |
- create a container definition for the android npk - install java and gradle - bash script to download, check, compile and verify artifacts - build boost - build ssl (using the logic from build-all-arch) so that the openssl version can be increased correct OpenSSL checksum for 1.0.2o - build monero using the m2049r/monero repository with the latest tag - build apk using the m2049r/xmrwallet repository with the latest tag - compile checksums from non-volitale files, skipping META-INF directories from apk and check them with a artifacts-verification version
rebased for clean history |
@jenniferberger running
|
Hi, have you fix this error? i encountered the same problem recently on my unbuntu-16.04-LTS system. |
inspired by doc/BUILDING-external-libs.md
The apk files currently differ against the verification because the gradle.properties are taken from the mr2049r/xmrwallet that does
android.keepTimestampsInApk = true
. On a modest hardware (i3/hdd) the build all takes about 4 hours, verification 4 hours again. When only java code changes this can be shaved to about 10 minutes (make artifacts/apk). Building with a patched xmrwallet repository the apk-files do not differ.@m2049r please comment if this toolchain is applicable in the current release workflow to make one of the next versions verifiable and if you need something to drop your current way of building the binaries. I think it is still required to do some work on signing the builds with the correct keys. The debug packages are signed with the debug.keystore added by this PR and the release packages do not contain a CERT.RSA file - not sure which is the one that will be released.
The current release (monerujo-1x5x3_armeabi-v7a.apk) produces different binaries (so-files) than uploaded to the https://github.com/m2049r/xmrwallet/releases page. This is expected and not meant as an offence.
Reviewers: please check the sha256 sums in the Dockerfile (android toolchain) and build-artifacts.sh (OpenSSL/Boost) so i really used the right versions for the container. There is still reviewing required in the monero fork of m2049r, but this is out of scope of this PR.
The verification can still be improved. Signal for example records all dependencies with their checksums. They are a bigger project with more resources to that direction. Even if I think those checks are important for a payment application, there are currently more urgent places that require attention.
references #232 (makes the artifacts reproducible and verifiable) and #57 (because it is still a goal to get into the official store some day as they do the verify as well)