- tor-commits - lists.torproject.org

[tor/main] sandbox: Filter "chown32" syscall on i386
by ahf＠torproject.org 08 Nov '21

08 Nov '21

commit 55571fc8d7c63e88075020cfc0a3012e5aa10927 Author: Simon South <simon(a)simonsouth.net> Date: Wed Nov 3 10:48:16 2021 -0400 sandbox: Filter "chown32" syscall on i386 On i386 glibc uses the "chown32" system call instead of "chown". Prevent attempts to filter calls to chown() on this architecture from failing by modifying the sandbox implementation to match. --- src/lib/sandbox/sandbox.c | 39 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/src/lib/sandbox/sandbox.c b/src/lib/sandbox/sandbox.c index aed7e3706f..a4e9cb7849 100644 --- a/src/lib/sandbox/sandbox.c +++ b/src/lib/sandbox/sandbox.c @@ -599,6 +599,32 @@ sb_chmod(scmp_filter_ctx ctx, sandbox_cfg_t *filter) return 0; } +#ifdef __i386__ +static int +sb_chown32(scmp_filter_ctx ctx, sandbox_cfg_t *filter) +{ + int rc; + sandbox_cfg_t *elem = NULL; + + // for each dynamic parameter filters + for (elem = filter; elem != NULL; elem = elem->next) { + smp_param_t *param = elem->param; + + if (param != NULL && param->prot == 1 && param->syscall + == SCMP_SYS(chown32)) { + rc = seccomp_rule_add_1(ctx, SCMP_ACT_ALLOW, SCMP_SYS(chown32), + SCMP_CMP_STR(0, SCMP_CMP_EQ, param->value)); + if (rc != 0) { + log_err(LD_BUG,"(Sandbox) failed to add chown32 syscall, received " + "libseccomp error %d", rc); + return rc; + } + } + } + + return 0; +} +#else static int sb_chown(scmp_filter_ctx ctx, sandbox_cfg_t *filter) { @@ -623,6 +649,7 @@ sb_chown(scmp_filter_ctx ctx, sandbox_cfg_t *filter) return 0; } +#endif /* defined(__i386__) */ /** * Function responsible for setting up the rename syscall for @@ -1270,7 +1297,11 @@ static sandbox_filter_func_t filter_func[] = { #ifdef __NR_mmap2 sb_mmap2, #endif +#ifdef __i386__ + sb_chown32, +#else sb_chown, +#endif sb_chmod, sb_open, sb_openat, @@ -1544,6 +1575,12 @@ new_element(int syscall, char *value) return new_element2(syscall, value, NULL); } +#ifdef __i386__ +#define SCMP_chown SCMP_SYS(chown32) +#else +#define SCMP_chown SCMP_SYS(chown) +#endif + #ifdef __NR_stat64 #define SCMP_stat SCMP_SYS(stat64) #else @@ -1594,7 +1631,7 @@ sandbox_cfg_allow_chown_filename(sandbox_cfg_t **cfg, char *file) { sandbox_cfg_t *elem = NULL; - elem = new_element(SCMP_SYS(chown), file); + elem = new_element(SCMP_chown, file); elem->next = *cfg; *cfg = elem;

1 0

[tor/main] Merge remote-tracking branch 'tor-gitlab/mr/479' into main
by ahf＠torproject.org 08 Nov '21

08 Nov '21

commit 32c45a8f94d855ed0eaadd652b9bb48c12bf8e1d Merge: 1c77deca4f c9e2ee076c Author: Alexander Færøy <ahf(a)torproject.org> Date: Mon Nov 8 14:10:29 2021 +0000 Merge remote-tracking branch 'tor-gitlab/mr/479' into main README | 2 + doc/HACKING/ReleasingTor.md | 261 +++++++++++----------------------------- doc/HACKING/ReleasingTor.md.old | 255 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 325 insertions(+), 193 deletions(-)

1 0

[tor/main] doc: Brand new ReleasingTor.md
by ahf＠torproject.org 08 Nov '21

08 Nov '21

commit c9e2ee076cafd694e0de664d3fc8f1ab1216ceb1 Author: David Goulet <dgoulet(a)torproject.org> Date: Tue Nov 2 11:56:50 2021 -0400 doc: Brand new ReleasingTor.md Closes #40508 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- doc/HACKING/ReleasingTor.md | 261 +++++++++++----------------------------- doc/HACKING/ReleasingTor.md.old | 255 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 323 insertions(+), 193 deletions(-) diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index 490c100fcb..12f5d1b16b 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -1,239 +1,114 @@ -# CHECKLIST - -Here's a summary checklist, with the things that Nick messes up most often. - -Did you: - - * [ ] Copy the ChangeLog to the ReleaseNotes? - * [ ] Check that the new versions got approved? - * [ ] Check the release date in the ChangeLog? - * [ ] Update the GeoIP file? - -# Putting out a new release +# How to Release Tor Here are the steps that the maintainer should take when putting out a -new Tor release: - -## 0. Preliminaries - -1. Get at least three of weasel/arma/Sebastian/Sina to put the new - version number in their approved versions list. Give them a few - days to do this if you can. - -2. If this is going to be an important security release, give the packagers - advance warning, via `tor-packagers(a)lists.torproject.org`. - - -3. Given the release date for Tor, ask the TB team about the likely release - date of a TB that contains it. See note below in "commit, upload, - announce". - -## I. Make sure it works - -1. Make sure that CI passes: have a look at the branches on gitlab. - - _Optionally_, have a look at Travis - (https://travis-ci.org/torproject/tor/branches) Appveyor - (https://ci.appveyor.com/project/torproject/tor/history) and - Jenkins (https://jenkins.torproject.org/view/tor/) - Make sure you're looking at the right branches. - - If there are any unexplained failures, try to fix them or figure them - out. - -2. Verify that there are no big outstanding issues. You might find such - issues -- - - * On Gitlab - - * On coverity scan - - * On OSS-Fuzz - -## II. Write a changelog - - -1a. (Alpha release variant) - - Gather the `changes/*` files into a changelog entry, rewriting many - of them and reordering to focus on what users and funders would find - interesting and understandable. - - To do this, run `./scripts/maint/sortChanges.py changes/* > changelog.in` - to combine headings and sort the entries. Copy the changelog.in file into - the ChangeLog. Run `format_changelog.py --inplace` (see below) to clean up - the line breaks. - - Remove the `changes/*` files that you just merged into the ChangeLog. - - After that, it's time to hand-edit and fix the issues that - lintChanges can't find: - - 1. Within each section, sort by "version it's a bugfix on", else by - numerical ticket order. - - 2. Clean them up: - - Make stuff very terse - - Describe the user-visible problem right away - - Mention relevant config options by name. If they're rare or unusual, - remind people what they're for - - Avoid starting lines with open-paren - - Present and imperative tense: not past. - - "Relays", not "servers" or "nodes" or "Tor relays". - - "Onion services", not "hidden services". +new Tor release. It is split in 3 stages and coupled with our Tor CI Release +pipeline. - "Stop FOOing", not "Fix a bug where we would FOO". +Before we begin, first rule is to make sure: - Try not to let any given section be longer than about a page. Break up - long sections into subsections by some sort of common subtopic. This - guideline is especially important when organizing Release Notes for - new stable releases. + - Our CI pass for each version to release + - Coverity has no new alerts - If a given changes stanza showed up in a different release (e.g. - maint-0.2.1), be sure to make the stanzas identical (so people can - distinguish if these are the same change). +## 0. Security Release - 3. Clean everything one last time. +To start with, if you are doing a security release, this must be done few days +prior to the release: - 4. Run `./scripts/maint/format_changelog.py --inplace` to make it prettier + 1. If this is going to be an important security release, give the packagers + advance warning, via `tor-packagers(a)lists.torproject.org`. -1b. (old-stable release variant) - For stable releases that backport things from later, we try to compose - their releases, we try to make sure that we keep the changelog entries - identical to their original versions, with a "backport from 0.x.y.z" - note added to each section. So in this case, once you have the items - from the changes files copied together, don't use them to build a new - changelog: instead, look up the corrected versions that were merged - into ChangeLog in the main branch, and use those. +## 1. Preliminaries - Add "backport from X.Y.Z" in the section header for these entries. +The following must be done 2 days at the very least prior to the release: -2. Compose a short release blurb to highlight the user-facing - changes. Insert said release blurb into the ChangeLog stanza. If it's - a stable release, add it to the ReleaseNotes file too. If we're adding - to a release-* branch, manually commit the changelogs to the later - git branches too. + 1. Add the version(s) in the dirauth-conf git repository as the + RecommendedVersion and RequiredVersion so they can be approved by the + authorities and be in the consensus before the release. -3. If there are changes that require or suggest operator intervention - before or during the update, mail operators (either dirauth or relays - list) with a headline that indicates that an action is required or - appreciated. + 2. Send a pre-release announcement to `tor-project(a)lists.torproject.org` in + order to inform every teams in Tor of the upcoming release. This is so + we can avoid creating release surprises and sync with other teams. -4. If you're doing the first stable release in a series, you need to - create a ReleaseNotes for the series as a whole. To get started - there, copy all of the Changelog entries from the series into a new - file, and run `./scripts/maint/sortChanges.py` on it. That will - group them by category. Then kill every bugfix entry for fixing - bugs that were introduced within that release series; those aren't - relevant changes since the last series. At that point, it's time - to start sorting and condensing entries. (Generally, we don't edit the - text of existing entries, though.) + 3. Ask the network-team to review the `changes/` files in all versions we + are about to release. This step is encouraged but not mandatory. -## III. Making the source release. -1. In `maint-0.?.x`, bump the version number in `configure.ac` and run - `./scripts/main/update_versions.py` to update version numbers in other - places, and commit. Then merge `maint-0.?.x` into `release-0.?.x`. +## 2. Tarballs - When you merge the maint branch forward to the next maint branch, or into - main, merge it with `-s ours` to avoid conflict with the version - bump. +To build the tarballs to release, we need to launch the CI release pipeline: -2. In `release-0.?.x`, run `make distcheck`, put the tarball up in somewhere - (how about your homedir on people.torproject.org?) , and tell `#tor-dev` - about it. + https://gitlab.torproject.org/tpo/core/tor-ci-release - If you want, wait until at least one person has built it - successfully. (We used to say "wait for others to test it", but our - CI has successfully caught these kinds of errors for the last several - years.) +The `versions.yml` needs to be modified with the Tor versions you want to +release. Once done, git commit and push to trigger the release pipeline. -3. Make sure that the new version is recommended in the latest consensus. - (Otherwise, users will get confused when it complains to them - about its status.) +The first two stages (Preliminary and Patches) will be run automatically. The +Build stage needs to be triggered manually once all generated patches have +been merged upstream. - If it is not, you'll need to poke Roger, Weasel, Sebastian, and Sina - again: see the note at the start of the document. + 1. Download the generated patches from the `Patches` stage. -## IV. Commit, upload, announce + 2. For the ChangeLog and ReleaseNotes, you need to write a blurb at the top + explaining a bit the release. -1. Sign the tarball, then sign and push the git tag: + 3. Review, modify if needed, and merged them upstream. -```console -$ gpg -ba <the_tarball> -$ git tag -s tor-0.4.x.y-<status> -$ git push origin tag tor-0.4.x.y-<status> -``` + 4. Manually trigger the `maintained` job in the `Build` stage so the CI can + build the tarballs without errors. - (You must do this before you update the website: the website scripts - rely on finding the version by tag.) +Once this is done, each selected developers need to build the tarballs in a +reproducible way using: - (If your default PGP key is not the one you want to sign with, then say - "-u <keyid>" instead of "-s".) + https://gitlab.torproject.org/tpo/core/tor-ci-reproducible -2. scp the tarball and its sig to the dist website, i.e. - `/srv/dist-master.torproject.org/htdocs/` on dist-master. Run - "static-update-component dist.torproject.org" on dist-master. +Simply run the `./build.sh` which will commit interactively the signature for +you. You then only need to git push. - In the `project/web/tpo.git` repository, update `databags/versions.ini` - to note the new version. Push these changes to `master`. +Once all signatures have been committed: - (NOTE: Due to #17805, there can only be one stable version listed at - once. Nonetheless, do not call your version "alpha" if it is stable, - or people will get confused.) + 1. Manually trigger the `signature` job in the `Post-process` stage of the + CI release pipeline. - (NOTE: It will take a while for the website update scripts to update - the website.) + 2. If it passes, the tarball(s) and signature(s) will be available as + artifacts and should be used for the release. -3. Email the tor-packagers(a)lists.torproject.org mailing list to tell them - about the new release. + 3. Put them on `dist.torproject.org`: - Also, email tor-packagers(a)lists.torproject.org. + Upload the tarball and its sig to the dist website, i.e. + `/srv/dist-master.torproject.org/htdocs/` on dist-master. Run + "static-update-component dist.torproject.org" on dist-master. - Mention where to download the tarball (`https://dist.torproject.org/`). + In the `project/web/tpo.git` repository, update `databags/versions.ini` + to note the new version. Push these changes to `master`. - Include a link to the changelog. + (NOTE: Due to #17805, there can only be one stable version listed at once. + Nonetheless, do not call your version "alpha" if it is stable, or people + will get confused.) -4. Wait for the download page to be updated. (If you don't do this before you - announce, people will be confused.) + (NOTE: It will take a while for the website update scripts to update the + website.) -5. Mail the release blurb and ChangeLog to tor-talk (development release) or - tor-announce (stable). - Post the changelog on the blog as well. You can generate a - blog-formatted version of the changelog with - `./scripts/maint/format_changelog.py -B` +## 3. Post Process - When you post, include an estimate of when the next TorBrowser - releases will come out that include this Tor release. This will - usually track https://wiki.mozilla.org/RapidRelease/Calendar , but it - can vary. +Once the tarballs have been uploaded and are ready to be announced, we need to +do the following: - For templates to use when announcing, see: - https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Announcemen… + 1. Merge upstream the artifacts from the `patches` job in the + `Post-process` stage of the CI release pipeline. -## V. Aftermath and cleanup + 2. Write and post the release announcement for the `forum.torproject.net` + in the `News -> Tor Release Announcement` category. -1. If it's a stable release, bump the version number in the - `maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours` - merge to avoid taking that change into main. + Mention in which Tor Browser version (with dates) the release will be + in. This usually only applies to the latest stable. -2. If there is a new `maint-x.y.z` branch, create a Travis CI cron job that - builds the release every week. (It's ok to skip the weekly build if the - branch was updated in the last 24 hours.) +### New Stable -3. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the - main branch. + 1. Create the `maint-x.y.z` and `release-x.y.z` branches and update the + `./scripts/git/git-list-tor-branches.sh` with the new version. -4. Keep an eye on the blog post, to moderate comments and answer questions. ## Appendix: An alternative means to notify packagers diff --git a/doc/HACKING/ReleasingTor.md.old b/doc/HACKING/ReleasingTor.md.old new file mode 100644 index 0000000000..490c100fcb --- /dev/null +++ b/doc/HACKING/ReleasingTor.md.old @@ -0,0 +1,255 @@ +# CHECKLIST + +Here's a summary checklist, with the things that Nick messes up most often. + +Did you: + + * [ ] Copy the ChangeLog to the ReleaseNotes? + * [ ] Check that the new versions got approved? + * [ ] Check the release date in the ChangeLog? + * [ ] Update the GeoIP file? + +# Putting out a new release + +Here are the steps that the maintainer should take when putting out a +new Tor release: + +## 0. Preliminaries + +1. Get at least three of weasel/arma/Sebastian/Sina to put the new + version number in their approved versions list. Give them a few + days to do this if you can. + +2. If this is going to be an important security release, give the packagers + advance warning, via `tor-packagers(a)lists.torproject.org`. + + +3. Given the release date for Tor, ask the TB team about the likely release + date of a TB that contains it. See note below in "commit, upload, + announce". + +## I. Make sure it works + +1. Make sure that CI passes: have a look at the branches on gitlab. + + _Optionally_, have a look at Travis + (https://travis-ci.org/torproject/tor/branches) Appveyor + (https://ci.appveyor.com/project/torproject/tor/history) and + Jenkins (https://jenkins.torproject.org/view/tor/) + Make sure you're looking at the right branches. + + If there are any unexplained failures, try to fix them or figure them + out. + +2. Verify that there are no big outstanding issues. You might find such + issues -- + + * On Gitlab + + * On coverity scan + + * On OSS-Fuzz + +## II. Write a changelog + + +1a. (Alpha release variant) + + Gather the `changes/*` files into a changelog entry, rewriting many + of them and reordering to focus on what users and funders would find + interesting and understandable. + + To do this, run `./scripts/maint/sortChanges.py changes/* > changelog.in` + to combine headings and sort the entries. Copy the changelog.in file into + the ChangeLog. Run `format_changelog.py --inplace` (see below) to clean up + the line breaks. + + Remove the `changes/*` files that you just merged into the ChangeLog. + + After that, it's time to hand-edit and fix the issues that + lintChanges can't find: + + 1. Within each section, sort by "version it's a bugfix on", else by + numerical ticket order. + + 2. Clean them up: + + Make stuff very terse + + Describe the user-visible problem right away + + Mention relevant config options by name. If they're rare or unusual, + remind people what they're for + + Avoid starting lines with open-paren + + Present and imperative tense: not past. + + "Relays", not "servers" or "nodes" or "Tor relays". + + "Onion services", not "hidden services". + + "Stop FOOing", not "Fix a bug where we would FOO". + + Try not to let any given section be longer than about a page. Break up + long sections into subsections by some sort of common subtopic. This + guideline is especially important when organizing Release Notes for + new stable releases. + + If a given changes stanza showed up in a different release (e.g. + maint-0.2.1), be sure to make the stanzas identical (so people can + distinguish if these are the same change). + + 3. Clean everything one last time. + + 4. Run `./scripts/maint/format_changelog.py --inplace` to make it prettier + +1b. (old-stable release variant) + + For stable releases that backport things from later, we try to compose + their releases, we try to make sure that we keep the changelog entries + identical to their original versions, with a "backport from 0.x.y.z" + note added to each section. So in this case, once you have the items + from the changes files copied together, don't use them to build a new + changelog: instead, look up the corrected versions that were merged + into ChangeLog in the main branch, and use those. + + Add "backport from X.Y.Z" in the section header for these entries. + +2. Compose a short release blurb to highlight the user-facing + changes. Insert said release blurb into the ChangeLog stanza. If it's + a stable release, add it to the ReleaseNotes file too. If we're adding + to a release-* branch, manually commit the changelogs to the later + git branches too. + +3. If there are changes that require or suggest operator intervention + before or during the update, mail operators (either dirauth or relays + list) with a headline that indicates that an action is required or + appreciated. + +4. If you're doing the first stable release in a series, you need to + create a ReleaseNotes for the series as a whole. To get started + there, copy all of the Changelog entries from the series into a new + file, and run `./scripts/maint/sortChanges.py` on it. That will + group them by category. Then kill every bugfix entry for fixing + bugs that were introduced within that release series; those aren't + relevant changes since the last series. At that point, it's time + to start sorting and condensing entries. (Generally, we don't edit the + text of existing entries, though.) + +## III. Making the source release. + +1. In `maint-0.?.x`, bump the version number in `configure.ac` and run + `./scripts/main/update_versions.py` to update version numbers in other + places, and commit. Then merge `maint-0.?.x` into `release-0.?.x`. + + When you merge the maint branch forward to the next maint branch, or into + main, merge it with `-s ours` to avoid conflict with the version + bump. + +2. In `release-0.?.x`, run `make distcheck`, put the tarball up in somewhere + (how about your homedir on people.torproject.org?) , and tell `#tor-dev` + about it. + + If you want, wait until at least one person has built it + successfully. (We used to say "wait for others to test it", but our + CI has successfully caught these kinds of errors for the last several + years.) + +3. Make sure that the new version is recommended in the latest consensus. + (Otherwise, users will get confused when it complains to them + about its status.) + + If it is not, you'll need to poke Roger, Weasel, Sebastian, and Sina + again: see the note at the start of the document. + +## IV. Commit, upload, announce + +1. Sign the tarball, then sign and push the git tag: + +```console +$ gpg -ba <the_tarball> +$ git tag -s tor-0.4.x.y-<status> +$ git push origin tag tor-0.4.x.y-<status> +``` + + (You must do this before you update the website: the website scripts + rely on finding the version by tag.) + + (If your default PGP key is not the one you want to sign with, then say + "-u <keyid>" instead of "-s".) + +2. scp the tarball and its sig to the dist website, i.e. + `/srv/dist-master.torproject.org/htdocs/` on dist-master. Run + "static-update-component dist.torproject.org" on dist-master. + + In the `project/web/tpo.git` repository, update `databags/versions.ini` + to note the new version. Push these changes to `master`. + + (NOTE: Due to #17805, there can only be one stable version listed at + once. Nonetheless, do not call your version "alpha" if it is stable, + or people will get confused.) + + (NOTE: It will take a while for the website update scripts to update + the website.) + +3. Email the tor-packagers(a)lists.torproject.org mailing list to tell them + about the new release. + + Also, email tor-packagers(a)lists.torproject.org. + + Mention where to download the tarball (`https://dist.torproject.org/`). + + Include a link to the changelog. + +4. Wait for the download page to be updated. (If you don't do this before you + announce, people will be confused.) + +5. Mail the release blurb and ChangeLog to tor-talk (development release) or + tor-announce (stable). + + Post the changelog on the blog as well. You can generate a + blog-formatted version of the changelog with + `./scripts/maint/format_changelog.py -B` + + When you post, include an estimate of when the next TorBrowser + releases will come out that include this Tor release. This will + usually track https://wiki.mozilla.org/RapidRelease/Calendar , but it + can vary. + + For templates to use when announcing, see: + https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Announcemen… + +## V. Aftermath and cleanup + +1. If it's a stable release, bump the version number in the + `maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours` + merge to avoid taking that change into main. + +2. If there is a new `maint-x.y.z` branch, create a Travis CI cron job that + builds the release every week. (It's ok to skip the weekly build if the + branch was updated in the last 24 hours.) + +3. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the + main branch. + +4. Keep an eye on the blog post, to moderate comments and answer questions. + +## Appendix: An alternative means to notify packagers + +If for some reason you need to contact a bunch of packagers without +using the publicly archived tor-packagers list, you can try these +people: + + - {weasel,sysrqb,mikeperry} at torproject dot org + - {blueness} at gentoo dot org + - {paul} at invizbox dot io + - {vincent} at invizbox dot com + - {lfleischer} at archlinux dot org + - {Nathan} at freitas dot net + - {mike} at tig dot as + - {tails-rm} at boum dot org + - {simon} at sdeziel.info + - {yuri} at freebsd.org + - {mh+tor} at scrit.ch + - {security} at brave.com

1 0

[tor/main] readme: CI Pipeline status icon at the top
by ahf＠torproject.org 08 Nov '21

08 Nov '21

commit 6cb349e989837a78cdaa1e557194473a20361bba Author: David Goulet <dgoulet(a)torproject.org> Date: Mon Nov 1 15:29:59 2021 -0400 readme: CI Pipeline status icon at the top Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- README | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README b/README index 397f6b927e..a1421e5186 100644 --- a/README +++ b/README @@ -1,3 +1,5 @@ +[![pipeline status](https://gitlab.torproject.org/tpo/core/tor/badges/main/pipeline.svg… + Tor protects your privacy on the internet by hiding the connection between your Internet address and the services you use. We believe Tor is reasonably secure, but please ensure you read the instructions and

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 07 Nov '21

07 Nov '21

commit c2d77fbc15b1f9895fdad39f9261b244c223d7cd Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 7 19:16:47 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+es.po | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contents+es.po b/contents+es.po index d1be193592..ef4730145b 100644 --- a/contents+es.po +++ b/contents+es.po @@ -3866,7 +3866,8 @@ msgid "" "/android-view-logs.gif\" alt=\"View Tor logs on Tor Browser for Android\">" msgstr "" "<img style=\"max-width:300px\" class=\"img-fluid\" src=\"../../static/images" -"/android-view-logs.gif\" alt=\"View Tor logs on Tor Browser for Android\">" +"/android-view-logs.gif\" alt=\"Ver el registro en Tor Browser para " +"Android\"/>" #: https//tb-manual.torproject.org/mobile-tor/ #: (content/mobile-tor/contents+en.lrtopic.body)

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 07 Nov '21

07 Nov '21

commit 09da141b420f6ff99b78b338e097d875066617fe Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 7 18:47:48 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+es.po | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contents+es.po b/contents+es.po index ae26ed7dae..e9d0914413 100644 --- a/contents+es.po +++ b/contents+es.po @@ -16766,6 +16766,8 @@ msgid "" "Roger Dingledine (0xEB5A896A28988BF5 and 0xC218525819F78451), Nick Mathewson" " (0xFE43009C4607B1FB) sign Tor source tarballs." msgstr "" +"Roger Dingledine (0xEB5A896A28988BF5 y 0xC218525819F78451), Nick Mathewson " +"(0xFE43009C4607B1FB) fiman los tarballs del código fuente de Tor." #: https//support.torproject.org/little-t-tor/verify-little-t-tor/ #: (content/little-t-tor/verify-little-t-tor/contents+en.lrquestion.description)

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 07 Nov '21

07 Nov '21

commit 860a5a4c9e59ad9a2a1c6e5ad0b069bc6714de5a Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 7 17:47:56 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+es.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contents+es.po b/contents+es.po index 32a191a27e..ae26ed7dae 100644 --- a/contents+es.po +++ b/contents+es.po @@ -9518,7 +9518,7 @@ msgid "" "This way each relay can decide the services, hosts, and networks it wants to" " allow connections to, based on abuse potential and its own situation." msgstr "" -"De esta forma cada repetidor puede elegir que servicios, destinos y redes " +"De esta forma cada repetidor puede elegir qué servicios, destinos y redes " "quiere permitir, basándose en el potencial para el abuso o en otros " "criterios." @@ -9714,7 +9714,7 @@ msgid "" "/path/to/correct/torrc`." msgstr "" "* Modifica los scripts de arranque del cliente y del repetidor para que " -"incluyan `-f /ruta/al/corrspondiente/torrc`." +"incluyan `-f /ruta/al/correspondiente/torrc`." #: https//support.torproject.org/relay-operators/hibernation/ #: (content/relay-operators/hibernation/contents+en.lrquestion.description) @@ -12595,7 +12595,7 @@ msgid "" "Yes! A list of our Onion Services is available at " "[onion.torproject.org](https://onion.torproject.org/)." msgstr "" -"¡Sí! Hay disponible una lista de nuestros servicios cebolla en " +"¡Sí! Hay una lista de nuestros servicios cebolla disponible en " "[onion.torproject.org](https://onion.torproject.org/)." #: https//support.torproject.org/onionservices/onionservices-5/

1 0

[translation/tpo-web_completed] https://gitweb.torproject.org/translation.git/commit/?h=tpo-web_completed
by translation＠torproject.org 07 Nov '21

07 Nov '21

commit b09f3fc28e7d83be13f62ddf73fe07b2d70d4b9c Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 7 17:47:53 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tpo-web_completed --- contents+es.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contents+es.po b/contents+es.po index 3713d011fe..94205a4125 100644 --- a/contents+es.po +++ b/contents+es.po @@ -1624,7 +1624,7 @@ msgstr "La privacidad es un derecho humano." #: lego/templates/banner.html:15 templates/banner.html:15 msgid "Your donation will be matched by Friends of Tor, up to $150,000." -msgstr "" +msgstr "Tu donación será igualada por Amigos de Tor hasta $150.000." #: lego/templates/banner.html:26 templates/banner.html:26 msgid "Your donation will be matched by Friends of Tor, up to $100,000." @@ -1633,7 +1633,7 @@ msgstr "A tu donación la emparejará Amigos de Tor hasta $100.000." #: lego/templates/banner.html:31 lego/templates/banner.html:33 #: templates/banner.html:31 templates/banner.html:33 msgid "Donate now" -msgstr "" +msgstr "Dona ahora" #: lego/templates/footer.html:13 lego/templates/footer.html:22 #: lego/templates/navbar.html:96 templates/footer.html:13

1 0

[translation/tpo-web] https://gitweb.torproject.org/translation.git/commit/?h=tpo-web
by translation＠torproject.org 07 Nov '21

07 Nov '21

commit df2a9348fd48d805184fa5e55e591be6d80bdb0b Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 7 17:47:49 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tpo-web --- contents+es.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contents+es.po b/contents+es.po index 047addedc9..94205a4125 100644 --- a/contents+es.po +++ b/contents+es.po @@ -1633,7 +1633,7 @@ msgstr "A tu donación la emparejará Amigos de Tor hasta $100.000." #: lego/templates/banner.html:31 lego/templates/banner.html:33 #: templates/banner.html:31 templates/banner.html:33 msgid "Donate now" -msgstr "Dona Ahora" +msgstr "Dona ahora" #: lego/templates/footer.html:13 lego/templates/footer.html:22 #: lego/templates/navbar.html:96 templates/footer.html:13

1 0

[translation/communitytpo-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-contentspot
by translation＠torproject.org 07 Nov '21

07 Nov '21

commit fca3492ed788fe1f0e09732f206c37480048694e Author: Translation commit bot <translation(a)torproject.org> Date: Sun Nov 7 17:45:15 2021 +0000 https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-conten… --- contents+es.po | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/contents+es.po b/contents+es.po index 95c63372b0..d53aecb5c0 100644 --- a/contents+es.po +++ b/contents+es.po @@ -8571,8 +8571,7 @@ msgid "" "Defending a site under attack requires creativity and a custom-tailored " "approach." msgstr "" -"Defender un sitio bajo ataque requiere creatividad y un abordaje a la " -"medida." +"Defender un sitio atacado requiere creatividad y un abordaje a la medida." #: https//community.torproject.org/onion-services/advanced/dos/ #: (content/onion-services/advanced/dos/contents+en.lrpage.body) @@ -8780,9 +8779,9 @@ msgid "" "many queries, try to detect that overuse and kill them using the " "`HiddenServiceExportCircuitID` torrc option." msgstr "" -"Si los atacantes te están abrumando con circuitos agresivos que realizan " -"demasiadas consultas, intenta detectar ese sobreuso y eliminarlos usando la " -"opción `HiddenServiceExportCircuitID` en torrc." +"Si los atacantes te acosan con circuitos agresivos que realizan demasiadas " +"consultas, intenta detectar ese sobreuso y eliminarlos usando la opción " +"`HiddenServiceExportCircuitID` en torrc." #: https//community.torproject.org/onion-services/advanced/dos/ #: (content/onion-services/advanced/dos/contents+en.lrpage.body) @@ -12393,8 +12392,8 @@ msgstr "" #: (content/relay/community-resources/tor-exit-guidelines/contents+en.lrpage.body) msgid "1. Ask if the ISP is okay with a Tor exit" msgstr "" -"1. Pregunta al proveedor de Internet si tiene problemas con las salidas de " -"Tor" +"1. Pregunta al proveedor de Internet si tiene problemas con que mantengas " +"una salida de Tor" #: https//community.torproject.org/relay/community-resources/tor-exit-guidelines/ #: (content/relay/community-resources/tor-exit-guidelines/contents+en.lrpage.body) @@ -16155,8 +16154,8 @@ msgid "" "free to educate them on this point." msgstr "" "**Edúcalos acerca de Tor**. La mayoría de las veces, los repetidores Tor " -"configurados correctamente no tendrán datos útiles para terceros que " -"soliciten información, y deberías educarlos al respecto." +"configurados correctamente no tendrán datos útiles para aquellos que " +"solicitan la información, y deberías educarlos al respecto." #: https//community.torproject.org/relay/community-resources/eff-tor-legal-faq/ #: (content/relay/community-resources/eff-tor-legal-faq/contents+en.lrpage.body) @@ -19226,11 +19225,10 @@ msgstr "" "puede tomar varios días o semanas hasta que veas un conjunto de usuarios " "consistentes, por lo que no te acobardes si no ves conexiones de usuarios " "desde el principio. BridgeDB usa cuatro métodos para la distribución de " -"puentes: HTTPS, Moat, correo electrónico y manual. Algunos métodos son " -"usados más que otros, lo cual afecta trambién al tiempo que pase hasta que " -"tu puente vea usuarios. Finalmente, no hay muchos usuarios de puentes allá " -"afuera, por lo que no puedes esperar que el tuyo sea tan popular como un " -"repetidor." +"puentes: HTTPS, Moat, correo electrónico y manual. Algunos métodos se usan " +"más que otros, lo cual afecta trambién al tiempo que pase hasta que tu " +"puente vea usuarios. Finalmente, no hay muchos usuarios de puentes, por lo " +"que note preocupes si el tuyo no es tan popular como un repetidor." #: https//community.torproject.org/relay/setup/bridge/post-install/ #: (content/relay/setup/bridge/post-install/contents+en.lrpage.body)

1 0