April 2018 - tor-commits - lists.torproject.org

[translation/exoneratorproperties_completed] Update translations for exoneratorproperties_completed
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit 0d001dbc8d3739bb36a1c54e4c87f267a8788660 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 18:49:37 2018 +0000 Update translations for exoneratorproperties_completed --- hu/exonerator.properties | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hu/exonerator.properties b/hu/exonerator.properties index 1878c536f..1b7e92cf7 100644 --- a/hu/exonerator.properties +++ b/hu/exonerator.properties @@ -19,6 +19,8 @@ summary.invalidparams.invalidip.title=Érvénytelen IP cím paraméter summary.invalidparams.invalidip.body=Sajnálom, a %s nem egy érvényes IP cím. Az elvárt IP cím formátuma %s vagy %s. summary.invalidparams.invalidtimestamp.title=Érvénytelen dátum paraméter summary.invalidparams.invalidtimestamp.body=Sajnálom, a %s nem egy érvényes dátum. Az elvárt dátum formátuma %s. +summary.invalidparams.timestamptoorecent.title=Az data paraméter túl friss +summary.invalidparams.timestamptoorecent.body=Az adatbázis nem tartalma elég adatot ahhoz, hogy pontosan megválaszolhassuk ezt a kérést. A legutoljára elfogadott adat tegnapelőtti. Kérjük ismételje meg a keresést egy másik napon. summary.serverproblem.nodata.title=Kiszolgáló probléma summary.serverproblem.nodata.body.text=Az adatbázis nem tartalmaz semmi adatot a kért dátumhoz. Kérlek próbáld újra később. Ha ez a probléma fennáll, kérlek %s! summary.serverproblem.nodata.body.link=add a tudomásunkra

1 0

[translation/exoneratorproperties] Update translations for exoneratorproperties
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit a6c019cb7fd50be9649e92dc475e9fd5066f5b3c Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 18:49:32 2018 +0000 Update translations for exoneratorproperties --- hu/exonerator.properties | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hu/exonerator.properties b/hu/exonerator.properties index e53aa1585..1b7e92cf7 100644 --- a/hu/exonerator.properties +++ b/hu/exonerator.properties @@ -19,8 +19,8 @@ summary.invalidparams.invalidip.title=Érvénytelen IP cím paraméter summary.invalidparams.invalidip.body=Sajnálom, a %s nem egy érvényes IP cím. Az elvárt IP cím formátuma %s vagy %s. summary.invalidparams.invalidtimestamp.title=Érvénytelen dátum paraméter summary.invalidparams.invalidtimestamp.body=Sajnálom, a %s nem egy érvényes dátum. Az elvárt dátum formátuma %s. -summary.invalidparams.timestamptoorecent.title=Date parameter too recent -summary.invalidparams.timestamptoorecent.body=The database may not yet contain enough data to correctly answer this request. The latest accepted data is the day before yesterday. Please repeat your search on another day. +summary.invalidparams.timestamptoorecent.title=Az data paraméter túl friss +summary.invalidparams.timestamptoorecent.body=Az adatbázis nem tartalma elég adatot ahhoz, hogy pontosan megválaszolhassuk ezt a kérést. A legutoljára elfogadott adat tegnapelőtti. Kérjük ismételje meg a keresést egy másik napon. summary.serverproblem.nodata.title=Kiszolgáló probléma summary.serverproblem.nodata.body.text=Az adatbázis nem tartalmaz semmi adatot a kért dátumhoz. Kérlek próbáld újra később. Ha ez a probléma fennáll, kérlek %s! summary.serverproblem.nodata.body.link=add a tudomásunkra

1 0

[translation/tails-perl5lib] Update translations for tails-perl5lib
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit a475b375cf5eb765baa20a0e0e2795161b3a5f2b Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 18:47:30 2018 +0000 Update translations for tails-perl5lib --- hu.po | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/hu.po b/hu.po index b342daa1c..ed89ab88f 100644 --- a/hu.po +++ b/hu.po @@ -5,13 +5,14 @@ # Translators: # benewfy <benewfy(a)gmail.com>, 2016 # Lajos Pasztor <mrlajos(a)gmail.com>, 2014 +# vargaviktor <viktor.varga(a)gmail.com>, 2018 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n" "POT-Creation-Date: 2018-03-15 12:15+0000\n" -"PO-Revision-Date: 2018-03-31 13:21+0000\n" -"Last-Translator: carolyn <carolyn(a)anhalt.org>\n" +"PO-Revision-Date: 2018-04-03 18:47+0000\n" +"Last-Translator: vargaviktor <viktor.varga(a)gmail.com>\n" "Language-Team: Hungarian (http://www.transifex.com/otf/torproject/language/hu/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -27,7 +28,7 @@ msgstr "Hiba" msgid "" "The device Tails is running from cannot be found. Maybe you used the 'toram'" " option?" -msgstr "" +msgstr "Az eszköz amiről a Tails fut nem található. Lehetséges, hogy a \"toram\" opciót használta?" #: ../lib/Tails/RunningSystem.pm:192 msgid ""

1 0

[translation/torbirdy_completed] Update translations for torbirdy_completed
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit 0618b5c51cc4dc49ba88651906847793db6c2214 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 18:46:04 2018 +0000 Update translations for torbirdy_completed --- hu/torbirdy.dtd | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hu/torbirdy.dtd b/hu/torbirdy.dtd index 20b95056c..e2a5ad139 100644 --- a/hu/torbirdy.dtd +++ b/hu/torbirdy.dtd @@ -38,6 +38,8 @@ <!ENTITY torbirdy.prefs.startup_folder.key "l"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.label "Ne tedd a fogadó kulcs ID-et a titkosított üzenetbe [alapértelemezett: tedd]"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.key "a"> +<!ENTITY torbirdy.prefs.enigmail_protected.label "Titkosított email fejlécek tiltása [alapértelmezett: engedélyezett]"> +<!ENTITY torbirdy.prefs.enigmail_protected.key "a"> <!ENTITY torbirdy.prefs.confirmemail.label "Email küldése előtt rákérdezés, ha Enigmail engedélyezett [alapértelmezés: ne egyen rákérdezés]"> <!ENTITY torbirdy.prefs.confirmemail.key "p"> <!ENTITY torbirdy.prefs.emailwizard.label "A Thunderbird automatikus email beállítási varázslójának engedélyezése [alapértelmezés: tiltott]">

1 0

[translation/torbirdy] Update translations for torbirdy
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit 858c3d2a02d72b3d1e42c78fa4091afa7985de61 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 18:45:58 2018 +0000 Update translations for torbirdy --- hu/torbirdy.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hu/torbirdy.dtd b/hu/torbirdy.dtd index c964d4d12..e2a5ad139 100644 --- a/hu/torbirdy.dtd +++ b/hu/torbirdy.dtd @@ -38,7 +38,7 @@ <!ENTITY torbirdy.prefs.startup_folder.key "l"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.label "Ne tedd a fogadó kulcs ID-et a titkosított üzenetbe [alapértelemezett: tedd]"> <!ENTITY torbirdy.prefs.enigmail_throwkeyid.key "a"> -<!ENTITY torbirdy.prefs.enigmail_protected.label "Disable encrypted email headers [default: enabled]"> +<!ENTITY torbirdy.prefs.enigmail_protected.label "Titkosított email fejlécek tiltása [alapértelmezett: engedélyezett]"> <!ENTITY torbirdy.prefs.enigmail_protected.key "a"> <!ENTITY torbirdy.prefs.confirmemail.label "Email küldése előtt rákérdezés, ha Enigmail engedélyezett [alapértelmezés: ne egyen rákérdezés]"> <!ENTITY torbirdy.prefs.confirmemail.key "p">

1 0

[torspec/master] 291: The move to two guard nodes
by nickm＠torproject.org 03 Apr '18

03 Apr '18

commit 815a7108eb4973106c002b1347fd7b67a09392de Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 3 14:30:03 2018 -0400 291: The move to two guard nodes --- proposals/000-index.txt | 6 +- proposals/291-two-guard-nodes.txt | 251 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 255 insertions(+), 2 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index e4eebf3..744353b 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -170,7 +170,7 @@ Proposals by number: 247 Defending Against Guard Discovery Attacks using Vanguards [DRAFT] 248 Remove all RSA identity keys [DRAFT] 249 Allow CREATE cells with >505 bytes of handshake data [ACCEPTED] -250 Random Number Generation During Tor Voting [CLOSED] +250 Random Number Generation During Tor Voting [CLOSED] 251 Padding for netflow record resolution reduction [DRAFT] 252 Single Onion Services [SUPERSEDED] 253 Out of Band Circuit HMACs [DRAFT] @@ -211,6 +211,7 @@ Proposals by number: 288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) [DRAFT] 289 Authenticating sendme cells to mitigate bandwidth attacks [OPEN] 290 Continuously update consensus methods [OPEN] +291 The move to two guard nodes [OPEN] Proposals by status: @@ -271,6 +272,7 @@ Proposals by status: 287 Reduce circuit lifetime without overloading the network 289 Authenticating sendme cells to mitigate bandwidth attacks 290 Continuously update consensus methods + 291 The move to two guard nodes ACCEPTED: 172 GETINFO controller option for circuit information 173 GETINFO Option Expansion @@ -365,7 +367,7 @@ Proposals by status: 238 Better hidden service stats from Tor relays 243 Give out HSDir flag only to relays with Stable flag 244 Use RFC5705 Key Exporting in our AUTHENTICATE calls [in 0.3.0.1-alpha] - 250 Random Number Generation During Tor Voting + 250 Random Number Generation During Tor Voting 264 Putting version numbers on the Tor subprotocols [in 0.2.9.4-alpha] 271 Another algorithm for guard selection [in 0.3.0.1-alpha] 272 Listed routers should be Valid, Running, and treated as such [in 0.2.9.3-alpha, 0.2.9.4-alpha] diff --git a/proposals/291-two-guard-nodes.txt b/proposals/291-two-guard-nodes.txt new file mode 100644 index 0000000..a900ee9 --- /dev/null +++ b/proposals/291-two-guard-nodes.txt @@ -0,0 +1,251 @@ +Filename: 291-two-guard-nodes.txt +Title: The move to two guard nodes +Author: Mike Perry +Created: 2018-03-22 +Supersedes: Proposal 236 +Status: Open + +0. Background + + Back in 2014, Tor moved from three guard nodes to one guard node[1,2,3]. + + We made this change primarily to limit points of observability of entry + into the Tor network for clients and onion services, as well as to + reduce the ability of an adversary to track clients as they move from + one internet connection to another by their choice of guards. + + +1. Proposed changes + +1.1. Switch to two guards per client + + When this proposal becomes effective, clients will switch to using + two guard nodes. The guard node selection algorithms of Proposal 271 + will remain unchanged. Instead of having one primary guard "in use", + Tor clients will always use two. + + This will be accomplished by setting the guard-n-primary-guards-to-use + consensus parameter to 2, as well as guard-n-primary-guards to 2. + (Section 3.1 covers the reason for both parameters). This is equivalent + to using the torrc option NumEntryGuards=3D2, which can be used for + testing behavior prior to the consensus update. + +1.2. Enforce Tor's path restrictions across this guard layer + + In order to ensure that Tor can always build circuits using two guards + without resorting to a third, they must be chosen such that Tor's path + restrictions could still build a path with at least one of them, + regardless of the other nodes in the path. + + In other words, we must ensure that both guards are not chosen from the + same /16 or the same node family. In this way, Tor will always be able to + build a path using these guards, preventing the use of a third guard. + + +2. Discussion + +2.1. Why two guards? + + The main argument for switching to two guards is that because of Tor's + path restrictions, we're already using two guards, but we're using them + in a suboptimal and potentially dangerous way. + + Tor's path restrictions enforce the condition that the same node cannot + appear twice in the same circuit, nor can nodes from the same /16 subnet + or node family be used in the same circuit. + + Tor's paths are also built such that the exit node is chosen first and + held fixed during guard node choice, as are the IP, HSDIR, and RPs for + onion services. This means that whenever one of these nodes happens to + be the guard[4], or be in the same /16 or node family as the guard, Tor + will build that circuit using a second "primary" guard, as per proposal + 271[7]. + + Worse still, the choice of RP, IP, and exit can all be controlled by an + adversary (to varying degrees), enabling them to force the use of a + second guard at will. + + Because this happens somewhat infrequently in normal operation, a fresh + TLS connection will typically be created to the second "primary" guard, + and that TLS connection will be used only for the circuit for that + particular request. This property makes all sorts of traffic analysis + attacks easier, because this TLS connection will not benefit from any + multiplexing. + + This is more serious than traffic injection via an already in-use + guard because the lack of multiplexing means that the data retention + level required to gain information from this activity is very low, and + may exist for other reasons. To gain information from this behavior, an + adversary needs only connection 5-tuples + timestamps, as opposed to + detailed timeseries data that is polluted by other concurrent activity + and padding. + + In the most severe form of this attack, the adversary can take a suspect + list of Tor client IP addresses (or the list of all Guard node IP addresses) + and observe when secondary Tor connections are made to them at the time when + they cycle through all guards as RPs for connections to an onion + service. This adversary does not require collusion on the part of observers + beyond the ability to provide 5-tuple connection logs (which ISPs may retain + for reasons such as netflow accounting, IDS, or DoS protection systems). + + A fully passive adversary can also make use of this behavior. Clients + unlucky enough to pick guard nodes in heavily used /16s or in large node + families will tend to make use of a second guard more frequently even + without effort from the adversary. In these cases, the lack of + multiplexing also means that observers along the path to this secondary + guard gain more information per observation. + +2.2. Why not MOAR guards? + + We do not want to increase the number of observation points for client + activity into the Tor network[1]. We merely want better multiplexing for + the cases where this already happens. + +2.3. Can you put some numbers on that? + + The Changing of the Guards[13] paper studies this from a few different + angles, but one of the crucially missing graphs is how long a client + can expect to run with N guards before it chooses a malicious guard. + + However, we do have tables in section 3.2.1 of proposal 247 that cover + this[14]. There are three tables there: one for a 1% adversary, one for + a 5% adversary, and one for a 10% adversary. You can see the probability + of adversary success for one and two guards in terms of the number of + rotations needed before the adversary's node is chosen. Not surprisingly, + the two guard adversary gets to compromise clients roughly twice as + quickly, but the timescales are still rather large even for the 10% + adversary: they only have 50% chance of success after 4 rotations, which + will take about 14 months with Tor's 3.5 month guard rotation. + +2.4. What about guard fingerprinting? + + More guards also means more fingerprinting[8]. However, even one guard + may be enough to fingerprint a user who moves around in the same area, + if that guard is low bandwidth or there are not many Tor users in that + area. + + Furthermore, our use of separate directory guards (and three of them) + means that we're not really changing the situation much with the + addition of another regular guard. Right now, directory guard use alone + is enough to track all Tor users across the entire world. + + While the directory guard problem could be fixed[12] (and should be + fixed), it is still the case that another mechanism should be used for + the general problem of guard-vs-location management[9]. + + +3. Alternatives + + There are two other solutions that also avoid the use of secondary guard + in the path restriction case. + +3.1. Eliminate path restrictions entirely + + If Tor decided to stop enforcing /16, node family, and also allowed the + guard node to be chosen twice in the path, then under normal conditions, + it should retain the use of its primary guard. + + This approach is not as extreme as it seems on face. In fact, it is hard + to come up with arguments against removing these restrictions. Tor's + /16 restriction is of questionable utility against monitoring, and it can + be argued that since only good actors use node family, it gives influence + over path selection to bad actors in ways that are worse than the benefit + it provides to paths through good actors[10,11]. + + However, while removing path restrictions will solve the immediate + problem, it will not address other instances where Tor temporarily opts + use a second guard due to congestion, OOM, or failure of its primary + guard, and we're still running into bugs where this can be adversarially + controlled or just happen randomly[5]. + + While using two guards means twice the surface area for these types of + bugs, it also means that instances where they happen simultaneously on + both guards (thus forcing a third guard) are much less likely than with + just one guard. (In the passive adversary model, consider that one guard + fails at any point with probability P1. If we assume that such passive + failures are independent events, both guards would fail concurrently + with probability P1*P2. Even if the events are correlated, the maximum + chance of concurrent failure is still MIN(P1,P2)). + + Note that for this analysis to hold, we have to ensure that nodes that + are at RESOURCELIMIT or otherwise temporarily unresponsive do not cause + us to consider other primary guards beyond than the two we have chosen. + This is accomplished by setting guard-n-primary-guards to 2 (in addition + to setting guard-n-primary-guards-to-use to 2). With this parameter + set, the proposal 271 algorithm will avoid considering more than our two + guards, unless *both* are down at once. + +3.2. No Guard-flagged nodes as exit, RP, IP, or HSDIRs + + Similar to 3.1, we could instead forbid the use of Guard-flagged nodes + for the exit, IP, RP, and HSDIR positions. + + This solution has two problems: First, like 3.1, it also does not handle + the case where resource exhaustion could force the use of a second + guard. Second, it requires clients to upgrade to the new behavior and + stop using Guard flagged nodes before it can be deployed. + + +4. The future is confluxed + + An additional benefit of using a second guard is that it enables us to + eventually use conflux[6]. + + Conflux works by giving circuits a 256bit cookie that is sent to the + exit/RP, and circuits that are then built to the same exit/RP with the + same cookie can then be fused together. Throughput estimates are used to + balance traffic between these circuits, depending on their performance. + + We have unfortunately signaled to the research community that conflux is + not worth pursuing, because of our insistence on a single guard. While + not relevant to this proposal (indeed, conflux requires its own proposal + and also concurrent research), it is worth noting that whichever way we + go here, the door remains open to conflux because of its utility against + similar issues. + + If our conflux implementation includes packet acking, then circuits can + still survive the loss of one guard node due to DoS, OOM, or other + failures because the second half of the path will remain open and + usable (see the probability of concurrent failure arguments in Section + 3.1). + + If exits remember this cookie for a short period of time after the last + circuit is closed, the technique can be used to protect against + DoS/OOM/guard downtime conditions that take down both guard nodes or + destroy many circuits to confirm both guard node choices. In these + cases, circuits could be rebuilt along an alternate path and resumed + without end-to-end circuit connectivity loss. This same technique will + also make things like ephemeral bridges (ie Snowflake/Flashproxy) more + usable, because bridge uptime will no longer be so crucial to usability. + It will also improve mobile usability by allowing us to resume + connections after mobile Tor apps are briefly suspended, or if the user + switches between cell and wifi networks. + + Furthermore, it is likely that conflux will also be useful against traffic + analysis and congestion attacks. Since the load balancing is dynamic and + hard to predict by an external observer and also increases overall + traffic multiplexing, traffic correlation and website traffic + fingerprinting attacks will become harder, because the adversary can no + longer be sure what percentage of the traffic they have seen (depending + on their position and other potential concurrent activity). Similarly, + it should also help dampen congestion attacks, since traffic will + automatically shift away from a congested guard. + + + +References: + +1. https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramet… +2. https://trac.torproject.org/projects/tor/ticket/12206 +3. https://gitweb.torproject.org/torspec.git/tree/proposals/236-single-guard-n… +4. https://trac.torproject.org/projects/tor/ticket/14917 +5. https://trac.torproject.org/projects/tor/ticket/25347#comment:14 +6. https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf +7. https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-… +8. https://trac.torproject.org/projects/tor/ticket/9273#comment:3 +9. https://tails.boum.org/blueprint/persistent_Tor_state/ +10. https://trac.torproject.org/projects/tor/ticket/6676#comment:3 +11. https://bugs.torproject.org/15060 +12. https://trac.torproject.org/projects/tor/ticket/10969 +13. https://www.freehaven.net/anonbib/cache/wpes12-cogs.pdf +14. https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-disco…

1 0

[translation/tor-browser-manual_completed] Update translations for tor-browser-manual_completed
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit ca108da9973c8fd1b405650f7103d7a876383a78 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 16:20:06 2018 +0000 Update translations for tor-browser-manual_completed --- pt/pt.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt/pt.po b/pt/pt.po index 497e49f7f..9bb190563 100644 --- a/pt/pt.po +++ b/pt/pt.po @@ -128,7 +128,7 @@ msgstr "" #: bridges.page:6 msgid "Learn what bridges are and how to get them" -msgstr "Saiba o que são as pontes e como obtê-las" +msgstr "Saiba o que são as pontes e como as obter" #: bridges.page:10 msgid "Bridges"

1 0

[translation/tor-browser-manual] Update translations for tor-browser-manual
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit 41f22570d9da675b9a10cf03519892e730c8567e Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 16:20:00 2018 +0000 Update translations for tor-browser-manual --- pt/pt.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt/pt.po b/pt/pt.po index 497e49f7f..9bb190563 100644 --- a/pt/pt.po +++ b/pt/pt.po @@ -128,7 +128,7 @@ msgstr "" #: bridges.page:6 msgid "Learn what bridges are and how to get them" -msgstr "Saiba o que são as pontes e como obtê-las" +msgstr "Saiba o que são as pontes e como as obter" #: bridges.page:10 msgid "Bridges"

1 0

[translation/tor-messenger-fingerdtd_completed] Update translations for tor-messenger-fingerdtd_completed
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit 3a167fead62da40430c66fc625cf6e7e14d24381 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 16:19:04 2018 +0000 Update translations for tor-messenger-fingerdtd_completed --- pt/finger.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt/finger.dtd b/pt/finger.dtd index 6d8302e94..df01ed1d5 100644 --- a/pt/finger.dtd +++ b/pt/finger.dtd @@ -8,7 +8,7 @@ <!ENTITY finger.verify "Verificar"> <!ENTITY finger.remove "Remover"> <!ENTITY finger.intro "Gerir a lista de assinaturas digitais que viu."> -<!ENTITY addFingerDialog.title "Adicionar identificador"> +<!ENTITY addFingerDialog.title "Adicionar Identificador"> <!ENTITY addFingerDialog.finger "Identificação"> <!ENTITY addFingerDialog.accept "OK"> <!ENTITY addFingerDialog.cancel "Ignorar">

1 0

[translation/tor-messenger-fingerdtd] Update translations for tor-messenger-fingerdtd
by translation＠torproject.org 03 Apr '18

03 Apr '18

commit bc20937f7dd4860c1a77487214efaef68dc35945 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 3 16:18:59 2018 +0000 Update translations for tor-messenger-fingerdtd --- pt/finger.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt/finger.dtd b/pt/finger.dtd index 6d8302e94..df01ed1d5 100644 --- a/pt/finger.dtd +++ b/pt/finger.dtd @@ -8,7 +8,7 @@ <!ENTITY finger.verify "Verificar"> <!ENTITY finger.remove "Remover"> <!ENTITY finger.intro "Gerir a lista de assinaturas digitais que viu."> -<!ENTITY addFingerDialog.title "Adicionar identificador"> +<!ENTITY addFingerDialog.title "Adicionar Identificador"> <!ENTITY addFingerDialog.finger "Identificação"> <!ENTITY addFingerDialog.accept "OK"> <!ENTITY addFingerDialog.cancel "Ignorar">

1 0