Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T00:42:35Zhttps://gitlab.torproject.org/legacy/trac/-/issues/24417Change Tor Browser defaults2020-06-16T00:42:35ZTracChange Tor Browser defaultsNow we have the following browser defaults:
beacon.enabled = true;
browser.tabs.crashReporting.sendReport = true;
camera.control.face_detection.enabled = true;
canvas.capturestream.enabled = true;
datareporting.policy.dataSubmissionEnab...Now we have the following browser defaults:
beacon.enabled = true;
browser.tabs.crashReporting.sendReport = true;
camera.control.face_detection.enabled = true;
canvas.capturestream.enabled = true;
datareporting.policy.dataSubmissionEnabled.v2 = undefined; // should be false
dom.ipc.plugins.flash.subprocess.crashreporter.enabled = true;
dom.ipc.plugins.reportCrashURL = true;
dom.ipc.reportProcessHangs = true;
dom.keyboardevent.code.enabled = true;
experiments.supported = true;
extensions.pocket.enabled = true;
identity.fxaccounts.profile_image.enabled = true;
keyword.enabled = true;
media.getusermedia.screensharing.enabled = true;
narrate.enabled = true;
network.allow-experiments = true;
places.history.enabled = true;
privacy.trackingprotection.enabled = false; //????
privacy.trackingprotection.ui.enabled = false;
security.ssl.treat_unsafe_negotiation_as_broken = false;
security.ssl3.rsa_des_ede3_sha = true; //DES should be disabled?
services.sync.sendTabToDevice.enabled = true;
services.sync.syncedTabs.showRemoteIcons = true;
services.sync.sendVersionInfo = true;
services.sync.engine.passwords = true;
services.sync.engine.history = true;
services.sync.engine.bookmarks = true;
signon.formlessCapture.enabled = true;
toolkit.telemetry.archive.enabled = true; //:)
toolkit.telemetry.rejected = undefined; //should be true
Obviously, it should be changed to more *secure* values to prevent user identification.
**Trac**:
**Username**: indigotimehttps://gitlab.torproject.org/legacy/trac/-/issues/28737Redesign sbws torrc option configuration2020-06-13T16:15:03ZteorRedesign sbws torrc option configurationsbws' torrc option handling is broken.
Here's a better scheme:
1. sbws config.default.ini and config.ini contain the following sections:
* tor.options.launch: a minimal set of options that must be configured when tor is launched. The ...sbws' torrc option handling is broken.
Here's a better scheme:
1. sbws config.default.ini and config.ini contain the following sections:
* tor.options.launch: a minimal set of options that must be configured when tor is launched. The minimal set contains the data directory config, control config, and log config. The network is disabled at launch. The initial options are:
```
'DataDirectory': conf.getpath('tor', 'datadir'),
'PidFile': conf.getpath('tor', 'pid'),
# Because we need things from full server descriptors (namely for now: the
# bandwidth line)
'UseMicrodescriptors': '0',
'ControlSocket': conf.getpath('tor', 'control_socket'),
# Easier than password authentication
'CookieAuthentication': '1',
'Log': [
'NOTICE file {}'.format(os.path.join(conf.getpath('tor', 'log'),
'notice.log')),
],
# useful logging options for clients that don't care about anonymity
'SafeLogging': '0',
'LogTimeGranularity': '1',
'ProtocolWarnings': '1',
'DisableNetwork': '1',
```
* tor.options.runtime.(group_name): Zero or more groups of tor options that can be set at runtime. The network is enabled at runtime. The "50-default" group of options is:
```
# We will find out via the ControlPort and not setting something static
# means a lower chance of conflict
'SocksPort': 'auto',
# To avoid path bias warnings
'UseEntryGuards': '0',
c.set_conf('__LeaveStreamsUnattached', '1')
# Things needed to make circuits fail a little faster. We get the
# circuit_timeout as a string instead of an int on purpose: stem only
# accepts strings.
'LearnCircuitBuildTimeout': '0',
'CircuitBuildTimeout': conf['general']['circuit_timeout'],
'DisableNetwork': '0',
```
* Zero or more tor.runtime.ignore_failure.(group name): tor options that are set in groups at runtime, but ignored if they fail. #28692 and #28694 will add options to this list.
Options in config.ini override options with the same name in sbws.default.ini, with + and / having the same meaning as in a torrc file (+ appends, / removes). Launch options are applied first, then runtime options are applied in group name order. Tor will make later runtime options replace earlier runtime options, and launch options.
2. sbws gets its control socket from the launch_options ControlSocket option(s)
3. sbws gets its data directory, pid, log(s), and circuit build timeout using GETCONF
4. For backwards compatibility:
* if tor.extra_lines is present, it should be appended to tor.options.launch. sbws' option merging code never worked, so appending shouldn't cause any more issues than the existing code.
* if any of these sbws options are present in an old config file, synthesise options.launch from the sbws options. If options.launch is also present in the same config file, it overrides the synthetic options. (sbws' option merging never worked for these options.)
```
'DataDirectory': conf.getpath('tor', 'datadir'),
'PidFile': conf.getpath('tor', 'pid'),
'ControlSocket': conf.getpath('tor', 'control_socket'),
'Log': [
'NOTICE file {}'.format(os.path.join(conf.getpath('tor', 'log'),
'notice.log')),
],
# Things needed to make circuits fail a little faster. We get the
# circuit_timeout as a string instead of an int on purpose: stem only
# accepts strings.
'CircuitBuildTimeout': conf['general']['circuit_timeout'],
```
The final option order is:
* sbws creates options.launch, using the last option from:
* synthetic legacy config options from config.default.ini
* options.launch from config.default.ini
* synthetic legacy config options from config.ini
* options.launch from config.ini
* sbws appends extra_lines to options.launch, using the last extra_lines from:
* config.default.ini
* config.ini
* sbws creates options.runtime groups, using the last one of each group from:
* config.default.ini
* config.ini
sbws launches tor with options.launch, then applies each group of options.runtime in order.
This is a new feature, so it should go in sbws 1.1.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28718Simplify configuration options2020-06-13T16:15:01ZjugaSimplify configuration optionsPrograms should allow in this order: cli options, user configuration files passed by cli, environment variables, system configuration files and program defaults.
There seems there's not a common easy way to achieve this in Python.
sbws a...Programs should allow in this order: cli options, user configuration files passed by cli, environment variables, system configuration files and program defaults.
There seems there's not a common easy way to achieve this in Python.
sbws accepts cli and user configuration files in a complicated way.
The program defaults are provided as a configuration file which might not be that convenient seems confuses where to find the defaults.
Maybe an external library like https://github.com/bw2/ConfigArgParse (supported in Debian) or some other design can help to simplify this.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27362(sub-)packages outside of core (cli) should not need to know about confs and ...2020-06-13T16:13:51Zjuga(sub-)packages outside of core (cli) should not need to know about confs and argsThat would help to have a more modular design and use other (sub)packages and (sub)modules without the need of creating ConfigParser and ArgumentParser objects.
It also would help to simplify tests configurations.
Additionally, a progra...That would help to have a more modular design and use other (sub)packages and (sub)modules without the need of creating ConfigParser and ArgumentParser objects.
It also would help to simplify tests configurations.
Additionally, a program should take into account in this order:
- cli arguments
- environment variables
- user configuration files
- system configuration files
- program defaults
That is currently almost match. but it would be better if they all can be took into account in a simpler way.
This is not for MVP, but creating the ticket cause i'm creating new code taking this into account, and would be nice to change at some point.
Some tickets, as #27358, happen because of this.sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27849Bootstrapping hangs with 'SocksPort 0'2020-06-13T15:32:08ZTracBootstrapping hangs with 'SocksPort 0'Debian uses a minimal torrc on onion.debian.org (our onionbalance node) and tor from Debian backports. We recently upgraded from 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 and discovered that our onionbalance services were no longer working, b...Debian uses a minimal torrc on onion.debian.org (our onionbalance node) and tor from Debian backports. We recently upgraded from 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 and discovered that our onionbalance services were no longer working, but the backend onion services and our normal onion services were still working. The issue was that the tor daemon on onion.debian.org could not achieve bootstrap. tor 0.3.3.9 worked with the existing config, but 0.3.4.8 did not. Changing the SocksPort parameter from 0 to 6666 allowed tor 0.3.4.8 to achieve bootstrap.
The config does not contain any onion services, because those are setup by onionbalance via the tor control port.
So the issue appears to be that tor is not trying to contact the tor network unless it has a socks port or an onion service or other tor network requiring thing configured.
```
SocksPort 0
Log notice syslog
#HiddenServiceSingleHopMode 1
#HiddenServiceNonAnonymousMode 1
ControlPort 9051
```
**Trac**:
**Username**: pabsTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/19665Should *Port_set count sockets?2020-06-13T15:25:32ZteorShould *Port_set count sockets?In parse_ports in 0.2.8-stable and earlier, we didn't count sockets as listeners when setting options->*Port_set.
This makes sense for server ports, is confusing for ControlPort/ControlSocket (because you can set a control socket using ...In parse_ports in 0.2.8-stable and earlier, we didn't count sockets as listeners when setting options->*Port_set.
This makes sense for server ports, is confusing for ControlPort/ControlSocket (because you can set a control socket using the ControlPort option, can't you?), and didn't matter for client ports, because those values were never used.
In #17178 I modified the client port options to count sockets.
But we should definitely review the control port situation some time.
I don't think it's serious, because the current code warns on ControlPorts and ControlSockets.
But it makes it easy to introduce subtle bugs.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22060Remove deprecated options from 0.2.9.2-alpha2020-06-13T15:20:44ZDavid Gouletdgoulet@torproject.orgRemove deprecated options from 0.2.9.2-alphaWe have a set of deprecated options in `src/or/config.c` in the `option_deprecation_notes_` array.
We should `OBSOLETE()` them and remove the associated code. Let's do one option removal per commit.
#21522 and #21031 asks to not get ri...We have a set of deprecated options in `src/or/config.c` in the `option_deprecation_notes_` array.
We should `OBSOLETE()` them and remove the associated code. Let's do one option removal per commit.
#21522 and #21031 asks to not get rid of `ClientDNSRejectInternalAddresses` so let's not for this ticket.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24303Tor fails to start if %include2020-06-13T15:17:29ZTracTor fails to start if %includeIf %include is present in torrc then tor service will fail to start.
The directive I aded to torrc was
%include /etc/torrc.d/
Folder exist and perms are valid, but tor service will not start and tor will not write the reason why to log...If %include is present in torrc then tor service will fail to start.
The directive I aded to torrc was
%include /etc/torrc.d/
Folder exist and perms are valid, but tor service will not start and tor will not write the reason why to log.
**Trac**:
**Username**: littlefeatherTor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19919If ORPort address is publicly routable, use it to guess Address2020-06-13T15:04:48ZteorIf ORPort address is publicly routable, use it to guess AddressSplitting this off from #13953: we'll warn in that ticket, and make the change to the address resolution order in this one.Splitting this off from #13953: we'll warn in that ticket, and make the change to the address resolution order in this one.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20502Setting UseBridges=1 UseEntryGuards=0 means you bypass your bridges2020-06-13T15:02:32ZRoger DingledineSetting UseBridges=1 UseEntryGuards=0 means you bypass your bridgesIf you set UseBridges=1, it's because you wanted to use bridges.
But if you also happen to set UseEntryGuards to 0, then in `choose_good_entry_server()` we do
```
if (state && options->UseEntryGuards &&
(purpose != CIRCUIT_PURPO...If you set UseBridges=1, it's because you wanted to use bridges.
But if you also happen to set UseEntryGuards to 0, then in `choose_good_entry_server()` we do
```
if (state && options->UseEntryGuards &&
(purpose != CIRCUIT_PURPOSE_TESTING || options->BridgeRelay)) {
/* This request is for an entry server to use for a regular circuit,
* and we use entry guard nodes. Just return one of the guard nodes. */
return choose_random_entry(state);
}
```
and we end up skipping that section because UseEntryGuards is 0. The result is that we make normal 3-hop circuits through normal relays.
I think the fix is that in config.c when we're validating the config, we need to not let the user proceed if UseBridges is 1 yet UseEntryGuards is 0.Tor: 0.3.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/12378Tor configuration policies using network CIDR syntax should clamp mask bits a...2020-06-13T14:42:36ZTracTor configuration policies using network CIDR syntax should clamp mask bits appropriatelyTor configuration policies using network CIDR syntax like 224.0.0.0/8 should clamp mask bits appropriately to IANA and network prefix.
An example bad configuration spotted in the wild:
224.0.0.0/3 which represents a binary
11100000.000...Tor configuration policies using network CIDR syntax like 224.0.0.0/8 should clamp mask bits appropriately to IANA and network prefix.
An example bad configuration spotted in the wild:
224.0.0.0/3 which represents a binary
11100000.00000000.00000000.00000000 &
00011111.11111111.11111111.11111111
in
tor_addr_compare_masked
which results in a comparison of only the first three bits of any comparison network under test.
Improve Tor to implement a clamp mask, and warn on a configuration policy that specifies an invalid mask per network prefix.
The netmask clamp would ensure that mask bits number at least 8 bits or more, meaning a /8 or smaller network policy. See https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
The netmask clamp would ensure that mask bits number at least the same number of bits in the network prefix, if the network prefix bits number 8 or more themselves.
**Trac**:
**Username**: anonhttps://gitlab.torproject.org/legacy/trac/-/issues/10052Tor Windows service should reload its configuration on SERVICE_CONTROL_PARAMC...2020-06-13T14:32:47ZTracTor Windows service should reload its configuration on SERVICE_CONTROL_PARAMCHANGE control codeThe Tor Windows service does not currently support reloading its configuration without stopping or restarting. This functionality is provided on other operating systems by sending the `SIGHUP` signal to a Tor process.
Windows services i...The Tor Windows service does not currently support reloading its configuration without stopping or restarting. This functionality is provided on other operating systems by sending the `SIGHUP` signal to a Tor process.
Windows services implement this kind of functionality by [registering](http://msdn.microsoft.com/en-us/library/ms685054%28v=vs.85%29.aspx) to the service manager to [listen](http://msdn.microsoft.com/en-us/library/ms683240%28v=vs.85%29.aspx) for control codes. Therefore the Tor Windows service should implement reloading its configuration on `SERVICE_CONTROL_PARAMCHANGE`.
**NOTE:** Because service control codes are only supported since Windows XP, it does not need to be implemented for Windows 2000.
**NOTE 2:** Functionality that is provided by sending other signals to a Tor process on other operating systems should be implemented as user defined control codes. Initial documentation on implementing every single one of those control codes should be recorded as separate trac tickets while probably being a child of this ticket.
**Trac**:
**Username**: GITNETor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6504Support Windows environment variables in HiddenServiceDir2020-06-13T14:21:35ZTracSupport Windows environment variables in HiddenServiceDirExpansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win3...Expansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win32 will take care of any necessary.
One direct benefit to you devs is that you could then use '%UserProfile%' in the HiddenServiceDir examples for Windows in your documentation, such as the one discussed in !#4798, yielding the appropriate location in every version that Tor supports.
This behavior could/should eventually broadened to all options for which a path can be specified (e.g. DataDirectory, GeoIPFile, PidFile), so if the fix would affect the opening of other paths (I haven't looked through the source code), all the better. If the fix isn't in a core function, I'd be happy to add a new, broader, ticket.
P.S. The version I'm using is actually 0.2.2.37, but I don't see it in the list.
**Trac**:
**Username**: criticoderTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4552Have a "defaults" torrc file and a regular one2020-06-13T14:15:04ZNick MathewsonHave a "defaults" torrc file and a regular one(Since I'm hoping to implement this, let's make a ticket. Hoping it's not a duplicate.)
Tor could support up to two torrc files: one installer-provided "defaults" file, and one user "torrc" file. Additionally, the user could provide a...(Since I'm hoping to implement this, let's make a ticket. Hoping it's not a duplicate.)
Tor could support up to two torrc files: one installer-provided "defaults" file, and one user "torrc" file. Additionally, the user could provide arguments from the command line as they can today. These three places to put options would constitute three "zones" or "configuration sources" or something: "defaults", "torrc", and "cmdline".
The behavior for reading them would be as follows:
* Any option set in cmdline would override torrc and defaults; any option set in torrc would override defaults.
* This goes for linelist options too. For example, if the defaults exit policy was "ExitPolicy reject *:*" and the torrc had "ExitPolicy accept *:80\nExitPolicy reject *:*", then the torrc's ExitPolicy would _replace_ the defaults exit policy. Or if the torrc had "SocksPort auto" and the command line had "SocksPort 9050", then there would be exactly one socksport, as specified by the command line. This would be new behavior.
* The behavior on saveconf would be to compute every option that differed from what its value had been after reading "defaults", and store that option's new value to "torrc".
* HUP and equivalents would reload all options.
Unknown behaviors:
A) should SAVECONF store stuff that was on the command-line?
B) Where do we look for the defaults file?
What would be most useful at this point would be to confirm whether this approach would work for vidalia, TBB, arm, others.Tor: 0.2.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28781nyx crash with traceback while browsing config2018-12-07T17:33:09ZTracnyx crash with traceback while browsing config**Versions**:
nyx: `2.0.4` installed with pip
stem: `1.7.0` installed with pip
tor: `0.3.4.9-1~bionic+1` installed from apt repository at deb.torproject.org
OS: Ubuntu GNU/Linux 18.04 Bionic
**Configuration**:
`/etc/tor/torrc...**Versions**:
nyx: `2.0.4` installed with pip
stem: `1.7.0` installed with pip
tor: `0.3.4.9-1~bionic+1` installed from apt repository at deb.torproject.org
OS: Ubuntu GNU/Linux 18.04 Bionic
**Configuration**:
`/etc/tor/torrc`:
```
SOCKSPort 127.0.0.1:9050
Log notice file /var/log/tor/notices.log
CookieAuthentication 1
DisableDebuggerAttachment 0
ORPort 443
BandwidthRate 4096 KBytes
BandwidthBurst 5120 KBytes
RelayBandwidthRate 4096 KBytes
RelayBandwidthBurst 5120 KBytes
ExitRelay 0
ExitPolicy reject *:*
HardwareAccel 1
```
`~/.nyx/config` - does not exist
**Steps to reproduce**:
* start nyx
* press `m` to show menu
* choose View - Config
* press `a` to show all options
* start scrolling down with key `down arrow` until the end
* nyx crashes
**Traceback**:
```
Traceback (most recent call last):
File "/usr/local/bin/nyx", line 11, in <module>
load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')()
File "/usr/local/lib/python2.7/dist-packages/nyx/__init__.py", line 176, in main
nyx.starter.main()
File "/usr/local/lib/python2.7/dist-packages/stem/util/conf.py", line 289, in wrapped
return func(*args, config = config, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/nyx/starter.py", line 118, in main
nyx.curses.start(nyx.draw_loop, acs_support = config.get('acs_support', True), transparent_background = True, cursor = False)
File "/usr/local/lib/python2.7/dist-packages/nyx/curses.py", line 217, in start
curses.wrapper(_wrapper)
File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
return func(stdscr, *args, **kwds)
File "/usr/local/lib/python2.7/dist-packages/nyx/curses.py", line 215, in _wrapper
function()
File "/usr/local/lib/python2.7/dist-packages/nyx/__init__.py", line 243, in draw_loop
keybinding.handle(key)
File "/usr/local/lib/python2.7/dist-packages/nyx/panel/__init__.py", line 82, in handle
self._action(key)
File "/usr/local/lib/python2.7/dist-packages/nyx/panel/config.py", line 232, in _scroll
self.redraw()
File "/usr/local/lib/python2.7/dist-packages/nyx/panel/__init__.py", line 175, in redraw
self._last_draw_size = nyx.curses.draw(self._draw, top = self._top, height = self.get_height(), draw_if_resized = draw_dimension)
File "/usr/local/lib/python2.7/dist-packages/nyx/curses.py", line 746, in draw
func(_Subwindow(subwindow_width, subwindow_height, curses_subwindow))
File "/usr/local/lib/python2.7/dist-packages/nyx/panel/config.py", line 315, in _draw
_draw_line(subwindow, scroll_offset, DETAILS_HEIGHT + i, entry, entry == selected, value_width, description_width)
File "/usr/local/lib/python2.7/dist-packages/nyx/panel/config.py", line 335, in _draw_line
attr = [CONFIG['attr.config.category_color'].get(entry.category, WHITE)]
File "/usr/local/lib/python2.7/dist-packages/nyx/panel/config.py", line 136, in category
return getattr(manual(self.name), 'category')
AttributeError: 'NoneType' object has no attribute 'category'
```
**Trac**:
**Username**: iquziev7Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28332Nyx configurashion editor reproducibly crashes if custom ordering is set2018-11-07T17:54:45ZTracNyx configurashion editor reproducibly crashes if custom ordering is setNyx 2.0.4 at Linux. How to reproduce:
1. Go to configuration editor.
2. Press `s` and select the following order: `Is Set`, `Name`, `Description`.
3. "Toggle filtering" by pressing `a`.
4. Nyx immediately crashes with the followi...Nyx 2.0.4 at Linux. How to reproduce:
1. Go to configuration editor.
2. Press `s` and select the following order: `Is Set`, `Name`, `Description`.
3. "Toggle filtering" by pressing `a`.
4. Nyx immediately crashes with the following log:
```
Traceback (most recent call last):
File "/usr/local/bin/nyx", line 9, in <module>
load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')()
File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 176, in main
nyx.starter.main()
File "/usr/local/lib/python3.4/dist-packages/stem/util/conf.py", line 289, in wrapped
return func(*args, config = config, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/nyx/starter.py", line 118, in main
nyx.curses.start(nyx.draw_loop, acs_support = config.get('acs_support', True), transparent_background = True, cursor = False)
File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 217, in start
curses.wrapper(_wrapper)
File "/usr/lib/python3.4/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 215, in _wrapper
function()
File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 243, in draw_loop
keybinding.handle(key)
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/__init__.py", line 84, in handle
self._action()
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 258, in _toggle_show_all
self._sort_content()
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 325, in _sort_content
self._all_content = sorted(self._all_content, key = lambda entry: [entry.sort_value(field) for field in self._sort_order])
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 325, in <lambda>
self._all_content = sorted(self._all_content, key = lambda entry: [entry.sort_value(field) for field in self._sort_order])
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 325, in <listcomp>
self._all_content = sorted(self._all_content, key = lambda entry: [entry.sort_value(field) for field in self._sort_order])
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 128, in sort_value
return self.description
File "/usr/local/lib/python3.4/dist-packages/nyx/panel/config.py", line 148, in description
return getattr(manual(self.name), 'description')
AttributeError: 'NoneType' object has no attribute 'description'
```
I guess it would also crash with many other types of ordering.
**Trac**:
**Username**: wagonDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18094Comment in start-tor-messenger advises to modify about:config preferences tha...2016-01-19T02:31:45ZcypherpunksComment in start-tor-messenger advises to modify about:config preferences that do not exist in instantbirdThere is a comment in the start-tor-messenger bash script telling what to do for
“Using a system-installed Tor process with Tor Messenger”. As the whole file is more or less a copy of start-tor-browser, the list of about:config values co...There is a comment in the start-tor-messenger bash script telling what to do for
“Using a system-installed Tor process with Tor Messenger”. As the whole file is more or less a copy of start-tor-browser, the list of about:config values contains torbutton preferences which exist in firefox but not in instantbird.
Only 6 out of 16 values are listed in instantbird’s about:config. Should the user ignore the rest or create new entries?
The whole issue only affects “sophisticated users”, like in wiki:org/meetings/2015SummerDevMeeting/TorProcessSharehttps://gitlab.torproject.org/legacy/trac/-/issues/9779Stem configs resetting to default2013-09-20T06:17:18ZcypherpunksStem configs resetting to defaultAfter some time, Tor receives a HUP signal (during a long period without any user interaction) and any configuration changes made in Stem are replaced with whatever is in the torrc file. Specifically, this change occurs at the precise mo...After some time, Tor receives a HUP signal (during a long period without any user interaction) and any configuration changes made in Stem are replaced with whatever is in the torrc file. Specifically, this change occurs at the precise moment that the tor log is rotated. Stem maintains authentication and can still communicate with tor...
My concern is with the purpose of Tor's HUP signal and the loss of any configuration made in Stem...
Example log tail:
.....
Sep 1 01:25:57.000 [notice] new bridge descriptor 'XXXXXX' (fresh): $0000000000000000000000000000000000000000~XXXXXX at 1.23.4.5
Sep 1 01:39:04.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Sep 1 01:39:04.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 1 01:39:04.000 [notice] Read configuration file "/etc/tor/torrc".Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/2342polipo sample config dnsUseGethostbyname=yes obsolete?2011-08-14T10:47:23ZTracpolipo sample config dnsUseGethostbyname=yes obsolete?the info file for polipo and the polipo -v output say the value of dnsUseGethostbyname should be one of (false, reluctantly, happily, true) but the sameple config supplied for Tor says "yes".
yes converts silently to true when polipo rea...the info file for polipo and the polipo -v output say the value of dnsUseGethostbyname should be one of (false, reluctantly, happily, true) but the sameple config supplied for Tor says "yes".
yes converts silently to true when polipo reads it.
https://gitweb.torproject.org/torbrowser.git/blob_plain/HEAD:/build-scripts/config/polipo.conf
**Trac**:
**Username**: kebErinn ClarkErinn Clark