[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #16980 [Tor]: Implicit time range assumption breaks Tor in Shadow
#16980: Implicit time range assumption breaks Tor in Shadow
----------------------------+--------------------------------
Reporter: robgjansen | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor | Version: Tor: 0.2.7.2-alpha
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
----------------------------+--------------------------------
Comment (by nickm):
We do indeed assume that time_t is signed; see this section in
configure.ac:
{{{
AX_CHECK_SIGN([time_t],
[ AC_DEFINE(TIME_T_IS_SIGNED, 1, [Define if time_t is signed]) ],
[ : ], [
#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
#ifdef HAVE_SYS_TIME_H
#include <sys/time.h>
#endif
#ifdef HAVE_TIME_H
#include <time.h>
#endif
])
if test "$ax_cv_decl_time_t_signed" = no; then
AC_MSG_WARN([You have an unsigned time_t; some things will probably
break. Please tell the Tor developers about your interesting platform.])
fi
}}}
We can safely turn that WARN into an ERR I think.
But refactoring crypto_rand_time_range() that way doesn't seem so safe to
me; it doesn't actually do the right thing with negative inputs. What
about something more like:
{{{
tor_assert(min < max);
return min + (time_t)crypto_rand_uint64(max-min);
}}}
(Also, I am far from convinced that this is the last thing that will break
if time() starts out at 0 -- I never really considered what would happen
if you tried to run Tor in 1970 before, and there may well be other things
that break. I wonder if, as a kludge, you wouldn't be better off starting
Shadow's time() at 1971 or 1980 or 2000 or something -- I bet there are
other programs out there that make similar assumptions not needing to run
at times before they were written.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16980#comment:3>
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