The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-24T12:48:34Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3241Seeing lots of "crypto error while reading public key from string" on DA2020-07-24T12:48:34ZLinus Nordberglinus@torproject.orgSeeing lots of "crypto error while reading public key from string" on DAI have about 200 of these (in 20 hours) on my DA:
May 18 21:06:05.183 [warn] crypto error while reading public key from string: too long (in asn1 encoding routines:ASN1_get_object)
May 18 21:06:05.183 [warn] crypto error while reading p...I have about 200 of these (in 20 hours) on my DA:
May 18 21:06:05.183 [warn] crypto error while reading public key from string: too long (in asn1 encoding routines:ASN1_get_object)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: bad object header (in asn1 encoding routines:ASN1_CHECK_TLEN)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: nested asn1 error (in asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: nested asn1 error (in asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I)
May 18 21:06:05.183 [warn] crypto error while reading public key from string: ASN1 lib (in PEM routines:PEM_ASN1_read_bio)
May 18 21:06:05.183 [warn] parse error: Couldn't parse public key.
May 18 21:06:05.183 [warn] Error tokenizing router descriptor.
May 18 21:06:05.183 [warn] Error reading extra-info: signature does not match.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2967bad pidfile handling on ENOSPC2020-07-24T12:40:54Zintrigeribad pidfile handling on ENOSPCThe Tor daemon was reported two years ago, as [Debian bug #514616](http://bugs.debian.org/514616), to behave quite badly when it does not manage to write its pidfile because of a full filesystem.
Some discussion between the bug reporter...The Tor daemon was reported two years ago, as [Debian bug #514616](http://bugs.debian.org/514616), to behave quite badly when it does not manage to write its pidfile because of a full filesystem.
Some discussion between the bug reporter and Peter happened there and is probably a good starting point to fix this bug.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/584Clients process descriptor fetches as they arrive?2020-07-24T12:17:47ZRoger DingledineClients process descriptor fetches as they arrive?While we're fetching descriptors in a directory request, wouldn't it
be nice if we could parse and make use of the ones that are sitting
on the buffer?
This would let us bootstrap quicker, and be especially relevant once
we use the fall...While we're fetching descriptors in a directory request, wouldn't it
be nice if we could parse and make use of the ones that are sitting
on the buffer?
This would let us bootstrap quicker, and be especially relevant once
we use the fallback consensus and start using slow dir caches to
bootstrap.
It will also avoid the 250K blobs sitting in ram.
This might be destabilizing enough that it should wait til 0.2.1.x. Not sure.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/21466Get chutney's scripts working with standard shell script checking options2020-07-23T20:31:12ZteorGet chutney's scripts working with standard shell script checking optionsWe'll make fewer mistakes if we:
```
set -e
set -u
```
at the top of every script.We'll make fewer mistakes if we:
```
set -e
set -u
```
at the top of every script.https://gitlab.torproject.org/tpo/core/tor/-/issues/7486Divergent behavior for over-long length on begin cells2020-07-23T18:11:10ZNick MathewsonDivergent behavior for over-long length on begin cellsWhen we get some other kind of error when parsing a begin cell, we send back an end cell. But if the error is an over-long length, we do nothing and just mark the connection. That's probably not right; if it is, it should be commented....When we get some other kind of error when parsing a begin cell, we send back an end cell. But if the error is an over-long length, we do nothing and just mark the connection. That's probably not right; if it is, it should be commented.
I needed to add extra code to keep the current behavior in the ipv6_exits branch; it would be neat to rip that out.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7216networkstatus_check_consensus_signature() shouldn't warn because of missing c...2020-07-23T18:00:06ZNick Mathewsonnetworkstatus_check_consensus_signature() shouldn't warn because of missing certsIf you're first bootstrapping and enough of your certificate downloads fail at least twice, you might see something like:
> A consensus needs 5 good signatures from recognized authorities for us to accept it. This one has 0 (). It has ...If you're first bootstrapping and enough of your certificate downloads fail at least twice, you might see something like:
> A consensus needs 5 good signatures from recognized authorities for us to accept it. This one has 0 (). It has 1 signatures from authorities we don't recognize. We were unable to check 7 of the signatures, because we were missing the keys.
That's not too helpful, especially to a new user.
From IRC, with irrelevant stuff omitted:
```
19:45 < armadev> if it warns about a consensus that it might not warn about
once it has certs, and once it gets certs it checks again, it
seems that the warn is a bug
19:47 <@nickm> armadev: Hm. You're saying that if we can't verify the
consensus, and missing certs might enable us to do so, the
warnings should instead be "Hey I've tried to download
certificates and it didn't work yet, trying more?"
19:47 <@nickm> or no warning
19:48 < armadev> i was saying no warning
19:49 < armadev> assuming we later warn if we fail to fetch the certs we
wanted, and we warn if we later don't like the consensus we
can now check
19:50 <@nickm> sounds okay. May I copy+paste some of the stuff you've said to
make a new ticket, or do you want to open one?
19:50 < armadev> go for it
19:51 < armadev> this is especially relevant because the case where you don't
have the certs yet means you're probably a new user starting
tor for the first time, nervously looking at the message log
```Tor: unspecifiedhttps://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/27992config DataDirectoryGroupReadable 1 is overridden if you set KeyDir == DataDir2020-07-14T22:24:19ZTracconfig DataDirectoryGroupReadable 1 is overridden if you set KeyDir == DataDirim trying to run zeronet over tor.
i need group access to the DataDirectory for cookie auth
so /var/lib/tor should have file mode 0750
spoiler: see below for workarounds + bugfix
when i run
# d=$(date +"%F %T"); \
chmod 0750 /var/lib/...im trying to run zeronet over tor.
i need group access to the DataDirectory for cookie auth
so /var/lib/tor should have file mode 0750
spoiler: see below for workarounds + bugfix
when i run
# d=$(date +"%F %T"); \
chmod 0750 /var/lib/tor; \
systemctl restart tor; sleep 2; \
journalctl -u tor --since="$d" \
| grep -i permissions; \
stat -c%a /var/lib/tor
i always get
Fixing permissions on directory /var/lib/tor
700
and datadir ends up with filemode 0700
so it is not accessible for other users in the tor group
... though in my torrc i set
DataDirectoryGroupReadable 1
# usermod -a -G tor zeronet
# sudo -u zeronet cat /var/lib/tor/control_auth_cookie
cat: /var/lib/tor/control_auth_cookie: Permission denied
the authcookie filemode is set correctly to 0640
with the config
CookieAuthFileGroupReadable 1
--
workaround 1
run
# chmod 0750 /var/lib/tor
after starting tor
workaround 2
add
CacheDirectoryGroupReadable 1
to your torrc file
workaround 3
add
CacheDirectory = /var/lib/tor/cache
to your torrc file
if your cache dir should not be group readable
why workaround 2 and 3?
cos the error only happens
if CacheDirectory == DataDirectory
which is the default config
--
bugfix
in
src/app/config/config.c
add
if (strcmp(options->KeyDirectory, options->DataDirectory) != 0) {
and
if (strcmp(options->CacheDirectory, options->DataDirectory) != 0) {
around line 1570 and 1590
before calling
check_and_create_data_directory
... and close the parentheses
--
# cat /etc/tor/torrc
Log notice syslog
DataDirectory /var/lib/tor
DataDirectoryGroupReadable 1
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/lib/tor/control_auth_cookie
**Trac**:
**Username**: needle8420Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31825Use the full name of optional modules, rather than an abbreviation2020-07-14T22:24:16ZteorUse the full name of optional modules, rather than an abbreviationSome Tor builders are confused by the optional module descriptions in Tor's configure script.
We should spell out abbreviations:
* dirauth = Directory AuthoritySome Tor builders are confused by the optional module descriptions in Tor's configure script.
We should spell out abbreviations:
* dirauth = Directory AuthorityTor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33472Document that bwauths should checkout stable versions when installing sbws fr...2020-07-14T16:44:07ZjugaDocument that bwauths should checkout stable versions when installing sbws from giti think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.i think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33609Check that onion services have successfully posted descriptors before verifying2020-07-07T15:12:56ZteorCheck that onion services have successfully posted descriptors before verifyingBefore verifying, chutney checks that:
* each relay descriptor is cached at each node
* each relay is in a consensus, cached at each node
* each relay is in a microdesc consensus, cached at each node
* each bridge descriptor is cached at...Before verifying, chutney checks that:
* each relay descriptor is cached at each node
* each relay is in a consensus, cached at each node
* each relay is in a microdesc consensus, cached at each node
* each bridge descriptor is cached at each bridge client
We have other tickets for checking:
* microdescriptors
* cached bridge descriptors at the bridge authority
* the bridge networkstatus
That just leaves onion services.
Onion services are tricky, because they post to some HSDirs in the network, but not all. And those HSDirs don't cache the onion service descriptors in a file.
So here is one possible design for this feature:
* check each onion service log for a successful descriptor post to at least one HSDir
* check v2 and v3 onion services
* call it an extra 200% "bootstrap" stage (because it's a sender log check, not a receiver cached file check)
* require 200% bootstrap for onion servicesNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/1/scan/ URL requires a trailing slash2020-07-02T00:54:18ZDavid Fifielddcf@torproject.org/scan/ URL requires a trailing slashDuring the [2020-06-30 Internet Measurement Village talk](https://www.youtube.com/watch?v=g6xEfNHkFKY), participants in chat tried to access a URL that doesn't work:
* https://bridges.torproject.org/scan ([archive](https://web.archive.or...During the [2020-06-30 Internet Measurement Village talk](https://www.youtube.com/watch?v=g6xEfNHkFKY), participants in chat tried to access a URL that doesn't work:
* https://bridges.torproject.org/scan ([archive](https://web.archive.org/save/https://bridges.torproject.org/scan)) gives status 404
It only works if you include the trailing slash:
* https://bridges.torproject.org/scan/ ([archive](https://web.archive.org/web/20200630152455/https://bridges.torproject.org/scan/))https://gitlab.torproject.org/tpo/core/tor/-/issues/17028silently ignore a bad/missing --defaults-torrc2020-06-27T20:40:08ZLunarsilently ignore a bad/missing --defaults-torrcThe nightly Debian packages for wheezy were broken because they were missing `/usr/share/tor/tor-service-defaults-torrc`. The issue was not easy to diagnose because Tor currently silently ignore a `--defaults-torrc` pointing to a non-exi...The nightly Debian packages for wheezy were broken because they were missing `/usr/share/tor/tor-service-defaults-torrc`. The issue was not easy to diagnose because Tor currently silently ignore a `--defaults-torrc` pointing to a non-existing file.
At least a warning would be good, but I think it would be even better to bail out unless `--ignore-missing-torrc` is specified.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19669`log_prefix_` maybe getting weird output from strftime2020-06-27T20:33:31ZDavid Fifielddcf@torproject.org`log_prefix_` maybe getting weird output from strftimelegacy/trac#19408 purports to show tor log lines. The date format in them is really strange:
```
6/13/2016 23:53:24 PM.700
6/13/2016 23:53:26 PM.200
6/14/2016 0:07:45 AM.200
6/14/2016 0:07:45 AM.200
```
There's a date string followed by ...legacy/trac#19408 purports to show tor log lines. The date format in them is really strange:
```
6/13/2016 23:53:24 PM.700
6/13/2016 23:53:26 PM.200
6/14/2016 0:07:45 AM.200
6/14/2016 0:07:45 AM.200
```
There's a date string followed by a dot and three digits' worth of fractional seconds. The format doesn't match what's specified in `log_prefix_`, which is `"%b %d %H:%M:%S"`.
https://gitweb.torproject.org/tor.git/tree/src/common/log.c?id=tor-0.2.7.6#n221
I don't see how this can happen, but I thought some one in core tor might want to take a look. Maybe the user has some kind of smart copy-paste that's mangling dates.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21864Support Bridges setting MyFamily to include Relays2020-06-27T20:32:04ZIsis LovecruftSupport Bridges setting MyFamily to include Relays
In src/or/config.c:
```
if (options->MyFamily && options->BridgeRelay) {
log_warn(LD_CONFIG, "Listing a family for a bridge relay is not "
"supported: it can reveal bridge fingerprints to censors. "
"You ...
In src/or/config.c:
```
if (options->MyFamily && options->BridgeRelay) {
log_warn(LD_CONFIG, "Listing a family for a bridge relay is not "
"supported: it can reveal bridge fingerprints to censors. "
"You should also make sure you aren't listing this bridge's "
"fingerprint in any other MyFamily.");
}
```
In src/or/router.c, function `router_build_fresh_descriptor`:
```
if (options->MyFamily && ! options->BridgeRelay) {
smartlist_t *family;
[…]
```
I propose instead that we:
1) Warn bridge operators not to include _other_ bridges in MyFamily, but let them know that including relays is fine. We should continue to warn them not to list any bridge in the MyFamily of a public relay.
2) Allow bridges to specify MyFamily.
The reasoning for this is that NoiseTor would like to run high-capacity default bridges for Tor Browser, but they are nervous about simultaneously running exits without being able to direct people not to use both.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31742Write a script or makefile target to install git hooks2020-06-27T20:23:24Zrl1987Write a script or makefile target to install git hooksAt this point we have to manually copy git hook scripts into .git/hooks directory and make them executable. Having a scripted way to do this would be more convenient.At this point we have to manually copy git hook scripts into .git/hooks directory and make them executable. Having a scripted way to do this would be more convenient.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/1061Two "Preferences" windows2020-06-27T14:43:16ZTracTwo "Preferences" windowsFf 3.5.2
step 1) File - > Add-ons -> Torbutton -> Options = window 1
(while window 1 is open)
step 2) Status bar -> preferences = window 2
Reversed steps behave correctly, focusing first opened window in step 2
[Automatically add...Ff 3.5.2
step 1) File - > Add-ons -> Torbutton -> Options = window 1
(while window 1 is open)
step 2) Status bar -> preferences = window 2
Reversed steps behave correctly, focusing first opened window in step 2
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: aidehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/8227Create descriptions for new Torbutton Security Prefs2020-06-27T14:42:50ZMike PerryCreate descriptions for new Torbutton Security PrefsWe simplified our Torbutton Security Prefs in legacy/trac#3100, but Nick pointed out that we should probably have inline descriptions of each pref and why you would want to set them. I think this is a good idea, but I suspect that it wil...We simplified our Torbutton Security Prefs in legacy/trac#3100, but Nick pointed out that we should probably have inline descriptions of each pref and why you would want to set them. I think this is a good idea, but I suspect that it will take a fair amount of time to both get the wording right and get the layout right, so I decided to push it out until we're more sure we actually have this time to spare before FF17 drops, or in case we simply decide we have to do it afterwords.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/10534Let's not advertise help desk emails directly2020-06-27T14:42:22ZLunarLet's not advertise help desk emails directlyTor Browser 3.5 now advertises support help desk emails more prominently. While showing our users how to get help is a great idea, giving them an help desk address directly puts a severe load on the support assistants that could partiall...Tor Browser 3.5 now advertises support help desk emails more prominently. While showing our users how to get help is a great idea, giving them an help desk address directly puts a severe load on the support assistants that could partially be avoided.
I think we should rather point them to a web page with the following:
* List of Tor Browser known issues.
* Frequently Asked Questions related to Tor Browser
* Frequently Asked Questions related to Tor
* The help desk emails
That list can be refined over time.
The ticket should probably be split in multiple things, as it concerns Tor Browser release management (for the list of known issues) and the website.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/10573`nsILocalFile` should be replaced with `nsIFile` in our extensions2020-06-27T14:42:22Zcypherpunks`nsILocalFile` should be replaced with `nsIFile` in our extensions```
Warning: Starting with Gecko 14, `nsILocalFile` inherits all functions and attributes from `nsIFile`, meaning that you no longer need to use `nsILocalFile`. If your add-on doesn't support versions older than 14, you should use `nsIFi...```
Warning: Starting with Gecko 14, `nsILocalFile` inherits all functions and attributes from `nsIFile`, meaning that you no longer need to use `nsILocalFile`. If your add-on doesn't support versions older than 14, you should use `nsIFile` instead of `nsILocalFile`.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=682360 for more information.
components/tl-protocol.js
{
var file = Cc['@mozilla.org/file/local;1'].createInstance(Ci.nsILocalFile);
file.initWithPath(aPath);
```