autogenerated versionCode and show last commit

[hannesa2]

I want to increase trust of PlayStore version of this wallet and want to have automatically right version in app. In an other wallet I figured out the commits didn't fit to PlayStore version. This is a no-go

To prevent this, I made this minor PR to increase trust. I changed versionCode logic and show the auto generated commit url in about. Probably there are some who like the previous numbers, but I say: This are just numbers

btw tools.gradle is now obsolete. What's the purpose to get branch without having git installed ? At least for build for Playstore it's mandatory

[Giszmo]

We need deterministic builds, with independent people monitoring what we put to the play store and that should be the industry standard with any deviation being huge red flags.

Currently all wallets on google and iTunes should be no-gos and I wish we could give it a higher priority but just because I put some commit hash into the about page doesn't mean I don't add some wallet-emptying "features" in the release. I know I wouldn't do that but I would still want this feature even for myself, as I can not know what kind of virus somebody manages to inject in my build computer.

That said, the proposed change sounds like a good idea to better know which version you are at.

[hannesa2]

To see it positive, I see at least the interest to increase trust ! The PR doesn't solve the trust on any point of view, but at least it increase it, and shows probably the commiter wallet-emptying "features".

• version number is stabil, when you avoid git commit --amend on master. This is a no-go in any case on master. And everyone in any repo should avoid this or be blocked. This decrease transparency

• please point me to the 'changelog' issue, I've no clue what you speak about. Let me investigate, if there is a smart way

• building from an internal repo is a fault. The main idea is to build public too, with full transparent CI build chain too. I know the keystore issue and I did a test to do it with an other wallet, on a own public hosted machine. If you are interested, I can show

[Giszmo]

• I edit the code locally until I like the binary. Then I commit and push it, often in two commits, one with the compiler fixes and the other with the changes to the version number and changelog entry. I can change that workflow, adding an --amend locally. In our private fork of the repo, master and develop are protected branches and don't allow any history rewriting. I fully agree on that and would love to have all changes fully attributable, with signed and co-signed commits.
• see this commit
• excuse me but I think your blanket statements are at fault. A full, transparent CI build can get you the wallet-stealer "feature", too, if the build-server has some special pre-compiler. The only thing that I know of that can really catch a deliberate attack is deterministic builds, with an auditor that is not affected by the attack. If the next gradle update comes with a Mycelium wallet patcher, we are probably screwed, unless they are on top of such security issues. Can't audit all the things.

[hannesa2]

Concerning changelog: The first idea to auto generate changelog I see currently no need. But to archive this you should continue making tags. (You stopped by v2.2.x) Then this can be a way git log "git describe --tags --abbrev=0"..HEAD --oneline (you have to change the ") .. but filtering can be useful.

Anyway, when we simple ignore versionCode in xml the log dialog is shown but initial without content, after push "more" you see it. I made some PR's https://github.com/cketti/ckChangeLog/pulls to solve this.

In general, when I've to decide a inital empty log dialog or a more trustful app, I would choose a more trustful app

[hannesa2]

summarize: just git hash is worth to merge but it should not shown -sad-

I disagree, when you say it makes no sense to link git sha1 information automatically in the app

I try it again but with more changes

I made a branch with

• auto versionCode
• auto versionName
• auto url to last commit
• auto trigger public CI (Travis) on specific branch
• auto publish to GooglePlay Alpha on specific branch
• auto CI url in about

What you do on a local git doesn't concern us any more, (Why you need it ?) because build is triggerd from github only and build transparent with public CI

I see this as an huge advance in deterministic builds !

I currently made it work on my personal account with hidden keystore and hidden password. Probably someone will say, ok show us and then I read, "no, this not", "just only this", "makes no sense", "too much" ... just blocking me and I waste my time

I would love to make a PR for this repo and I need some support of github account holder to setup Travis, but for this I need a loud and clear "yes, we want this in all points" otherwise this my end of this story

[hannesa2]

It seams there is no interest to improve build chain and improve deterministic builds