tor-commits April 2014

tor-commits@lists.torproject.org

22 participants
2020 discussions

[tor/maint-0.2.4] Fill in the list of blacklisted signing keys.
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit 46cf63bb42f2818201bc0c39036f2c17e210fcdb Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 16:03:53 2014 -0400 Fill in the list of blacklisted signing keys. I used a list of certificate files from arma, and a little script, both at 11464. --- src/or/routerlist.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/or/routerlist.c b/src/or/routerlist.c index e993e13..7cbf6ef 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -459,7 +459,18 @@ authority_cert_dl_failed(const char *id_digest, int status) } static const char *BAD_SIGNING_KEYS[] = { - "----------------------------------------", + "09CD84F751FD6E955E0F8ADB497D5401470D697E", // Expires 2015-01-11 16:26:31 +// dizum still needs to rotate as of 2014-04-04 +//"0E7E9C07F0969D0468AD741E172A6109DC289F3C", // Expires 2014-08-12 10:18:26 +// dannenberg still needs to rotate as of 2014-04-04 +//"57B85409891D3FB32137F642FDEDF8B7F8CDFDCD", // Expires 2015-02-11 17:19:09 + "87326329007AF781F587AF5B594E540B2B6C7630", // Expires 2014-07-17 11:10:09 + "98CC82342DE8D298CF99D3F1A396475901E0D38E", // Expires 2014-11-10 13:18:56 + "9904B52336713A5ADCB13E4FB14DC919E0D45571", // Expires 2014-04-20 20:01:01 + "9DCD8E3F1DD1597E2AD476BBA28A1A89F3095227", // Expires 2015-01-16 03:52:30 + "A61682F34B9BB9694AC98491FE1ABBFE61923941", // Expires 2014-06-11 09:25:09 + "B59F6E99C575113650C99F1C425BA7B20A8C071D", // Expires 2014-07-31 13:22:10 + "D27178388FA75B96D37FA36E0B015227DDDBDA51", // Expires 2014-08-04 04:01:57 NULL, };

1 0

[tor/maint-0.2.4] Merge remote-tracking branch 'origin/maint-0.2.3' into maint-0.2.4
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit 149931571a4c5ad9ec24eb6d4306e8965a454211 Merge: 47f7085 75b4975 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 18:00:38 2014 -0400 Merge remote-tracking branch 'origin/maint-0.2.3' into maint-0.2.4 Conflicts: src/or/routerlist.h changes/bug11464_023 | 5 +++++ src/or/networkstatus.c | 11 +++++++++++ src/or/routerlist.c | 33 +++++++++++++++++++++++++++++++++ src/or/routerlist.h | 1 + src/or/routerparse.c | 8 ++++++++ 5 files changed, 58 insertions(+) diff --cc src/or/routerlist.c index cb39729,a7968be..b49dc1a --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@@ -600,39 -455,42 +600,72 @@@ authority_cert_dl_failed(const char *id !(cl = digestmap_get(trusted_dir_certs, id_digest))) return; - download_status_failed(&cl->dl_status, status); + /* + * Are we noting a failed download of the latest cert for the id digest, + * or of a download by (id, signing key) digest pair? + */ + if (!signing_key_digest) { + /* Just by id digest */ + download_status_failed(&cl->dl_status_by_id, status); + } else { + /* Reset by (id, signing key) digest pair + * + * Look for a download_status_t in the map with this digest + */ + dlstatus = dsmap_get(cl->dl_status_map, signing_key_digest); + /* Got one? */ + if (dlstatus) { + download_status_failed(dlstatus, status); + } else { + /* + * Do this rather than hex_str(), since hex_str clobbers + * old results and we call twice in the param list. + */ + base16_encode(id_digest_str, sizeof(id_digest_str), + id_digest, DIGEST_LEN); + base16_encode(sk_digest_str, sizeof(sk_digest_str), + signing_key_digest, DIGEST_LEN); + log_warn(LD_BUG, + "Got failure for cert fetch with (fp,sk) = (%s,%s), with " + "status %d, but knew nothing about the download.", + id_digest_str, sk_digest_str, status); + } + } } + static const char *BAD_SIGNING_KEYS[] = { + "09CD84F751FD6E955E0F8ADB497D5401470D697E", // Expires 2015-01-11 16:26:31 + // dizum still needs to rotate as of 2014-04-14 + //"0E7E9C07F0969D0468AD741E172A6109DC289F3C", // Expires 2014-08-12 10:18:26 + // dannenberg still needs to rotate as of 2014-04-14 + //"57B85409891D3FB32137F642FDEDF8B7F8CDFDCD", // Expires 2015-02-11 17:19:09 + "87326329007AF781F587AF5B594E540B2B6C7630", // Expires 2014-07-17 11:10:09 + "98CC82342DE8D298CF99D3F1A396475901E0D38E", // Expires 2014-11-10 13:18:56 + "9904B52336713A5ADCB13E4FB14DC919E0D45571", // Expires 2014-04-20 20:01:01 + "9DCD8E3F1DD1597E2AD476BBA28A1A89F3095227", // Expires 2015-01-16 03:52:30 + "A61682F34B9BB9694AC98491FE1ABBFE61923941", // Expires 2014-06-11 09:25:09 + "B59F6E99C575113650C99F1C425BA7B20A8C071D", // Expires 2014-07-31 13:22:10 + "D27178388FA75B96D37FA36E0B015227DDDBDA51", // Expires 2014-08-04 04:01:57 + NULL, + }; + + /** DOCDOC */ + int + authority_cert_is_blacklisted(const authority_cert_t *cert) + { + char hex_digest[HEX_DIGEST_LEN+1]; + int i; + base16_encode(hex_digest, sizeof(hex_digest), + cert->signing_key_digest, sizeof(cert->signing_key_digest)); + + for (i = 0; BAD_SIGNING_KEYS[i]; ++i) { + if (!strcasecmp(hex_digest, BAD_SIGNING_KEYS[i])) { + return 1; + } + } + return 0; + } + /** Return true iff when we've been getting enough failures when trying to * download the certificate with ID digest <b>id_digest</b> that we're willing * to start bugging the user about it. */ diff --cc src/or/routerlist.h index ce0f0f2,bd55b7b..5056858 --- a/src/or/routerlist.h +++ b/src/or/routerlist.h @@@ -39,8 -25,8 +39,9 @@@ void authority_cert_dl_failed(const cha void authority_certs_fetch_missing(networkstatus_t *status, time_t now); int router_reload_router_list(void); int authority_cert_dl_looks_uncertain(const char *id_digest); +const smartlist_t *router_get_trusted_dir_servers(void); +const smartlist_t *router_get_fallback_dir_servers(void); + int authority_cert_is_blacklisted(const authority_cert_t *cert); -smartlist_t *router_get_trusted_dir_servers(void); const routerstatus_t *router_pick_directory_server(dirinfo_type_t type, int flags);

1 0

[tor/maint-0.2.4] Merge branch 'bug11464_023_squashed' into maint-0.2.3
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit 75b4975d7722d9497847fdab8dcfb2ac10f58fdb Merge: 2658e70 09ed8a5 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 17:59:01 2014 -0400 Merge branch 'bug11464_023_squashed' into maint-0.2.3 changes/bug11464_023 | 5 +++++ src/or/networkstatus.c | 11 +++++++++++ src/or/routerlist.c | 33 +++++++++++++++++++++++++++++++++ src/or/routerlist.h | 1 + src/or/routerparse.c | 8 ++++++++ 5 files changed, 58 insertions(+)

1 0

[tor/maint-0.2.3] Code to blacklist authority signing keys
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit 50ad3939242885b1a1a11688abd0c9756631747f Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 11 10:22:14 2014 -0400 Code to blacklist authority signing keys (I need a list of actual signing keys to blacklist.) --- changes/bug11464_023 | 5 +++++ src/or/networkstatus.c | 11 +++++++++++ src/or/routerlist.c | 22 ++++++++++++++++++++++ src/or/routerlist.h | 1 + src/or/routerparse.c | 8 ++++++++ 5 files changed, 47 insertions(+) diff --git a/changes/bug11464_023 b/changes/bug11464_023 new file mode 100644 index 0000000..a9cd658 --- /dev/null +++ b/changes/bug11464_023 @@ -0,0 +1,5 @@ + o Major features (security): + - Block every authority signing key that was used on an authority + vulnerable to the "heartbleed" bug in openssl (CVE-2014-0160). + (We don't have any evidence that these keys _were_ compromised; + we're doing this to be prudent.) Resolves ticket 11464. diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c index e780ead..10cc562 100644 --- a/src/or/networkstatus.c +++ b/src/or/networkstatus.c @@ -453,6 +453,17 @@ networkstatus_check_document_signature(const networkstatus_t *consensus, DIGEST_LEN)) return -1; + if (authority_cert_is_blacklisted(cert)) { + /* We implement blacklisting for authority signing keys by treating + * all their signatures as always bad. That way we don't get into + * crazy loops of dropping and re-fetching signatures. */ + log_warn(LD_DIR, "Ignoring a consensus signature made with deprecated" + " signing key %s", + hex_str(cert->signing_key_digest, DIGEST_LEN)); + sig->bad_signature = 1; + return 0; + } + signed_digest_len = crypto_pk_keysize(cert->signing_key); signed_digest = tor_malloc(signed_digest_len); if (crypto_pk_public_checksig(cert->signing_key, diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 3c39e36..e993e13 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -458,6 +458,28 @@ authority_cert_dl_failed(const char *id_digest, int status) download_status_failed(&cl->dl_status, status); } +static const char *BAD_SIGNING_KEYS[] = { + "----------------------------------------", + NULL, +}; + +/** DOCDOC */ +int +authority_cert_is_blacklisted(const authority_cert_t *cert) +{ + char hex_digest[HEX_DIGEST_LEN+1]; + int i; + base16_encode(hex_digest, sizeof(hex_digest), + cert->signing_key_digest, sizeof(cert->signing_key_digest)); + + for (i = 0; BAD_SIGNING_KEYS[i]; ++i) { + if (!strcasecmp(hex_digest, BAD_SIGNING_KEYS[i])) { + return 1; + } + } + return 0; +} + /** Return true iff when we've been getting enough failures when trying to * download the certificate with ID digest <b>id_digest</b> that we're willing * to start bugging the user about it. */ diff --git a/src/or/routerlist.h b/src/or/routerlist.h index 8dcc6eb..bd55b7b 100644 --- a/src/or/routerlist.h +++ b/src/or/routerlist.h @@ -25,6 +25,7 @@ void authority_cert_dl_failed(const char *id_digest, int status); void authority_certs_fetch_missing(networkstatus_t *status, time_t now); int router_reload_router_list(void); int authority_cert_dl_looks_uncertain(const char *id_digest); +int authority_cert_is_blacklisted(const authority_cert_t *cert); smartlist_t *router_get_trusted_dir_servers(void); const routerstatus_t *router_pick_directory_server(dirinfo_type_t type, diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 299d07d..97e0bc8 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3053,6 +3053,14 @@ networkstatus_parse_vote_from_string(const char *s, const char **eos_out, log_warn(LD_DIR,"Mismatch between identities in certificate and vote"); goto err; } + if (ns->type != NS_TYPE_CONSENSUS) { + if (authority_cert_is_blacklisted(ns->cert)) { + log_warn(LD_DIR, "Rejecting vote signature made with blacklisted " + "signing key %s", + hex_str(ns->cert->signing_key_digest, DIGEST_LEN)); + goto err; + } + } voter->address = tor_strdup(tok->args[2]); if (!tor_inet_aton(tok->args[3], &in)) { log_warn(LD_DIR, "Error decoding IP address %s in network-status.",

1 0

[tor/maint-0.2.3] Tweak changes file and comment dates.
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit 09ed8a5dbb5216caae0055c1608abbc8c76412c9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 17:58:49 2014 -0400 Tweak changes file and comment dates. --- changes/bug11464_023 | 2 +- src/or/routerlist.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/changes/bug11464_023 b/changes/bug11464_023 index a9cd658..80c04b2 100644 --- a/changes/bug11464_023 +++ b/changes/bug11464_023 @@ -1,5 +1,5 @@ o Major features (security): - - Block every authority signing key that was used on an authority + - Block authority signing keys that were used on an authorities vulnerable to the "heartbleed" bug in openssl (CVE-2014-0160). (We don't have any evidence that these keys _were_ compromised; we're doing this to be prudent.) Resolves ticket 11464. diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 7cbf6ef..a7968be 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -460,9 +460,9 @@ authority_cert_dl_failed(const char *id_digest, int status) static const char *BAD_SIGNING_KEYS[] = { "09CD84F751FD6E955E0F8ADB497D5401470D697E", // Expires 2015-01-11 16:26:31 -// dizum still needs to rotate as of 2014-04-04 +// dizum still needs to rotate as of 2014-04-14 //"0E7E9C07F0969D0468AD741E172A6109DC289F3C", // Expires 2014-08-12 10:18:26 -// dannenberg still needs to rotate as of 2014-04-04 +// dannenberg still needs to rotate as of 2014-04-14 //"57B85409891D3FB32137F642FDEDF8B7F8CDFDCD", // Expires 2015-02-11 17:19:09 "87326329007AF781F587AF5B594E540B2B6C7630", // Expires 2014-07-17 11:10:09 "98CC82342DE8D298CF99D3F1A396475901E0D38E", // Expires 2014-11-10 13:18:56

1 0

[tor/maint-0.2.3] Fill in the list of blacklisted signing keys.
by nickm＠torproject.org 14 Apr '14

14 Apr '14

1 0

[tor/maint-0.2.3] Merge branch 'bug11464_023_squashed' into maint-0.2.3
by nickm＠torproject.org 14 Apr '14

14 Apr '14

1 0

[torspec/master] Clarify 232 status
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit abbfc2767d5bbaa81133869ad23926b283c2aed6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 16:40:20 2014 -0400 Clarify 232 status --- proposals/000-index.txt | 4 ++-- proposals/232-pluggable-transports-through-proxy.txt | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index b6742d4..6964e2e 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -152,7 +152,7 @@ Proposals by number: 229 Further SOCKS5 extensions [DRAFT] 230 How to change RSA1024 relay identity keys [DRAFT] 231 Migrating authority RSA1024 identity keys [DRAFT] -232 Pluggable Transport through SOCKS proxy [DRAFT] +232 Pluggable Transport through SOCKS proxy [OPEN] Proposals by status: @@ -174,7 +174,6 @@ Proposals by status: 229 Further SOCKS5 extensions 230 How to change RSA1024 relay identity keys [for 0.2.?] 231 Migrating authority RSA1024 identity keys [for 0.2.?] - 232 Pluggable Transport through SOCKS proxy NEEDS-REVISION: 131 Help users to verify they are using Tor 190 Bridge Client Authorization Based on a Shared Secret @@ -208,6 +207,7 @@ Proposals by status: 226 "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS" 227 Include package fingerprints in consensus documents 228 Cross-certifying identity keys with onion keys + 232 Pluggable Transport through SOCKS proxy [for 0.2.6.x] ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/232-pluggable-transports-through-proxy.txt b/proposals/232-pluggable-transports-through-proxy.txt index ba32ded..c861a1f 100644 --- a/proposals/232-pluggable-transports-through-proxy.txt +++ b/proposals/232-pluggable-transports-through-proxy.txt @@ -2,7 +2,8 @@ Filename: 232-pluggable-transports-through-proxy.txt Title: Pluggable Transport through SOCKS proxy Author: Arturo Filastò Created: 28 February 2012 -Status: Draft +Status: Open +Target: 0.2.6.x Overview

1 0

[torspec/master] Add proposals 233 and 234 from Virgil Griffith et al
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit f1ea369418afc2bbbce3288ab2b5f1c1d88a8e5d Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 16:49:18 2014 -0400 Add proposals 233 and 234 from Virgil Griffith et al --- proposals/233-quicken-tor2web-mode.txt | 32 ++++++++++++++++++++++++++++ proposals/234-remittance-addresses.txt | 36 ++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+) diff --git a/proposals/233-quicken-tor2web-mode.txt b/proposals/233-quicken-tor2web-mode.txt new file mode 100644 index 0000000..433e2a7 --- /dev/null +++ b/proposals/233-quicken-tor2web-mode.txt @@ -0,0 +1,32 @@ +Filename: 233-quicken-tor2web-mode.txt +Title: Making Tor2Web mode faster +Author: Virgil Griffith, Fabio Pietrosanti, Giovanni Pellerano +Created: 2014-03-27 +Status: Open + + +1. Introduction +While chatting with the Tor archons at the winter meeting, two speed +optimizations for tor2web mode [1] were put forward. This proposal specifies +concretizes these two optimizations. As with the current tor2web mode, this +quickened tor2web mode negates any client anonymity. + + +2. Tor2web optimizations + 2.1) self-rendezvous + In the current tor2web mode, the client establishes a 1-hop circuit (direct + connection) to a chosen rendezvous point. We propose that, alternatively, + the client set *itself* as the rendezvous point. This coincides with ticket + #9685[2]. + + + 2.2) direct-introduction + Identical to the non-tor2web mode, in the current tor2web mode, the + client establishes a 3-hop circuit to the introduction point. + We propose that, alternatively, the client builds a 1-hop circuit to + the introduction point. + + +4. References +[1] Tor2web mode: https://trac.torproject.org/projects/tor/ticket/2553 +[2] Self-rendezvous: https://trac.torproject.org/projects/tor/ticket/9685 diff --git a/proposals/234-remittance-addresses.txt b/proposals/234-remittance-addresses.txt new file mode 100644 index 0000000..55cd8bd --- /dev/null +++ b/proposals/234-remittance-addresses.txt @@ -0,0 +1,36 @@ +Filename: 234-remittance-addresses.txt +Title: Adding remittance field to directory specification +Author: Virgil Griffith, Leif Ryge, Rob Jansen +Created: 2014-03-27 +Status: Open + + +1. Motivation +We wish to add the ability for individual users to donate to the owners of +relay operators using a cryptocurrency. We propose adding an optional line to +the torrc file which will be published in the directory consensus and listed +on https://compass.torproject.org. + + +2. Proposal +Allow an optional "RemittanceAddresses" line to the torrc file containing +comma-delimited cryptocurrency URIs. The format is: + +RemittanceAddressses <currency1>:<address>1,<currency2>:<address2> + +For an example using an actual bitcoin and namecoin address, this is: + +RemittanceAddressses bitcoin:19mP9FKrXqL46Si58pHdhGKow88SUPy1V8,namecoin:NAMEuWT2icj3ef8HWJwetZyZbXaZUJ5hFT + +The contents of a relay's RemittanceAddresses line will be mirrored in +the relay's router descriptor (which is then published in the directory +consensus). This line will be treated akin to the ContactInfo field. A +cryptocurrency address may not contain a colon, comma, whitespace, or other +nonprintable ASCII. + +Like the ContactInfo line, there is no explicit length limit for +RemittanceAddressses---the only limit is the length of the entire descriptor. +If the relay lists multiple addresses of the same currency type (e.g., two +bitcoin addresses), only the first (left-most) one of each currency is +published in the directory consensus. +

1 0

[torspec/master] Reflow proposals 233, 234.
by nickm＠torproject.org 14 Apr '14

14 Apr '14

commit 1c57e5de3b0de3eee2ee44b1ae2a0c800c2d5a76 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 16:52:29 2014 -0400 Reflow proposals 233, 234. --- proposals/000-index.txt | 4 ++++ proposals/233-quicken-tor2web-mode.txt | 35 ++++++++++++++------------- proposals/234-remittance-addresses.txt | 41 +++++++++++++++++--------------- 3 files changed, 45 insertions(+), 35 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 6964e2e..dc257ae 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -153,6 +153,8 @@ Proposals by number: 230 How to change RSA1024 relay identity keys [DRAFT] 231 Migrating authority RSA1024 identity keys [DRAFT] 232 Pluggable Transport through SOCKS proxy [OPEN] +233 Making Tor2Web mode faster [OPEN] +234 Adding remittance field to directory specification [OPEN] Proposals by status: @@ -208,6 +210,8 @@ Proposals by status: 227 Include package fingerprints in consensus documents 228 Cross-certifying identity keys with onion keys 232 Pluggable Transport through SOCKS proxy [for 0.2.6.x] + 233 Making Tor2Web mode faster + 234 Adding remittance field to directory specification ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/233-quicken-tor2web-mode.txt b/proposals/233-quicken-tor2web-mode.txt index 433e2a7..325ff87 100644 --- a/proposals/233-quicken-tor2web-mode.txt +++ b/proposals/233-quicken-tor2web-mode.txt @@ -6,27 +6,30 @@ Status: Open 1. Introduction -While chatting with the Tor archons at the winter meeting, two speed -optimizations for tor2web mode [1] were put forward. This proposal specifies -concretizes these two optimizations. As with the current tor2web mode, this -quickened tor2web mode negates any client anonymity. + While chatting with the Tor archons at the winter meeting, two speed + optimizations for tor2web mode [1] were put forward. This proposal + specifies concretizes these two optimizations. As with the current + tor2web mode, this quickened tor2web mode negates any client + anonymity. 2. Tor2web optimizations - 2.1) self-rendezvous - In the current tor2web mode, the client establishes a 1-hop circuit (direct - connection) to a chosen rendezvous point. We propose that, alternatively, - the client set *itself* as the rendezvous point. This coincides with ticket - #9685[2]. +2.1. Self-rendezvous - 2.2) direct-introduction - Identical to the non-tor2web mode, in the current tor2web mode, the - client establishes a 3-hop circuit to the introduction point. - We propose that, alternatively, the client builds a 1-hop circuit to - the introduction point. + In the current tor2web mode, the client establishes a 1-hop circuit + (direct connection) to a chosen rendezvous point. We propose that, + alternatively, the client set *itself* as the rendezvous point. This + coincides with ticket #9685[2]. + +2.2. direct-introduction + Identical to the non-tor2web mode, in the current tor2web mode, the + client establishes a 3-hop circuit to the introduction point. We + propose that, alternatively, the client builds a 1-hop circuit to the + introduction point. 4. References -[1] Tor2web mode: https://trac.torproject.org/projects/tor/ticket/2553 -[2] Self-rendezvous: https://trac.torproject.org/projects/tor/ticket/9685 + + [1] Tor2web mode: https://trac.torproject.org/projects/tor/ticket/2553 + [2] Self-rendezvous: https://trac.torproject.org/projects/tor/ticket/9685 diff --git a/proposals/234-remittance-addresses.txt b/proposals/234-remittance-addresses.txt index 55cd8bd..303df85 100644 --- a/proposals/234-remittance-addresses.txt +++ b/proposals/234-remittance-addresses.txt @@ -6,31 +6,34 @@ Status: Open 1. Motivation -We wish to add the ability for individual users to donate to the owners of -relay operators using a cryptocurrency. We propose adding an optional line to -the torrc file which will be published in the directory consensus and listed -on https://compass.torproject.org. + + We wish to add the ability for individual users to donate to the + owners of relay operators using a cryptocurrency. We propose adding + an optional line to the torrc file which will be published in the + directory consensus and listed on https://compass.torproject.org. 2. Proposal -Allow an optional "RemittanceAddresses" line to the torrc file containing -comma-delimited cryptocurrency URIs. The format is: -RemittanceAddressses <currency1>:<address>1,<currency2>:<address2> + Allow an optional "RemittanceAddresses" line to the torrc file + containing comma-delimited cryptocurrency URIs. The format is: + + RemittanceAddressses <currency1>:<address>1,<currency2>:<address2> -For an example using an actual bitcoin and namecoin address, this is: + For an example using an actual bitcoin and namecoin address, this is: -RemittanceAddressses bitcoin:19mP9FKrXqL46Si58pHdhGKow88SUPy1V8,namecoin:NAMEuWT2icj3ef8HWJwetZyZbXaZUJ5hFT + RemittanceAddressses bitcoin:19mP9FKrXqL46Si58pHdhGKow88SUPy1V8,namecoin:NAMEuWT2icj3ef8HWJwetZyZbXaZUJ5hFT -The contents of a relay's RemittanceAddresses line will be mirrored in -the relay's router descriptor (which is then published in the directory -consensus). This line will be treated akin to the ContactInfo field. A -cryptocurrency address may not contain a colon, comma, whitespace, or other -nonprintable ASCII. + The contents of a relay's RemittanceAddresses line will be mirrored in + the relay's router descriptor (which is then published in the + directory consensus). This line will be treated akin to the + ContactInfo field. A cryptocurrency address may not contain a colon, + comma, whitespace, or other nonprintable ASCII. -Like the ContactInfo line, there is no explicit length limit for -RemittanceAddressses---the only limit is the length of the entire descriptor. -If the relay lists multiple addresses of the same currency type (e.g., two -bitcoin addresses), only the first (left-most) one of each currency is -published in the directory consensus. + Like the ContactInfo line, there is no explicit length limit for + RemittanceAddressses---the only limit is the length of the entire + descriptor. If the relay lists multiple addresses of the same + currency type (e.g., two bitcoin addresses), only the first + (left-most) one of each currency is published in the directory + consensus.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2014