Ian Goldberg transcribed 1.2K bytes:
> > There may need to be a maximum sum length of the X- entries. This is
> > left to the developers. I propose a maximum sum length of 5 kilobytes.
A couple questions:
0. Does this proposal include adding these additional `X-*` fields to
the `@type bridge-server-descriptor`s as well? Or only to the
non-bridge server-descriptors?
I ask because there have been times where BridgeDB appeared to be
receiving around 17,000,000 bridge descriptors from Tonga (the
BridgeAuth) per half hour. BridgeDB needs to parse all of these.
While the parsers can obviously skip any `X-*` lines, if, by some
error somewhere in the network, BridgeDB were to start receiving
seventeen million bridge descriptors again, except that now each
descriptor contains your proposed maximum of 5KB extra text, that adds
approximately 81GB every half hour. The previous case where the
seventeen-million-bridge-descriptor bug happened nearly OOMed
BridgeDB's machine continuously for two whole days, it ran out of disk
space several times, and required constant babysitting from both me
and sysrqb. If every bridge, or meerly a few hundred malicious
bridges, were to send their `@type bridge-server-descriptor` every
second with 5KB extra text, it would wreak havoc on several machines
critical to the network's infrastructure.
Don't get me wrong, I like this proposal. I just don't want to say
okay to something that'll wind up with me waking up to the Nagios
instance screaming at me that BridgeDB's machine is down.
Which brings me to my next question:
1. Why 5KB?
Are we planning on allowing people to use Tor's consensus to pass
encrypted emails around? I understand the desire to enable relays to
be able to store *anything* in these fields, but this seems kind of
crazy. Couldn't we specify the maximum length per line to something
smaller? I also think that Ian's suggestion below to have an upper
bound on the number of individual keys is a good idea.
> Should there be an upper bound for individual keys, values, or key/value
> pairs?
Additionally, you might want to add something to the spec which states
that duplicate keys aren't allowed, or that only the last such key
will be parsed as valid, or they all get parsed, or however you want
the parsers to behave.
--
ââ isis agora lovecruft
_________________________________________________________
GPG: 4096R/A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev