long term robustness of gevent.sleep

[Eelco Hoogendoorn]

I am planning to use gevent.sleep in an application where it may not have been used before; I want a greenlet to sleep for a year or more. The point is to force a renewed license check which cannot be circumvented by changing the system clock or rerouting internet based time queries.

I gevent.sleep supposed to be stable over such times periods? Its specified in seconds, and a year is only 30 million of them, which should hardly overflow. But will this work at all? It probably isn't part of the standard test suite...

Thanks for any insight you can offer!

[Stephan Preeker]

I would use a cron job. Something thats survives a restart of the system.
Theoretically it probably would work..

--
You received this message because you are subscribed to the Google Groups "gevent: coroutine-based Python network library" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gevent+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eelco Hoogendoorn]

Anything configurable from the OS would be rather easy to circumvent. A restart of the system would require a new check of internet based time anyway, to prevent simply loading an old disc image. The point is not to require an internet connection if the program is simply running for years on end in a lab, as it is intended to. Otherwise I could simply check the internet clock at more regular intervals.

[AM]

Your best bet is for the software to check in with a server you control
once a day or perhaps at a lower frequency. Anything running on the
user's computer can be messed with, even gettimeofday can be patched for
a running application.

In my experience trying to have a long running thread just for licensing
enforcement is the wrong problem to solve. I would recommend:

1. Have a license key that has the date of purchase and length of
license encoded in it.
2. Periodically (preferably on startup or every 24 hours if running
continously) check with a server to make sure that the license has not
been mucked with.

Please keep in mind that this merely raises the bar for license
manipulation and does not completely eliminate it.

HTH
AM

On 12/29/14 10:56 AM, Eelco Hoogendoorn wrote:
>
> Anything configurable from the OS would be rather easy to circumvent.
> A restart of the system would require a new check of internet based
> time anyway, to prevent simply loading an old disc image. The point is
> not to require an internet connection if the program is simply running
> for years on end in a lab, as it is intended to. Otherwise I could
> simply check the internet clock at more regular intervals.
>
>
>
> On Saturday, December 6, 2014 9:54:10 AM UTC+1, stephan preeker wrote:
>
> I would use a cron job. Something thats survives a restart of the
> system.
> Theoretically it probably would work..
>
> On Dec 6, 2014 12:33 AM, "Eelco Hoogendoorn"

> <hoogendo...@gmail.com <javascript:>> wrote:
>
>
> I am planning to use gevent.sleep in an application where it
> may not have been used before; I want a greenlet to sleep for
> a year or more. The point is to force a renewed license
> check which cannot be circumvented by changing the system
> clock or rerouting internet based time queries.
>
> I gevent.sleep supposed to be stable over such times periods?
> Its specified in seconds, and a year is only 30 million of
> them, which should hardly overflow. But will this work at all?
> It probably isn't part of the standard test suite...
>
> Thanks for any insight you can offer!
> --
> You received this message because you are subscribed to the
> Google Groups "gevent: coroutine-based Python network library"
> group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to gevent+un...@googlegroups.com <javascript:>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "gevent: coroutine-based Python network library" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to gevent+un...@googlegroups.com

> <mailto:gevent+un...@googlegroups.com>.

[Eelco Hoogendoorn]

Yes, I fully agree with your observations.

That is, I would prefer to minimize the reliance on internet. Ideally, internet would only be required at program sartup, where it checks the license, and sets up the program to be reverified or killed by a greenlet which isn't dependent on the system date, but rather initiates a countdown for the remaining license period. Without some rather deep hacking into compiled code, this system should be secure against trivial hacks like reinstalling the original disc image, or changing the system time, without annoying interruptions due to flaky internet connections.

But my question isn't about license checking per se, but rather specifically about gevent. This kind of countdown could be several years. Is gevent.wait made to deal with these kind of situations, or is this likely to run into problems?

[Denis Bilenko]

On Mon, Dec 29, 2014 at 10:04 PM, Eelco Hoogendoorn
<hoogendo...@gmail.com> wrote:
> But my question isn't about license checking per se, but rather specifically
> about gevent. This kind of countdown could be several years. Is gevent.wait
> made to deal with these kind of situations, or is this likely to run into
> problems?

No, it is not made to deal with these kind of situations. It merely
uses libev's timer which in turn uses your system's gettimeofday or
clock_gettime.

[Eelco Hoogendoorn]

So any gevent.wait/sleep command can be thrown off by mucking with the system time? 

[Eelco Hoogendoorn]

That is, I hope its clock_gettime, rather than gettimeofday. The former is guaranteed to be monotonically increasing; which is the kind of feature im looking for. The latter can be reset at any point.

Anyway, some such mechanism must underlie gevent.sleep; but I imagine there could be multiple failure mode along the way