The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-07-20T14:52:54Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30668Mobile: Favicon is not used when making a shortcut on Home screen2022-07-20T14:52:54ZTracMobile: Favicon is not used when making a shortcut on Home screen- Tor Browser and Tor Broswer (Alpha):
- Press the three dotted button in the top right,
- Select "Page >",
- Select "Add to home screen".
- A button on the home screen appears, but is missing the favicon.
Would the proper behaviour be ...- Tor Browser and Tor Broswer (Alpha):
- Press the three dotted button in the top right,
- Select "Page >",
- Select "Add to home screen".
- A button on the home screen appears, but is missing the favicon.
Would the proper behaviour be to download the largest favicon possible and then resize it down on the client-side to avoid resquesting an icon dize that might identify the client os?
NOTE: Old Orfox appears to function correctly, in that the icon is used and it appears brilliant and sharp (ie. high-resolution).
**Trac**:
**Username**: torlovehttps://gitlab.torproject.org/tpo/core/tor/-/issues/17928Warnings in syslog for wrong permissions on hidden service dir are misleading2021-06-18T18:13:20ZTracWarnings in syslog for wrong permissions on hidden service dir are misleadingI had the wrong permissions on my hidden service directory which caused the tor service to fail starting. Logging doesn't work when the permissions are not set properly, so I could only get info from the syslog. I see the following error...I had the wrong permissions on my hidden service directory which caused the tor service to fail starting. Logging doesn't work when the permissions are not set properly, so I could only get info from the syslog. I see the following errors:
Dec 24 00:46:28 ArchLaptop tor[7297]: Dec 24 00:46:28.460 [notice] Read configuration file "/etc/tor/torrc".
Dec 24 00:46:28 ArchLaptop tor[7297]: Dec 24 00:46:28.465 [warn] Permissions on directory /home/merito/hidden_service/ are too permissive.
Dec 24 00:46:28 ArchLaptop tor[7297]: Dec 24 00:46:28.465 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Dec 24 00:46:28 ArchLaptop tor[7297]: Dec 24 00:46:28.465 [err] Reading config failed--see warnings above.
Dec 24 00:46:28 ArchLaptop systemd[1]: tor.service: Main process exited, code=exited, status=1/FAILURE
Maybe the log entry on the permissions for the directory should be of level err? A warning seems to suggest that this is acceptable, so I tried to find an issue in the parsing of the config, thinking there might be some kind of complicated problem with configuring rendezvous options.
**Trac**:
**Username**: throwaway232344https://gitlab.torproject.org/tpo/core/tor/-/issues/17948HiddenServicePort should connect to localhost by default2020-06-27T13:59:52ZteorHiddenServicePort should connect to localhost by defaultHiddenServicePort currently connects to 127.0.0.1 by default, but this will fail in configs where localhost is somewhere else in 127.0.0.0/8 or is [::1]. (Such as BSD jails.)
Instead, we can:
* resolve "localhost", and check that it's i...HiddenServicePort currently connects to 127.0.0.1 by default, but this will fail in configs where localhost is somewhere else in 127.0.0.0/8 or is [::1]. (Such as BSD jails.)
Instead, we can:
* resolve "localhost", and check that it's in 127.0.0.0/8 or [::1], and use the IPv4 address first for compatibility with existing configurations
* default to 127.0.0.1 if that exists
* default to [::1] if 127.0.0.1 does not exist
This is not a security issue, as it results in a failed hidden service connection on unusual configs. It's a minor usability issue.
(Split from legacy/trac#17901 / legacy/trac#11360.)Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17949Make loopback address search more accurate2021-08-23T15:17:35ZteorMake loopback address search more accuratelegacy/trac#17901 and legacy/trac#11360 search local interfaces for loopback addresses.
We could make this more efficient by using the flags returned with each address:
* getifaddrs returns struct ifaddrs with ifa_flags which has IFF_LO...legacy/trac#17901 and legacy/trac#11360 search local interfaces for loopback addresses.
We could make this more efficient by using the flags returned with each address:
* getifaddrs returns struct ifaddrs with ifa_flags which has IFF_LOOPBACK
* ioctl(.,SIOCGIFCONF,.) returns struct ifreq with ifr_flags which has IFF_LOOPBACK
* GetAdaptersAddresses (Win32) returns IP_ADAPTER_ADDRESSES with IfType which has IF_TYPE_SOFTWARE_LOOPBACK
* Also pass GAA_FLAG_SKIP_FRIENDLY_NAME as we never use it
* tor_getsockname/get_interface_address6_via_udp_socket_hack connects to a public address. When passed the localhost flag, it could connect to a loopback address, but this seems rather tautologous, and it's hard to know which loopback address to pick in 127/8. Alternately, we could lookup localhost using the resolver, and check the returned address is 127/8 or ::1 (otherwise, broken DNS configs could lead to security issues).
A design for this could be:
* pass a flag to get_interface_address* indicating whether we want loopback addresses
* pass that flag down to get_interface_addresses_raw
* pass that flag to the API-specific functions
* when converting the address to a smartlist, include/exclude addresses matching the specified types
* always exclude tor_addr_is_null()
* always exclude addresses matching tor_addr_is_multicast
* for extra points, create a flags argument for:
* loopback
* this will require disabling the checks for tor_addr_is_loopback() in get_interface_address6_list() and get_interface_address6_via_udp_socket_hack(), see legacy/trac#17901
* listen any (0.0.0.0 and [::], needs `tor_addr_is_listen_any()`)
* link-local (needs `tor_addr_is_link_local()`)
* other internal/private
* public
* with #defines:
* _INTERNAL: everything except public
* _INTERNAL_FOR_LISTENING: everything except public and listen any
After doing this, refactor the changes in legacy/trac#17901 and legacy/trac#11360, and all existing code, to use the new flags argument.
This will also resolve issues where systems have addresses other than 127.0.0.0/8 or ::1 as the loopback address (like some BSD jails and OpenVZ). But we're not too worried about this, they're non-standards-compliant, so the operator can configure the exact address correctly, as long as we fail with an informative message.
I need this to do legacy/trac#17835, I'll likely do it then if no-one gets to it first.https://gitlab.torproject.org/tpo/core/tor/-/issues/17950Make address family search more accurate2020-06-27T13:59:52ZteorMake address family search more accurateTor searches local interfaces for IPv4/IPv6 addresses, but it often retrieves all addresses, then filters for IPv4/IPv6.
We could make this more efficient for some of the interface address functions:
* getifaddrs doesn't take an address...Tor searches local interfaces for IPv4/IPv6 addresses, but it often retrieves all addresses, then filters for IPv4/IPv6.
We could make this more efficient for some of the interface address functions:
* getifaddrs doesn't take an address family, but we can check the address families of the returned addresses
* ioctl(.,SIOCGIFCONF,.) only supports AF_INET6 on AIX, or on HP-UX and Solaris with SIOCGLIFCONF, and otherwise only returns IPv4 addresses
* GetAdaptersAddresses (Win32) takes an address family as its first argument
* tor_getsockname/get_interface_address6_via_udp_socket_hack takes an address family as its first argument
A design for this could be:
* pass the address family to get_interface_addresses_raw
* pass the address family to the API-specific functions that take an address family, or when converting the address to a smartlist, include/exclude addresses matching the specified address familiesTor: 0.2.8.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/17951Make address family search via UDP socket hack more accurate2020-06-27T13:59:51ZteorMake address family search via UDP socket hack more accurateThe following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it s...The following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it should be call get_interface_address6_via_udp_socket_hack with AF_INET, and then AF_INET6, and then both addresses should be returnedTor: 0.2.8.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/17952Make address family search via ioctl more accurate on obscure platforms2020-07-17T11:11:50ZteorMake address family search via ioctl more accurate on obscure platformsThe following address family search functions only return an IPv6 address on some platforms:
* ioctl(.,SIOCGIFCONF,.) only returns IPv4 addresses, except:
* on HP-UX and Solaris, which support AF_INET6 with SIOCGLIFCONF
* see http:...The following address family search functions only return an IPv6 address on some platforms:
* ioctl(.,SIOCGIFCONF,.) only returns IPv4 addresses, except:
* on HP-UX and Solaris, which support AF_INET6 with SIOCGLIFCONF
* see http://www.manpages.info/sunos/if_tcp.7.html
* on AIX, using the sa_len field in struct sockaddr to distinguish between IPv4 and IPv6 addresses
* on MVS and z/OS, which support AF_INET6 with SIOCGIFCONF6 / __net_ifconf6header_s
* see http://www-01.ibm.com/support/docview.wss?uid=isg1PK22885 for details
* on these platforms, we should try AF_INET, then AF_INET6, and then both addresses should be returnedTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17953Fallback to resolving localhost when interface searches fail2021-08-23T15:17:35ZteorFallback to resolving localhost when interface searches failAs described in legacy/trac#17949 & legacy/trac#17901, tor needs to know the loopback address.
We can fall back to resolving localhost on systems that don't return any loopback addresses when their interfaces are enumerated.
We need to...As described in legacy/trac#17949 & legacy/trac#17901, tor needs to know the loopback address.
We can fall back to resolving localhost on systems that don't return any loopback addresses when their interfaces are enumerated.
We need to check that the returned values are standard 127/8 or [::1]. This allows tor to work on non-127.0.0.1 loopback IPv4 systems, and IPv6-only systems, without the security issues inherent in trusting a possibly non-local resolver.https://gitlab.torproject.org/tpo/core/tor/-/issues/17957Detect stolen onion service key2021-06-18T18:13:21ZTracDetect stolen onion service keyWould it be possible to add a detection mechanism for stolen onion service keys?
How it could work (I know very little about Tor internals):
A HSDir could tell the tor client that someone else with the same key announced a hidden servic...Would it be possible to add a detection mechanism for stolen onion service keys?
How it could work (I know very little about Tor internals):
A HSDir could tell the tor client that someone else with the same key announced a hidden service just minutes ago.
To determine that it was someone else, a random number could be sent with each announcement of an onion service, and that number randomly changes every time tor is restarted. If tor isn't restarted but the HSDir tells the announcing tor client that a different number was used to announce the onion service before, one could reasonably suspect that the key has been compromised. The user could then try to rule out a false positive, and get a new key.
It might be problematic that the HSDir can lie to .onions it doesn't like, but as long as no automatic action but the notification is done, this shouldn't cause much harm.
**Trac**:
**Username**: ess2https://gitlab.torproject.org/tpo/core/tor/-/issues/17985Refactor common parts of entry_is_live and entry_guard_set_status2021-09-16T14:34:35ZteorRefactor common parts of entry_is_live and entry_guard_set_statusentry_is_live and entry_guard_set_status look very similar, and return almost identical messages.
We could refactor out the common code (even if we have to use macros).
This would also avoid them getting out of sync.entry_is_live and entry_guard_set_status look very similar, and return almost identical messages.
We could refactor out the common code (even if we have to use macros).
This would also avoid them getting out of sync.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17991Handle non-127.0.0.1 IPv4 loopback addresses2021-06-18T18:13:21ZteorHandle non-127.0.0.1 IPv4 loopback addressesIn legacy/trac#17901, we identified some FreeBSD jails and OpenVZ VMs as having no 127.0.0.1. legacy/trac#17901 deals with those systems that have no loopback at all.
But some FreeBSD jails block access to 127.0.0.1, and have loopback o...In legacy/trac#17901, we identified some FreeBSD jails and OpenVZ VMs as having no 127.0.0.1. legacy/trac#17901 deals with those systems that have no loopback at all.
But some FreeBSD jails block access to 127.0.0.1, and have loopback on a valid yet unexpected address, like 127.0.0.2.
Tor could bind to any address in 127/8 (or ::1, see legacy/trac#11360) and be accessible locally.
One possible implementation is:
* find all addresses on all loopback interfaces (legacy/trac#17949)
* as a fallback, resolve localhost (legacy/trac#17953), and check that it's 127.0.0.0/8 or ::1
* choose the address that's closest to 127.0.0.1
* use that address as the bind address
* If there is no 127.0.0.0/8 (or ::1) on the server, reject the *Port with a warning that tells the user to use AF_UNIX (if their system supports it), or supply an explicit IP address if they really want their *Port listening on a non-local address.
Operators can always specify an explicit bind address in the *Port line, so this isn't a serious usability issue.https://gitlab.torproject.org/tpo/core/tor/-/issues/18051directory_send_command should decorate IPv6 addresses to avoid port ambiguity2020-06-27T13:59:47Zteordirectory_send_command should decorate IPv6 addresses to avoid port ambiguityIn legacy/trac#17573, we discovered that directory_send_command doesn't quote IPv6 addresses in directory URLs. This could cause issues with the ":port" suffix for directories that aren't on the default port 80.In legacy/trac#17573, we discovered that directory_send_command doesn't quote IPv6 addresses in directory URLs. This could cause issues with the ":port" suffix for directories that aren't on the default port 80.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18095Unit test integer precision warnings on 32 bit clang targets2020-06-27T13:59:46ZteorUnit test integer precision warnings on 32 bit clang targetsI think legacy/trac#17076 introduced some integer precision warnings on 32 bit clang targets.
https://jenkins.torproject.org/job/tor-ci-linux-master-clang/997/ARCHITECTURE=i386,SUITE=sid/console
```
01:08:40 src/test/test_options.c:231...I think legacy/trac#17076 introduced some integer precision warnings on 32 bit clang targets.
https://jenkins.torproject.org/job/tor-ci-linux-master-clang/997/ARCHITECTURE=i386,SUITE=sid/console
```
01:08:40 src/test/test_options.c:2311:25: error: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'long' [-Werror,-Wshorten-64-to-32]
01:08:40 tt_int_op(tdata->opt->RelayBandwidthBurst, OP_EQ, 1000);
01:08:40 ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
01:08:40 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
01:08:40 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
01:08:40 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
01:08:40 type val1_ = (a); \
01:08:40 ^
01:08:40 src/test/test_options.c:2319:25: error: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'long' [-Werror,-Wshorten-64-to-32]
01:08:40 tt_int_op(tdata->opt->RelayBandwidthRate, OP_EQ, 1001);
01:08:40 ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
01:08:40 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
01:08:40 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
01:08:40 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
01:08:40 type val1_ = (a); \
01:08:40 ^
01:08:40 src/test/test_options.c:2350:25: error: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'long' [-Werror,-Wshorten-64-to-32]
01:08:40 tt_int_op(tdata->opt->BandwidthRate, OP_EQ, 1001);
01:08:40 ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
01:08:40 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
01:08:40 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
01:08:40 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
01:08:40 type val1_ = (a); \
01:08:40 ^
01:08:40 src/test/test_options.c:2362:25: error: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'long' [-Werror,-Wshorten-64-to-32]
01:08:40 tt_int_op(tdata->opt->BandwidthBurst, OP_EQ, 1001);
01:08:40 ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
01:08:40 ./src/ext/tinytest_macros.h:158:22: note: expanded from macro 'tt_int_op'
01:08:40 tt_assert_test_type(a,b,#a" "#op" "#b,long,(val1_ op val2_), \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:144:26: note: expanded from macro 'tt_assert_test_type'
01:08:40 tt_assert_test_fmt_type(a,b,str_test,type,test,type,fmt, \
01:08:40 ^
01:08:40 ./src/ext/tinytest_macros.h:116:16: note: expanded from macro 'tt_assert_test_fmt_type'
01:08:40 type val1_ = (a); \
01:08:40 ^
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18096test_options_validate__control fails on Windows because there are no ControlS...2020-06-27T13:59:46Zteortest_options_validate__control fails on Windows because there are no ControlSocketsThis is another issue with legacy/trac#17076.
Windows does not have unix sockets, so the error message and return value should be different.
https://jenkins.torproject.org/job/tor-ci-mingwcross-test/501/ARCHITECTURE=amd64,SUITE=jessie/...This is another issue with legacy/trac#17076.
Windows does not have unix sockets, so the error message and return value should be different.
https://jenkins.torproject.org/job/tor-ci-mingwcross-test/501/ARCHITECTURE=amd64,SUITE=jessie/console
```
02:58:18 options/validate__control: [forking] fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
02:58:18 fixme:toolhelp:Heap32ListFirst : stub
02:58:18 fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
02:58:18 fixme:toolhelp:Heap32ListFirst : stub
02:58:18 fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
02:58:18 fixme:toolhelp:Heap32ListFirst : stub
02:58:18
02:58:18 FAIL src/test/test_options.c:3230: assert(ret OP_EQ 0): -1 vs 0
02:58:18 [validate__control FAILED]
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18105Replace getsockname with tor_getsockname2020-06-27T13:59:45ZteorReplace getsockname with tor_getsocknameThere's a lot of duplicate code in Tor that calls getsockname, then stuffs the address in a tor_addr_t.
Let's cleanup that code by replacing it with tor_getsockname where that makes sense.
For example, in legacy/trac#18100, we left beh...There's a lot of duplicate code in Tor that calls getsockname, then stuffs the address in a tor_addr_t.
Let's cleanup that code by replacing it with tor_getsockname where that makes sense.
For example, in legacy/trac#18100, we left behind duplicate code in destination_from_socket, because it was a backport, and the changes required to deduplicate it were complex.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18123Avoid a local port-stealing attack on Windows2021-08-23T15:17:35ZteorAvoid a local port-stealing attack on WindowsOn Windows, Tor is vulnerable to a port-stealing attack described on this StackOverflow post under the "Windows" heading:
https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-the...On Windows, Tor is vulnerable to a port-stealing attack described on this StackOverflow post under the "Windows" heading:
https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
In short, another app can set SO_REUSEADDR, then bind to a port that Tor is already bound to, stealing all future connections to Tor.
Therefore, I think we should set SO_EXCLUSIVEADDRUSE on all listener sockets on Windows, which prevents this attack.
We could do this near make_socket_reusable in connection_listener_new. make_socket_reusable already has a comment about this issue.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18124We never use interface names on Windows, avoid retrieving them2021-09-16T14:34:11ZteorWe never use interface names on Windows, avoid retrieving themWe're scanning local interfaces more often in the tor codebase, so it would be a good idea to optimise get_interface_addresses_win32().
We never use the interface names, so let's avoid retrieving them by passing GAA_FLAG_SKIP_FRIENDLY_N...We're scanning local interfaces more often in the tor codebase, so it would be a good idea to optimise get_interface_addresses_win32().
We never use the interface names, so let's avoid retrieving them by passing GAA_FLAG_SKIP_FRIENDLY_NAME in FLAGS.
Reference documentation:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365915%28v=vs.85%29.aspxhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18133In OfflineMasterKey mode master keys are not supposed to be available, do not...2020-06-27T13:59:44ZcypherpunksIn OfflineMasterKey mode master keys are not supposed to be available, do not suggest they should beWhen Ed25519 signing keys expire tor logs the following messages:
```
(1) [notice] It looks like I should try to generate and sign a new medium-term signing key, because the one I have is going to expire soon. But OfflineMasterKey is se...When Ed25519 signing keys expire tor logs the following messages:
```
(1) [notice] It looks like I should try to generate and sign a new medium-term signing key, because the one I have is going to expire soon. But OfflineMasterKey is set, so I won't try to load a permanent master identity key is set. You will need to use 'tor --keygen' make a new signing key and certificate.
(2) [notice] It looks like I need to generate and sign a new medium-term signing key, because the one I have is expired. To do that, I need to load the permanent master identity key.
(3)[warn] We needed to load a secret key from .../tor/keys/ed25519_master_id_secret_key, but couldn't find it. Did you forget to copy it over when you copied the rest of the signing key material?
(4)[warn] Can't load master identity key; OfflineMasterKey is set.
(5)[err] Unable to update Ed25519 keys! Exiting.
```
(3) suggests that one forgot to copy the master key, but in such a setup OfflineMasterKey 1, the masterkey is not supposed to be there, so the warn message could be replaced with "please provide tor with new valid Ed25519 signing keys/cert" (or similar) instead of suggesting to the user that it should copy the master key to the relay - which is not recommended, no?Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18134tor issues missleading permission warning when torrc overrides User config di...2020-07-27T18:38:20Zcypherpunkstor issues missleading permission warning when torrc overrides User config directive of default torrc
Tor issues the follwoing warn loglevel entry when it starts even though permissions are fine (drwx------):
```
[warn] Fixing permissions on directory <datadir>
```
this occurs only if the torrc overrides the default-torrc's User parame...
Tor issues the follwoing warn loglevel entry when it starts even though permissions are fine (drwx------):
```
[warn] Fixing permissions on directory <datadir>
```
this occurs only if the torrc overrides the default-torrc's User parameter
besides this warn loglevel tor runs fine nonetheless.
warning is issued with:
```
tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f torrc
```
no warning with:
```
tor --runasdaemon 0 -f torrc
```
both (defaults-torrc and torrc) specify a User config parameter.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18248tor logging twice when --+Log argument and config are used2020-06-27T13:59:39ZTractor logging twice when --+Log argument and config are usedWhen specifying the Log option to the same place twice various messages will be logged twice.
Specifying
```
# On the command line:
--+Log notice file /var/log/tor
# In torrc:
Log notice file /var/log/tor
```
will result in messages...When specifying the Log option to the same place twice various messages will be logged twice.
Specifying
```
# On the command line:
--+Log notice file /var/log/tor
# In torrc:
Log notice file /var/log/tor
```
will result in messages like those:
```
Feb 05 11:05:41.000 [notice] Bootstrapped 0%: Starting
Feb 05 11:05:41.000 [notice] Bootstrapped 0%: Starting
Feb 05 11:05:54.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Feb 05 11:05:54.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Feb 05 11:05:54.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Feb 05 11:05:54.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Feb 05 11:05:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
Feb 05 11:05:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
```
In a way one could say that's expected, but I think equivalent options should maybe be deduplicated.
This occurs on: Tor v0.2.8.1-alpha (git-9093e3769746742f) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2f and Zlib 1.2.8.
**Trac**:
**Username**: reezerTor: 0.2.9.x-final