[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #3197 [Tor bundles/installation]: m:/tor-mingw/tbb-erinn.git/build-scripts/build-stable-windows/built/share\tor\fallback-consensus

#3197: m:/tor-mingw/tbb-erinn.git/build-scripts/build-stable-
windows/built/share\tor\fallback-consensus
--------------------------------------+-------------------------------------
 Reporter:  arma                      |          Owner:  erinn
     Type:  defect                    |         Status:  new  
 Priority:  normal                    |      Milestone:       
Component:  Tor bundles/installation  |        Version:       
 Keywords:                            |         Parent:       
   Points:                            |   Actualpoints:       
--------------------------------------+-------------------------------------

Comment(by Lee Fisher):

 > I would have expected the errin I/O to be this:
 >
 >  C:\Users\user\AppData\Roaming\tor\cached-fallback-consensus
 >  C:\Users\user\AppData\Roaming\tor\cached-fallback-consensus

 Typo from last bug entry, the above second line should read unverified,
 not cached. As in a pair of (cached,unverified)-%s-consensus, where flavor
 %s is "fallback".

 However, fallback-consensus is marked OBSOLETE in Tor, so why is Tor even
 using it? In src/or/config.c it is defined as:

   OBSOLETE("FallbackNetworkstatusFile"),

 Of the various other entries marked OBSOLETE, this appears to be the only
 init-time filename marked in this way.  Tor gets the path correct for all
 other files except fallback-consensus.

 Also, the output of "strings tor.exe | grep -y erinn":

 ----snip----
 c:/Users/erinn/build-scripts.git/osx-bundles/build-alpha/share\tor
 \fallback-consensus
 OPENSSLDIR: "/c/Users/erinn/build-scripts.git/osx-bundles/build-alpha"
 gcc -D_WINDLL -DOPENSSL_USE_APPLINK -DOPENSSL_PIC -DOPENSSL_THREADS -D_MT
 -DDSO_WIN32 -I/c/Users/erinn/build-scripts.git/osx-bundles/build-
 alpha/include -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3
 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM
 -DGHASH_ASM
 /c/Users/erinn/build-scripts.git/osx-bundles/build-alpha/lib/engines
 /c/Users/erinn/build-scripts.git/osx-bundles/build-alpha/private
 /c/Users/erinn/build-scripts.git/osx-bundles/build-alpha
 /c/Users/erinn/build-scripts.git/osx-bundles/build-alpha/certs
 /c/Users/erinn/build-scripts.git/osx-bundles/build-alpha/cert.pem
 ----snip----

 shows that the this full path is hardcoded, not built at runtime in that
 %s. This is a built-time problem.

 And the grep output shows that it is the only entry hard-coded path like
 this.

 [There are some other similarly-invalid paths for OpenSSL dirs/files in
 the grep output, which might be another bug, or part of this bug,
 especially if those hard-coded invalid errinn OpenSSL dirs/paths are
 supposed to be usable dirs/paths, I'm not clear.  And does Tor really need
 OpenSSL compiled with WHILRPOOL enabled?  If resolving this bug doesn't
 resolve these other OpenSSL entries, this should become a separate bug, I
 suppose.]

 So, where does Tor get this path:

    "$PREFIX/share/tor/"
   "C:\Users\erinn\build-scripts.git\osx-bundles\build-alpha\share\tor"?

 When it should be using:

   "%APPDATA\tor\"
   aka:
   "C:\Users\user\AppData\Roaming\tor\"

 How does GNU/Autotools get/set "$PREFIX/share/tor" using MinGW toolchain?

 Windows, of course, has no "/share" subdirectory anywhere to refer to,
 that is a Unix thing. Unless Tor's Windows installer creates the
 directory, and I don't recall seeing any of that in the NSIS/WIX installer
 scripts.

 In Makefile.in this is interesting:

     -----snip-----
     FORCE:
     # fallback_consensus

     # If we don't have it, fake it.
     src_config_fallback-consensus:
         touch src/config/fallback-consensus
     -----snip-----

 And in src/config/include.am, this is interesting:

     -----snip-----
     EXTRA_DIST+= src/config/geoip src/config/geoip6
     # fallback-consensus

     conf_DATA = src/config/torrc.sample

     tordata_DATA = src/config/geoip src/config/geoip6
     # fallback_consensus

     # If we don't have it, fake it.
     src_config_fallback-consensus:
         touch src/config/fallback-consensus
     -----snip-----

 Why does the makefile touch an obsolete file like this, at all?

 Note that "src/config" doesn't exist on a Windows installation, AFAIK.

 Perhaps this touch is failing on the Windows build, with that invalid
 path?  Does your toolchain even have a touch.exe, or is that also failing?
 I'm afraid I can't figure out how to get further without Erinn's build
 log, and system and toolchain info. Someone with more GNU/Autotools skills
 is needed.

 It appears this feature was added in 2008:

 ----snip----
 - When we have no consensus, check FallbackNetworkstatusFile (defaults
 to $PREFIX/share/tor/fallback-consensus) for a consensus. This way
 we can start out knowing some directory caches. We don't ship with
 a fallback consensus by default though, because it was making
 bootstrapping take too long while we tried many down relays.
 ---snip----

 Thanks,
 Lee

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3197#comment:5>
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