-----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-----
aaaaad6ac95b402fe18d019d67897ced6b316ee0 scripted-diff: Bump copyright of files changed in 2019 (MarcoFalke)
Pull request description:
ACKs for top commit:
practicalswift:
ACK aaaaad6ac95b402fe18d019d67897ced6b316ee0
promag:
ACK aaaaad6ac95b402fe18d019d67897ced6b316ee0 🎉
fanquake:
ACK aaaaad6ac95b402fe18d019d67897ced6b316ee0 - going to merge this now because the year is over and conflicts are minimal.
Tree-SHA512: 58cb1f53bc4c1395b2766f36fabc7e2332e213780a802762fff0afd59468dad0c3265f553714d761c7a2c44ff90f7dc250f04458f4b2eb8eef8b94f8c9891321
ee883201cf134952284632e9e9ae72bf1c8c792f guix: repro: Sort find output in libtool for gcc-8 (Carl Dong)
ee0a67c32a8861eab650bf8894af06807578eba0 codesigning: Use SHA256 as digest for osslsigncode (Windows) (Carl Dong)
38eb91eb0616ed6dbe34c23e11588d130fef07f8 guix: Add codesigning functionality (Carl Dong)
bac2690e6f683fcedb883fe1d32f3c33c628a141 guix: Package codesigning tools (Carl Dong)
0a2176d47767972e4cd5ed302c1dbeedece1708b guix: Reindent existing manifest.scm (Carl Dong)
c090a3e9238ba2df07875b4708e908d8dca4ed9b Makefile.am: use APP_DIST_DIR instead of hard-coding dist (Carl Dong)
Pull request description:
This is the last PR before we reach feature-parity with the Gitian process!
Note: I tried using the `Makefile` inside the distsrc to make the dmg instead of manually listing out the commands, but `make` seems to want to re-make a lot of other files which broke the dmg.
The workflow looks something like this:
1. `env [ FOO=bar... ] ./contrib/guix/guix-build` (add additional env vars as necessary)
2. Codesigners only:
1. Copy `guix-build-<short-id>/output/x86_64-apple-darwin18/bitcoin-<short-id>-osx-unsigned.tar.gz` and `guix-build-<short-id>/output/x86_64-w64-mingw32/bitcoin-<short-id>-win-unsigned.tar.gz` to signing computer
2. Codesign with `./detached-sig-create.sh` inside the tarball
3. Upload contents of `signature-{osx,win}.tar.gz` to https://github.com/bitcoin-core/bitcoin-detached-sigs (as a new tag)
3. Checkout new tag for `bitcoin-core/bitcoin-detached-sigs` with the detached signatures
4. `env [ FOO=bar... ] DETACHED_SIGS_REPO=<path/to/bitcoin-detached-sigs> ./contrib/guix/guix-codesign` (modify env vars as necessary)
5. Make sure `guix.sigs` is cloned and updated
6. `env GUIX_SIGS_REPO=<path/to/guix.sigs> SIGNER=0x96AB007F1A7ED999=dongcarl ./contrib/guix/guix-attest` (modify env vars as necessary)
7. Commit your new signatures and SHA256SUMS in `guix.sigs`
8. Optionally, after there are multiple signatures in `guix.sigs`: `env GUIX_SIGS_REPO=<path/to/guix.sigs> ./contrib/guix/guix-verify`
ACKs for top commit:
laanwj:
Tested ACK ee883201cf134952284632e9e9ae72bf1c8c792f
achow101:
ACK ee883201cf134952284632e9e9ae72bf1c8c792f
Tree-SHA512: e812a07a5f19f900600c70cb9c717769ef544a6c0c12760b5558b76b6b37df863257f3dbf38b0757e6e06e334470267e94c9f2bdbc27409d6837b1a0bfc6acbc
1ac454a3844b9b8389de0f660fa9455c0efa7140 Enable ShellCheck rules (Hennadii Stepanov)
Pull request description:
Enable some simple ShellCheck rules.
Note for reviewers: `bash` and `shellcheck` on macOS are different from ones on Ubuntu.
For local tests the latest `shellcheck` version 0.6.0 should be used (see #15166).
ACKs for top commit:
practicalswift:
utACK 1ac454a3844b9b8389de0f660fa9455c0efa7140
dongcarl:
utACK 1ac454a
fanquake:
ACK 1ac454a3844b9b8389de0f660fa9455c0efa7140
Tree-SHA512: 8d0a3a5c09fe1a0c22120178f5e6b80f81f746f8c3356b7701ff301c117acb2edea8fe08f08fb54ed73f94b1617515fb239fa28e7ab4121f74872e6494b6f20e
* update public part of windows code signing certificate
Signed-off-by: pasta <pasta@dashboost.org>
* Fixing line-breaks
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
47776a958b08382d76d69b5df7beed807af168b3 Add linter: Make sure all shell scripts opt out of locale dependence using "export LC_ALL=C" (practicalswift)
3352da8da1243c03fc83ba678d2f5d193bd5a0c2 Add "export LC_ALL=C" to all shell scripts (practicalswift)
Pull request description:
~~Make sure `LC_ALL=C` is set when using `grep` range expressions.~~
Make sure `LC_ALL=C` is set in all shell scripts.
From the `grep(1)` documentation:
> Within a bracket expression, a range expression consists of two characters separated by a hyphen. It matches any single character that sorts between the two characters, inclusive, using the locale's collating sequence and character set. For example, in the default C locale, `[a-d]` is equivalent to `[abcd]`. Many locales sort characters in dictionary order, and in these locales `[a-d]` is typically not equivalent to `[abcd]`; it might be equivalent to `[aBbCcDd]`, for example. To obtain the traditional interpretation of bracket expressions, you can use the C locale by setting the `LC_ALL` environment variable to the value C.
Context: [Locale issue found when reviewing #13450](https://github.com/bitcoin/bitcoin/pull/13450/files#r194877736)
Tree-SHA512: fd74d2612998f9b49ef9be24410e505d8c842716f84d085157fc7f9799d40e8a7b4969de783afcf99b7fae4f91bbb4559651f7dd6578a6a081a50bdea29f0909
09fe2d9 release: update docs to show basic codesigning procedure (Cory Fields)
f642753 release: create a bundle for the new signing script (Cory Fields)
0068361 release: add win detached sig creator and our cert chain (Cory Fields)
Tree-SHA512: 032ad84697c70faaf857b9187f548282722cffca95d658e36413dc048ff02d9183253373254ffcc1158afb71140753f35abfc9fc8781ea5329c04d13c98759c0
