Sending two replies, with an updated proposal in the second. On 11 December 2017 at 18:38, teor <teor2...@gmail.com> wrote: >> It should make the file available >> at >> http://<hostname>/tor/status-vote/next/bwauth.z > > We shouldn't use next/ unless we're willing to cache a copy of the file > we actually used to vote. If we do, we should serve it from next/ as > soon as we vote using it, then serve it from current/ as soon as the > consensus is created. > > If we don't store a copy of the file, we should use a different URL, > like status-vote/now/bwauth, and recommend that the file is fetched at > hh:50, when the votes are created. This would allow us to implement > current/bwauth and next/bwauth in a future version.
Sure. > Have you thought about versioning the URL if we have multiple flavours > of bwauth file? We could use bwauth-<FLAVOR> like consensuses. For lack of a better name I'll propose bwauth-legacy? > Also, Tor has new compression options for zstd and lzma. > > Given that this is an externally-controlled file, we could stream it > from disk and compress it on the fly with something cheap like gzip > or zstd. I haven't seen any indicated in dir-spec how to handle those? Or how I should change the proposal to accommodate them? Should I make the url .gz and say that the DirAuth should compress it and stream it from disk? >> The raw bwauth vote file does not [really: is not believed to] expose >> any sensitive information. All authorities currently make this >> document public already, an example is at >> https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile > > How large is the file? > Maybe we should pre-compress it, to avoid CPU exhaustion attacks. > If we did this, we could say that it's safe, as long as it is smaller > than the full consensus or full set of descriptors. ~2.6MB. See above. -tom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev