Hi Pablo, On Tue, Nov 19, 2019 at 11:33:18PM +0100, Pablo Neira Ayuso wrote: > On Tue, Nov 19, 2019 at 11:20:23PM +0100, Phil Sutter wrote: > > Hi, > > > > On Tue, Nov 19, 2019 at 11:12:36PM +0100, Pablo Neira Ayuso wrote: > > > On Tue, Nov 19, 2019 at 12:06:23PM +0100, Ander Juaristi wrote: > > > > El 2019-11-18 19:34, Pablo Neira Ayuso escribió: > > > > > Hi Phil, > > > > > > > > > > On Sat, Nov 16, 2019 at 10:32:18PM +0100, Phil Sutter wrote: > > > > > > Payload generated for 'meta time' matches depends on host's timezone > > > > > > and > > > > > > DST setting. To produce constant output, set a fixed timezone in > > > > > > nft-test.py. Choose UTC-2 since most payloads are correct then, adjust > > > > > > the remaining two tests. > > > > > > > > > > This means that the ruleset listing for the user changes when daylight > > > > > saving occurs, right? Just like it happened to our tests. > > > > > > > > It shouldn't, as the date is converted to a timestamp that doesn't take DST > > > > into account (using timegm(3), which is Linux-specific). > > > > > > > > The problem is that payloads are hard-coded in the tests. > > > > > > > > Correct me if I'm missing something. > > > > > > I see, so it's just the _snprintf() function in the library. I > > > remember we found another problem with these on big endian, it would > > > be probably to move them to libnftables at some point. > > > > > > Acked-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> > > > > Ah, now that I reread your question, I finally got it. And you're right: > > If DST occurs, time values will change. This is clear from looking at > > hour_type_print(): Whatever the kernel returned gets cur_tm->tm_gmtoff > > added to it. Here, this is either 3600 or 7200 depending on whether DST > > is active or not. > > > > The other alternative would be to make kernel DST-aware, I don't think > > that's the case. > > Hm, so the ruleset listing changes after DST. Yes, but only because payload (and hence kernel data) remains the same. > If the user specifies the time according to the userspace timezone, > then ruleset listing should not change? > > I'm still trying to understand if this is a real problem. IMHO, it's a controversy of whether we want to make the time match respect DST changes or not: It should, because when I restrict internet access to my kids after 8pm, I don't want to touch my firewall's ruleset twice a year. It needs not, because upon the next reboot things are correct again, anyway. It should not because otherwise once a year there are two spooky hours in which things run twice that should never ever run more than once per night. Apart from that, description of --kerneltz in iptables-extensions(8) speaks for itself. So long story short, it is always a problem no matter how it is solved. :( Cheers, Phil
