pluggable transports issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues2020-06-27T13:43:52Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/28936Use Travis CI for goptlib.git repositories on Github2020-06-27T13:43:52ZAlexander Færøyahf@torproject.orgUse Travis CI for goptlib.git repositories on GithubMembers on the network team have been happy to use the Travis CI for `tor.git` in the past year or so.
Let's have the same for `goptlib.git` if some people are going to do development there and have their repositories located on Github.Members on the network team have been happy to use the Travis CI for `tor.git` in the past year or so.
Let's have the same for `goptlib.git` if some people are going to do development there and have their repositories located on Github.Tor: unspecifiedDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/16895allow Tor to parse bridge information copied and pasted verbatim from bridges...2021-11-15T18:53:41Zproperallow Tor to parse bridge information copied and pasted verbatim from bridges.torproject.orgCurrently bridges.torproject.org returns replies for copy and paste in the following form.
```
obfs4 ip:port fingerprint
```
This is easy for copied into tor-launcher. But one who wanted to copy this into its `/etc/tor/torrc` would hav...Currently bridges.torproject.org returns replies for copy and paste in the following form.
```
obfs4 ip:port fingerprint
```
This is easy for copied into tor-launcher. But one who wanted to copy this into its `/etc/tor/torrc` would have to modify it to.
```
Bridge obfs4 ip:port fingerprint
```
This is a usability issue. Therefore, could you make for example `/etc/tor/torrc` config option `obfs4` a shortcut to `Bridge obfs4` etc.?
Ideally, pluggable transports once they plugged into Tor using `ClientTransportPlugin` would be responsible for running the code for setting up these shortcuts themselves so you don't have to maintain a static/outdated list of shortcuts within the Tor core.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/15593Bring sanity to the tor side of the PT shutdown process.2021-11-15T18:55:15ZYawning AngelBring sanity to the tor side of the PT shutdown process.This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow...This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow graceful termination to look like this:
1. Close stdin (and on U*IX, send a SIGTERM, PT behavior here is equivalent).
2. Wait for a grace period (~1 sec?)
3. If the child still is not dead, send a SIGKILL/TerminateProcess(). (Failsafe)
This fixes legacy/trac#9330 in that, PTs that wish to trap a graceful shutdown on Windows have a way to do so, despite the final stage of the process killing the PT in the most violent way possible as a failsafe (realistically, PTs should exit shortly after step 1).Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/10629PT spec changes for better interoperability with other projects2021-11-08T19:56:38ZXimin LuoPT spec changes for better interoperability with other projectsI spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.
Major improvements:
- better spec documentation
- less Tor jarg...I spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.
Major improvements:
- better spec documentation
- less Tor jargon, split Tor-specific information into separate sections (e.g. Tor env vars)
- some guidelines for non-Tor programs to use PTs
- better handling of per-endpoint config params such as pubkeys, instead of current hack via SOCKS auth params
Smaller enhancements, "good to have":
- possibility of letting a single process to act as both a client (outgoing) and server (incoming).
- flashproxy must allow client-specific remote endpoints (already as legacy/trac#10196)
- don't trust the entire localhost machine to make outgoing connections, e.g. if one users wants to run his own instance. two options here:
- SSL connection with user/pass to the SOCKS transport client
- use unix domain sockets. This also frees up ports, which is extra-useful in PT composition. Doesn't work on windows, though.Tor: unspecifiedYawning AngelYawning Angel