With a "Build successful" compilation of CT, I try to test the installation, going to /test, and executing: make OPENSSLDIR=”/usr/local/ssl” GTESTDIR=”/home/izenpe/CT/gtest-1.6.0” test
I am using a default binary installation of openssl, so I don't have the /usr/local/ssl/apps/openssl directory. The error it shows is:

BUILD SUCCESSFUL
Total time: 2 seconds
make[2]: Entering directory /home/izenpe/CT/certificate-transparency/python' make[2]: Nothing to be done forall'.
make[2]: Leaving directory /home/izenpe/CT/certificate-transparency/python' make[1]: Leaving directory/home/izenpe/CT/certificate-transparency'
OPENSSLDIR=/usr/local/ssl ./sslconnect_test.sh
./sslconnect_test.sh: line 114: /usr/local/ssl/apps/openssl: No such file or directory
make: *** [test] Error 127

Is there any way to execute these tests with a binary installation of openssl?. I have downloaded the CT source code using git.
Thanks

These operations are likely to hit the disk (and possibly do somewhat expensive crypto?), so they should be spun off to another thread.

Before we do so, the pieces involved should be reviewed for thread-safety, of course.

The RFC allows returning less than what is requested. We should do this, to protect ourselves from excessive requests.

When the log is empty, get-sth returns this:

{
  "tree_size":0,
  "timestamp":0,
  "sha256_root_hash":"",
  "tree_head_signature":"AAAAAA=="
}

It should instead sign an empty tree (which can be done on the fly, not a big deal), and return that.

When I try to install CT, in the step where the script tries to compile handler.cc this is the error I get:

server/handler.cc: In member function 'void cert_trans::HttpHandler::GetEntries(evhttp_request_) const':
server/handler.cc:284:31: error: comparison between signed and unsigned integer expressions [-Werror=sig n-compare]
for (size_t i = start; i <= end; ++i) {
^
server/handler.cc: In member function 'void cert_trans::HttpHandler::GetProof(evhttp_request_) const':
server/handler.cc:354:65: error: comparison between signed and unsigned integer expressions [-Werror=sig n-compare]
if (tree_size < 0 || tree_size > manager_->GetSTH().tree_size()) {
^
cc1plus: all warnings being treated as errors
make[1]: *** [server/handler.o] Error 1
make[1]: Leaving directory `/home/izenpe/CT/certificate-transparency/cpp'
make: *** [cpp] Error 2

Source code is downloaded this morning, using "git clone https://github.com/google/certificate-transparency.git". Flags used to compile are: make GTESTDIR=”/home/izenpe/CT/gtest-1.6.0” CPPNETLIBDIR="/home/izenpe/CT/ cpp-netlib-0.10.1".
Also I used export LOCAL_CXXFLAGS="-Wno-error=unused-local-typedefs" to avoid errors like "all warnings being treated as errors", but they are still appearing
Thanks

With CT source code just downloaded with git, "git clone https://github.com/google/certificate-transparency.git", I get the following compilation error:

g++ -I . -I /home/izenpe/CT/openssl-OpenSSL_1_0_2-stable/include -I /home/izenpe/CT/gtest-1.6.0/include -I /usr/local/include -Wall -Werror -g -O3 -I/usr/local/include/json-c -c -o client/ssl_client.o client/ssl_client.cc
client/ssl_client.cc: In constructor 'SSLClient::SSLClient(const string&, uint16_t, const string&, LogVerifier_)':
client/ssl_client.cc:86:22: error: 'SSL_CTX_set_custom_cli_ext' was not declared in this scope
&verify_args_);
^
make[1]: *_* [client/ssl_client.o] Error 1
make[1]: Leaving directory `/home/izenpe/CT/certificate-transparency/cpp'

make: *** [cpp] Error 2

When I launch the make, I'm using a compiled version of openssl (1.0.2):

make OPENSSLDIR="/home/izenpe/CT/openssl-OpenSSL_1_0_2-stable" GTESTDIR="/home/izenpe/CT/gtest-1.6.0" CPPNETLIBDIR="/home/izenpe/CT/cpp-netlib-0.10.1"

Thanks

I'm having some issues trying to launch my ct-server with a certificate generated with RSA 2048. It looks like it only allows Elliptic Curves. According to bullet point 2.1.4 of RFC 6962 "A log MUST use either elliptic curve signatures using the NIST P-256 curve (...) or RSA signatures using a key of at least 2048 bits. I'm not sure if i'm doing something wrong, or the Google CT server really doesn't allow any other algorithm than ECCs. This is the output in my console:

F1008 14:24:38.362268 7057 signer.cc:27] Unsupported key type 6

And if we take a look to signer.cc:27, it verifies that signature algorithm is ECDSA

Thanks

Imagine a cluster of multiple nodes, where an elected leader does the signing of new tree heads, the rest of the cluster are followers, possibly trailing behind by some arbitrary number of entries, and you have a load balancer in front of this that sends incoming requests arbitrarily. You could then get in this situation:

1. client gets an STH, and happens to get it from the leader (most up to date)
2. client tries to get proofs, but it goes to a follower that doesn't have a bit enough tree size
3. client tries to get the STH again, hoping to get whatever tree size that the follower would accept, but it goes to the leader again
4. client tries to get proofs again, but the same thing happens again

This could go on possibly forever, in a degenerate case.

@benlaurie said that there should be a single call to get the current STH, and a proof (if a hash was provided), and a consistency proof (if a tree size was provided), so that you could get a consistent view for a single logical operation.

This requires adding an entirely new function to the API, but @benlaurie suggested that if, at least, the get-proof call would return its current STH in case of an error, it could at least converge on a good answer, by keeping the STH that had the smallest tree size, and using that for retrying the get-proof call. In that case, the previous scenario would play out like this:

1. client gets an STH, and happens to get it from the leader (most up to date)
2. client tries to get proofs, it goes to a follower that doesn't have a bit enough tree size, so it gets an error, accompanied with its (older) STH
3. client tries to get proofs again, based on the older STH tree size, it goes to the leader, which can answer the query, and the client can verify it against the STH it received previously

This would still be an extension from what is specified in the RFC, but can be implemented within it (the RFC doesn't specify at all the body of the response in case of error).

If launch the tool "python print_log_list.py" I get the following error:

Traceback (most recent call last):
File "print_log_list.py", line 155, in
sys.argv = FLAGS(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/gflags.py", line 1333, in call
self._AssertAllValidators()
File "/usr/local/lib/python2.7/dist-packages/gflags.py", line 1074, in _AssertAllValidators
self._AssertValidators(all_validators)
File "/usr/local/lib/python2.7/dist-packages/gflags.py", line 1093, in _AssertValidators
raise IllegalFlagValue('%s: %s' % (message, str(e)))
gflags.IllegalFlagValue: flag --log_list=None: Flag --log_list must be specified.

I think I fulfill all requirements, according to "pip install -r requirements.txt" output.
Thanks

If a get-entries request is received for entries that we do not have, we should return what we do have.

This will be especially important in the context of a clustered implementation, where a request might be routed to a server that's a bit behind in the replication. The client should at least get what it can, and keep retrying to get what it's still missing, in that case.