[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #11648 [Tor]: Problem parsing .z-compressed descriptors fetched via DirPort
#11648: Problem parsing .z-compressed descriptors fetched via DirPort
-------------------------+-----------------------
Reporter: karsten | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor | Version:
Resolution: | Keywords: tor-relay
Actual Points: | Parent ID:
Points: |
-------------------------+-----------------------
Comment (by wfn):
I might have a sneaking suspicion that we might need to look at
`or/directory.c` for this. It might be that tor is not returning a proper
zlib image (properly 'terminated', or whatever (I don't know how zlib
format works, at least not yet.))
Maybe take a look at the part of the code that does the actual 'send zlib-
compressed data in chunks' (in `directory_handle_command_get()` which
starts on line ~2524):
{{{
2786 if (smartlist_len(items)) {
2787 if (compressed) {
2788 conn->zlib_state = tor_zlib_new(1, ZLIB_METHOD);
2789 SMARTLIST_FOREACH(items, const char *, c,
2790 connection_write_to_buf_zlib(c, strlen(c), conn,
0));
2791 connection_write_to_buf_zlib("", 0, conn, 1);
2792 } else {
/* ... */
}}}
Could it be that the way tor terminates that zlib stream (add 'empty
compressed data' to the zlib stream) is not a proper way to close a zlib
archive? (So for example this could mean that tor does indeed assume that
it's okay to send 'partial content' (in the sense of unclosed-zlib-
archive, zlib-as-stream, not in the sense of fail-to-send-some-data)?)
Can't look more into this right now, but maybe this pointer will help
somehow.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11648#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs