Opened 7 years ago

Closed 6 years ago

#6384 closed enhancement (implemented)

Log library versions at startup, and in response to a command-line option

Reported by: ioerror Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: easy tor-client
Cc: nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'd like to know which openssl/libevent/zlib that I'm using when I start Tor. This should be output with --version.

Child Tickets

Change History (11)

comment:1 Changed 7 years ago by nickm

Component: - Select a componentTor Client
Milestone: Tor: unspecified

I would favor a separate --library-versions or something for this.

It should be pretty verbose: logging the compile-time and run-time versions of each library, and logging both the human-readable and the hex-encoded versions.

comment:2 Changed 7 years ago by nickm

Summary: add lib output in tor startupLog library versions at startup, and in response to a command-line option

comment:3 Changed 7 years ago by nickm

Keywords: easy added

comment:4 Changed 7 years ago by nickm

Keywords: tor-client added

comment:5 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:6 Changed 6 years ago by Ry

Please check the below branch for a partial implementation. Currently treating it like '--versions' and will exit after printing. Also updated the versions string after regular startup to include runtime zlib version (was already printing openssl and libevent).

Haven't implemented hex-encoded versions yet, just need to clarify that we're just wanting the hexprint of the integer version number and not a hash of the actual lib or something? Is this also required for compile and runtime?

Are we supporting zlib <= 1.1 as I think the ZLIB_VERNUM is only usable after that, but we can just parse the ZLIB_VERSION to get a similar output if necessary. Do you have any additional requirements for the hex-encoded versions?

Thanks

https://github.com/Ryman/tor/tree/bug6384

comment:7 Changed 6 years ago by nickm

Quick notes:

  • crypto_openssl_get_header_version_str leaks its output. It should probably use the static-variable trick.
  • I don't think the hex thing is actually needed. (I wonder why I mentioned it above?)
  • I hope we aren't supporting zlib <= 1.1; zlib 1.1.0 was released in 1998, and several security flaws in zlib have been fixed since then.

Other than that, it seems okay to me.

It's going to conflict with #4647, but that's not a big deal. (Don't worry about this; solving merge conflicts my thing.) I'll merge it after #4647, since it'll probably be easier that way.

comment:8 Changed 6 years ago by nickm

Oh -- parse_openssl_version_str should probably have documentation.

comment:10 Changed 6 years ago by nickm

As of 386e9fb29775f972cfaa, this looks good. I'll merge it once #4647 is in.

comment:11 Changed 6 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged into master; thanks!

Note: See TracTickets for help on using tickets.