It is not the end of the world when a router descriptor has an unrecognized kwd

svn:r4480
This commit is contained in:
Nick Mathewson 2005-06-24 23:42:15 +00:00
parent c831a9f701
commit b759fe4b8d
2 changed files with 9 additions and 4 deletions

View File

@ -852,9 +852,14 @@ after "directory-signature". This digest is then padded with PKCS.1,
and signed with the directory server's signing key.
If software encounters an unrecognized keyword in a single router descriptor,
it should reject only that router descriptor, and continue using the
others. If it encounters an unrecognized keyword in the directory header,
it should reject the entire directory.
it MUST reject only that router descriptor, and continue using the
others. Because this mechanism is used to add 'critical' extensions to
future versions of the router descriptor format, implementation should treat
it as a normal occurrence and not, for example, report it to the user as an
error. [Versions of Tor prior to 0.1.1 did this.]
If software encounters an unrecognized keyword in the directory header,
it SHOULD reject the entire directory.
7.4. Network-status descriptor

View File

@ -853,7 +853,7 @@ router_parse_entry_from_string(const char *s, const char *end)
goto err;
}
if ((tok = find_first_by_keyword(tokens, _UNRECOGNIZED))) {
log_fn(LOG_WARN, "Unrecognized keyword '%s'; skipping descriptor.",
log_fn(LOG_INFO, "Unrecognized critical keyword '%s'; skipping descriptor. (It may be from another version of Tor.)",
tok->args[0]);
goto err;
}