[Dev] Release candidate Feathercoin 0.9.6 checklist & final issues

Wellenreiter

@aciddude said in [Dev] Release candidate Feathercoin 0.9.6 checklist & final issues:

@wrapper said in [Dev] Release candidate Feathercoin 0.9.6 checklist & final issues:

Problem : Confirming the Windows and Mac builds (or others) are correct for the official release of Feathercoin software.

Whilst anyone can compile and release there own version, the official FTC version must also prevent potential harm to members and have evidence the release is secure.

Proposal : Binary build test

Once a build has been confirmed with the official release, the builder asks for confirmation.

A second person tries to reproduce the build : If binaries produced same : passes binary build test

If fails, differences in the set-ups can be discussed and set-up adjusted. : passes binary build test

If fails, can be confirmed by 3rd tester : pass

If fails, Use of the same virtual environment, discus results : pass

Do the Feathercoin Team have an official PGP Key ?

These links are interesting:
https://gitian.org/
https://www.reddit.com/r/Bitcoin/wiki/verifying_bitcoin_core
https://bitcointalk.org/index.php?topic=1588906.0
http://bitcoin.stackexchange.com/questions/50185/how-to-verify-bitcoin-core-release-signing-keys/50186

As ‘feathercoin’ is an artificial user, with a group of people behind it, the feathercoin user should not be used to sign code.

My opinion is, that every coder should use his own -github created?- signature to sign the code he modified.

A different story is the signature of the binaries. Linux PPA created by me are loaded from my repository that of course is signed.
We should sign the MAC and Windows binaries, too. My suggestion is to use the key of the user who compiled the code and created the binary/installation package

AcidD

@Wellenreiter

These links are interesting:
https://gitian.org/
https://www.reddit.com/r/Bitcoin/wiki/verifying_bitcoin_core
https://bitcointalk.org/index.php?topic=1588906.0
http://bitcoin.stackexchange.com/questions/50185/how-to-verify-bitcoin-core-release-signing-keys/50186

As ‘feathercoin’ is an artificial user, with a group of people behind it, the feathercoin user should not be used to sign code.

My opinion is, that every coder should use his own -github created?- signature to sign the code he modified.

A different story is the signature of the binaries. Linux PPA created by me are loaded from my repository that of course is signed.
We should sign the MAC and Windows binaries, too. My suggestion is to use the key of the user who compiled the code and created the binary/installation package

Yes I believe bitcoin does something similar, all the developers have their own keys for signing their own releases.

the actual binary signing needs to be signed with a cert that has a valid root CA (something from Comodo or Symantec etc) - this proves the authenticity of the code.

The main issue is you’re required to give a lot of details about your project when you try to buy a cert for code signing. You need to provide valid ID (passport, Drivers license etc), details on the project name, website link, etc.

I applied for/bought an OpenSource code signing cert, it was cheap because it’s supposed to be for OpenSource projects only. I bought it from http://certum.pl/certum/main.xml and paid 17 Euros.

They’ve now asked for verification, I’ve provided a copy of my passport and other identification documents.

I’ve sent them the Feathercoin.com url as well as the github page, I’ve explained that I contribute to the Git repo and I have my own personal fork as well, registered in my name with the same email address I used to register for the cert. I hope this is enough as proof. They did ask me to put my real name somewhere on the website for validation, I’ve explained because this is an OpenSource project, I’d only be able to post my name in the forums or on my personal fork of the Feathercoin repo.

Waiting to hear back from them now.

AcidD

http://certum.pl/certum/main.xml got back to me.

The OpenSource certificate can only be applied to a person. So it would have my name in it and nothing to do with Feathercoin…hence why it’s soo cheap. it’s for really really personal projects.

This is what needs to be bought:
https://cheapsslsecurity.co.uk/comodo/codesigningcertificate.html

If Feathercoin-Qt is not code signed, on MacOS you’ll get the following warning:
alt text

Not good. To run unsigned software they need to go into Mac OS X Preferences>Security & Privacy>General and change Allow applications downloaded from Mac App store and identified developers to Anywhere:

on Windows you’d see something similar
alt text

AmDD

@aciddude said in [Dev] Release candidate Feathercoin 0.9.6 checklist & final issues:

http://certum.pl/certum/main.xml got back to me.

The OpenSource certificate can only be applied to a person. So it would have my name in it and nothing to do with Feathercoin…hence why it’s soo cheap. it’s for really really personal projects.

This is what needs to be bought:
https://cheapsslsecurity.co.uk/comodo/codesigningcertificate.html

If Feathercoin-Qt is not code signed, on MacOS you’ll get the following warning:

Not good. To run unsigned software they need to go into Mac OS X Preferences>Security & Privacy>General and change Allow applications downloaded from Mac App store and identified developers to Anywhere:

on Windows you’d see something similar

Since Im no dev and dont really contribute much here - I can at least throw in some coin to buy this cert. Let me know if we go this direction.

wrapper

Thanks and kudos to @Aciddude who I know has done quite a bit of work on this code signing issue.

@Aciddude, let us know what you think the options are and if you cut the binaries, how much a “proper” certificate is.

As the person that has done a huge amount to help get all the builds working, and have the VBs set-up , you should get first choice to do the (Mac and Windows) builds. Plus the Ubuntu build, if we can’t transfer the OpenSuse build service Ubuntu binaries.

The other choice (as far as buying them a code certificate) would be look into the Github based certificate that @Wellenreiter can use, as he’s now took responsibility for controlling the Feathercoin Github. Just in case that is better way to do it.

Also, could we also use that to other builds or scripts, e.g. Arch, BSD, Android?

Wellenreiter

For the Github code, I think, we don’t really need a official certificate, if we can apply a PGP key and use that to sign the code.

All the certificate stuff is about building trust, and that also can be archived through BGP and even through the forum here, If we show the fingerprints of your keys somewhere on the forum, maybe in our trailers, that are appended to the posts

Wellenreiter

I have one other task, that I would like to give to someone else:

check/update Linux manpages for feathercoind, feathercoin-qt and feathercoin-cli
- check, that no occurrences of ‘Bitcoin’ are in the man pages
- check overall usability of the man pages
- the page for feathercoin-cli needs to be created. That can be done by copying the content from feathercoind man page and modify it to mention feathercoin-cli

The man page files are on Github here

AcidD

~~I’ll sort out those man pages and do a pull request when I’m done.~~

@Wellenreiter PR sent -
https://github.com/FeatherCoin/Feathercoin/pull/153

wrapper

@Wellenreiter - These issues from Github can be signed off / completed. Mostly due to patches AFB and I did in 0.9.3.2./ 0.9.6 and Lizhi pulled in, to improve the user interface design and consistency.

Wallet main screen UI design / issue - Status Icons covered by frames
https://github.com/FeatherCoin/Feathercoin/issues/103
Interface work

The layout of the form for advanced feature : OpenNames
https://github.com/FeatherCoin/Feathercoin/issues/102
Interface work

Test fail --Transaction right click - Dropdown Bitmessage - Fails to operate
https://github.com/FeatherCoin/Feathercoin/issues/120
Documentation work

Test fail–Transaction right click - Dropdown Ubuntu 16.04
https://github.com/FeatherCoin/Feathercoin/issues/119
Sign off : Not Fixed in 0.9.6 : Raise issue to test Show Transaction Total is correct in 0.11 or further versions.

Test results - Create Stealth Address from the Button Receive Grid
https://github.com/FeatherCoin/Feathercoin/issues/121
Not being done - sign off

wrapper

travis.yml and automatic testing for FTC 0.9.6.

@Aciddude is looking into automatic testing. These are some notes, FTC possible ways forward / Bitcoin Litecoin status.

Bitcoin implemented / has a travis test file in version 0.10. Similar with Litecoin.

FTC is forked from Bitcoin, so it is proposed Bitcoin travis.yml be backported form Bitcoin 0.10 and tested for FTC compatibility / required changes to have 0.9.6 auto tested.

Notes:

Litcoin have made some slight modifications / fixes, so their version is worth studying.
There are later versions of the Bitcoin travis.yml in 0.11, 0.12 and 0.13

Bitcoin 0.10 travis.yml test file :
https://github.com/bitcoin/bitcoin/blob/0.10/.travis.yml

Litecoin 0.10 travis.yml
https://github.com/litecoin-project/litecoin/blob/0.10/.travis.yml

Latest Bitcoin travis.yml
https://github.com/bitcoin/bitcoin/blob/master/.travis.yml

Wellenreiter

I would like to release 0.9.6 this week, so I suggest to freeze the 0.9.6 code and only improve the man pages and release notes.
We can either bring the new test capabilities in a version 0.9.7 or better implement them in 0.11.x
For 0.9.6 we can live with the manual testing

wrapper

Ok, I agree. FTC is ready to release. We’ve got a lot of further refinement we can quickly apply to 0.11. 0.9.6 is a significant update to 0.9.1.

I think it is expedient to create FTC 0.9.7-dev ,

Reason for 0.9.7-dev:

Copy / branch of code : Just prior to final release changes. Prevent / identify “rougue releases”
We may need to fix a bug (unlikely), but also can get travis working (nearly there), ready to accept and test any issues or further improvements to test.
Known testing ground for comparison with 0.11 in further developments
Gives FTC the possible to release “wallet fix versions” (i.e. new functionality review, possible remove shapeshift , etc) - that can be done with no fork issues.

Backport Branch

Suggestions for Development plan for 0.9.x branch

Feathercoin 0.9.7-dev
Implement Unit Test
Implement Auto build service
Collect issues From 0.9.6 release
Test fixes to issues
Move issue to Feathercoin 0.11-dev
Collect issues and release 0.9.8

AcidD

@wrapper @Wellenreiter - Agreed, +1 !

There’s quite a few files that would need to be pulled in for Travis-CI to work correctly. I’d like to spend time understanding these files instead of blindly pulling in from Bitcoin or Litecoin.

an easy example of what’s definitely going to break is zxing - so even if we got the build scripts for travis CI working, they wouldn’t include QR codes until we put in the necessary script/procedure for zxing.

pushing Travis-CI stuff to a later version of Feathercoin sounds like the right idea :)

AcidD

@wrapper said in [Dev] Release candidate Feathercoin 0.9.6 checklist & final issues:

Ok, I agree. FTC is ready to release. We’ve got a lot of further refinement we can quickly apply to 0.11. 0.9.6 is a significant update to 0.9.1.

I think it is expedient to create FTC 0.9.7-dev ,

Reason for 0.9.7-dev:

Copy / branch of code : Just prior to final release changes. Prevent / identify “rougue releases”

We may need to fix a bug (unlikely), but also can get travis working (nearly there), ready to accept and test any issues or further improvements to test.

Known testing ground for comparison with 0.11 in further developments

Gives FTC the possible to release “wallet fix versions” (i.e. new functionality review, possible remove shapeshift , etc) - that can be done with no fork issues.

Backport Branch

Sugestions for Development plan for 0.9.x branch

Feathercoin 0.9.7-dev
Implement Unit Test
Implement Auto build service
Collect issues From 0.9.6 release
Test fixes to issues
Move issue to Feathercoin 0.11-dev
Collect issues and release 0.9.8

This is a good idea.

Maybe create a post in the Admin/team area for now, just so that the version numbers dont confuse forum members. Once 0.9.6 is fully released as “production” - you could move the 0.9.7-dev topic to the public forums for discussion/in-put from the general feather public :-)

wrapper

@Aciddude I agree with your comments.

The probability is we will move all development to 0.11 and just the stub (0.9.7-dev), without the “release specific changes” will remain.

Hopefully most issues can be fixed in 0.11.

We can get a feel for how quickly 0.11 can be audited for release, will depend on the number of changes to bring across etc. Obviously, the quicker we can do that the less likely further developments in 0.9.x …