On Sun, Jun 1, 2014 at 1:09 PM, intrigeri <intrigeri@???> 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
