[tor-bugs] #11648 [Tor]: Problem parsing .z-compressed descriptors fetched via DirPort

[Tor Bug Tracker & Wiki]

#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