n probably be removed from:
https://metrics.torproject.org/onionoo.html#details_relay_overload_general_timestamp
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailma
related rC3 presentation:
title: Towards a more Trustworthy Tor Network
when: 2021-12-28, 17:00 CET
where: https://streaming.media.ccc.de/rc3/csh
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev
-by-bandwidth.html
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
[DIR] tor-experimental-buster/ 2021-12-20 22:21-
[DIR] tor-experimental-focal/ 2021-12-20 22:21-
[...]
thank you!
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
kind regards,
nusenu
[1]
https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#proof
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi,
below is a partial proposal draft for human readable relay operator IDs that
are authenticated
by directory authorities. If there is any interest in implementing
something like this I'll complete the draft and submit
it via gitlab.
kind regards,
nusenu
# HAROI: Human Readable
for these parameters is in param-spec.txt at
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/param-spec.txt#L194
thank you Nick for explaining this,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
?
thanks,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
and authentication builtin).
In that case the suggested solution would be even more needed because in that
case relabling
via prometheus' scrape config is no longer possible.
What do you think about this suggestion?
kind regards,
nusenu
--
https://nusenu.github.io
Said this I will update both the timestamp and the protocol version for
consistency.
thanks, appreciated.
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman
://metrics.torproject.org/onionoo.html#versions
Is that and the 'version' field in onionoo no longer maintained?
(since it didn't change with the new fields)
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
ent
(2) they have met at least once in a physical setting (not just online)
https://github.com/nusenu/tor-relay-operator-ids-trust-information/blob/main/README.md#trust-anchor-ta
If I sign a my mate's
relay,
Note: there is no manual signing and no trust at the individual relay level in
th
David Goulet:
On 29 Oct (22:48:53), nusenu wrote:
Hi,
I'm wondering if the current version of the text is the latest available
version of it or
if there is somewhere a newer version that hasn't been pushed yet?
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay
is already in released tor versions.
also in the context of this change:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40364
the proposal still mentions extra-info documents.
thanks,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing li
Hi,
thanks for your input.
There will be a new iteration of the draft and I will reply to your email
again once that is done, as it should cover some of the areas you mentioned.
kind regards,
nusenu
yanma...@cock.li:
(sorry for replying directly before)
On 2021-10-03 16:16, nusenu-lists
to come to a common format that can be used everywhere
even in places where "/" is not supported.
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-b
On Tue, Aug 4, 2020 at 6:41 PM nusenu wrote:
nusenu:
I'll wait until you (Tor developers) decided on the final naming and format
Is there any interest to move this topic forward to come to some decision
in the near future? (before the end of the month)
I don't think that'd be too hard
):
tor_relay_exit_dns_error_total{... reason="format"}-> FormErr?
tor_relay_exit_dns_error_total{... reason="notexist"} -> NXDomain?
kind regards,
nusenu
[1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/453
[3] https://support.torproject.org/relay-operators/relay-bri
nusenu:
cut -b 33- ed25519_master_id_public_key |base64
hint: don't use this
Since cut is line based it will only read until the end of the line
but the input file is not a text file - so it will stop reading at random
offsets.
--
https://nusenu.github.io
all flags indicating that the relay
is usable for a particular position.
This part was not clear to me, but if I ignore it, the rest makes sense.
It is not clear because it says an authority should set _all_ flags to indicate
that a relay is unusable for a particular purpose.
kind regards,
nusenu
escription, so I can confirm that this:
cut -b 33- ed25519_master_id_public_key |base64
gives me the same string as in the file fingerprint-ed25519
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.
Hi,
given a relay's ed25519_master_id_public_key
file, is there a simple way to generate the
43 chars long ed25519 identity string (also found in fingerprint-ed25519)?
thanks,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev
Maybe you would like to open a merge request or post it on tor-dev in its
entirety so we can comment? Whatever you prefer.
https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/49
--
https://nusenu.github.io
___
tor-dev mailing list
Hi,
I wrote down a spec for a simple web of trust
for relay operator IDs:
https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-operator-ids/proposals/ideas/xxx-simple-relay-operator-wot.md#a-simple-web-of-trust-for-tor-relay-operator-ids
This is related to:
https
Hi Neel,
it would be great if you could open a MR for the proposal so we can always see
the latest version and changes
there.
(Over time it became unclear what comments have already been addressed in the
text an which didn't.)
kind regards,
nusenu
--
https://nusenu.github.io
if it will go in.
thanks for these pointers.
In case "ExcludeGuardNodes" option is accepted and merged, the documentation
should explicitly point out
the differences between
LimitToMiddleOnlyNodes NodeX
vs.
ExcludeGuardNodes NodeX
+
ExcludeExitNodes NodeX
thanks,
nusenu
--
https://nusenu
ven relays are excluded from the
middle position
but in fact they should be limited to the middle position.
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
her including option)
mentions a relay fingerprint that is also excluded.
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
: UseMicrodescriptors 0 -> start tor -> fast to complete descriptor
fetching
2) no torrc change -> start tor -> controller.set_conf('UseMicrodescriptors',
'0') -> slow
Maybe (2) is slower because tor does not start the download directly after
set_conf('UseMicrodescriptors', '
persistently and restarting the tor client.
Can I tell tor to "fetch now" directly after
controller.set_conf('UseMicrodescriptors', '0')
via an additional control command?
kind regards,
nusenu
--
https://nusenu.github.io
___
tor-dev mailing li
Jorropo:
> Is this expected or I am doing something wrong?
Have a look at the documentation of DNSPort:
https://2019.www.torproject.org/docs/tor-manual.html.en#DNSPort
Tor's DNSPort is rather limited,
if you need more I recommend to
use an encrypted DNS protocol like DNS-over-TLS or
I've put this thread into a new ticket:
"provide relay health prometheus metrics via MetricsPort/MetricsSocket"
https://gitlab.torproject.org/tpo/core/tor/-/issues/40194
___
tor-dev mailing list
tor-dev@lists.torproject.org
Nick Mathewson:
>> in the past
>> https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases
>>
>> used to be the canonical place for tor EoL information.
>> Since Trac is no longer used: Is there a new home for this kind of
>> information?
>
>
://nusenu.github.io/OrNetStats/#tor-version-distribution-relays
https://nusenu.github.io/OrNetStats/#end-of-life-relays-share
kind regards,
nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
it does not require any implementation in tor's code.
kind regards,
nusenu
[1] https://github.com/torproject/torspec/pull/129#issuecomment-681194660
[2] https://github.com/protocol-registries/well-known-uris/issues/8
[3] https://github.com/torproject/torspec/blob/master/proposals/001-process.txt
si
Hi,
I'm submitting this as a proposal according to:
https://github.com/torproject/torspec/blob/master/proposals/001-process.txt
I made a PR request for you:
https://github.com/torproject/torspec/pull/129/files
kind regards,
nusenu
signature.asc
Description: OpenPGP digital signature
Damian Johnson:
> Hi nusenu, tor's manual says [1]...
>
> "To split one configuration entry into multiple lines, use a single
> backslash character (\) before the end of the line. Comments can be
> used in such multiline entries, but they must start at the beginning
>
Nick Mathewson:
> On Mon, Aug 10, 2020 at 6:13 PM nusenu wrote:
>>
>> Hi,
>>
>> it is not clear to me whether ExcludeNodes and other similar options
>> (ExcludeExitNodes)
>> can be used multiple times in a torrc file.
>>
>> Are all of the li
Hi,
it is not clear to me whether ExcludeNodes and other similar options
(ExcludeExitNodes)
can be used multiple times in a torrc file.
Are all of the lines merged like multiple "MyFamily" lines or
how does it behave?
thanks,
nusenu
--
https://mastodon.social/@nusenu
sig
omething if it's on track to get used.
The ContactInfo spec is used currently by 100 relays (>12% exit probability).
The amount of relays using it increased from 44 to 100 after version 1
of the spec got released on 2020-07-21. The well-known URI will
be part of version 2.
regards,
nusenu
--
https://
nusenu:
> submitted as:
> https://github.com/protocol-registries/well-known-uris/issues/8
>
>
> @nickm and Mike: Mark would like to hear your opinion on it.
> https://github.com/protocol-registries/well-known-uris/issues/8#issuecomment-670269951
here is the background story
submitted as:
https://github.com/protocol-registries/well-known-uris/issues/8
@nickm and Mike: Mark would like to hear your opinion on it.
https://github.com/protocol-registries/well-known-uris/issues/8#issuecomment-670269951
--
https://mastodon.social/@nusenu
signature.asc
Description
Damian Johnson:
>> I hope we can agree to use the same format in all places.
>
> Thanks nusenu, that's a great summary. Honestly I doubt that
> deprecating RSA keys is on anyone's visible horizon, and by extension
> RSA-based fingerprints will remain our can
nusenu:
> I'll wait until you (Tor developers) decided on the final naming and format
Is there any interest to move this topic forward to come to some decision
in the near future? (before the end of the month)
Here is a short summary of what opinions I observed for this topic (nam
Damian Johnson:
>> Isn't using "fingerprint" not a bit misleading since it is not the output of
>> a hash function but the ed25519 master public key itself?
>
> Hi nusenu, that's fair. We've begun to conflate a couple concepts here...
>
> * Relay operato
character?
https://tools.ietf.org/html/rfc4648#section-5
https://docs.python.org/3/library/base64.html#base64.urlsafe_b64encode
--
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torpr
nd the control API.
maybe add a file similar to the datadir/fingerprint file
containing the base64 representation of the Ed25519 public key?
maybe datadir/ed25519_identity ?
--
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
I've put together the text, if you have any
comments please let me know. I'm planning to submit it
soon-ish.
https://nusenu.github.io/tor-relay-well-known-uri-spec/
I'll also send it to the tor-relays mailing list.
kind regards,
nusenu
--
https://mastodon.social/@nusenu
signature.asc
nusenu:
>> The only question that came up was: Will there be two types of relay
>> fingerprints
>> in the future (Ed25519)?
>
> I assume the correct proposal for the Ed25519 keys is this:
> https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt
&
ngerprint:
openssl rsa -in keys/secret_id_key -outform DER -RSAPublicKey_out 2> /dev/null|
openssl sha1 -r|cut -d" " -f1|sed -e 's/ /,/g'
also:
Are there any plans to include the Ed25519 IDs in onionoo/Relay Search?
What format would you most likely use there?
thanks,
nusenu
These are the
Hi,
to reduce the risk of certain kinds of attacks
I'm aiming to submit a short spec (like [1])
in accordance with RFC8615
https://tools.ietf.org/html/rfc8615#section-3.1
for the registration of of a suffix for the verifyurl
from
https://github.com/nusenu/ContactInfo-Information-Sharing
Georg Koppen:
> nusenu:
>> Hi,
>>
>> since Mozilla did tests [0] on DOH [1] in Firefox I was wondering
>> if Torbrowser developers have put any thought into that as well?
>
> Actually, the study did not get done yet. The start date is scheduled
> for June 4t
Christian Hofer:
> On Tue, 2020-06-09 at 23:54 +0200, nusenu wrote:
>>> However, thinking about it, DNSSEC might be useful for caching DNS
>>> records on the client side.
>>
>> caching has privacy implications and is therefore a risk.
>>
>
> So you ar
erformance implications and
increase the number
of available DoH servers.
but finding resolvers is probably one of the smaller issues when compared to
getting
everything implemented in firefox/tor browser. Current versions do not even
allow
to set more than one resolver URL.
kind rega
ble to visit a HTTPS website without the exit relay learning what domain it
was
(encrypted DNS + encrypted SNI)
There are a few issues to solve along that path.
kind regards,
nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing
Christian Hofer:
> On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote:
>> Alexander Færøy:
>>> I wonder if it would make more sense to have an onion-aware
>>> DNSSEC-enabled resolver *outside* of the Tor binary and have a way
>>> for
>>> Tor to query an e
> Before we go further, can you walk me through the reasons (if you had thought
> of it of course) why you didn't use something like libunbound?
>
> There are side effects of adding DNSSEC client support (with our own
> implementation) that we, people maintaining tor, have to become DNSSEC expert
> To me, extra round-trips over the Tor network in the critical path of
> "user clicks and waits for the website to load" are really bad, and
> need a really good argument for being there. Given that DNS is only one
> piece of the connection -- after all, the exit relay can still route you
>
Alexander Færøy:
> I wonder if it would make more sense to have an onion-aware
> DNSSEC-enabled resolver *outside* of the Tor binary and have a way for
> Tor to query an external tool for DNS lookups.
I'm also in favor of this approach,
and you can do this today with no code changes to tor at
> I can not really say anything about how this design compares to other
> approaches, since I don't know how I can setup meaningful test
> scenarios to compare them.
Do we really need test setups to discuss protocol designs
and compare protocols with a common threat model if specs for the
PS):
- this design increases the network path when the configured resolver is not
the exit relay
- a design that will not use the exit for resolution will likely have a
performance impact on domains that do geoIP
based optimizations to allow i.e. HTTP fetches from locations near the exit
relay
anything.
https://trac.torproject.org/projects/tor/ticket/26646
--
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/lis
al feature to make the internet more accessible
to Tor users.
thanks,
nusenu
[1] https://trac.torproject.org/projects/tor/ticket/3847#comment:6
--
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailin
possibly useful for you:
https://gitweb.torproject.org/torspec.git/tree/path-spec.txt
https://gitweb.torproject.org/torspec.git/tree/guard-spec.txt
--
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor
nusenu:
> Hi,
>
> every now and then I'm in contact with relay operators
> about the "health" of their relays.
> Following these 1:1 discussions and the discussion on tor-relays@
> I'd like to rise two issues with you (the developers) with the goal
> to help improv
Hi,
as far as I can tell there is no way for a tor client to ask an exit to resolve
a given TXT record and to provide the answer for it.
Just wanted to make sure there is even no hack around that limitation.
thanks,
nusenu
https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded
gt; Has this bug been fixed in later versions of tor or current master?
My assumption was a bit to fast ;)
exitmap just reads 10 bytes only:
resp = self._recv_all(10)
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description
> Running tor 0.3.5.8.
>
> Has this bug been fixed in later versions of tor or current master?
moved to trac:
https://trac.torproject.org/projects/tor/ticket/31115
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital
IPv6 response, but Exitmap ignores the
> address type, and turns the first 4 bytes of the response into an
> IPv4 address.
I modified exitmap to print the entire response in case the ATYP field is set
to 04 (meaning the
response contains an IPv6 address) but
the response is not any longer a
resp[1].encode("hex"))
>
> return socket.inet_ntoa(resp[4:8])
Does Tor's SOCKS resolution extension support IPv6 answers
or does it only attempt A records?
I'm aiming to resolve a hostname and would like to get
the IPv4 and if available the IPv6 add
ermail/tor-relays/2019-May/017273.html
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
t; spot spikes down to the minute.
30 or 60 minutes granularity seems reasonable
> Some of the stats below are safe in my opinion like the memory usage but
> most of them need to be looked at in terms of safety
yes please
--
https://twitter.com
these features
seem reasonable to you.
Looking forward to hearing your feedback.
nusenu
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.
todon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
hen I guess.
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi,
the tor 0.3.5.x repos (example [1]) exist since some time
but are empty since then, is that intentional?
kind regards,
nusenu
[1]
https://deb.torproject.org/torproject.org/dists/tor-experimental-0.3.5.x-stretch/main/binary-amd64/Packages
--
https://twitter.com/nusenu_
https
Hi r1610091651,
thanks for your report.
please add that information and your OS+version to
https://trac.torproject.org/projects/tor/ticket/27813
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
;15% of the Tor network's exit capacity,
which means that we are around 50% RPKI ROA coverage for Tor exit capacity now.
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-
y but
we should have a discussion and reach some form of consensus on the topic
to move forward instead of waiting until it significantly affects reachability.
Would be nice to have an initial discussion even before writing a proposal to
gather opinions if that would be actually worth doing.
kin
tween these two, to address
the regression in 6.2 (#27039) before September?
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torpr
ide
> /TorRelayGuide/DebianUbuntu
> /TorRelayGuide/CentOSRHEL
> /TorRelayGuide/Fedora
> /TorRelayGuide/FreeBSD
> /TorRelayGuide/openSUSE
/BSDUpdates (I might split that so we can assign that as easily as the rest)
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
sign
Hi Vinícius,
(moving this discussion to the tor-dev mailing list since this isn't limited to
the OpenBSD ticket scope
https://trac.torproject.org/projects/tor/ticket/26619#comment:14 )
Vinícius wrote:
> you [nusenu] took over /FreeBSD, /BSDUpdates, and /OpenBSD and enabled the
>
I pasted that email to trac as
https://trac.torproject.org/projects/tor/ticket/26910
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
the vandalism.
thanks!
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor
and deployed.
would be nice to have that in tor 0.3.5
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https
>> Would anyone be willing to implement it in tor?
>
> This would be a feature for scanners, not little-t-tor itself, right?
the test would be performed by tor in the dir auth role (like other tests
performed by dir auths)
--
https://twitter.com/nusenu_
https://mastodon.so
ld simply
require the exit to not fail to many DNS resolution attempts.
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.
/26691
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
nusenu:
> It would be nice if every subsection (i.e. "SPDY and HTTP/2" would have an
> anchor
> so we can easily link to it)
in what trac component would I file this request?
"Webpages/Website"?
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
ately onionoo does not have fallbackdir data, so I can't
provide the same table as above for fallbacks without
creating it myself first
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
_
teor:
>
>> On 3 Jul 2018, at 05:52, nusenu wrote:
>>
>> Hi,
>>
>> I like unbound's documentation with this regards, for example they say
>> in their man page:
>>
>>> The interfaces are not changed on a reload (kill -HUP)
&
tative information about
what changes require restarts vs. reloads.
[1] https://unbound.net/documentation/unbound.conf.html
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev m
grarpamp:
> On Sat, Jun 30, 2018 at 5:22 PM, nusenu wrote:
>> tor's man page for OutboundBindAddress* options say:
>>
>>> IPv6 addresses should be wrapped in square brackets
>>
>> since it does not throw an error without square brackets:
>> does it make
uld like to document the impact
of my bug (if there is any).
thanks,
nusenu
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
ht
or/ticket/14997#comment:3
[3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html
[4] https://trac.torproject.org/projects/tor/ticket/26474
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
_
state change on the ticket when a PR is acted upon.
I closed the ticket now.
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproje
ve its maintainability.
Is that ok with you?
@Alison: is there a timeline for community.tpo?
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproje
not HTTPS) for onion v3 - unnecessary
if everyone can get letsencrypt certs for their onions)
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Georg Koppen:
> This should be fixed now, thanks (and visible once the website rebuilds).
Thank you for addressing this so timely.
btw: It would be nice if every subsection (i.e. "SPDY and HTTP/2" would have an
anchor
so we can easily link to it).
--
https://mastodon.s
1 - 100 of 317 matches
Mail list logo
