Usually it's unset, but depends toolchain files set it explicitly
for cross-compiling. Don't override preset values. But make sure
it's set for all x86 / x86_64 builds, not just Linux.
Also make sure -std=c++11 is set for Darwin builds, not all
submodules were getting it consistently before.
Use shorter, prefix-unique directory names
gitian-builder -> builder
gitian-sigs -> sigs
monero-binaries -> out
Just use builder/inputs/monero, no need for 2nd repo clone
Resetting the timer after shutdown was initiated would keep
a reference to the object inside ASIO, which would keep the
connection alive until the timer timed out
The problem actually exists in two parts:
1. When sending chunks over a connection, if the queue size is
greater than N, the seed is predictable across every monero node.
>"If rand() is used before any calls to srand(), rand() behaves as if
it was seeded with srand(1). Each time rand() is seeded with the same seed, it
must produce the same sequence of values."
2. The CID speaks for itself: "'rand' should not be used for security-related
applications, because linear congruential algorithms are too easy to break."
*But* this is an area of contention.
One could argue that a CSPRNG is warranted in order to fully mitigate any
potential timing attacks based on crafting chunk responses. Others could argue
that the existing LCG, or even an MTG, would suffice (if properly seeded). As a
compromise, I've used an MTG with a full bit space. This should give a healthy
balance of security and speed without relying on the existing crypto library
(which I'm told might break on some systems since epee is not (shouldn't be)
dependent upon the existing crypto library).
bdcdb0e Remove unused code under WINDWOS_PLATFORM guard (tomsmeding)
a84aa04 syncobj.h no longer defines shared_guard, so remove those define's (tomsmeding)
The removed preprocessor macro's refer to types that are not defined in
the file anymore; the only other place where shared_guard is defined is
in winobj.h, which also defines the same macro's. Therefore, this change
is safe.
(Side note is that these macro's weren't used at all anyway, but that is
orthogonal to the issue.)
fcbf7b3 p2p: propagate out peers limit to payload handler (moneromooo-monero)
098aadf p2p: close the right number of connections on setting max in/out peers (moneromooo-monero)
new cli options (RPC ones also apply to wallet):
--p2p-bind-ipv6-address (default = "::")
--p2p-bind-port-ipv6 (default same as ipv4 port for given nettype)
--rpc-bind-ipv6-address (default = "::1")
--p2p-use-ipv6 (default false)
--rpc-use-ipv6 (default false)
--p2p-require-ipv4 (default true, if ipv4 bind fails and this is
true, will not continue even if ipv6 bind
successful)
--rpc-require-ipv4 (default true, description as above)
ipv6 addresses are to be specified as "[xx:xx:xx::xx:xx]:port" except
in the cases of the cli args for bind address. For those the square
braces can be omitted.
The tar archives generated by gitian are currently unversioned. This
adds either a tag name when building from a tag, or a short commit id
when building from a commit hash.
The macos binaries in release v0.14.1.0 were compiled with the buggy
hidapi-0.8.0-rc1 version. This resulted in users not being able to use
their Ledger with the latest cli wallet. After the patch depends now
fetches the source from the libusb hidapi repository that has taken over
maintenance of hidapi.
Before this commit the icu4c repo was fetched from TheCharlatan's
repository. This step was made, because up until recently the source
code was hosted on sourceforge and their downloads proved very
unreliable. The origin is now the official icu4c repository.
Also remove some commented lines left over from development.
This commits adds the `--no-apt` flag to the gitian-build.py script.
This allows gitian builds to be run without root access and non-debian
based operating systems.
To speedup the depends cached builds, remove some some clutter from the package
files. This mainly incldues removing all the shared libraries and .la
linker files. It also gives stronger guarantees that monero only links
the static libs without any external rvalues.
- This addresses https://www.openssl.org/news/secadv/20190226.txt (CVE: 2019-1559) which impacted all versions of openssl-1.0.
Note that this does not address CVE-2019-1543 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1543), which impacts all versions of openssl 1.1 through 1.1.0j and 1.1.1b.
The above (1.1) is patched in openssl, where it was marked as low severity. Similar issues possibly present in monero, should be looked into w.r.t. CVE-2019-1543.
