be1b0ff On Mac OS X fsync does not guarantee write to disk. Use fcntl F_FULLFSYNC instead.
git-subtree-dir: src/leveldb
git-subtree-split: be1b0ff1fcd6ad820a7fd111ac671fb51cc68001
This reduces a peer's ability to attack network resources by
using a full bloom filter, but without reducing the usability
of bloom filters. It sets a default match everything filter
for peers and it generalizes a prior optimization to
cover more cases.
a02ddf9 Added GNU/kFreeBSD kernel name (TARGET_OS)
8487468 CondVar::SignalAll was broken, leading to deadlocks on Windows builds. http://code.google.com/p/leveldb/issues/detail?id=149
f6d84d1 Allow files to be opened for reading multiple times
cb8e3f7 Checking whether closing succeeds
d5317e8 Print actual Win32 error that occurred on file creation failure.
907f308 Port leveldb to MinGW32
9def2bf Mingw support for Windows LevelDB port
0a7b074 Pre-Vista leveldb::port::InitOnce implementation
31a2b09 Native Windows LevelDB port
058a035 Remove Snappy support
5bd76dc Release leveldb 1.12
7b094f1 Release leveldb 1.11
28dad91 Release leveldb 1.10
514c943 Make DB::Open fail if sst files are missing.
d84c825 Fix corruption bug found and analyzed by dhruba@gmail.com
ea2e919 added utility to dump leveldb files
REVERT: ae6c262 Merge branch 'leveldb' into ripple-fork
REVERT: 28fa222 Looks like a bit more delay is needed to smooth the latency.
REVERT: a18f3e6 Tidy up JobQueue, add ripple_core module
REVERT: ab82e57 Release leveldb 1.12
REVERT: 02c6259 Release leveldb 1.11
REVERT: 5bbb544 Rate limit compactions with a 25ms pause after each complete file.
REVERT: 8c29c47 LevelDB issue 178 fix: cannot resize a level 0 compaction set
REVERT: 18b245c Added GNU/kFreeBSD kernel name (TARGET_OS)
REVERT: 8be9d12 CondVar::SignalAll was broken, leading to deadlocks on Windows builds. http://code.google.com/p/leveldb/issues/detail?id=149
REVERT: c9fc070 Upgrade LevelDB to 1.10.0, mostly for better write stall logging.
REVERT: 8215b15 Tweak to variable name to support unity build
REVERT: aca1ffc Allow files to be opened for reading multiple times
REVERT: 693a70c Checking whether closing succeeds
REVERT: 0144d04 Print actual Win32 error that occurred on file creation failure.
REVERT: 43ed517 Fix corruption bug found and analyzed by dhruba@gmail.com
REVERT: 413c74c added utility to dump leveldb files
REVERT: 96eda85 Port leveldb to MinGW32
REVERT: 0967260 Mingw support for Windows LevelDB port
REVERT: ee3f9bd Pre-Vista leveldb::port::InitOnce implementation
REVERT: f5d0a41 Native Windows LevelDB port
REVERT: 28b35f1 Remove Snappy support
git-subtree-dir: src/leveldb
git-subtree-split: a02ddf9b14d145e88185ee209ab8b01d8826663a
To fix a minor malleability found by Sergio Lerner (reported here:
https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898)
The problem is that if (R,S) is a valid ECDSA signature for a given
message and public key, (R,-S) is also valid. Modulo N (the order
of the secp256k1 curve), this means that both (R,S) and (R,N-S) are
valid. Given that N is odd, S and N-S have a different lowest bit.
We solve the problem by forcing signatures to have an even S value,
excluding one of the alternatives.
This commit just changes the signing code to always produce even S
values, and adds a verification mode to check it. This code is not
enabled anywhere yet. Existing tests in key_tests.cpp verify that
the produced signatures are still valid.
The length of vectors, maps, sets, etc are serialized using
Write/ReadCompactSize -- which, unfortunately, do not use a
unique encoding.
So deserializing and then re-serializing a transaction (for example)
can give you different bits than you started with. That doesn't
cause any problems that we are aware of, but it is exactly the type
of subtle mismatch that can lead to exploits.
With this pull, reading a non-canonical CompactSize throws an
exception, which means nodes will ignore 'tx' or 'block' or
other messages that are not properly encoded.
Please check my logic... but this change is safe with respect to
causing a network split. Old clients that receive
non-canonically-encoded transactions or blocks deserialize
them into CTransaction/CBlock structures in memory, and then
re-serialize them before relaying them to peers.
And please check my logic with respect to causing a blockchain
split: there are no CompactSize fields in the block header, so
the block hash is always canonical. The merkle root in the block
header is computed on a vector<CTransaction>, so
any non-canonical encoding of the transactions in 'tx' or 'block'
messages is erased as they are read into memory by old clients,
and does not affect the block hash. And, as noted above, old
clients re-serialize (with canonical encoding) 'tx' and 'block'
messages before relaying to peers.
Fixes issue#2838; this is a tweaked version of pull#2845 that
should not leak the length of the password and is more generic,
in case we run into other situations where we need
timing-attack-resistant comparisons.
