Fix for bug 797 (by arma, with tweaks): always use create_fast for circuits where we do not know an onion key.

svn:r16942

ChangeLog

@@ -33,6 +33,9 @@ Changes in version 0.2.1.6-alpha - 2008-09-xx
       might succeed. Similarly, if the last v2 fetch fails, we were
       failing the whole hidden service request even if a v0 fetch is
       still pending. Fixes bug 814. Bugfix on 0.2.0.10-alpha.
+    - Avoid a bug where the FistFirstHopPK 0 option would keep Tor from
+      bootstrapping with tunneled directory connections.  Bugfix on
+      0.1.2.5-alpha.  Fixes bug 797.
 
   o Minor features:
     - Update to the "September 1 2008" ip-to-country file.

doc/tor.1.in

@@ -660,11 +660,14 @@ resolved.  This helps trap accidental attempts to resolve URLs and so on.
 .LP
 .TP
 \fBFastFirstHopPK \fR\fB0\fR|\fB1\fR\fP
-When this option is enabled and we aren't running as a server, Tor
-skips the public key step for the first hop of creating circuits.  This is
-safe since we have already used TLS to authenticate the server and to
-establish forward-secure keys.  Turning this option off makes circuit
-building slower.
+When this option is disabled, Tor uses the public key step for the first
+hop of creating circuits. Skipping it is generally safe since we have
+already used TLS to authenticate the relay and to establish forward-secure
+keys. Turning this option off makes circuit building slower.
+
+Note that Tor will always use the public key step for the first hop if
+it's operating as a relay, and it will never use the public key step if
+it doesn't yet know the onion key of the first hop.
 (Default: 1)
 .LP
 .TP

src/or/circuitbuild.c

@@ -537,19 +537,20 @@ inform_testing_reachability(void)
   return 1;
 }
 
-/** Return true iff we should send a create_fast cell to build a circuit
- * starting at <b>router</b>. (If <b>router</b> is NULL, we don't have
- * information on the router, so assume true.) */
+/** Return true iff we should send a create_fast cell to start building a given
+ * circuit */
 static INLINE int
-should_use_create_fast_for_router(routerinfo_t *router,
-                                  origin_circuit_t *circ)
+should_use_create_fast_for_circuit(origin_circuit_t *circ)
 {
   or_options_t *options = get_options();
-  (void) router; /* ignore the router's version. */
-
-  if (!options->FastFirstHopPK) /* create_fast is disabled */
-    return 0;
-  if (server_mode(options) && circ->cpath->extend_info->onion_key) {
+  tor_assert(circ->cpath);
+  tor_assert(circ->cpath->extend_info);
+
+  if (!circ->cpath->extend_info->onion_key)
+    return 1; /* our hand is forced: only a create_fast will work. */
+  if (!options->FastFirstHopPK)
+    return 0; /* we prefer to avoid create_fast */
+  if (server_mode(options)) {
     /* We're a server, and we know an onion key. We can choose.
      * Prefer to blend in. */
     return 0;
@@ -589,14 +590,9 @@ circuit_send_next_onion_skin(origin_circuit_t *circ)
       control_event_bootstrap(BOOTSTRAP_STATUS_CIRCUIT_CREATE, 0);
 
     router = router_get_by_digest(circ->_base.n_conn->identity_digest);
-    fast = should_use_create_fast_for_router(router, circ);
-    if (!fast && !circ->cpath->extend_info->onion_key) {
-      log_warn(LD_CIRC,
-               "Can't send create_fast, but have no onion key. Failing.");
-      return - END_CIRC_REASON_INTERNAL;
-    }
+    fast = should_use_create_fast_for_circuit(circ);
     if (!fast) {
-      /* We are an OR, or we are connecting to an old Tor: we should
+      /* We are an OR and we know the right onion key: we should
        * send an old slow create cell.
        */
       cell_type = CELL_CREATE;