done automatically.
At some point along the line, fully offline builds were no longer happening
when strictly following the release-process.md instructions.
We should ensure that users who might want to torify or build offline need
to take extra steps to remain offline.
Also, corrections to build process: including gverify examples for new builders.
This is an ideal version of what the release process should look like,
making it more consistent with the OS X process. Some of the changes
described here would need to be made in the descriptors, which is somewhat
beyond what I would feel comfortable doing, not really understanding the signature process in depth.
[skip ci]
Rather than fetching a signature.tar.gz from somewhere on the net, instruct
Gitian to use a signature from a tag in the bitcoin-detached-sigs repository
which corresponds to the tag of the release being built.
This changes detached-sig-apply.sh to take a dirname rather than a tarball as
an argument, though detached-sig-create.sh still outputs a tarball for
convenience.
To give the torrents (which use web seeds) better names, we updated the
URL scheme on bitcoin.org/bin. This updates the release notes and
release doc accordingly, plus updates some other details based on recent
changes to the site.
[skip ci]
- Split linux32/linux64 releases
- Split win32/win64 zips
- Post-processing should no longer be required. The deterministic outputs are
ready for consumption.
This is PR #4271, but with the changes to the descriptors, both the names of the
files and the names of the intermediate build artifact archives, removed.
This also closes#3775 if it goes in, because it covers the changes in
that PR.
Make the instdate for lrelease etc deterministic. This should have been
part of 0.9.2. Luckily this doesn't affect the end product, it is just
a bit annoying.
Rebased-From: 386e732
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Upgrade for https://www.openssl.org/news/secadv_20140605.txt
Just in case - there is no vulnerability that affects ecdsa signing or
verification.
The MITM attack vulnerability (CVE-2014-0224) may have some effect on
our usage of SSL/TLS.
As long as payment requests are signed (which is the common case), usage
of the payment protocol should also not be affected.
The TLS usage in RPC may be at risk for MITM attacks. If you have
`-rpcssl` enabled, be sure to update OpenSSL as soon as possible.
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Rebased-From: 6e7c4d1
Upgrade for https://www.openssl.org/news/secadv_20140605.txt
Just in case - there is no vulnerability that affects ecdsa signing or
verification.
The MITM attack vulnerability (CVE-2014-0224) may have some effect on
our usage of SSL/TLS.
As long as payment requests are signed (which is the common case), usage
of the payment protocol should also not be affected.
The TLS usage in RPC may be at risk for MITM attacks. If you have
`-rpcssl` enabled, be sure to update OpenSSL as soon as possible.
