a7eeda5d3f
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ## Issue being fixed or feature implemented Implement a new code-singing certificate for windows. Previously we used a certificate issued by DigiCert, however that certificate recently expired. A renewed certificate would cost roughly $200/year at the cheapest CAs and $370/year with DigiCert. EV certificates are relatively novel types of certificates that start out with positive reputation, reducing smart screen popups for users. EV certificates start at $270/year. As a result we had (/have) 4 options: 1. Get a new code signing certificate from a trusted CA - - Pro: Certificate gains reputation over time in smart screen and binaries are signed - - Pro: Shows "Verified Publisher" and "Dash Core Group Inc" on install - - Con: Costs, feels manipulative to pay at least $600 simply for someone to sign a certificate 2. Get a new EV code signing certificate - - Pro: Certificate starts with good reputation and gains reputation over time - - Con: Even greater costs for a signature that says that we are from Dash Core Group 3. Continue signing with the expired certificate - - Con: This is, it has been discovered, a terrible idea and these binaries are treated worse than unsigned binaries 4. Deliver unsigned windows binaries - - Pro: Binary will gain reputation over time as users download it - - Pro: Easy, is what it says on the tin - - Con: Binaries are completely unsigned, could be tampering or corruption issues that go undetected - - Con: Will visibly state "Unknown Publisher" 5. Deliver self-signed windows binaries - - Pro: Binary will gain reputation over time as users download it - - Pro: *Possibility* that certificate will gain reputation over time as users download binaries signed by it. It may also be that only certificates issued by a CA will gain reputation over time. - - Pro: Binaries are still signed - - Pro: Users have the option to import certificate into keychain to remove "Unknown Publisher" - - Pro: In limited testing, install is sometimes is treated better than unsigned, otherwise is treated the same - - Con: may appear sketchy, as Root CA is not a trusted Root CA - - Con: will display "Unknown Publisher" to most users - - Con: greater potential uncertainty around future changes to treatment of self signing systems Based on the above discussion and testing, the best route currently is option 5; that is what this PR implements. In the future it may make sense to move towards a codesigning certificate issued by a trusted CA. The root certificate authority has the following information  with a sha256 fingerprint of `46 84 FF 27 11 D7 C8 C5 BB FA D1 55 41 B3 F0 43 77 97 AC 67 4C 32 19 AE B4 E7 15 11 1F BB 42 A0` The code signing certificate is issued by the root CA, has a common name of "Dash Core Windows Signing" and a sha256 fingerprint of `1A 09 54 6E D3 81 E9 FC AD 62 44 32 35 40 39 FF 5F A7 30 0E 5E 03 C4 E0 96 5A 62 AA 19 2B 79 EE`. This certificate is only authorized for the purpose of code signing. ## What was done? ## How Has This Been Tested? Multiple users installing binaries of type 1,3,4 and 5. ## Breaking Changes This new windows signing certificate should be documented in the release notes. ## Checklist: _Go over all the following points, and put an `x` in all the boxes that apply._ - - [x] I have performed a self-review of my own code - - [ ] I have commented my code, particularly in hard-to-understand areas - - [ ] I have added or updated relevant unit/integration/functional/e2e tests - - [ ] I have made corresponding changes to the documentation - - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKVkDYuyHioH9PCArUlJ77avoeYQFAmWfAbUACgkQUlJ77avo eYTSCBAAuDEoWABdonIMs/4RaYP+DGTULltRu9CHBAqYuksXrl/4iV0r17DPSWWW L/5vLNAUTI47Tsa7R45ZPb0hR8VPMBkvxTQipKBYK7vZpwefcR4VOprEBJJ0Bl3g ZHtAVjZbcANEIAW3SlaiOgWbxWGKfDyM7gN3aNfoidMFBefbcYKEttuAGCnktWRI Y3eLMGPCpxOVB0O1nLU+pzwixAWXOeVChiK31ecFfQrF3JmUc12yiFUI+OJTogg4 0G2GMIQYHiVwclj8hSWT/yZfjcyxXdLYqkmH4Nr5mye39hRI2aUQEkmkYOy8pjcB ykKLg8JpUg/zg6GSuS6mFJnd5NHq5iSBxSRHPfR8xij1xFpmdgAaNCw4/6j9PEXB l8cfuJ7hgX3yX09L4p2E4t7MYpM8igaenAIWAK37hmKs1WADBmaj/nf6ThKhjvzI 2GR0FOzm6Is36KYvdUQJDE0g70g31SvGy+qjlcK49MtX6BvecYt+dg8AaNZ5FIn7 d1kFI4NXM6JX2WdiHMenz5d+oFYRS/P1sXjQ1wtl9HSkiZQQkEBbgiWXfh+EXjpW fNc8cej2LLCNZlhVcpffF8UaINsMTZVQsEGWGInjSi5eCs/YNrqL8XDdC/8mmZCu cNvp0QBtQ+4lpbUSdhFUdgic0MRCsdeHuYIBfvPJN9tl8McbknA= =kL6E -----END PGP SIGNATURE----- |
||
|---|---|---|
| .github | ||
| .tx | ||
| build-aux/m4 | ||
| ci | ||
| contrib | ||
| depends | ||
| doc | ||
| share | ||
| src | ||
| test | ||
| .cirrus.yml | ||
| .dockerignore | ||
| .editorconfig | ||
| .fuzzbuzz.yml | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .python-version | ||
| .style.yapf | ||
| .travis.yml | ||
| autogen.sh | ||
| CMakeLists.txt | ||
| configure.ac | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| INSTALL.md | ||
| libdashconsensus.pc.in | ||
| Makefile.am | ||
| README.md | ||
| SECURITY.md | ||
Dash Core staging tree
| CI | master | develop |
|---|---|---|
| Gitlab |  |
 |
For an immediately usable, binary version of the Dash Core software, see https://www.dash.org/downloads/.
Further information about Dash Core is available in the doc folder.
What is Dash?
Dash is an experimental digital currency that enables instant, private payments to anyone, anywhere in the world. Dash uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Dash Core is the name of the open source software which enables the use of this currency.
For more information read the original Dash whitepaper.
License
Dash Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.
Development Process
The master branch is meant to be stable. Development is normally done in separate branches.
Tags are created to indicate new official,
stable release versions of Dash Core.
The develop branch is regularly built (see doc/build-*.md for instructions) and tested, but is not guaranteed to be
completely stable.
The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.
Testing
Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.
Automated Testing
Developers are strongly encouraged to write unit tests for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled in configure) with: make check. Further details on running
and extending unit tests can be found in /src/test/README.md.
There are also regression and integration tests, written
in Python.
These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py
The Travis CI system makes sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.
Manual Quality Assurance (QA) Testing
Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.
Translations
Changes to translations as well as new translations can be submitted to Dash Core's Transifex page.
Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.
Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.