-
Notifications
You must be signed in to change notification settings - Fork 48
[WIP] Update a cancelableReader importing gpg keys #489
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -40,7 +40,7 @@ func (pr *prSignedBy) isSignatureAuthorAccepted(ctx context.Context, image priva | |||||||||
| } | ||||||||||
|
|
||||||||||
| // FIXME: move this to per-context initialization | ||||||||||
| mech, trustedIdentities, err := newEphemeralGPGSigningMechanism(data) | ||||||||||
| mech, trustedIdentities, err := newEphemeralGPGSigningMechanism(ctx, data) | ||||||||||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
@mtrmac Updated the code. Do we still need to add timeout context pass down, so the cancellable reader to work? if not hardcode a timeout here, will the caller cancel the context?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I’m afraid I can’t parse the question. Are you asking whether the CRI-O server already has a timeout / request cancellation logic of some kind (maybe triggering when/if the Kubelet client gives up)? That would be a CRI-O question. And if CRI-O did pass to I would, by default, expect the timeout, if any, to be set at a pretty high-level; I was thinking one for the whole RPC operation served by CRI-O … except that that doesn’t work well for pulls, which, on slow links, may be making steady progress over many minutes, so there is no good timeout that can be set for the whole pull by default. So, I guess, in the caller of [There’s also CRI-O’s |
||||||||||
| if err != nil { | ||||||||||
| return sarRejected, nil, err | ||||||||||
| } | ||||||||||
|
|
||||||||||
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.
Does this even work/address the problem in any case? The issue is the Read is blocking so checking the context before/after will not solve the issue if the bug is is read() blocks forever.
I mean sure it does work if the the problem is that it keep reading indefinitely over and over in some loop and we want to timeout that but per #421 I got the impression that is not the case.
If we use a real pipe as reader go exposes SetDeadline() so that could be used to limit the actual time the read would block.
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.
GPGME is a C library running
gnupgas a subprocess, and communicating with it using a ~poll loop — and something goes wrong and hangs there. (My limited investigation suggests that this centers on a control FD which is not visible in the GPGME API at all, but that might be wrong or a consequence of some earlier failure.)Replacing one of the data sources with something that can indicate failure is hypothetically a way to interrupt that poll loop — if the code has a reason to execute one more iteration of the poll. There’s not much reason to think that the code will actually have a chance to poll again, but, also, that’s the ~only cancellation mechanism we have. That would absolutely not be a fix but it might be a pragmatic workaround if it happened to be proven to affect things.
In this PR, the cancellation is on a source that is passed as a byte array, so it should never block. OTOH that also makes it fairly unlikely that the cancellation opportunity would manifest.
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.
ack, then I don't think the context check on read can help to work around it.