On Sun, Jun 1, 2014 at 1:09 PM, intrigeri <[email protected]> wrote: > Hi, > > AK wrote (01 Jun 2014 17:17:02 GMT) : >> OK, but note this from the htpdate website [1]: > >> "!!! no development on the Perl version is done anymore !!! " > > Thanks for the pointer. > > In practice, we've forked it years ago, after sending pull requests to > upstream, who never replied. The version we're using works very well > for us. So, I'm neither overly concerned, nor convinced that having > this thing maintained upstream would be a game-changer. > >> "Be aware that the script makes a step in time and some programs (e.g. >> database) do not always appreciate a step backwards in time. The C >> version of htpdate doesn't step but adjusts the time smoothly." > >> So it is no longer maintained by upstream, and it doesn't adjust the >> time smoothly. I guess you don't want to always adjust the time >> smoothly since you want people to be able to get started right away, > > Right. > >> but I think that if their clock is already close enough, it is better >> to adjust smoothly (built in kernel feature as I understand it). > > Why?
I just did some quick research on my it's important to have a clock that doesn't go backwards in time (the monotonic requirement). Other than the fact that the C version of htpdate requires this with its "adjust" feature (gave example about databases) and NTP has this in its design as well, I found a paper by David Mills (inventor of NTP) [1] that talks about the monotonic requirement. However, I couldn't see a good explanation as to why it's important. So I looked some more and found one concrete example [2] of a software system that does rely on the monotonic requirement. I know there should be more evidence, and I will look, but I think it's always a good security/correctness practice to have a monotonically increasing clock. [1] http://www.eecis.udel.edu/~mills/database/reports/time/timeb.pdf [2] https://www.unidata.ucar.edu/software/ldm/ldm-current/basics/platform.html > >> Also, C can run slightly faster (not sure if it's significant) > > I believe that the Tails' time syncing process is not CPU-bound. > I could be wrong, but I would be surprised if the time spent computing > things took significantly more than a few percents of the process. > >> For memory protection, I would suggest using kernel hardening such as >> PaX from grsecurity [2]. > > Sure, this would be good. I suggest refering to the discussion about > it, on this mailing-list, a couple months ago, to get an idea of > the challenges. > > But still, having enough band-aid to hope one is able to stop the > bleeding is not good reason to create injuries in the first place :) > > Cheers, > -- > intrigeri > | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc > | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
