Before Zcash launched, we were heavily relying on `zcutil/build.sh` to
apply our Zcash-specific hardening flags. The Gitian deterministic build
system obviously didn't use our script, so the corresponding flags were
manually added to `gitian-linux.yml`.
Since then, we have migrated all of our flags into `configure.ac`.
Manually setting them in the Gitian descriptor is no longer necessary,
and should have been removed at the same time. This didn't cause any
noticeable issues, however, leaving it undetected until we migrated to
Clang in zcash/zcash#4613, and performed a Gitian build for 4.1.0-rc1.
The Gitian failure was caused by linker flags specific to C++ being used
in configuration tests for secp256k1 (a C library). This causes ldd to
emit warnings, which are then converted to errors by the -Werror flags
that were added to CFLAGS and CXXFLAGS by `gitian-linux.yml`. CI did not
encounter this because it uses the standard `--enable-werror` config flag,
which adds `-Werror` to CXXFLAGS but not CFLAGS.
Co-authored-by: Jack Grigg <jack@z.cash>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Rename the FS_ZIP214_ECC funding stream to FS_ZIP214_BP
See also https://github.com/zcash/zips/pull/412 .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Improve reject reasons for unmet shielded requirements
These reject messages end up bubbling up to users via the RPC interface.
Distinguishing between the various failure cases will help users figure
out why their transaction is being rejected.
Closeszcash/zcash#3114.
Enabled ShellCheck rules:
SC1087
SC2001
SC2004
SC2005
SC2006
SC2016
SC2028
SC2048
SC2066 (note that IFS already contains only a line feed)
SC2116
SC2166
SC2181
SC2206
SC2207
SC2230
SC2236
Zcash: Only the changes that applied to the versions of the scripts we have.
Fix an error reporting bug in "Checksum missing or mismatched ..."
The sense of the test was accidentally inverted in my change to #4733. The message should be shown if any of the files exist but have an incorrect checksum. fixes#4813
No documentation needed.
Test plan: as for #4733, and also check that there are no false positive "Checksum missing or mismatched ..." warnings.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
The sense of the test was accidentally inverted in my change to #4733.
The message should be shown if any of the files exist but have an incorrect checksum.
We also now correctly handle the case where there are no package source files.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
These reject messages end up bubbling up to users via the RPC interface.
Distinguishing between the various failure cases will help users figure
out why their transaction is being rejected.
Uses operator* instead of std::optional::value because the latter was
introduced in macOS 10.14, and our current minimum is 10.12.
Closeszcash/zcash#3114.
depends download: fix a logging bug for multi-archive packages:
No documentation change needed.
The test plan appears below. Since this bug output should appear on all builds without a pre-existing source cache, then an easier test plan might be to verify the bug output is not present from an infrastructure build log that doesn't rely on cached sources.
# Bug Behavior
While initially fetching packages, I saw `sh: test:` error messages in the make output for only two packages. However, it appears all packages are correctly fetched.
See detailed output appendix for demonstration of the bug output and conditions compared to with this patch for the same conditions.
# Analysis
## Design Requirements
The intent of the `check_or_remove_sources` is to fetch sources if either existing archive hashes do not match or the archives aren't present.
Additionally, this should report hash mismatches and be quiet about missing files.
## Bug Source
The second design requirement goal has a bug for multi-archive packages which define `$(package)_extra_sources)` because `test -f $($(package)_all_sources)` passes more than one argument to `test -f` which is not supported. If sha256sum fails in any case for multi-archive packages, a `sh: test` error line is always printed.
Aside from this spurious output, this bug has no effect, I believe. Fortunately this bug does not bypass the hash check!
## Testing
I tested this patch manually by running the same three tests against the `v4.0.0` tag and then again repeating those same three steps with this patch. In all 6 cases I visually inspected the output.
1. Starting with a pre-downloaded source cash, run the `download` target.
2. Remove an archive from a multi-archive package, then rerun `download`.
3. Alter a hash to cause a hash mismatch condition, then rerun `download`.
I believe after each step both with and without this patch the resulting source cache should be identical (except for filesystem timestamps).
### Testing v4.0.0 without this patch
Notice in the second and third steps the same bug output:
```
/bin/sh: 1: test: rust-std-1.42.0-x86_64-apple-darwin.tar.gz: unexpected operator
```
While initially fetching packages, I saw `sh: test:` error messages in the make output for only two packages.
However, it appears all packages are correctly fetched.
I tested this patch manually by running these three tests against the `v4.0.0` tag and then with this patch.
In all 6 cases I visually inspected the output.
1. Starting with a pre-downloaded source cash, run the `download` target.
2. Remove an archive from a multi-archive package, then rerun `download`.
3. Alter a hash to cause a hash mismatch condition, then rerun `download`.
I believe after each step both with and without this patch the resulting source cache should be identical
(except for filesystem timestamps).
Co-authored-by: Nathan Wilcox <nathan@electriccoin.co>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>