mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-06 19:41:15 +01:00
easy tweaks on r12607
svn:r12608
This commit is contained in:
@@ -288,14 +288,10 @@ buf_shrink_freelists(int free_all)
|
||||
int i, n_to_skip, n_to_free;
|
||||
char **ptr;
|
||||
if (free_all) { /* Free every one of them */
|
||||
/* Just a consideration: Is this log statement really useful on
|
||||
* info level? -KL */
|
||||
log_debug(LD_GENERAL, "Freeing all %d elements from %d-byte freelist.",
|
||||
list->len, (int)list->chunksize);
|
||||
n_to_free = list->len;
|
||||
} else { /* Skip over the slack and non-lowwater entries */
|
||||
/* Just a consideration: Is this log statement really useful on
|
||||
* info level? -KL */
|
||||
log_debug(LD_GENERAL, "We haven't used %d/%d allocated %d-byte buffer "
|
||||
"memory chunks since the last call; freeing all but %d of "
|
||||
"them",
|
||||
@@ -379,8 +375,6 @@ buf_resize(buf_t *buf, size_t new_capacity)
|
||||
if (buf->mem)
|
||||
raw = tor_realloc(RAW_MEM(buf->mem), ALLOC_LEN(new_capacity));
|
||||
else {
|
||||
/* Just a consideration: Is this log statement really useful on
|
||||
* info level? -KL */
|
||||
log_debug(LD_GENERAL, "Jumping straight from 0 bytes to %d",
|
||||
(int)new_capacity);
|
||||
raw = tor_malloc(ALLOC_LEN(new_capacity));
|
||||
|
||||
@@ -1826,14 +1826,6 @@ typedef struct origin_circuit_t {
|
||||
/** Stores the rendezvous descriptor version if purpose is S_*. Used to
|
||||
* distinguish introduction and rendezvous points belonging to the same
|
||||
* rendezvous service ID, but different descriptor versions.
|
||||
* XXXX020 I believe this is a bitmap, but the doc doesn't say so. If so,
|
||||
* why? A circuit can't be using two different rendezvous decriptors. -NM
|
||||
* Yes, it is a bitmap. The reason is that it might turn out that a version
|
||||
* 3 _can_ use the same introduction point as version 2; only version 0
|
||||
* is incompatible. Would it be clearer to switch to a single version number
|
||||
* for now and switch back to a bitmap, when the above becomes true? -KL
|
||||
* Yes. "YAGNI." -NM
|
||||
* Now it's not a bitmap any more. -KL
|
||||
*/
|
||||
uint8_t rend_desc_version;
|
||||
|
||||
|
||||
+5
-13
@@ -60,15 +60,7 @@ typedef struct rend_service_t {
|
||||
rend_service_descriptor_t *desc;
|
||||
time_t desc_is_dirty;
|
||||
time_t next_upload_time;
|
||||
/* XXXX020 A service never actually has both descriptor versions; perhaps
|
||||
* this should be an int rather than in intmax. */
|
||||
/* A service can never publish v0 and v2 descriptors, but maybe it can
|
||||
* publish v2 and v3 descriptors in the future. As with origin_circuit_t:
|
||||
* Would it be clearer to switch to a single version number for now and
|
||||
* switch back to a bitmap, when the above becomes true? -KL */
|
||||
/* Yes. s/when/if/. "YAGNI" -NM. */
|
||||
/* Now it's used as version number, not as bitmask. -KL */
|
||||
int descriptor_version; /**< rendezvous descriptor version that will be
|
||||
int descriptor_version; /**< Rendezvous descriptor version that will be
|
||||
* published. */
|
||||
} rend_service_t;
|
||||
|
||||
@@ -133,7 +125,7 @@ rend_service_free_all(void)
|
||||
/** Validate <b>service</b> and add it to rend_service_list if possible.
|
||||
*/
|
||||
static void
|
||||
add_service(rend_service_t *service)
|
||||
rend_add_service(rend_service_t *service)
|
||||
{
|
||||
int i;
|
||||
rend_service_port_config_t *p;
|
||||
@@ -163,7 +155,7 @@ add_service(rend_service_t *service)
|
||||
v0_service->intro_exclude_nodes = tor_strdup(service->intro_exclude_nodes);
|
||||
v0_service->intro_period_started = service->intro_period_started;
|
||||
v0_service->descriptor_version = 0; /* Unversioned descriptor. */
|
||||
add_service(v0_service);
|
||||
rend_add_service(v0_service);
|
||||
|
||||
service->descriptor_version = 2; /* Versioned descriptor. */
|
||||
}
|
||||
@@ -275,7 +267,7 @@ rend_config_services(or_options_t *options, int validate_only)
|
||||
if (validate_only)
|
||||
rend_service_free(service);
|
||||
else
|
||||
add_service(service);
|
||||
rend_add_service(service);
|
||||
}
|
||||
service = tor_malloc_zero(sizeof(rend_service_t));
|
||||
service->directory = tor_strdup(line->value);
|
||||
@@ -340,7 +332,7 @@ rend_config_services(or_options_t *options, int validate_only)
|
||||
if (validate_only)
|
||||
rend_service_free(service);
|
||||
else
|
||||
add_service(service);
|
||||
rend_add_service(service);
|
||||
}
|
||||
|
||||
return 0;
|
||||
|
||||
@@ -3261,10 +3261,11 @@ rend_parse_v2_service_descriptor(rend_service_descriptor_t **parsed_out,
|
||||
/* If it's <2, it shouldn't be under this format. If the number
|
||||
* is greater than 2, we bumped it because we broke backward
|
||||
* compatibility. See how version numbers in our other formats
|
||||
* work. */
|
||||
* work. -NM */
|
||||
/* That means that adding optional fields to the descriptor wouldn't
|
||||
* require a new version number, but the way of verifying it's origin
|
||||
* would. Okay. -KL */
|
||||
/* XXX020 Nick, confirm that you're happy here -RD */
|
||||
log_warn(LD_REND, "Wrong descriptor version: %d", result->version);
|
||||
goto err;
|
||||
}
|
||||
@@ -3304,7 +3305,7 @@ rend_parse_v2_service_descriptor(rend_service_descriptor_t **parsed_out,
|
||||
smartlist_split_string(versions, tok->args[0], ",",
|
||||
SPLIT_SKIP_SPACE|SPLIT_IGNORE_BLANK, 0);
|
||||
for (i = 0; i < smartlist_len(versions); i++) {
|
||||
/* XXXX020 validate the numbers here. */
|
||||
/* XXXX020 validate the numbers here. -NM */
|
||||
/* As above, validating these numbers on a hidden service directory
|
||||
* might require an extension to new valid numbers at some time. But
|
||||
* this would require making a distinction of hidden service direcoties
|
||||
@@ -3313,13 +3314,14 @@ rend_parse_v2_service_descriptor(rend_service_descriptor_t **parsed_out,
|
||||
/* As above, increased version numbers are for
|
||||
* non-backward-compatible changes. This code doesn't know how to
|
||||
* parse a v3 descriptor, because a v3 descriptor is by definition not
|
||||
* compatible with this code. */
|
||||
* compatible with this code. -NM */
|
||||
/* This refers to the permitted versions of introduction cells which might
|
||||
* change independently from the descriptor version. If we validated the
|
||||
* numbers here, a hidden service directory might reject a descriptor that
|
||||
* would be understood by newer clients. Then we would need a "HSDir3" tag
|
||||
* only to be able to use a new introduction cell version. I really think
|
||||
* we should not validate it here. -KL */
|
||||
/* XXX020 Nick, confirm that you're happy here -RD */
|
||||
version = atoi(smartlist_get(versions, i));
|
||||
result->protocols |= 1 << version;
|
||||
}
|
||||
@@ -3475,8 +3477,9 @@ rend_decrypt_introduction_points(rend_service_descriptor_t *parsed,
|
||||
/* Parse onion port. */
|
||||
tok = find_first_by_keyword(tokens, R_IPO_ONION_PORT);
|
||||
info->port = (uint16_t) atoi(tok->args[0]);
|
||||
/* XXXX020 this next check fails with ports like 65537. */
|
||||
/* XXXX020 this next check fails with ports like 65537. -NM */
|
||||
/* No, uint16_t only allows numbers in the interval 0..65535. -KL */
|
||||
/* XXX020 Nick, confirm that you're happy here -RD */
|
||||
if (!info->port) {
|
||||
log_warn(LD_REND, "Introduction point onion port is out of range: %d",
|
||||
info->port);
|
||||
|
||||
Reference in New Issue
Block a user