February 2016 - tor-commits - lists.torproject.org

[nyx/master] Couple missed s/arm/nyx
by atagar＠torproject.org 26 Feb '16

26 Feb '16

commit e83b9efb88a2c8991a06f9c4c28a70603544373e Author: Damian Johnson <atagar(a)torproject.org> Date: Fri Feb 26 08:34:32 2016 -0800 Couple missed s/arm/nyx Caught thanks to cypherpunks on... https://trac.torproject.org/projects/tor/ticket/18065#comment:6 --- README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index 0922802..8b79069 100644 --- a/README +++ b/README @@ -87,7 +87,7 @@ share and it should be fine. > Is there any chance that nyx will leak data? -No. Arm is a completely passive listener, fetching all information from either +No. Nyx is a completely passive listener, fetching all information from either Tor or the local system. > When nyx starts it gives "Unable to resolve tor pid, abandoning connection @@ -96,7 +96,7 @@ listing"... why? If you're running multiple instances of Tor then nyx needs to figure out which pid belongs to the open control port. If it's running as a different user (such as being in a chroot jail) then it's probably failing due to permission issues. -Arm still runs, just no connection listing or ps stats. +Nyx still runs, just no connection listing or ps stats. > The bandwidth graph isn't showing up

1 0

[translation/https_everywhere_completed] Update translations for https_everywhere_completed
by translation＠torproject.org 26 Feb '16

26 Feb '16

commit 483f244bff43583387b6fc757bd7e12bf4b8da6f Author: Translation commit bot <translation(a)torproject.org> Date: Fri Feb 26 09:45:20 2016 +0000 Update translations for https_everywhere_completed --- de/https-everywhere.dtd | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/de/https-everywhere.dtd b/de/https-everywhere.dtd index 391ad99..e26f98d 100644 --- a/de/https-everywhere.dtd +++ b/de/https-everywhere.dtd @@ -14,6 +14,7 @@ <!ENTITY https-everywhere.about.or "oder"> <!ENTITY https-everywhere.about.donate_eff "An EFF spenden"> +<!ENTITY https-everywhere.menu.donate_eff_imperative "Spende an EFF"> <!ENTITY https-everywhere.menu.about "Über HTTPS Everywhere"> <!ENTITY https-everywhere.menu.observatory "SSL-Observatory-Einstellungen"> <!ENTITY https-everywhere.menu.globalEnable "HTTPS Everywhere aktivieren"> @@ -41,3 +42,15 @@ <!ENTITY https-everywhere.chrome.stable_rules_description "Erzwingen Sie eine verschlüsselte Verbindung zu diesen Webseiten:"> <!ENTITY https-everywhere.chrome.experimental_rules "Experimentelle Regeln"> <!ENTITY https-everywhere.chrome.experimental_rules_description "Kann Warnungen oder Abstürze verursachen. Standardmäßig deaktiviert."> +<!ENTITY https-everywhere.chrome.add_rule "Erstelle eine Regel für diese Seite"> +<!ENTITY https-everywhere.chrome.add_new_rule "Erstelle eine neue Regel für diese Seite"> +<!ENTITY https-everywhere.chrome.always_https_for_host "Benutze immer https für diesen host"> +<!ENTITY https-everywhere.chrome.host "Host:"> +<!ENTITY https-everywhere.chrome.show_advanced "Erweiterte Optionen anzeigen"> +<!ENTITY https-everywhere.chrome.hide_advanced "Erweiterte Optionen ausblenden"> +<!ENTITY https-everywhere.chrome.rule_name "Regelname"> +<!ENTITY https-everywhere.chrome.regex "Übereinstimmende regex"> +<!ENTITY https-everywhere.chrome.redirect_to "Weiterleiten nach"> +<!ENTITY https-everywhere.chrome.status_cancel_button "Abbrechen"> + +

1 0

[translation/https_everywhere] Update translations for https_everywhere
by translation＠torproject.org 26 Feb '16

26 Feb '16

commit e15bdead208f925e5d26cb05dc36aadbcd57cf11 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Feb 26 09:45:15 2016 +0000 Update translations for https_everywhere --- de/https-everywhere.dtd | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/de/https-everywhere.dtd b/de/https-everywhere.dtd index 3767b37..e26f98d 100644 --- a/de/https-everywhere.dtd +++ b/de/https-everywhere.dtd @@ -14,7 +14,7 @@ <!ENTITY https-everywhere.about.or "oder"> <!ENTITY https-everywhere.about.donate_eff "An EFF spenden"> -<!ENTITY https-everywhere.menu.donate_eff_imperative "Donate to EFF"> +<!ENTITY https-everywhere.menu.donate_eff_imperative "Spende an EFF"> <!ENTITY https-everywhere.menu.about "Über HTTPS Everywhere"> <!ENTITY https-everywhere.menu.observatory "SSL-Observatory-Einstellungen"> <!ENTITY https-everywhere.menu.globalEnable "HTTPS Everywhere aktivieren"> @@ -42,15 +42,15 @@ <!ENTITY https-everywhere.chrome.stable_rules_description "Erzwingen Sie eine verschlüsselte Verbindung zu diesen Webseiten:"> <!ENTITY https-everywhere.chrome.experimental_rules "Experimentelle Regeln"> <!ENTITY https-everywhere.chrome.experimental_rules_description "Kann Warnungen oder Abstürze verursachen. Standardmäßig deaktiviert."> -<!ENTITY https-everywhere.chrome.add_rule "Add a rule for this site"> -<!ENTITY https-everywhere.chrome.add_new_rule "Add a new rule for this site"> -<!ENTITY https-everywhere.chrome.always_https_for_host "Always use https for this host"> +<!ENTITY https-everywhere.chrome.add_rule "Erstelle eine Regel für diese Seite"> +<!ENTITY https-everywhere.chrome.add_new_rule "Erstelle eine neue Regel für diese Seite"> +<!ENTITY https-everywhere.chrome.always_https_for_host "Benutze immer https für diesen host"> <!ENTITY https-everywhere.chrome.host "Host:"> -<!ENTITY https-everywhere.chrome.show_advanced "Show advanced"> -<!ENTITY https-everywhere.chrome.hide_advanced "Hide advanced"> -<!ENTITY https-everywhere.chrome.rule_name "Rule name"> -<!ENTITY https-everywhere.chrome.regex "Matching regex"> -<!ENTITY https-everywhere.chrome.redirect_to "Redirect to"> -<!ENTITY https-everywhere.chrome.status_cancel_button "Cancel"> +<!ENTITY https-everywhere.chrome.show_advanced "Erweiterte Optionen anzeigen"> +<!ENTITY https-everywhere.chrome.hide_advanced "Erweiterte Optionen ausblenden"> +<!ENTITY https-everywhere.chrome.rule_name "Regelname"> +<!ENTITY https-everywhere.chrome.regex "Übereinstimmende regex"> +<!ENTITY https-everywhere.chrome.redirect_to "Weiterleiten nach"> +<!ENTITY https-everywhere.chrome.status_cancel_button "Abbrechen">

1 0

[tor/master] Silence clang-scan warnings in ed25519_donna
by nickm＠torproject.org 25 Feb '16

25 Feb '16

commit 9ab1037de1c03b4a41186a1318674c2c3fa6d779 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Wed Feb 24 23:24:01 2016 +0800 Silence clang-scan warnings in ed25519_donna --- src/ext/ed25519/donna/ed25519_tor.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/ext/ed25519/donna/ed25519_tor.c b/src/ext/ed25519/donna/ed25519_tor.c index ac726ba..52b259d 100644 --- a/src/ext/ed25519/donna/ed25519_tor.c +++ b/src/ext/ed25519/donna/ed25519_tor.c @@ -168,8 +168,8 @@ ed25519_donna_seckey_expand(unsigned char *sk, const unsigned char *skseed) int ed25519_donna_pubkey(unsigned char *pk, const unsigned char *sk) { - bignum256modm a; - ge25519 ALIGN(16) A; + bignum256modm a = {0}; + ge25519 ALIGN(16) A = {{0}, {0}, {0}, {0}}; /* A = aB */ expand256_modm(a, sk, 32); @@ -204,8 +204,8 @@ ed25519_donna_sign(unsigned char *sig, const unsigned char *m, size_t mlen, const unsigned char *sk, const unsigned char *pk) { ed25519_hash_context ctx; - bignum256modm r, S, a; - ge25519 ALIGN(16) R; + bignum256modm r = {0}, S, a; + ge25519 ALIGN(16) R = {{0}, {0}, {0}, {0}}; hash_512bits hashr, hram; /* This is equivalent to the removed `ED25519_FN(ed25519_sign)` routine,

1 0

[tor/master] Changes file for bug 18384: bugfix on 0f3eeca9 in 0.2.7.2-alpha.
by nickm＠torproject.org 25 Feb '16

25 Feb '16

commit b76b9d77d39efb0e06e9a19de1bf1bc2e76a5f99 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Thu Feb 25 13:57:04 2016 +0800 Changes file for bug 18384: bugfix on 0f3eeca9 in 0.2.7.2-alpha. --- changes/bug18384 | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/changes/bug18384 b/changes/bug18384 new file mode 100644 index 0000000..78befca --- /dev/null +++ b/changes/bug18384 @@ -0,0 +1,5 @@ + o Minor bugfixes (crypto, static analysis): + - Silence spurious clang-scan warnings in the ed25519_donna code + by explicitly initialising some objects. + Fixes bug 18384; bugfix on 0f3eeca9 in 0.2.7.2-alpha. + Patch by "teor".

1 0

[tor/master] Merge remote-tracking branch 'teor/bug18384'
by nickm＠torproject.org 25 Feb '16

25 Feb '16

commit 3687526c668adc7a7d2d19db66d65b3978b6b97d Merge: 7a78282 b76b9d7 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Feb 25 13:46:34 2016 -0500 Merge remote-tracking branch 'teor/bug18384' changes/bug18384 | 5 +++++ src/ext/ed25519/donna/ed25519_tor.c | 8 ++++---- 2 files changed, 9 insertions(+), 4 deletions(-)

1 0

[torspec/master] proposal: 267-tor-consensus-transparency.txt (from Linus)
by nickm＠torproject.org 25 Feb '16

25 Feb '16

commit 33c1c31567d633d6861ffb3d96c2cc9cdf2bf6d0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Feb 25 09:52:04 2016 -0500 proposal: 267-tor-consensus-transparency.txt (from Linus) --- proposals/000-index.txt | 2 + proposals/267-tor-consensus-transparency.txt | 363 +++++++++++++++++++++++++++ 2 files changed, 365 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index ae65d5a..062f782 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -187,6 +187,7 @@ Proposals by number: 264 Putting version numbers on the Tor subprotocols [OPEN] 265 Load Balancing with Overhead Parameters [ACCEPTED] 266 Removing current obsolete clients from the Tor network [DRAFT] +267 Tor Consensus Transparency [DRAFT] Proposals by status: @@ -213,6 +214,7 @@ Proposals by status: 259 New Guard Selection Behaviour 260 Rendezvous Single Onion Services 266 Removing current obsolete clients from the Tor network + 267 Tor Consensus Transparency NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret NEEDS-RESEARCH: diff --git a/proposals/267-tor-consensus-transparency.txt b/proposals/267-tor-consensus-transparency.txt new file mode 100644 index 0000000..9d761e7 --- /dev/null +++ b/proposals/267-tor-consensus-transparency.txt @@ -0,0 +1,363 @@ +Filename: 267-tor-consensus-transparency.txt +Title: Tor Consensus Transparency +Author: Linus Nordberg +Created: 2014-06-28 +Status: Draft + +0. Introduction + + This document describes how to provide and use public, append-only, + verifiable logs containing Tor consensus and vote status documents, + much like what Certificate Transparency [CT] does for TLS + certificates, making it possible for log monitors to detect false + consensuses and votes. + + Tor clients and relays can refuse using a consensus not present in + a set of logs of their choosing, as well as provide possible + evidence of misissuance by submitting such a consensus to any + number of logs. + +1. Overview + + Tor status documents, consensuses as well as votes, are stored in + one or more public, append-only, externally verifiable log using a + history tree like the one described in [CrosbyWallach]. + + Consensus-users, i.e. Tor clients and relays, expect to receive one + or more "proof of inclusions" with new consensus documents. A proof + of inclusion is a hash sum representing the tree head of a log, + signed by the logs private key, and an audit path listing the nodes + in the tree needed to recreate the tree head. Consensus-users are + configured to use one or more logs by listing a log address and a + public key for each log. This is enough for verifying that a given + consensus document is present in a given log. + + Submission of status documents to a log can be done by anyone with + an internet connection (and the Tor network, in case of logs only + on a .onion address). The submitter gets a signed tree head and a + proof of inclusion in return. Directory authorities are expected to + submit to one or more logs and include the proofs when serving + consensus documents. Directory caches and consensus-users receiving + a consensus not including a proof of inclusion may submit the + document and use the proof they receive in return. + + Auditing log behaviour and monitoring the contents of logs is + performed in cooperation between the Tor network and external + services. Relays act as log auditors with help from Tor clients + gossiping about what they see. Directory authorities are good + candidates for monitoring log content since they know what votes + they have sent and received as well as what consensus documents + they have issued. Anybody can run both an auditor and a monitor + though, which is an important property of the proposed system. + +2. Motivation + + Popping a handful of boxes (currently five) or factoring the same + number of RSA keys should not be ruled out as a possible attack + against a subset of Tor users. An attacker controlling a majority + of the directory authorities signing keys can, using + man-in-the-middle or man-on-the-side attacks, serve consensus + documents listing relays under their control. If mounted on a small + subset of Tor users on the internet, the chance of detection is + probably low. Implementation of this proposal increases the cost + for such an attack by raising the chances of it being detected. + + Note that while the proposed solution gives each individual some + degree of protection against using a false consensus this is not + the primary goal but more of a nice side effect. The primary goal + is to detect correctly signed consensus documents which differ from + the consensus of the directory authoritites. This raises the risk + of exposure of an attacker capable of producing a consensus and + feed it to users. + + The complexity of the proposed solution is motivated by the fact + that the log key is not just another key on top of the directory + authority keys since the log doesn't have to be trusted. Another + value is the decentralisation given -- anybody can run their own + log and use it. Anybody can audit all existing logs and verify + their correct behaviour. This empowers people outside the group of + Tor directory authority operators and the people who trust them for + one reason or the other. + +3. Design + + Communication with logs is done over HTTP using TLS or Tor onion + services for transport, similar to what is defined in + [rfc6962-bis-12]. Parameters for POSTs and all responses are + encoded as name/value pairs in JSON objects [RFC4627]. + + Summary of proposed changes to Tor: + + - Configuration is added for listing known logs and for describing + policy for using them. + + - Directory authorities start submitting newly created consensuses + to at least one public log. + + - Tor clients and relays receiving a consensus not accompanied by a + proof of inclusion start submitting that consensus to at least + one public log. + + - Consensus-users start rejecting consensuses accompanied by an + invalid proof of inclusion. + + - A new cell type LOG_STH is defined, for clients and relays to + exchange information about seen tree heads and their validity. + + - Consensus-users send seen tree heads to relays acting as log + auditors. + + - Relays acting as log auditors validate tree heads (section 3.2.2) + received from consensus-users and send results back. + + - Consensus-users start rejecting consensuses for which valid + proofs of inclusion can not be obtained. + + Definitions: + + - Log id: The SHA-256 hash of the log's public key, to be treated + as an opaque byte string identifying the log. + +3.1. Consensus submission + + Logs accept consensus submissions from anyone as long as the + consensus is signed by a majority of the Tor directory authorities + of the Tor network that it's logging. + + Consensus documents are POST:ed to a well-known URL as defined in + section 5.2. + + The output is what we call a proof of inclusion. + +3.2. Verification + +3.2.1. Log entry membership verification + + Calculate a tree head from the hash of the received consensus and + the audit path in the accompanying proof. Verify that the + calculated tree head is identical to the tree head in the + proof. This can easily be done by consensus-users for each received + consensus. + + We now know that the consensus is part of a tree which the log + claims to be The Tree. Whether this tree is the same tree that + everybody else see is unknown at this point. + +3.2.2. Log consistency verification + + Ask the log for a consistency proof between the tree head to verify + and a previously known good tree head from the pool. Section 5.3 + specifies how to fetch a consistency proof. + + [[TBD require auditors to fetch and store the tree head for the + empty tree as part of bootstrapping, in order to avoid the case + where there's no older tree to verify against?]] + + [[TODO description of verification of consistency goes here]] + + Relays acting as auditors cache results to minimise calculations + and communication with log servers. + + [[TBD have clients verify consistency as well? NOTE: we still want + relays to see tree heads in order to catch a lying log (the + split-view attack)]] + + We now know that the verified tree is a superset of a known good + tree. + +3.3. Log auditing + + A log auditor verifies two things: + + - A logs append-only property, i.e. that no entries once accepted + by a log are ever altered or removed. + + - That a log presents the same view to all of its users [[TODO + describe the Tor networks role in auditing more than what's found + in section 3.2.2]] + + A log auditor typically doesn't care about the contents of the log + entries, other than calculating their hash sums for auditing + purposes. + + Tor relays should act as log auditors. + +3.4. Log monitoring + + A log monitor downloads and investigates each entry in a log + searching for anomalies according to its monitoring policy. + + This document doesn't define monitoring policies but does outline a + few strategies for monitoring in section [[TBD]]. + + Note that there can be more than one valid consensus documents for + a given point in time. One reason for this is that the number of + signatures can differ due to consensus voting timing + details. [[TODO Are there more reasons?]] + + [[TODO expand on monitoring strategies -- even if this is not part + of the proposed extensions to the Tor network it's good for + understanding. a) dirauths can verify consensus documents byte for + byte; b) anyone can look for diffs larger than D per time T, where + "diffs" certainly can be smarter than a plain text diff]] + +3.5. Consensus-user behaviour + + [[TODO move most of this to section 5]] + + Keep an on-disk cache of consensus documents. Mark them as being in + one of three states: + + LOG_STATE_UNKNOWN -- don't know whether it's present in enough logs + or not + LOG_STATE_LOGGED -- have seen good proof(s) of inclusion + LOG_STATE_LOGGED_GOOD -- confident about the tree head representing + a good tree + + Newly arrived consensus documents start in UNKNOWN or LOGGED + depending on whether they are accompanied by enough proofs or + not. There are two possible state transitions: + + - UNKNOWN --> LOGGED: When enough correctly verifying proofs of + inclusion (section 3.2.1) have been seen. The number of good + proofs required is a policy setting in the configuration of the + consensus-user. + + - LOGGED --> LOGGED_GOOD: When the tree head in enough of the + inclusion proofs have been verified (section 3.2.2) or enough + LOG_STH cells vouching for the same tree heads have been + seen. The number of verifications required is a policy setting in + the configuration of the consensus-user. + + Consensuses in state UNKNOWN are not used but are instead submitted + to one or more logs. If the submission succeeds, this will take the + consensus to state LOGGED. + + Consensuses in state LOGGED are used despite not being fully + verified with regard to logging. LOG_STH cells containing + tree heads from received proofs are being sent to relays for + verification. Clients send to all relays that they have a circuit + to, i.e. their guard relay(s). Relays send to three random relays + that they have a circuit to. + +3.6. Relay behaviour when acting as an auditor + + In order to verify the append-only property of a log, relays acting + as log auditors verify the consistency of tree heads received in + LOG_STH cells. An auditor keeps a copy of 2+N known good tree heads + in a pool stored on persistent media [[TBD where N is either a + fixed number in the range 32-128 or is a function of the log + size]]. Two of them are the oldest and newest tree heads seen, + respectively. The rest, N, are randomly chosen from the tree heads + seen. + + [[TODO describe or refer to an algorithm for "randomly chosen", + hopefully not subjective to flushing attacks (or other attacks)]]. + +3.7. Notable differences from Certificate Transparency + + - The data logged is "strictly time-stamped", i.e. ordered. + + - Much shorter lifetime of logged data -- a day rather than a + year. Is the effects of this difference of importance only for + "one-shot attacks"? + + - Directory authorities have consensus about what they're + signing -- there are no "web sites knowing better". + + - Submitters are not in the same hurry as CA:s and can wait minutes + rather than seconds for a proof of inclusion. + +4. Security implications + + TODO + +5. Specification + +5.0. Data structures + + Data structures are defined as described in [RFC5246] section 4, + i.e. TLS 1.2 presentation language. While it is tempting to try to + avoid yet another format, the cost of redefining the data + structures in [rfc6962-bis-12] outweighs this consideration. The + burden of redefining, reimplementing and testing is extra true for + those structures which need precise definitions because they are to + be signed. + +5.1. Signed Tree Head (STH) + + An STH is a TransItem structure of type "signed_tree_head" as + defined in [rfc6962-bis-12] section 5.8. + +5.2. Submitting a consensus document to a log + + POST https://<log server>/tct/v1/add-consensus + + Input: + + consensus: A consensus status document as defined in [dir-spec] + section 3.4.1 [[TBD gziped and base64 encoded to save 50%?]] + + Output: + + sth: A signed tree head as defined in section 5.1 refering to a + tree in which the submitted document is included. + + inclusion: An inclusion proof as specified for the "inclusion" + output in [rfc6962-bis-12] section 6.5. + +5.3. Getting a consistency proof from a log + + GET https://<log server>/tct/v1/get-sth-consistency + + Input and output as specified in [rfc6962-bis-12] section 6.4. + +5.x. LOG_STH cells + + A LOG_STH cell is a variable-length cell with the following + fields: + + TBDname [TBD octets] + TBDname [TBD octets] + TBDname [TBD octets] + +6. Compatibility + + TBD + +7. Implementation + + TBD + +8. Performance and scalability notes + + TBD + +A. Open issues / TODOs + + - TODO: Add SCTs from CT, at least as a practical "cookie" (i.e. no + need to send them around or include them anywhere). Logs should + be given more time for distributing than we're willing to wait on + an HTTP response for. + + - TODO: explain why no hash function and signing algorithm agility, + [[rfc6962-bis-12] section 10 + + - TODO: add a blurb about the values of publishing logs as onion + services + + - TODO: discuss compromise of log keys + +B. Acknowledgements + + This proposal leans heavily on [rfc6962-bis-12]. Some definitions + are copied verbatim from that document. Valuable feedback has been + received from Ben Laurie, Karsten Loesing and Ximin Luo. + +C. References + + [CrosbyWallach] http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf + [dir-spec] https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt + [RFC4627] https://tools.ietf.org/html/rfc4627 + [rfc6962-bis-12] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/12 + [CT] https://https://www.certificate-transparency.org/

1 0

[translation/tor-messenger-otrproperties] Update translations for tor-messenger-otrproperties
by translation＠torproject.org 25 Feb '16

25 Feb '16

commit 1d6b9519c89e08fdea17424805286ae4f44afc57 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 25 12:16:57 2016 +0000 Update translations for tor-messenger-otrproperties --- fi/otr.properties | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fi/otr.properties b/fi/otr.properties index 3e45429..9adef98 100644 --- a/fi/otr.properties +++ b/fi/otr.properties @@ -10,7 +10,7 @@ msgevent.rcvdmsg_unreadable=We received an unreadable encrypted message from %S. msgevent.rcvdmsg_malformed=We received a malformed data message from %S. msgevent.log_heartbeat_rcvd=Heartbeat received from %S. msgevent.log_heartbeat_sent=Heartbeat sent to %S. -msgevent.rcvdmsg_general_err=An OTR error occured. +msgevent.rcvdmsg_general_err=OTR-virhe sattui. msgevent.rcvdmsg_unecrypted=The following message received from %S was not encrypted: %S msgevent.rcvdmsg_unrecognized=We received an unrecognized OTR message from %S. msgevent.rcvdmsg_for_other_instance=%S has sent a message intended for a different session. If you are logged in multiple times, another session may have received the message. @@ -21,11 +21,11 @@ error.enc=Error occurred encrypting message. error.not_priv=You sent encrypted data to %S, who wasn't expecting it. error.unreadable=You transmitted an unreadable encrypted message. error.malformed=You transmitted a malformed data message. -resent=[resent] +resent=[uudelleenlähetetty] tlv.disconnected=%S has ended their private conversation with you; you should do the same. query.msg=%S has requested an Off-the Record private conversation. However, you do not have a plugin to support that. See http://otr.cypherpunks.ca/ for more information. -trust.unused=Unused -trust.not_private=Not Private -trust.unverified=Unverified -trust.private=Private -trust.finished=Finished +trust.unused=Käyttämätön +trust.not_private=Ei yksityinen +trust.unverified=Varmistamaton +trust.private=Yksityinen +trust.finished=Valmistunut

1 0

[translation/tor-messenger-commandsproperties] Update translations for tor-messenger-commandsproperties
by translation＠torproject.org 25 Feb '16

25 Feb '16

commit 07f454740951058edc2944479ce21f68ac7c7254 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 25 12:16:37 2016 +0000 Update translations for tor-messenger-commandsproperties --- fi/commands.properties | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fi/commands.properties b/fi/commands.properties index 55ca16a..ef1e2ba 100644 --- a/fi/commands.properties +++ b/fi/commands.properties @@ -7,8 +7,8 @@ commands=Commands: %S.\nUse /help <command> for more information. # LOCALIZATION NOTE (noCommand, noHelp): # %S is the command name the user typed. -noCommand=No '%S' command. -noHelp=No help message for the '%S' command, sorry! +noCommand=Ei komentoa '%S'. +noHelp=Ei ohjeviestiä komennolle '%S'. sayHelpString=say <message>: send a message without processing commands. rawHelpString=raw <message>: send a message without escaping HTML entities.

1 0

[translation/torbutton-brandproperties_completed] Update translations for torbutton-brandproperties_completed
by translation＠torproject.org 25 Feb '16

25 Feb '16

commit 9f3f66c84a1b82397e54201fb595a75fe61decab Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 25 12:16:03 2016 +0000 Update translations for torbutton-brandproperties_completed --- fi/brand.properties | 1 + 1 file changed, 1 insertion(+) diff --git a/fi/brand.properties b/fi/brand.properties index e564a30..df73808 100644 --- a/fi/brand.properties +++ b/fi/brand.properties @@ -2,6 +2,7 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. +brandShorterName=Tor-selain brandShortName=Tor-selain brandFullName=Tor-selain vendorShortName=Tor-projekti

1 0