Only build fuzz tests in a fuzz build, and don't build other tests.
Keeps fuzz compilers from instrumenting other tests, which are not fuzzed.
Resolves#7232
Both drop_connection and add_host_fail can drop the connection,
which invalidates the context, and thus the address it contains.
Thanks to wfaressuissia[m] for lots of help and prodding when
debugging this
- rolling_median: tried to free uninitialized pointer in a constructor
- net_node.inl: erase-remove idiom was used incorrectly. remove_if doesn't actually remove elements, see http://cpp.sh/6fcjv
- bulletproofs.cc: call to sizeof() instead of vector.size(), luckily it only impacts performance and not code logic there
These are functions that check whether a tx is in the db, so whether
it is there or not is really not interesting, and it seems to scare
people from time to time
do not include blocked hosts in peer lists or public node lists by default,
warn about no https on clearnet and about untrusted peers likely being spies
If enabled, pulls IPs to block on blocklist.moneropulse.*, and
blocks then for 8 days (so IPs dropping from the list will
eventually get unblocked, and DNS failures don't result in
instant clearing of the blocklist).
Enable with --enable-dns-blocklist
Add monero_add_minimal_executable and use in tests
This is done in order not to have to relink targets, when just an .so changed, but not its interface.
Tests running after being compiled with `make debug-test` failed with
```
[ FAILED ] block_reward_and_current_block_weight.fails_on_huge_median_size
[ FAILED ] block_reward_and_current_block_weight.fails_on_huge_block_weight
```
With the introduction of the patch in
be82c40703 (diff-1a57d4e6013984c420da98d1adde0eafL113)
the assertions checking the weight of the median and current block
against a size limit were removed. Since the limit is now enforced by a
long divisor and a uint64_t type, checking in a separate test makes
little sense, so they are removed here.
When given a wrong argument, some daemon commands failed with "unknown
command" error, instead of a meaningful error message. This patch
brings consistency into the error messages.
In several places, this patch removes relatively useful messages,
and replaces them with more generic ones. E.g.,
- std::cout << "use: print_pl [white] [gray] [<limit>] [pruned]
[publicrpc]" << std::endl;
+ std::cout << "Invalid syntax: Too many parameters. For more
details, use the help command." << std::endl;
There are two reasons for this:
1. Consistency.
2. Removing duplicates.
The detailed information about the parameters is present in
the help messages already. Having it in two places increases
the risk that the messages would get out of date.
A 20% fluff probability increases the precision of a spy connected to
every node by 10% on average, compared to a network using 0% fluff
probability. The current value (10% fluff) should increase precision by
~5% compared to baseline.
This decreases the expected stem length from 10 to 5. The embargo
timeout was therefore lowered to 39s; the fifth node in a stem is
expected to have a 90% chance of being the first to timeout, which is
the same probability we currently have with an expected stem length of
10 nodes.
IPv6 addresses include a range that can map IPv4 addresses,
which allowed those mapped addresses to bypass filtering.
This filter should be replaced by AS filtering at some point.
d20ff4f64 functional_tests: add a large (many randomx epochs) p2p reorg test (moneromooo-monero)
6a0b3b1f8 functional_tests: add randomx tests (moneromooo-monero)
9d42649d5 core: fix mining from a block that's not the current top (moneromooo-monero)
975ae22 Fix send scalar z in plaintext (grydz)
333ae55 Update minimal Ledger Monero app version (grydz)
0a3c5a6 Update protocol version with Ledger's HW (grydz)
fa06c39 Bind signature to full address and signing mode (SarangNoether)
743608e wallet: allow signing a message with spend or view key (moneromooo-monero)
85899230d simplewallet: allow setting tx keys when sending to a subaddress (moneromooo-monero)
e916201f1 wallet2: fix setting tx keys when another is already set (moneromooo-monero)
This reduces the attack surface for data that can come from
malicious sources (exported output and key images, multisig
transactions...) since the monero serialization is already
exposed to the outside, and the boost lib we were using had
a few known crashers.
For interoperability, a new load-deprecated-formats wallet
setting is added (off by default). This allows loading boost
format data if there is no alternative. It will likely go
at some point, along with the ability to load those.
Notably, the peer lists file still uses the boost serialization
code, as the data it stores is define in epee, while the new
serialization code is in monero, and migrating it was fairly
hairy. Since this file is local and not obtained from anyone
else, the marginal risk is minimal, but it could be migrated
later if needed.
Some tests and tools also do, this will stay as is for now.
6bfcd3101 Updates InProofV1, OutProofV1, and ReserveProofV1 to new V2 variants that include all public proof parameters in Schnorr challenges, along with hash function domain separators. Includes new randomized unit tests. (Sarang Noether)
There are a few Borromean proofs txes in the v8 era, and these
aren't supported by get_pruned_transaction_weight. Moreover, only
only the most recent variant of bulletproofs is currently supported.
The sort predicate is a boolean ordered-before value, but these are
returning the memcmp value directly, and thus returns true whenever the
pubkeys aren't equal. This means:
- it isn't actually sorting.
- it can (and does) segfault for some inputs.
The cache is discarded when a block is popped, but then gets
rebuilt when the difficulty for next block is requested.
While this is all properly locked, it does not take into account
the delay caused by a database transaction being only committed
(and thus its effects made visible to other threads) later on,
which means another thread could request difficulty between
the pop and the commit, which would end up using stale database
view to build the cache, but that cache would not be invalidated
again when the transaction gets committed, which would cause the
cache to not match the new database data.
To fix this, we now keep track of when the cache is invalidated
so we can invalidate it again upon database transaction commit
to ensure it gets calculated again with fresh data next time it
is nedeed.
bde7f1c fuzz_tests: fix init check in oss-fuzz mode (moneromooo-monero)
c4b7420 Do not use PIE with OSS-Fuzz (moneromooo-monero)
c4df8b1 fix leaks in fuzz tests (moneromooo-monero)
38ca1bb fuzz_tests: add a tx extra fuzz test (moneromooo-monero)
On startup, it checks against the difficulty checkpoints, and if any mismatch is found, recalculates all the blocks with wrong difficulties. Additionally, once a week it recalculates difficulties of blocks after the last difficulty checkpoint.
bb5c5df cryptonote_protocol: reject requests/notifications before handshake (moneromooo-monero)
f1d0457 cryptonote_protocol: stricter limit to number of objects requested (moneromooo-monero)
The Bug:
1. Construct `byte_slice.portion_` with `epee::span(buffer)` which copies a pointer to the SSO buffer to `byte_slice.portion_`
2. It constructs `byte_slice.storage_` with `std::move(buffer)` (normally this swap pointers, but SSO means a memcpy and clear on the original SSO buffer)
3. `slice.data()` returns a pointer from `slice.portion_` that points to the original SSO cleared buffer, `slice.storage_` has the actual string.
This can now happen if:
- we have a pruned db
- we have not connected to the monero network for a while
- we connect to a node
- that node asks us for history
- we only have a pruned version of the most recent common block
In that case, it's better to not reply but keep the connection alive,
so we can sync off it.
Some tools report the alignment check as UB, which seems a bit
dubious, but since the performance difference between the two
versions is minimal, I'll go with the safe version
The default monero.conf file depends on the existence of the folders `/var/log/monero/` and `/var/lib/monero/`.
This change makes sure systemd will create them, together with the proper permissions, if they don't exist.
`StateDirectory` can be considered an extra safety in case the user `monero` happens to have been created with specifying `/var/lib/monero/` as a home folder but without actually creating it.
- choice where to enter passphrase is now made on the host
- use wipeable string in the comm stack
- wipe passphrase memory
- protocol optimizations, prepare for new firmware version
- minor fixes and improvements
- tests fixes, HF12 support
An automatic tx variable is initialized properly on the first
run through the loop, but not the second. Moving the variable
inside the loop ensures the ctor is called again to init it.
7326b69 functional_tests: ensure signatures never reuse a timestamp (moneromooo-monero)
082dd2c functional_tests: ensure signed timestamps are fresh (moneromooo-monero)
- Add abstract_http_client.h which http_client.h extends.
- Replace simple_http_client with abstract_http_client in wallet2,
message_store, message_transporter, and node_rpc_proxy.
- Import and export wallet data in wallet2.
- Use #if defined __EMSCRIPTEN__ directives to skip incompatible code.
Expects an account number, then the usual sweep_all options
Useful to move monero that was accidentally sent to a subaddress
with a very large account index.
81c5943 Remove temporary std::string creation in some hex->bin calls (vtnerd)
5fcc23a Move hex->bin conversion to monero copyright files and with less includes (vtnerd)
3387f0e Reduce template bloat in hex->bin for ZMQ json (vtnerd)
When a handshake fails, it can fail due to timeout or destroyed
connection, in which case the connection will be, or already is,
closed, and we don't want to do it twice.
Additionally, when closing a connection directly from the top
level code, ensure the connection is gone from the m_connects
list so it won't be used again.
AFAICT this is now clean in netstat, /proc/PID/fd and print_cn.
This fixes a noisy (but harmless) exception.
760ecf2 console_handler: do not let exception past the dor (moneromooo-monero)
09c8111 threadpool: lock mutex in create (moneromooo-monero)
e377977 tx_pool: catch theoretical error in get_block_reward (moneromooo-monero)
The warning about spending more than one output with similar creation
time was skipped if print-ring-members was not set, and it defaults to
false, which means most people probably aren't getting this warning if
they spend correlated outputs.
Reported by SeventhAlpaca.
0349347e ringdb: use a different iv for key and data in rings table (moneromooo-monero)
7b882087 simplewallet: reword mixin in user message in terms of ring size (moneromooo-monero)
f507a43a wallet2: do not remove known rings when a tx fails (moneromooo-monero)
- New flag in NOTIFY_NEW_TRANSACTION to indicate stem mode
- Stem loops detected in tx_pool.cpp
- Embargo timeout for a blackhole attack during stem phase
A newly synced Alice sends a (typically quite small) list of
txids in the local tpxool to a random peer Bob, who then uses
the existing tx relay system to send Alice any tx in his txpool
which is not in the list Alice sent
5.7.1 was removed from official qt.io archive, this is one of the few mirrors remaining that keep a copy.
I think it would be better if @TheCharlatan updated to a newer version soon than merging this PR
This allows RPC coming from the loopback interface to not have
to pay for service. This makes it possible to run an externally
accessible RPC server for payment while also having a local RPC
server that can be run unrestricted and payment free.
4771a7ae p2p: remove obsolete local time in handshake (moneromooo-monero)
2fbbc4a2 p2p: avoid sending the same peer list over and over (moneromooo-monero)
3004835b epee: remove backward compatible endian specific address serialization (moneromooo-monero)
39a343d7 p2p: remove backward compatible peer list (moneromooo-monero)
60631802 p2p: simplify last_seen serialization now we have optional stores (moneromooo-monero)
9467b2e4 cryptonote_protocol: omit top 64 bits of difficulty when 0 (moneromooo-monero)
b595583f serialization: do not write optional fields with default value (moneromooo-monero)
5f98b46d p2p: remove obsolete local time from TIMED_SYNC (moneromooo-monero)
If a db resize happened, the txpool meta cursor might be stale,
and was not being renewed when necessary.
It would cause this SEGSEGV:
in mdb_cursor_set ()
in mdb_cursor_get ()
in cryptonote::BlockchainLMDB::get_txpool_tx_blob(crypto::hash const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, cryptonote::relay_category) const ()
in cryptonote::tx_memory_pool::get_transaction(crypto::hash const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, cryptonote::relay_category) const ()
in cryptonote::t_cryptonote_protocol_handler<cryptonote::core>::handle_notify_new_fluffy_block(int, epee::misc_utils::struct_init<cryptonote::NOTIFY_NEW_FLUFFY_BLOCK::request_t>&, cryptonote::cryptonote_connection_context&) ()
During the handshake for an incoming connection, the peer id is checked against the local node's peer id only for the specific zone of the incoming peer, in order to avoid linking public addresses to tor addresses:
5d7ae2d279/src/p2p/net_node.inl (L2343)
However, on handshakes for outgoing connections, all zones are checked:
5d7ae2d279/src/p2p/net_node.inl (L1064)
If an attacker wanted to link a specific tor node to a public node, they could potentially connect to as many public nodes as possible, get themselves added to the peer whitelist, maybe stuff some more attacker-owned addresses into the greylist, then disconnect, and for any future incoming connections, respond with the tor node's id in an attempt to link the public/tor addresses.
- Finding handling function in ZMQ JSON-RPC now uses binary search
- Temporary `std::vector`s in JSON output now use `epee::span` to
prevent allocations.
- Binary -> hex in JSON output no longer allocates temporary buffer
- C++ structs -> JSON skips intermediate DOM creation, and instead
write directly to an output stream.
88b82bef simplewallet: point to "set help" in the lock screen message (moneromooo-monero)
f19c9f23 util: allow newlines in string to be split (moneromooo-monero)
94266eeb simplewallet: fix output age display with duplicate heights (moneromooo-monero)
f1d379d2 simplewallet: fix "outputs in same tx" detector (moneromooo-monero)
From the FreeBSD architecture handbook (https://www.freebsd.org/doc/en/books/arch-handbook/jail-restrictions.html) as it relates to `allow.sysvipc`, "By default, this sysctl is set to 0. If it were set to 1, it would defeat the whole purpose of having a jail; privileged users from the jail would be able to affect processes outside the jailed environment." This is undesirable behavior.
Per `man jail`, regarding `allow.sysvipc`, "A process within the jail has access to System V primitives. This is deprecated in favor of the per-module parameters."
Since FreeBSD 11, the new way to deal with this (the per-module parameters) is with: `sysvshm`, for shared memory, `sysvsem`, for semaphores, and `sysvmsg`, for message queues. These can be set selectively to either `disable`; `inherit`, for the previous behavior (problematic due to UID collision, apparently); and `new`, for new behavior that avoids the UID collision problem.
Monero only uses semaphores, therefore we should recommend that jails be run with `sysvsem="new"` in the jail's jail.conf. Tested on FreeBSD 12.1.
Also, Monero is now able to be downloaded as a package or built from ports as `monero-cli` with a versioned suffix. It's got `Monero 'Carbon Chamaeleon' (v0.15.0.1-release)` as of right now, and it's been there 2-3 months, meaning it's currently and timely.
In some contrived case, it might theoretically be the case that
destroy is called from another thread, which would modify the
threads array from two threads.
Coverity 208372
22d30866 simplewallet: add missing inactivity-lock-timeout to set help blurb (moneromooo-monero)
9f57f0df simplewallet: do not mention inactivity if a lock was manual (moneromooo-monero)
b90c4bc3 rpc: error out from get_info if the proxied call errors out (moneromooo-monero)
fa16df99 make_test_signature: exit nicely on top level exception (moneromooo-monero)
054b2621 node_rpc_proxy: init some new rpc payment fields in invalidate (moneromooo-monero)
d0faae2a rpc: init a few missing client_info members (moneromooo-monero)
d56a483a rpc: do not propagate exceptions out of a dtor (moneromooo-monero)
3c849188 rpc: always set the update field in update on sucess (moneromooo-monero)
Nodes remember which connections have been sent which peer addresses
and won't send it again. This causes more addresses to be sent as
the connection lifetime grows, since there is no duplication anymore,
which increases the diffusion speed of peer addresses. The whole
white list is now considered for sending, not just the most recent
seen peers. This further hardens against topology discovery, though
it will more readily send peers that have been last seen earlier
than it otherwise would. While this does save a fair amount of net
bandwidth, it makes heavy use of std::set lookups, which does bring
network_address::less up the profile, though not too aggressively.
The implicit copy assignment operator was deprecated because the class
has an explicit copy constructor. According to the standard:
The generation of the implicitly-defined copy assignment operator is
deprecated (since C++11) if T has a user-declared destructor or
user-declared copy constructor.
Recent versions of gcc (9.1+) and clang (10.0) warn about this.
8231c7cd rpc: fix bootstrap RPC payment RPC being made in raw JSON, not JSON RPC (moneromooo-monero)
81c26589 rpc: don't auto fail RPC needing payment in bootstrap mode (moneromooo-monero)
The backward compatibility code was always setting it to 1
in modern wallets since store_tx_keys was not present and thus
assumed to be 1 by default.
Reported by SeventhAlpaca
- e.g., fixes gen_block_big_major_version test, error: generation failed: what=events not set, cannot compute valid RandomX PoW
- ask for events only if difficulty > 1 (when it really matters)
- throwing an exception changed to logging, so it is easy to spot a problem if tests start to fail.
56dced2d translations: fix "monero_" prefix when taking languages from file (moneromooo-monero)
be3a4326 translations: find lrelease disguised as lrelease-qt5 (moneromooo-monero)
Adding a new `amounts` field ot the output of `get_transfers` RPC
method. This field specifies individual payments made to a single
subaddress in a single transaction, e.g., made by this command:
transfer <addr1> <amount1> <addr1> <amount2>
The added condition "hshd.current_height >= target" guards against
reporting "synchronized" too early in the special situation that the
very first peer sending us data is synced to a lower height than
ourselves.
This is technically a record encrypted in two pieces,
so the iv needs to be different.
Some backward compatibility is added to read data written
by existing code, but new data is written with the new code.
M100 = max{300kb, min{100block_median, m_long_term_effective_median_block_weight}}
not
M100 = max{300kb, m_long_term_effective_median_block_weight}
Fix base reward in get_dynamic_base_fee_estimate().
get_dynamic_base_fee_estimate() should match check_fee()
Fee is calculated based on block reward, and the reward penalty takes into account 0.5*max_block_weight (both before and after HF_VERSION_EFFECTIVE_SHORT_TERM_MEDIAN_IN_PENALTY).
Moved median calculation according to best practice of 'keep definitions close to where they are used'.
10 block lock time is for incoming outputs and not only incoming transactions (outgoing transaction has an incoming change output that is also locked for 10 blocks)
If more than one thread wants to make sure of the spend secret key,
then we decrypt on the first caller and reencrypt on the last caller,
otherwise we could use an invalid secret key.
If the hashes received would move the current blockchain past the
stop point, the short history would not be updated, since we do
not expect another loop, but the daemon might return earlier hashes,
causing the end index to not be enough to reach the threshold and
this require another loop, which will download the same hashes and
cause an infinite loop.
Dividing `dt` here by 1e6 converts it to seconds, but that is clearly
wrong since `REQUEST_NEXT_SCHEDULED_SPAN_THRESHOLD_STANDBY` is measured
in microseconds. As a result, this if statement was effectively never
used.
boost::asio::ssl::context is created using specifically TLSv1.2, which
blocks the ability to use superior version of TLS like TLSv1.3.
Filtering is also made specially later in the code to remove unsafe
version for TLS such SSLv2, SSLv3 etc..
This change is removing double filtering to allow TLSv1.2 and above to
be used.
testssl.sh 3.0rc5 now reports the following (please note monerod was
built with USE_EXTRA_EC_CERT):
$ ./testssl.sh --openssl=/usr/bin/openssl \
--each-cipher --cipher-per-proto \
--server-defaults --server-preference \
--vulnerable --heartbleed --ccs --ticketbleed \
--robot --renegotiation --compression --breach \
--poodle --tls-fallback --sweet32 --beast --lucky13 \
--freak --logjam --drown --pfs --rc4 --full \
--wide --hints 127.0.0.1:38081
Using "OpenSSL 1.1.1d 10 Sep 2019" [~80 ciphers]
on ip-10-97-15-6:/usr/bin/openssl
(built: "Dec 3 21:14:51 2019", platform: "linux-x86_64")
Start 2019-12-03 21:51:25 -->> 127.0.0.1:38081 (127.0.0.1) <<--
rDNS (127.0.0.1): --
Service detected: HTTP
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 offered (OK)
TLS 1.3 offered (OK): final
NPN/SPDY not offered
ALPN/HTTP2 not offered
Testing for server implementation bugs
No bugs found.
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK)
Triple DES Ciphers / IDEA not offered (OK)
Average: SEED + 128+256 Bit CBC ciphers not offered
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK), ciphers follow (client/browser support is important here)
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384
x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256
xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256
xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
Testing server preferences
Has server cipher order? yes (OK)
Negotiated protocol TLSv1.3
Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Cipher order
TLSv1.2: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256
TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "EC point formats/#11" "supported versions/#43" "key share/#51" "max fragment length/#1" "extended master secret/#23"
Session Ticket RFC 5077 hint no -- no lifetime advertised
SSL Session ID support yes
Session Resumption Tickets no, ID: no
TLS clock skew Random values, no fingerprinting possible
Server Certificate #1 (in response to request w/o SNI)
Signature Algorithm SHA256 with RSA
Server key size RSA 4096 bits
Server key usage --
Server extended key usage --
Serial / Fingerprints 01 / SHA1 132E42981812F5575FA0AE64922B18A81B38C03F
SHA256 EBA3CC4AA09DEF26706E64A70DB4BC8D723533BB67EAE12B503A845019FB61DC
Common Name (CN) (no CN field in subject)
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (self signed)
EV cert (experimental) no
"eTLS" (visibility info) not present
Certificate Validity (UTC) 181 >= 60 days (2019-12-03 21:51 --> 2020-06-02 21:51)
# of certificates provided 1
Certificate Revocation List --
OCSP URI --
NOT ok -- neither CRL nor OCSP URI provided
OCSP stapling not offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency --
Server Certificate #2 (in response to request w/o SNI)
Signature Algorithm ECDSA with SHA256
Server key size EC 256 bits
Server key usage --
Server extended key usage --
Serial / Fingerprints 01 / SHA1 E17B765DD8124525B1407E827B89A31FB167647D
SHA256 AFB7F44B1C33831F521357E5AEEB813044CB02532143E92D35650A3FF792A7C3
Common Name (CN) (no CN field in subject)
subjectAltName (SAN) missing (NOT ok) -- Browsers are complaining
Issuer
Trust (hostname) certificate does not match supplied URI
Chain of trust NOT ok (self signed)
EV cert (experimental) no
"eTLS" (visibility info) not present
Certificate Validity (UTC) 181 >= 60 days (2019-12-03 21:51 --> 2020-06-02 21:51)
# of certificates provided 1
Certificate Revocation List --
OCSP URI --
NOT ok -- neither CRL nor OCSP URI provided
OCSP stapling not offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency --
Testing HTTP header response @ "/"
HTTP Status Code 404 Not found (Hint: supply a path which doesn't give a "404 Not found")
HTTP clock skew Got no HTTP time, maybe try different URL?
Strict Transport Security not offered
Public Key Pinning --
Server banner Epee-based
Application banner --
Cookie(s) (none issued at "/") -- maybe better try target URL of 30x
Security headers --
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension
ROBOT Server does not support any cipher suites that use RSA key transport
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) No fallback possible, no protocol below TLS 1.2 offered (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don't use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=EBA3CC4AA09DEF26706E64A70DB4BC8D723533BB67EAE12B503A845019FB61DC could help you to find out
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
BEAST (CVE-2011-3389) no SSL3 or TLS1 (OK)
LUCKY13 (CVE-2013-0169), experimental not vulnerable (OK)
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing ciphers per protocol via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
SSLv2
SSLv3
TLS 1
TLS 1.1
TLS 1.2
xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS 1.3
x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384
x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256
x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256
Running client simulations (HTTP) via sockets
Browser Protocol Cipher Suite Name (OpenSSL) Forward Secrecy
------------------------------------------------------------------------------------------------
Android 4.2.2 No connection
Android 4.4.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 256 bit ECDH (P-256)
Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 256 bit ECDH (P-256)
Android 7.0 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519)
Android 8.1 (native) No connection
Android 9.0 (native) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519)
Chrome 65 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519)
Chrome 74 (Win 10) No connection
Firefox 62 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519)
Firefox 66 (Win 8.1/10) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519)
IE 6 XP No connection
IE 7 Vista No connection
IE 8 Win 7 No connection
IE 8 XP No connection
IE 11 Win 7 No connection
IE 11 Win 8.1 No connection
IE 11 Win Phone 8.1 No connection
IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Edge 15 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Edge 17 (Win 10) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Opera 60 (Win 10) No connection
Safari 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Tor 17.0.9 Win 7 No connection
Java 6u45 No connection
Java 7u25 No connection
Java 8u161 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Java 9.0.4 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
OpenSSL 1.0.1l TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
OpenSSL 1.1.0j (Debian) TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 253 bit ECDH (X25519)
OpenSSL 1.1.1b (Debian) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519)
Thunderbird (60.6) TLSv1.3 TLS_AES_256_GCM_SHA384 253 bit ECDH (X25519)
The highlight check was based on height, so would highlight
any output at that height, resulting in several matches if
a fake out was picked at the same height as the real spend
This fixes rapid reconnections failing as the peer hasn't yet
worked out the other side is gone, and will reject "duplicate"
connections until a timeout.
Avoids a DB error (leading to an assert) where a thread uses
a read txn previously created with an environment that was
since closed and reopened. While this usually works since
BlockchainLMDB renews txns if it detects the environment has
changed, this will not work if objects end up being allocated
at the same address as the previous instance, leading to stale
data usage.
Thanks hyc for the LMDB debugging.
- Removed copy of field names in binary deserialization
- Removed copy of array values in binary deserialization
- Removed copy of string values in json deserialization
- Removed unhelpful allocation in json string value parsing
- Removed copy of blob data on binary and json serialization
- We are also available via [HackerOne](https://hackerone.com/monero)
## Research
The [Monero Research Lab](https://src.getmonero.org/resources/research-lab/) is an open forum where the community coordinates research into Monero cryptography, protocols, fungibility, analysis, and more. We welcome collaboration and contributions from outside researchers! Because not all Lab work and publications are distributed as traditional preprints or articles, they may be easy to miss if you are conducting literature reviews for your own Monero research. You are encouraged to get in touch with our researchers if you have questions, wish to collaborate, or would like guidance to help avoid unnecessarily duplicating earlier or known work.
Our researchers are available on IRC in [#monero-research-lab on Freenode](https://webchat.freenode.net/?randomnick=1&channels=%23monero-research-lab&prompt=1&uio=d4) or by email:
- Sarang Noether, Ph.D.: [sarang@getmonero.org](mailto:sarang@getmonero.org) or [sarang.noether@protonmail.com](mailto:sarang.noether@protonmail.com); [research repository](https://github.com/SarangNoether/research-lab)
- You can subscribe to an [announcement listserv](https://lists.getmonero.org) to get critical announcements from the Monero core team. The announcement list can be very helpful for knowing when software updates are needed.
## Translations
The CLI wallet is available in different languages. If you want to help translate it, see our self-hosted localization platform, Weblate, on [translate.getmonero.org](https://translate.getmonero.org/projects/CLI/). Every translation *must* be uploaded on the platform, pull requests directly editing the code in this repository will be closed. If you need help with Weblate, you can find a guide with screenshots [here](https://github.com/monero-ecosystem/monero-translations/blob/master/weblate.md).
If you need help/support/info about translations, contact the localization workgroup. You can find the complete list of contacts on the repository of the workgroup: [monero-translations](https://github.com/monero-ecosystem/monero-translations#contacts).
## Build Status
### IMPORTANT
These builds are of the master branch, which is used for active development and can be either unstable or incompatible with release software. Please compile release branches.
Monero is a private, secure, untraceable, decentralised digital currency. You are your bank, you control your funds, and nobody can trace your transfers unless you allow them to do so.
**Privacy:** Monero uses a cryptographically sound system to allow you to send and receive funds without your transactions being easily revealed on the blockchain (the ledger of transactions that everyone has). This ensures that your purchases, receipts, and all transfers remain absolutely private by default.
**Security:** Using the power of a distributed peer-to-peer consensus network, every transaction on the network is cryptographically secured. Individual wallets have a 25 word mnemonic seed that is only displayed once, and can be written down to backup the wallet. Wallet files are encrypted with a passphrase to ensure they are useless if stolen.
**Untraceability:** By taking advantage of ring signatures, a special property of a certain type of cryptography, Monero is able to ensure that transactions are not only untraceable, but have an optional measure of ambiguity that ensures that transactions cannot easily be tied back to an individual user or computer.
**Decentralization:** The utility of monero depends on its decentralised peer-to-peer consensus network - anyone should be able to run the monero software, validate the integrity of the blockchain, and participate in all aspects of the monero network using consumer-grade commodity hardware. Decentralization of the monero network is maintained by software development that minimizes the costs of running the monero software and inhibits the proliferation of specialized, non-commodity hardware.
## About this project
This is the core implementation of Monero. It is open source and completely free to use without restrictions, except for those specified in the license agreement below. There are no restrictions on anyone creating an alternative implementation of Monero that uses the protocol and network in a compatible manner.
As with many development projects, the repository on Github is considered to be the "staging" area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then subsequently tested by contributors who focus on testing and code reviews. That having been said, the repository should be carefully considered before using it in a production environment, unless there is a patch in the repository for a particular show-stopping issue you are experiencing. It is generally a better idea to use a tagged release for stability.
**Anyone is welcome to contribute to Monero's codebase!** If you have a fix or code change, feel free to submit it as a pull request directly to the "master" branch. In cases where the change is relatively small or does not affect other parts of the codebase it may be merged in immediately by any one of the collaborators. On the other hand, if the change is particularly large or complex, it is expected that it will be discussed at length either well in advance of the pull request being submitted, or even directly on the pull request.
Wownero is a privacy-centric memecoin that was fairly launched on April 1, 2018 with no pre-mine, stealth-mine or ICO. Wownero has a maximum supply of around 184 million WOW with a slow and steady emission over 50 years. It is a fork of Monero, but with its own genesis block, so there is no degradation of privacy due to ring signatures using different participants for the same tx outputs on opposing forks.
## Supporting the project
Monero is a 100% community-sponsored endeavor. If you want to join our efforts, the easiest thing you can do is support the project financially. Both Monero and Bitcoin donations can be made to **donate.getmonero.org** if using a client that supports the [OpenAlias](https://openalias.org) standard. Alternatively you can send XMR to the Monero donation address via the `donate` command (type `help` in the command-line wallet for details).
Wownero is a 100% community-sponsored endeavor. Supporting services are also graciously provided by sponsors:
The Monero donation address is: `44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A` (viewkey: `f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501`)
The Bitcoin donation address is: `1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H`
Developers are volunteers doing this mostly for shits and giggles. If you would like to support our shenanigans and stimulant addictions, please consider donating to [WFS proposals](https://funding.wownero.com/proposals) or the dev slush fund.
Core development funding and/or some supporting services are also graciously provided by sponsors:
There are also several mining pools that kindly donate a portion of their fees, [a list of them can be found on our Bitcointalk post](https://bitcointalk.org/index.php?topic=583449.0).
If you want to help out, see [CONTRIBUTING](CONTRIBUTING.md) for a set of guidelines.
## Release staging and Contributing
**Anyone is welcome to contribute to Wownero's codebase!**
If you have a fix or code change, feel free to submit it as a pull request. Ahead of a scheduled software upgrade, a development branch will be created with the new release version tag. Pull requests that address bugs should be made to Master. Pull requests that require review and testing (generally, optimizations and new features) should be made to the development branch. All pull requests will be considered safe until the US dollar valuation of 1 Wownero equals $1000. After this valuation has been reached, more research will be needed to introduce experimental cryptography and/or code into the codebase.
Things to Do, Work in Progress, and Help Wanted tasks are tracked in the [Meta](https://git.wownero.com/wownero/meta/issues) repo.
Join `#wownero-dev` on IRC freenode to participate in development conversation.
## Scheduled software upgrades
Monero uses a fixed-schedule software upgrade (hard fork) mechanism to implement new features. This means that users of Monero (end users and service providers) should run current versions and upgrade their software on a regular schedule. Software upgrades occur during the months of April and October. The required software for these upgrades will be available prior to the scheduled date. Please check the repository prior to this date for the proper Monero software version. Below is the historical schedule and the projected schedule for the next upgrade.
Dates are provided in the format YYYY-MM-DD.
Wownero uses a fixed-schedule software upgrade (hard fork) mechanism to implement new features. This means that users of Wownero (end users and service providers) should run current versions and upgrade their software on a regular schedule. The required software for these upgrades will be available prior to the scheduled date. Please check the repository prior to this date for the proper Wownero software version. Below is the historical schedule and the projected schedule for the next upgrade.
Dates are provided in the format YYYY-MM-DD.
| Software upgrade block height | Date | Fork version | Minimum Monero version | Recommended Monero version | Details |
| Software upgrade block height | Date | Release Name | Minimum Wownero version | Recommended Wownero version | Details |
| 1788000 | 2019-03-09 | v10 | v0.14.0.0 | v0.14.1.2 | New PoW based on Cryptonight-R, new block weight algorithm, slightly more efficient RingCT format
| 1788720 | 2019-03-10 | v11 | v0.14.0.0 | v0.14.1.2 | forbid old RingCT transaction format
| 1978433 | 2019-11-30* | v12 | v0.15.0.0 | v0.15.0.0 | New PoW based on RandomX, only allow >= 2 outputs, change to the block median used to calculate penalty, v1 coinbases are forbidden, rct sigs in coinbase forbidden, 10 block lock time for incoming transactions
| 114,969 | 2019-06-14 | F For Fappening | v0.6.1.0 | v0.6.1.2 | RandomWOW, new block weight algorithm, slightly more efficient RingCT format
| 160,777 | 2019-11-20 | Gaping Goatse | v0.7.0.0 | v0.7.1.0 | Only allow >= 2 outputs, change to the block median used to calculate penalty, rct sigs in coinbase forbidden, 4 unlock time as protocol rule
X's indicate that these details have not been determined as of commit date.
* indicates estimate as of commit date
## Release staging schedule and protocol
\* indicates estimate as of commit date
Approximately three months prior to a scheduled software upgrade, a branch from master will be created with the new release version tag. Pull requests that address bugs should then be made to both master and the new release branch. Pull requests that require extensive review and testing (generally, optimizations and new features) should *not* be made to the release branch.
## Compiling Monero from source
### Dependencies
The following table summarizes the tools and libraries required to build. A
few of the libraries are also included in this repository (marked as
"Vendored"). By default, the build uses the library installed on the system,
and ignores the vendored sources. However, if no library is found installed on
the system, then the vendored source will be built and used. The vendored
sources are also used for statically-linked builds because distribution
packages often include only shared library binaries (`.so`) but not static
library archives (`.a`).
| Dep | Min. version | Vendored | Debian/Ubuntu pkg | Arch pkg | Fedora | Optional | Purpose |
[1] On Debian/Ubuntu `libgtest-dev` only includes sources and headers. You must
build the library binary manually. This can be done with the following command ```sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make && sudo mv libg* /usr/lib/ ```
[2] libnorm-dev is needed if your zmq library was built with libnorm, and not needed otherwise
Install all dependencies at once on Debian/Ubuntu:
Monero uses the CMake build system and a top-level [Makefile](Makefile) that
invokes cmake commands as needed.
#### On Linux and macOS
* Install the dependencies
* Change to the root of the source code directory, change to the most recent release branch, and build:
```bash
cd monero
git checkout release-v0.15
make
```
*Optional*: If your machine has several cores and enough memory, enable
parallel build by running `make -j<number of threads>` instead of `make`. For
this to be worthwhile, the machine should have one core and about 2GB of RAM
available per thread.
*Note*: If cmake can not find zmq.hpp file on macOS, installing `zmq.hpp` from
https://github.com/zeromq/cppzmq to `/usr/local/include` should fix that error.
*Note*: The instructions above will compile the most stable release of the
Monero software. If you would like to use and test the most recent software,
use ```git checkout master```. The master branch may contain updates that are
both unstable and incompatible with release software, though testing is always
encouraged.
* The resulting executables can be found in `build/release/bin`
* Add `PATH="$PATH:$HOME/monero/build/release/bin"` to `.profile`
* Run Monero with `monerod --detach`
* **Optional**: build and run the test suite to verify the binaries:
```bash
make release-test
```
*NOTE*: `core_tests` test may take a few hours to complete.
* **Optional**: to build binaries suitable for debugging:
```bash
make debug
```
* **Optional**: to build statically-linked binaries:
```bash
make release-static
```
Dependencies need to be built with -fPIC. Static libraries usually aren't, so you may have to build them yourself with -fPIC. Refer to their documentation for how to build them.
* **Optional**: build documentation in `doc/html` (omit `HAVE_DOT=YES` if `graphviz` is not installed):
```bash
HAVE_DOT=YES doxygen Doxyfile
```
#### On the Raspberry Pi
Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (2017-09-07 or later) from https://www.raspberrypi.org/downloads/raspbian/. If you are using Raspian Jessie, [please see note in the following section](#note-for-raspbian-jessie-users).
* `apt-get update && apt-get upgrade` to install all of the latest software
* Install the dependencies for Monero from the 'Debian' column in the table above.
* Increase the system swap size:
```bash
sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=2048
sudo /etc/init.d/dphys-swapfile start
```
* If using an external hard disk without an external power supply, ensure it gets enough power to avoid hardware issues when syncing, by adding the line "max_usb_current=1" to /boot/config.txt
* Clone monero and checkout the most recent release version:
* The resulting executables can be found in `build/release/bin`
* Add `PATH="$PATH:$HOME/monero/build/release/bin"` to `.profile`
* Run Monero with `monerod --detach`
* You may wish to reduce the size of the swap file after the build has finished, and delete the boost directory from your home directory
#### *Note for Raspbian Jessie users:*
If you are using the older Raspbian Jessie image, compiling Monero is a bit more complicated. The version of Boost available in the Debian Jessie repositories is too old to use with Monero, and thus you must compile a newer version yourself. The following explains the extra steps, and has been tested on a Raspberry Pi 2 with a clean install of minimal Raspbian Jessie.
* As before, `apt-get update && apt-get upgrade` to install all of the latest software, and increase the system swap size
```bash
sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=2048
sudo /etc/init.d/dphys-swapfile start
```
* Then, install the dependencies for Monero except `libunwind` and `libboost-all-dev`
* Install the latest version of boost (this may first require invoking `apt-get remove --purge libboost*` to remove a previous version if you're not using a clean install):
sudo ./bjam cxxflags=-fPIC cflags=-fPIC -a install
```
* Wait ~4 hours
* From here, follow the [general Raspberry Pi instructions](#on-the-raspberry-pi) from the "Clone monero and checkout most recent release version" step.
#### On Windows:
Binaries for Windows are built on Windows using the MinGW toolchain within
[MSYS2 environment](https://www.msys2.org). The MSYS2 environment emulates a
POSIX system. The toolchain runs within the environment and *cross-compiles*
binaries that can run outside of the environment as a regular Windows
application.
**Preparing the build environment**
* Download and install the [MSYS2 installer](https://www.msys2.org), either the 64-bit or the 32-bit package, depending on your system.
* Open the MSYS shell via the `MSYS2 Shell` shortcut
* Update packages using pacman:
```bash
pacman -Syu
```
* Exit the MSYS shell using Alt+F4
* Edit the properties for the `MSYS2 Shell` shortcut changing "msys2_shell.bat" to "msys2_shell.cmd -mingw64" for 64-bit builds or "msys2_shell.cmd -mingw32" for 32-bit builds
* Restart MSYS shell via modified shortcut and update packages again using pacman:
```bash
pacman -Syu
```
* Install dependencies:
To build for 64-bit Windows:
```bash
pacman -S mingw-w64-x86_64-toolchain make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost mingw-w64-x86_64-openssl mingw-w64-x86_64-zeromq mingw-w64-x86_64-libsodium mingw-w64-x86_64-hidapi
```
To build for 32-bit Windows:
```bash
pacman -S mingw-w64-i686-toolchain make mingw-w64-i686-cmake mingw-w64-i686-boost mingw-w64-i686-openssl mingw-w64-i686-zeromq mingw-w64-i686-libsodium mingw-w64-i686-hidapi
```
* Open the MingW shell via `MinGW-w64-Win64 Shell` shortcut on 64-bit Windows
or `MinGW-w64-Win64 Shell` shortcut on 32-bit Windows. Note that if you are
running 64-bit Windows, you will have both 64-bit and 32-bit MinGW shells.
* If you would like a specific [version/tag](https://github.com/monero-project/monero/tags), do a git checkout for that version. eg. 'v0.15.0.0'. If you don't care about the version and just want binaries from master, skip this step:
```bash
git checkout v0.15.0.0
```
* If you are on a 64-bit system, run:
```bash
make release-static-win64
```
* If you are on a 32-bit system, run:
```bash
make release-static-win32
```
* The resulting executables can be found in `build/release/bin`
* **Optional**: to build Windows binaries suitable for debugging on a 64-bit system, run:
```bash
make debug-static-win64
```
* **Optional**: to build Windows binaries suitable for debugging on a 32-bit system, run:
```bash
make debug-static-win32
```
* The resulting executables can be found in `build/debug/bin`
### On FreeBSD:
The project can be built from scratch by following instructions for Linux above(but use `gmake` instead of `make`). If you are running monero in a jail you need to add the flag: `allow.sysvipc=1` to your jail configuration, otherwise lmdb will throw the error message: `Failed to open lmdb environment: Function not implemented`.
We expect to add Monero into the ports tree in the near future, which will aid in managing installations using ports or packages.
### On OpenBSD:
You will need to add a few packages to your system. `pkg_add cmake gmake zeromq cppzmq libiconv boost`.
The `doxygen` and `graphviz` packages are optional and require the xbase set.
Running the test suite also requires `py-requests` package.
By default, in either dynamically or statically linked builds, binaries target the specific host processor on which the build happens and are not portable to other processors. Portable binaries can be built using the following targets:
* ```make release-static-linux-x86_64``` builds binaries on Linux on x86_64 portable across POSIX systems on x86_64 processors
* ```make release-static-linux-i686``` builds binaries on Linux on x86_64 or i686 portable across POSIX systems on i686 processors
* ```make release-static-linux-armv8``` builds binaries on Linux portable across POSIX systems on armv8 processors
* ```make release-static-linux-armv7``` builds binaries on Linux portable across POSIX systems on armv7 processors
* ```make release-static-linux-armv6``` builds binaries on Linux portable across POSIX systems on armv6 processors
* ```make release-static-win64``` builds binaries on 64-bit Windows portable across 64-bit Windows systems
* ```make release-static-win32``` builds binaries on 64-bit or 32-bit Windows portable across 32-bit Windows systems
### Cross Compiling
You can also cross-compile static binaries on Linux for Windows and macOS with the `depends` system.
* ```make depends target=x86_64-linux-gnu``` for 64-bit linux binaries.
* ```make depends target=x86_64-w64-mingw32``` for 64-bit windows binaries.
* ```make depends target=i686-linux-gnu``` for 32-bit linux binaries.
* Requires: `g++-multilib bc`
* ```make depends target=i686-w64-mingw32``` for 32-bit windows binaries.
* Requires: `python3 g++-mingw-w64-i686`
* ```make depends target=arm-linux-gnueabihf``` for armv7 binaries.
* Requires: `g++-arm-linux-gnueabihf`
* ```make depends target=aarch64-linux-gnu``` for armv8 binaries.
* Requires: `g++-aarch64-linux-gnu`
* ```make depends target=riscv64-linux-gnu``` for RISC V 64 bit binaries.
* Requires: `g++-riscv64-linux-gnu`
The required packages are the names for each toolchain on apt. Depending on your distro, they may have different names.
Using `depends` might also be easier to compile Monero on Windows than using MSYS. Activate Windows Subsystem for Linux (WSL) with a distro (for example Ubuntu), install the apt build-essentials and follow the `depends` steps as depicted above.
The produced binaries still link libc dynamically. If the binary is compiled on a current distribution, it might not run on an older distribution with an older installation of libc. Passing `-DBACKCOMPAT=ON` to cmake will make sure that the binary will run on systems having at least libc version 2.17.
## Installing Monero from a package
**DISCLAIMER: These packages are not part of this repository or maintained by this project's contributors, and as such, do not go through the same review process to ensure their trustworthiness and security.**
## Installing from a package
Packages are available for
* Debian Bullseye and Sid
* Arch Linux/Manjaro
```bash
sudo apt install monero
```
More info and versions in the [Debian package tracker](https://tracker.debian.org/pkg/monero).
yay -S wownero-git
* Arch Linux (via [AUR](https://aur.archlinux.org/)):
Packaging for your favorite distribution would be a welcome contribution!
## Running monerod
**DISCLAIMER: These packages are not part of this repository, and as such, do not go through the same review process to ensure their trustworthiness and security.**
## Building from Source
* Docker
git clone https://git.wownero.com/wownero/wownero && cd wownero
This section contains general instructions for debugging failed installs or problems encountered with Monero. First, ensure you are running the latest version built from the Github repo.
### Obtaining stack traces and core dumps on Unix systems
We generally use the tool `gdb` (GNU debugger) to provide stack trace functionality, and `ulimit` to provide core dumps in builds which crash or segfault.
* To use `gdb` in order to obtain a stack trace for a build that has stalled:
Run the build.
Once it stalls, enter the following command:
```bash
gdb /path/to/monerod `pidof monerod`
```
Type `thread apply all bt` within gdb in order to obtain the stack trace
* If however the core dumps or segfaults:
Enter `ulimit -c unlimited` on the command line to enable unlimited filesizes for core dumps
Enter `echo core | sudo tee /proc/sys/kernel/core_pattern` to stop cores from being hijacked by other tools
Run the build.
When it terminates with an output along the lines of "Segmentation fault (core dumped)", there should be a core dump file in the same directory as monerod. It may be named just `core`, or `core.xxxx` with numbers appended.
You can now analyse this core dump with `gdb` as follows:
```bash
gdb /path/to/monerod /path/to/dumpfile`
```
Print the stack trace with `bt`
* If a program crashed and cores are managed by systemd, the following can also get a stack trace for that crash:
```bash
coredumpctl -1 gdb
```
#### To run monero within gdb:
Type `gdb /path/to/monerod`
Pass command-line options with `--args` followed by the relevant arguments
Type `run` to run monerod
### Analysing memory corruption
There are two tools available:
#### ASAN
Configure Monero with the -D SANITIZE=ON cmake flag, eg:
```bash
cd build/debug && cmake -D SANITIZE=ON -D CMAKE_BUILD_TYPE=Debug ../..
```
You can then run the monero tools normally. Performance will typically halve.
#### valgrind
Install valgrind and run as `valgrind /path/to/monerod`. It will be very slow.
### LMDB
Instructions for debugging suspected blockchain corruption as per @HYC
There is an `mdb_stat` command in the LMDB source that can print statistics about the database but it's not routinely built. This can be built with the following command:
```bash
cd ~/monero/external/db_drivers/liblmdb && make
```
The output of `mdb_stat -ea <path to blockchain dir>` will indicate inconsistencies in the blocks, block_heights and block_info table.
The output of `mdb_dump -s blocks <path to blockchain dir>` and `mdb_dump -s block_info <path to blockchain dir>` is useful for indicating whether blocks and block_info contain the same keys.
These records are dumped as hex data, where the first line is the key and the second line is the data.
# Known Issues
## Protocols
### Socket-based
Because of the nature of the socket-based protocols that drive monero, certain protocol weaknesses are somewhat unavoidable at this time. While these weaknesses can theoretically be fully mitigated, the effort required (the means) may not justify the ends. As such, please consider taking the following precautions if you are a monero node operator:
- Run `monerod` on a "secured" machine. If operational security is not your forte, at a very minimum, have a dedicated a computer running `monerod` and **do not** browse the web, use email clients, or use any other potentially harmful apps on your `monerod` machine. **Do not click links or load URL/MUA content on the same machine**. Doing so may potentially exploit weaknesses in commands which accept "localhost" and "127.0.0.1".
- If you plan on hosting a public "remote" node, start `monerod` with `--restricted-rpc`. This is a must.
### Blockchain-based
Certain blockchain "features" can be considered "bugs" if misused correctly. Consequently, please consider the following:
- When receiving monero, be aware that it may be locked for an arbitrary time if the sender elected to, preventing you from spending that monero until the lock time expires. You may want to hold off acting upon such a transaction until the unlock time lapses. To get a sense of that time, you can consider the remaining blocktime until unlock as seen in the `show_transfers` command.
Use port `9050` instead of `9150` if you installed Tor as a standalone daemon. For more information, check out [ANONYMITY_NETWORKS](https://git.wownero.com/wownero/wownero/src/branch/master/ANONYMITY_NETWORKS.md).
// ! (how ever if in some wonderful juristdictions that is not the case, then why not make another sub-class withat that members and licence it as epee part)
// ! Working on above premise, IF this is valid in your juristdictions, then consider this code as released as:
// Copyright (c) 2014-2019, The Monero Project
// Copyright (c) 2014-2020, The Monero Project
//
// All rights reserved.
//
@@ -132,10 +132,10 @@ class connection_basic { // not-templated base class for rapid developmet of som
MDEBUG(m_connection_context<<"LEVIN_PACKET partial msg received. len="<<cb<<", current total "<<m_cache_in_buffer.size()<<"/"<<m_current_head.m_cb<<" ("<<(100.0f*m_cache_in_buffer.size()/(m_current_head.m_cb?m_current_head.m_cb:1))<<"%)");
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.