The Time Namespace Appears To Finally Be On-Deck For The Mainline Linux Kernel

[oiaohm]

Also, I was thinking about back in the heyday of shareware. If I were writing time-limited trialware these days, I'd pile on the ability to recover from any amount of clock stupidity by allowing the application to look up an NTP pool (using a DNS query direct to its choice of 1.1.1.1 or 8.8.8.8 with no HOSTS file override) and query NTP for the real time. Anyone willing to MITM requests for specific IP addresses is probably also willing to just google up a cracked version, so it's outside my goals to try any harder to stop them.

Yes problem is I am think currently made shareware. Those writing current time trial stuff are still not smart enough todo this in lots of cases. You might be one of the handful who successfully gets it right. Projects like wine have to deal with all the others. Its not like it impossible to write a sane time trial with online registration but you also have to remember there are parties who don't want to run their own servers todo this so they attempt to solve the problem fully local to the machine. With motherboard clock being able to jump all over the place fully local really does not really work. Also add in that issues like y20k how to do time wrong are still being invented and a lot of parties writing time trials are not making sure their code don't have these flaws. Its not a hard thing to write a automated test for to test a program at least to the end of it supported life in time(yes were faking time or intentionally set real machines forwards comes in) yet this is also not done with a lot of those writing this stuff.

Current state of play by those writing time trial applications is a stack of badly coded broken stuff that is poorly tested and poorly planned.

Remember at times wine project developers are using company provided demos/trials to fix bugs because they throw the same fault as the real program. This is why to wine developers at times are cursing loudly because they have to work around one of these time trial bugs before they can get to the real bug they are interested in. Yes working around a time bug for one time trial bug can also cause if you are not careful for time to travel massive for a functional time trial application and upset it as well. Basically this time trial stuff is on going headache.

[ssokolow]

Basically the logic you wrote is the kind of logic those making time trials do all the time and end up causing some very wrong screw up. Do note I mentioned y20k this is screwing up because its 2020 that not a typo for y2k that is stuffing up because its 2000. They are many ways to do time trial limitations wrong.

You make valid points... but most of them are of questionable relevance when you add something I thought was so self-evident as to not need saying: My "rewind no more than 25 hours before the latest observed date" starting point for such a design mechanism would be explicitly built with time-zone changes in mind. Install with the wrong timezone? Flip the RTC between local time and UTC? Sure. Change it. I'm willing to benefit honest actors by allowing liars to cheat their way to up to 25 extra hours of trial period.

Also, I was thinking about back in the heyday of shareware. If I were writing time-limited trialware these days, I'd pile on the ability to recover from any amount of clock stupidity by allowing the application to look up an NTP pool (using a DNS query direct to its choice of 1.1.1.1 or 8.8.8.8 with no HOSTS file override) and query NTP for the real time. Anyone willing to MITM requests for specific IP addresses is probably also willing to just google up a cracked version, so it's outside my goals to try any harder to stop them.

[oiaohm]

And how many people could afford laptops in the 90s? Five? ;P

Seriously, though, I should have been less specific and just said "against mucking with the clock too much".

Were I writing something like that, I'd probably take it as a design challenge to see how elegant I could make my funny-business detection without writing a ton of code to do it. (I'd start with the idea that, barring correcting for a fast clock, 25 hours is the most your can "rewind" time, because that's the effect of circumnavigating from one side of the International Date Line to the other while simultaneously switching off Daylight Saving Time.)

"clock moving backward by more than an hour."
I am not talking about the 90s here. You see software with this mistake made in the 2010- now.

Lets take Australia you re on main land. There is currently a 3 hour time difference between the east and west cost. USA has also a 3 hour difference between coasts. People do move houses for work. But this is not the problem.

The problems stupid as it sounds first turns up on desktops. Maybe those in USA don't notice it.

Its the play from hell with poorly written shareware/time trials..

Person gets new computer here in Australia. Person sets it up quickly don't notice default to USA time zone(yes your OEM whitebox install discs do this here same with your vendor images on harddrives/ssd). They notice the time is not correct the time zone. Now the local time in windows has basically done instant travel from USA to Australia. Now that crapware anti mailware time trial included with the computer by the vendor goes bell up now they cannot log into their computer. That is something that happened last week and it was a desktop. So they don't just go bell up because the time goes backwards they also manged todo it because time go forwards by too much.

Another good cause of massive jumped backwards is the real time clock battery was not installed properly and it fell out. Yes battery fell out reset to bios/UEFI default can happen when you move a desktop computer from one place in house to another if the lithium battery clip was not done right. This basically can cause your clock to rewind by years.

None of these problems require laptops these are problems that happen with desktops.

Linux that sets RTC normally do GMT is better than windows that sets RTC to local time.

Making a time trial that goes stupid simply
1) Don't use local time use "Coordinated Universal Time (UTC) (also known as GMT)"
2) Don't block the computer from booting because the time is out.

Also fast clock worst I have seen in one particular motherboard maker RTC failure mode if you have had the RTC battery fall out and you put in back in while power is applied. It ends up running at a years time passing in 1 min.

Really computer clocks are not really that trustworthy.

Basically the logic you wrote is the kind of logic those making time trials do all the time and end up causing some very wrong screw up. Do note I mentioned y20k this is screwing up because its 2020 that not a typo for y2k that is stuffing up because its 2000. They are many ways to do time trial limitations wrong.

[ssokolow]

Those are also dumb as they have a habit of exploding on people who travel as they cross timezones.

And how many people could afford laptops in the 90s? Five? ;P

Seriously, though, I should have been less specific and just said "against mucking with the clock too much".

Were I writing something like that, I'd probably take it as a design challenge to see how elegant I could make my funny-business detection without writing a ton of code to do it. (I'd start with the idea that, barring correcting for a fast clock, 25 hours is the most your can "rewind" time, because that's the effect of circumnavigating from one side of the International Date Line to the other while simultaneously switching off Daylight Saving Time.)

[oiaohm]

And all but the dumbest time-limited shareware usually has at least some protection against the clock moving backward by more than an hour.

Those are also dumb as they have a habit of exploding on people who travel as they cross timezones.

[ssokolow]

i doubt shareware software cares about either monotonic or boottime clock

And all but the dumbest time-limited shareware usually has at least some protection against the clock moving backward by more than an hour.

[pal666]

Can this be useful to crack shareware software?

i doubt shareware software cares about either monotonic or boottime clock

[ssokolow]

http://manpages.ubuntu.com/manpages/trusty/man1/faketime.1.html

Thinking faketime that is userspace solution can be used to defeat a lot of shareware timelocks this would only do it minor-ally better. Wine project for at times for testing old shareware software that does not work due to y2k and y20k and other equal issues needs to be worked around. The hard reality is time locking copy-protection/digital rights management used by shareware is not well coded and has a bug somewhere that at some point will have to be worked around. There are tools under windows for injecting fake time into applications as well for the same reasons.

Still, it'll be nice to have something less hacky than LD_PRELOAD for playing games that do annoying things like only letting you experience holiday bonus content (eg. Santa hats on enemies and the like) in December when you may be busy with other things or not in the mood for a particular game.

[oiaohm]

Can this be useful to crack shareware software? I don't fo it, just curious about the weird cases.

http://manpages.ubuntu.com/manpages/trusty/man1/faketime.1.html

Thinking faketime that is userspace solution can be used to defeat a lot of shareware timelocks this would only do it minor-ally better. Wine project for at times for testing old shareware software that does not work due to y2k and y20k and other equal issues needs to be worked around. The hard reality is time locking copy-protection/digital rights management used by shareware is not well coded and has a bug somewhere that at some point will have to be worked around. There are tools under windows for injecting fake time into applications as well for the same reasons.

[timofonic]

Can this be useful to crack shareware software? I don't fo it, just curious about the weird cases.