Skip to content
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

(PUP-7283) Disable CRL checking when fetching the CRL #5725

Merged
merged 2 commits into from Mar 28, 2017
Merged

(PUP-7283) Disable CRL checking when fetching the CRL #5725

merged 2 commits into from Mar 28, 2017

Conversation

adrienthebo
Copy link
Contributor

@adrienthebo adrienthebo commented Mar 16, 2017

When we're fetching the CRL for the first time and a CRL hasn't been provided out of band, we need to disable CRL checking until that request has completed.

I've also included a graphical representation of the indirector for anyone interested.

Ouroboros

@puppetcla
Copy link

CLA signed by all contributors.

@@ -40,6 +40,7 @@ def pop
if @stack[-1][0] == 0
raise(StackUnderflow, "Attempted to pop, but already at root of the context stack.")
else
@id -= 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this just a bug that already existed? This changes us from always having unique context ID in the stack to possibly having duplicates. I'm not super familiar with the system - is that safe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The @id field isn't directly exposed and you can only really observe it by stepping into the class via the debugger. I assumed the id was meant to indicate the context depth but it could be a unique identifier. Is that more helpful, identifying the context or stack depth?

But since this isn't exposed anywhere I can drop this commit and we can pretend this question never came up.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

¯_(ツ)_/¯. I looked further at it and agree its innocuous.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure @id is meant to be a unique id for things in the stack, not the stack depth. Although it isn't exposed outside of this class, I'm thinking we shouldn't modify it's behavior, especially since it's not meaningful to this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

@@ -7,4 +7,16 @@ class Puppet::SSL::CertificateRevocationList::Rest < Puppet::Indirector::REST
use_server_setting(:ca_server)
use_port_setting(:ca_port)
use_srv_service(:ca)

def find(request)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would we ever execute a find via the file terminus and run into the same problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to have this guard clause because we might need to make network operations in order to configure SSL, which causes infinite recursion. With the file terminus the file is there or it's not, and we won't recurse.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 that makes sense

@MosesMendoza
Copy link
Contributor

@adrienthebo are you able to do a local acceptance run against this?

@adrienthebo
Copy link
Contributor Author

@MosesMendoza I've run the tests locally and I don't get the infinite recursion that we did last time. However I was getting a failure on the autosign command tests but that was also failing against the 4.9.4 tag, so I don't know if it's related. I'm going to investigate more and see if the failure is related or due to some precondition that another test was satisfying.

@adrienthebo
Copy link
Contributor Author

adrienthebo commented Mar 21, 2017

@branan @MosesMendoza I've been getting a lot of failures when running beaker locally, and they generally seem unrelated to the changes I've made. The autosigning failure that I've seen is perplexing but it happens on master and my branch, so I'm baffled. May we try merging this and see if it works? If nothing else the infinite recursion looks fixed.

(I'd also like to get this wrapped up before the end of the sprint tomorrow)

@MosesMendoza
Copy link
Contributor

@adrienthebo sounds good. puppet/master tests are currently red but good to merge when green.

@adrienthebo
Copy link
Contributor Author

Thank you!

@@ -7,4 +7,16 @@ class Puppet::SSL::CertificateRevocationList::Rest < Puppet::Indirector::REST
use_server_setting(:ca_server)
use_port_setting(:ca_port)
use_srv_service(:ca)

def find(request)
if request.method == :find && !Puppet::FileSystem.exist?(Puppet[:hostcrl])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the request.method == :find check redundant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching that, I originally implemented this in #network where this check was needed. When I shifted the implementation I didn't drop this check. It's gone now.

…factor-ssl-validators""

This reverts commit 01d5d51.
The poor lifecycle management of Puppet's SSL implementation can lead to
cases where trying to fetch the CRL causes us to try to fetch the CRL.
This commit makes Puppet resemble Ouroboros a bit less by specifically
disabling CRL checking when we're fetching the CRL.
@adrienthebo
Copy link
Contributor Author

@MosesMendoza it looks like the puppet master component tests are passing, can this get merged today?

@branan
Copy link
Contributor

branan commented Mar 28, 2017

Since this has a thumb from @MosesMendoza pending a green master, master is green, and I am also 👍 : I'm hitting the big green button. Nobody can stop me. NOBODY! MUAHAHAHAHAHAHAHA!

@branan branan merged commit 5671a3b into puppetlabs:master Mar 28, 2017
MosesMendoza pushed a commit that referenced this pull request Mar 31, 2017
Revert "Merge pull request #5725 from adrienthebo/revert-pup-7283"
shawnferry pushed a commit to shawnferry/puppet that referenced this pull request Jun 30, 2017
…p-7283"

This reverts commit 5671a3b, reversing
changes made to cc9465c.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants