The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-01-21T21:55:53Zhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/20Split Salmon code into separate source code files2021-01-21T21:55:53ZPhilipp Winterphw@torproject.orgSplit Salmon code into separate source code filessalmon.go currently counts 609 lines of code. We should take some of its functionality (in particular the data structures for proxies, users, and associations) and move it to separate source code files.salmon.go currently counts 609 lines of code. We should take some of its functionality (in particular the data structures for proxies, users, and associations) and move it to separate source code files.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1270Split service Recovering state into RecoveringReachable and RecoveringUnreach...2024-02-12T12:36:58Zgabi-250Split service Recovering state into RecoveringReachable and RecoveringUnreachableThe following discussion from !1966 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1966#note_2994338): (+1 comment)
> I have two comments about this.
>
...The following discussion from !1966 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1966#note_2994338): (+1 comment)
> I have two comments about this.
>
> Firstly, "The service may or may not be reachable" means this status cannot be properly handled by a caller that wants to (for example) wait during startup for the service to be readhable. So I think this status ought to be split, or something.
>
> Secondly, the doc comments form part of the public API but all talk about information that is only available inside the crate, and that a caller can't determine. By writing this here, you're inviting the author of calling code to attempt to figure out how to obtain this other information, which they can't.
>
> I think probably the best thing to do for this MR is to make the ifs and buts be `//` comments rather than doc comments, and make a ticket about the first problem.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/2475Split SIZE_T_CEILING, SSIZE_T_CEILING2020-06-27T14:08:43ZNick MathewsonSplit SIZE_T_CEILING, SSIZE_T_CEILINGFor good C practice, we should have separate signed and unsigned values for the ssize_t and size_t ceilings, and avoid signed-to-unsigned comparisons. See comments in bug legacy/trac#2337 for background.
(We don't want to just make SIZ...For good C practice, we should have separate signed and unsigned values for the ssize_t and size_t ceilings, and avoid signed-to-unsigned comparisons. See comments in bug legacy/trac#2337 for background.
(We don't want to just make SIZE_T_CEILING unsigned and use it everwhere, since comparing a ssize_t to an unsigned SIZE_T_CEILING is just as broken as comparing a size_t to a signed SIZE_T_CEILING.)https://gitlab.torproject.org/tpo/core/tor/-/issues/26481Split src/common into src/lib2020-06-27T13:53:07ZNick MathewsonSplit src/common into src/libThis work has already begun; we should have a ticket for it.This work has already begun; we should have a ticket for it.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27892Split the non-stats part of the stats module into different modules2021-09-16T14:28:09ZNick MathewsonSplit the non-stats part of the stats module into different modulesPart of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Part of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17579Split tor-gencert into "make cert" and "sign" portions2022-06-17T16:31:35ZNick MathewsonSplit tor-gencert into "make cert" and "sign" portionsThe only part of tor-gencert that wants to stay offline is the part that actually uses the master identity key to sign the certificate. All the rest of generating the cert could be done online.
If we made those changes, we would allow ...The only part of tor-gencert that wants to stay offline is the part that actually uses the master identity key to sign the certificate. All the rest of generating the cert could be done online.
If we made those changes, we would allow operators to leave their offline gencert setups unmaintained for a very very very long time, which would make it easier to keep master identity keys offline.https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/24Split torcontrol methods to measure into other file2022-02-08T08:59:00ZjugaSplit torcontrol methods to measure into other fileonbasca: 1.0jugajugahttps://gitlab.torproject.org/tpo/core/arti/-/issues/360Split up cases of errors based on END cells in tor-proto2022-02-24T19:56:31ZNick MathewsonSplit up cases of errors based on END cells in tor-protoAs discussed on #348, these shouldn't all be under a single RemoteStreamError errorkind; they should instead be distinguished based on the actual code in the END cell.As discussed on #348, these shouldn't all be under a single RemoteStreamError errorkind; they should instead be distinguished based on the actual code in the END cell.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/359Split up cases of IoError in tor-proto2022-02-24T19:56:31ZNick MathewsonSplit up cases of IoError in tor-protoFrom #348.
When we get an IoError, we should distinguish its real kind based on what kind of io error happened where.
These should _not_ be under the "Network" ErrorKind, which shouldn't exit.From #348.
When we get an IoError, we should distinguish its real kind based on what kind of io error happened where.
These should _not_ be under the "Network" ErrorKind, which shouldn't exit.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40542Split up rbm.conf2023-08-26T06:05:20ZGeorg KoppenSplit up rbm.confThe options in `rbm.conf` are either `tor-browser-build` specific or should move to `rbm` or be module-dependent. We should go over them and split things out accordingly.The options in `rbm.conf` are either `tor-browser-build` specific or should move to `rbm` or be module-dependent. We should go over them and split things out accordingly.Sponsor 131 - Phase 5 - Ongoing Maintenanceboklmboklmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27924Split up routerparse.c2020-06-27T13:51:59ZNick MathewsonSplit up routerparse.cIt's one of the largest files still in tor, and it should divide up nicely.It's one of the largest files still in tor, and it should divide up nicely.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40350Split up tor-browser-build into a generic project and tor-browser related parts2023-01-05T13:55:25ZGeorg KoppenSplit up tor-browser-build into a generic project and tor-browser related partsOver the weekend I wanted to look at [relay-search](https://gitlab.torproject.org/tpo/network-health/metrics/relay-search) and how I can modify code in it. I had some trouble compiling it and ended up working on a [reproducible builds en...Over the weekend I wanted to look at [relay-search](https://gitlab.torproject.org/tpo/network-health/metrics/relay-search) and how I can modify code in it. I had some trouble compiling it and ended up working on a [reproducible builds environment for our metrics projects](https://gitlab.torproject.org/gk/metrics-build.git). I heard @richard and @JeremyRand started from forking off of tor-browser-build and it was... not an optimal experience. I started from the other side: a project just with [rbm](https://gitlab.torproject.org/tpo/applications/rbm) as submodule, picking from tor-browser-build what I actually needed. While doing so it felt to me that all the consumers of our reproducible build system would benefit if we could move the shared tor-browser-build items in a separate project. That might help the adoption of our reproducible build system, too. What I thought worth sharing and maintaining in an own project was:
- the container creation and handling
- the infrastructure dealing with git/mercurial repos, signed tags etc.
- all the reproducibility related bits
- dealing with old artifacts (that is `make clean` things)
- a default example rbm config file dealing with the minimum of config options (like number of CPUs, or logging location etc.)
/cc @boklm, @richard, @JeremyRandboklmboklmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21349Split up very long functions in entrynodes.c2021-09-16T14:33:05ZNick MathewsonSplit up very long functions in entrynodes.cSome functions in entrynodes.c are now pretty huge, especially:
* sampled_guards_update_from_consensus()
* entry_guards_update_primary()
* select_entry_guard_for_circuit()
It would be good for testing and maintenance to split them...Some functions in entrynodes.c are now pretty huge, especially:
* sampled_guards_update_from_consensus()
* entry_guards_update_primary()
* select_entry_guard_for_circuit()
It would be good for testing and maintenance to split them up.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/34216Split visualizations into public server vs. v2 onion server vs. v3 onion serv...2020-07-02T09:59:18ZKarsten LoesingSplit visualizations into public server vs. v2 onion server vs. v3 onion server measurementsRight now, OnionPerf visualizations contain all measurements found in a data set. This can be very confusing, because this includes measurements performed via exits, via v2 onion service, and via v3 onion service. We should split visuali...Right now, OnionPerf visualizations contain all measurements found in a data set. This can be very confusing, because this includes measurements performed via exits, via v2 onion service, and via v3 onion service. We should split visualizations, or we should provide a filter and only graph one subset of measurements at a time.OnionPerf: Scalability, Performance, Establishing Basline MetricsKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32137Split {feature,core,app}/*/include.am out of core/include.am2020-06-27T13:49:07ZteorSplit {feature,core,app}/*/include.am out of core/include.amIt seems a bit weird that we're missing feature/include.am, maybe it's time to fix that.It seems a bit weird that we're missing feature/include.am, maybe it's time to fix that.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24658Split/refactor crypto.h into smaller separate modules2021-09-16T14:31:18ZIsis LovecruftSplit/refactor crypto.h into smaller separate modulesThis will make it easier to maintain, as well as easier to create new/alternate implementations of portions of the code (e.g. in Rust). `crypto.h` is already somewhat neatly partitioned into sections. nickm said that likely appropriate c...This will make it easier to maintain, as well as easier to create new/alternate implementations of portions of the code (e.g. in Rust). `crypto.h` is already somewhat neatly partitioned into sections. nickm said that likely appropriate categories for code for the new modules are
> something like: rsa, stream cipher, digest+xof, prime-field dh, openssl management, PRNG, and derived functions.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17380Splitting the build of each components2020-06-27T14:40:03ZboklmSplitting the build of each componentsFor legacy/trac#17379, the gitian descriptors need to be split by component and converted in a new format.
Some of them have already been done for Tor Messenger:
- python
- binutils
- gcc
- mingw-w64
- macosx-toolchain
- tor-launcher
T...For legacy/trac#17379, the gitian descriptors need to be split by component and converted in a new format.
Some of them have already been done for Tor Messenger:
- python
- binutils
- gcc
- mingw-w64
- macosx-toolchain
- tor-launcher
The main ones that are not yet done:
- the browser
- torbutton
- openssl
- tor
- the various pluggable transportsboklmboklmhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/16995Splitting the pool of bridges by seperating people depending on typing cadence2020-06-27T13:43:02ZTracSplitting the pool of bridges by seperating people depending on typing cadencewith OCR getting better and better captchas soon wont be able to provide enough protection against bots fetching bridges anymore. but even if it was safe enough a censor could still hire a cheap worker to type in captchas all day long.
...with OCR getting better and better captchas soon wont be able to provide enough protection against bots fetching bridges anymore. but even if it was safe enough a censor could still hire a cheap worker to type in captchas all day long.
if you let a neural network group people by typing cadence and only supply a group with a subset of the bridges then a single person/bot will never be able to pull the whole database.
**Trac**:
**Username**: elypterIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/tpa/team/-/issues/5240spoiler plugin2020-06-27T14:21:13Zproperspoiler pluginCan you please install the spoiler plugin?
A spoiler enhances the wiki. You can hide text with a spoiler which will be revealed after pressing a button.
There is a [video demonstration](https://www.youtube.com/watch?v=TyuelS_e0Js) avai...Can you please install the spoiler plugin?
A spoiler enhances the wiki. You can hide text with a spoiler which will be revealed after pressing a button.
There is a [video demonstration](https://www.youtube.com/watch?v=TyuelS_e0Js) available (html5, only 9 seconds). It does not need javascript. [Here](http://trac-hacks.org/wiki/SpoilerMacro) are instructions how to install it and the source code. If there are technical questions, the author of the plugin is very friendly and [answers fast](https://groups.google.com/group/trac-users/browse_thread/thread/f55ceee3a26abaa9).
This plugin would be very useful for [my project](https://trac.torproject.org/projects/tor/wiki/doc/TorBOX).Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/150Sponsor 123: New upstream domain for VOA Turkish service2023-06-27T21:11:10ZSilvio RhattoSponsor 123: New upstream domain for VOA Turkish serviceVOA Turkey primary domain has been changed from amerikaninsesi.com to voaturkce.com recently.
Upstream did not informed us before the change and hence the Onion Service https://sesic3wy3ursfzn7odbol5ddurz2kr3rbfvgnowhwbaefjahzwwsycqd.o...VOA Turkey primary domain has been changed from amerikaninsesi.com to voaturkce.com recently.
Upstream did not informed us before the change and hence the Onion Service https://sesic3wy3ursfzn7odbol5ddurz2kr3rbfvgnowhwbaefjahzwwsycqd.onion stopped working.
Service for amerikaninsesi.org (https://sesi2v3autjxps3xrdvhguwas74fgevaslohurbvh736dlkdazdrqqad.onion) is unaffected.
/cc @rayaSponsor 123: Tor Secure Access Package for USAGM [First Phase]Silvio RhattoSilvio Rhatto2022-09-28