-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: update Timer.md
with caveats
#3827
Conversation
to re-establish timers after an upgrade is to walk stable variables | ||
in the `post_upgrade` hook and distill necessary timer information | ||
from there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe some will come up with a good example. Maybe we could have made this work using a single well-known update method, but that wasn't in the Rust version either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct?
is to walk stable variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I think it is common usage to walk (i.e. traverse) data structures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But see suggestions
in the `post_upgrade` hook and distill necessary timer information | ||
from there. | ||
|
||
Note: Basing security (e.g. access control) on timers is almost always |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the underlying reason that security controls shouldn't use timers? Or is this based on my comment in slack?
I can't come up with a good scenario in which one would want to. Just wondering if this statements mean that timers are not very reliable or that usually if you need timers in a security control you there is a design issue. The thing we wanted to remark from ProdSec is that IF you use timers for security controls, make sure to reinstate them after an upgrade.
Agreed that access control would likely not need timers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is triggered by your slack comment. There are access control methods that use time, e.g. exponential lockout for mistyped passwords etc. These are problematic here, as there is no protection against reentrancy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a blurb. PTAL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed this comment back then. LGTM if you still want to merge it.
Co-authored-by: Claudio Russo <[email protected]>
Co-authored-by: Claudio Russo <[email protected]>
Just doing some repo cleanup for better focussing on active work: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for improving the docs!
... and suggestions. Touch on security and the default mechanism.
Also linking @dfinity-berestovskyy's timer FAQ, which is https://internetcomputer.org/docs/current/developer-docs/backend/periodic-tasks#timers-library-limitations