Pro Updater: "Unknown error. Please wait 15 minutes and try again."

[raamdev]

Some users are reporting seeing the following error when using the Comet Cache Pro Updater to upgrade Comet Cache Pro:

Unknown error. Please wait 15 minutes and try again.

---

It appears this is an issue with the version of cURL on some web hosts, so not all users are affected. Manually upgrading Comet Cache Pro works around the issue for now.

[raamdev]

@jaswsinc You mentioned this CloudFlare Universal SSL issue; are you thinking that's what's causing this?

[jaswrks]

Yes, I think that could be the issue. It sounds like a cURL bug may cause this.

[jaswrks]

cURL versions < 7.36 are impacted by this. https://curl.haxx.se/changes.html

nss: allow to use ECC ciphers if NSS implements them https://bugzilla.redhat.com/1058776

See also: https://community.centminmod.com/posts/10738/

[raamdev]

@jaswsinc So do we have a resolution to this other than having everybody request that their web host upgrade the version of cURL? It seems like we could avoid this issue altogether by either a) not using CloudFlare Universal SSL, or b) setting up a separate server for the Pro updater that doesn't use CloudFlare Universal SSL.

[jaswrks]

Hmm. I hadn't given this much thought yet, but I like the idea of just moving it to another server. That's probably a better idea anyway, and it's what I was thinking for you-know-what also.

I'll come back to this over the weekend or on Monday.

[raamdev]

I believe this is related. I just installed Comet Cache Pro and Query Monitor showed that one POST by Comet Cache to https://cometcache.com failed with:

error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

The Call Stack indicates this originated in UpdateUtils.php on Line 74, which is in the maybeCheckLatestProVersion() method. This happened on the same server that I'm having trouble running the Pro Updater and where I'm getting "Unknown error. Please wait 15 minutes and try again."

[kristineds]

Also reported here, referencing internal / private ticket.

[jaswrks]

I just reviewed this again and I suggest a tag of wontfix here. While it is possible for us to try and work around this problem by exposing a version of the API that acts as a less-secure proxy to a more-secure server; that only sacrifices the SSL ciphersuite that both CloudFlare and our own configuration both use; i.e., sacrificing security for compatibility, and in this case I think that's a bad idea.

Servers running old versions of cURL that cannot support newer/stronger ciphers will be unable to connect. That's as it should be. They are transmitting account-related data to us, and if they can't do that in a secure way they should not be allowed to do it at all.

Any remote API (that uses cURL to connect to our servers) must be running cURL version 7.36 or higher, which resolves a bug that prevents newer/stronger ECC ciphers from being accepted during a handshake. cURL v7.36 was released March 26 2014. It's time to upgrade.

Another reason I suggest wontfix here, is because given the number of SSL vulnerabilities that have been exposed over the past couple years (another one just today: https://ssrg.nicta.com.au/projects/TS/cachebleed/), it is becoming more and more risky for us to run a server (of any kind) that uses older ciphers. And, in fact, there are high odds that if we went to the trouble of exposing a less-secure proxy, it could lead to other problems that we can't see from the perspective we have right now; e.g., servers refusing to connect because we are not secure enough. In other words, fixing one problem, only to acquire a new one either now or in the near future.

I am working toward updating all of our other servers as well. So this problem is from us upgrading our SSL certificate and server infrastructure. That's a good thing more than a bad thing. Unfortunately, it means older versions of cURL are going to have problems. We will need to tell site owners they should contact their hosting company and request that cURL be updated to the latest version.

[jaswrks]

A reason not to choose HostGator. http://www.remcotolsma.nl/2015/06/hostgator-curl-outdated-disappointing-support/

[jaswrks]

I reported this to HostGator techs. Awaiting a response from them.

[raamdev]

We will need to tell site owners they should contact their hosting company and request that cURL be updated to the latest version.

Then we should add messaging to the WordPress Dashboard accordingly, or even better, detect the version of cURL and hide the Pro Updater altogether with a message about why it's unavailable when cURL is outdated.

We'll need a KB Article that explains all of this too.

[raamdev]

We should also be sure to prevent the plugin updater from attempting to call maybeCheckLatestProVersion() or anything else that might result in the handshake failure mentioned above when an old version of cURL is installed.

[raamdev]

Workaround for Upgrading Comet Cache Pro

If you're currently seeing this error when trying to update Comet Cache, you'll need to do manual upgrade by deactivating and deleting Comet Cache, and then installing the latest version. See https://cometcache.com/pro-installation/

[1wdtv]

We are running Curl 7.38 and still have the same problem... Please investigate and let us know the actual required min version so we can request the same from our host?

cheers! spence

[raamdev]

@1wdtv Can you tell us what version PHP you're using? Or provide us with a link to the output of phpinfo()?

[raamdev]

@1wdtv I'm running PHP 5.5.30 with cURL v7.38.0 and the Pro Updater is working correctly for me. Could you post a screenshot of the curl section of the phpinfo() output on your server? Here's mine:

[1wdtv]

Mine is exactly the same... cURL Information shows 7.38.0

On Mon, Mar 21, 2016 at 10:03 AM Raam Dev notifications@github.com wrote:

@1wdtv https://github.com/1wdtv I'm running PHP 5.5.30 with cURL v7.38.0 and the Pro Updater is working correctly for me. Could you post a screenshot of the curl section of the phpinfo() output on your server? Here's mine:

[image: 2016-03-21_11-02-26] https://cloud.githubusercontent.com/assets/53005/13922844/840b5f7c-ef54-11e5-80a4-dc9955fdfcf3.png

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/websharks/comet-cache/issues/678#issuecomment-199328402

[jaswrks]

@1wdtv When you say exactly the same, do you mean all of the details in that area are exactly the same, or just the cURL information/version? It would be really helpful if you could post a screenshot so everyone can compare here.

[1wdtv]

Here it is:

[image: phpinfo().jpg]

On Tue, Mar 22, 2016 at 5:44 PM jaswsinc notifications@github.com wrote:

@1wdtv https://github.com/1wdtv When you say exactly the same, do you mean all of the details in that area are exactly the same, or just the cURL information/version? It would be really helpful if you could post a screenshot so everyone can compare here.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/websharks/comet-cache/issues/678#issuecomment-200065532

[raamdev]

@1wdtv GitHub does not support attachments when you reply via email. You need to drag the attachment into the comment box in your browser.

[1wdtv]

[raamdev]

So the differences are that my output has NTLMWB and TLS-SRP, which yours is missing, and my SSL Version is OpenSSL/1.0.1e while yours is OpenSSL/0.9.8b.

@jaswsinc Anything jumping out at you as a possible issue here? I thought that maybe OpenSSL/0.9.8b was vulnerable to HeartBleed, but I confirmed that it is not vulnerable. That said, it is an older version of OpenSSL, so that might still be the issue.

[1wdtv]

I'm not sure what you guys have planned here, but my suggestion is that you consider a solution that does not require "latest and greatest" hosting options.

Why?

Because our hosts have confirmed that it is a major PITA for them to reconfigure updates to curl, php, etc., and not something they are willing to do on VPS or standard reseller hosting.

Your previous version of ZenCache Pro did not require "cutting edge" hosting for something as basic as file updates... it seems obvious that you shouldn't be putting the "pinch" on users of comet cache either.

PS - what's the deal with the third name change??

[raamdev]

PS - what's the deal with the third name change??

See https://cometcache.com/blog/announcing-comet-cache-formerly-zencache/

[jaswrks]

@raamdev writes...

@jaswsinc Anything jumping out at you as a possible issue here? I thought that maybe OpenSSL/0.9.8b was vulnerable to HeartBleed, but I confirmed that it is not vulnerable. That said, it is an older version of OpenSSL, so that might still be the issue.

OpenSSL v0.9.8b jumps out at me as being the most likely issue. 0.9.8 was originally released back in 2005 and 0.9.8b was last updated in 2006. So it's about 10 years old now.

https://en.wikipedia.org/wiki/OpenSSL#Major_version_releases

---

Because our hosts have confirmed that it is a major PITA for them to reconfigure updates to curl, php, etc., and not something they are willing to do on VPS or standard reseller hosting.

Yep. It's an ongoing issue. Security and reliability vs. what is practical. While we do try to preserve back compat. in any way that we can, this is a case where security should take precedence in my view. There have been a number of SSL vulnerabilities over the past few years, and so it makes it very difficult for any popular site (e.g., any site powered by CloudFlare, Google, PayPal, Stripe, and many others) to leave support for older versions of cURL and/or OpenSSL, while still remaining secure.

In this specific case, you have a web server that is unable to connect to a site (our site) which is powered by CloudFlare. There are many sites across the web powered by CloudFlare. So resolving this problem will not only allow you to connect to our update server, but it will also make it possible for your web server to speak with other sites that also use enhanced SSL ciphers.

For this reason, I would suggest that you urge your host to reconsider and take the initiative to upgrade their software (especially security-related software) to a more modern version. Preferrably something from the last 2-3 years.

[1wdtv]

Our webhost is a smaller ISP and while they are cooperative, it requires them to take down the VPS, and reload the new configuration, with a turnaround of about two hours.

While I don't disagree with your suggestion, it seems to be an odd choice to alienate existing customers who were perfectly content with your last product version...over a feature like "automatic updates".

In other words... there does not seem to be anything about your core Comet Cache features that are in question here, only the auto-updates...and that feature does not (based on your last iteration) "require" you to move to this new method.

So "why" force it on us?

We do think you have an outstanding plugin, and recommend it to all of our users...but they are all similarly situated with a mix of older configurations.... so now they will face the same annoyance as we are facing... the broken updater notice (which cannot be dismissed any longer because there does not seem to be a way to save preferences in the new plugin so long as the updater is broken).

On Tue, Mar 22, 2016 at 10:35 PM jaswsinc notifications@github.com wrote:

@raamdev https://github.com/raamdev writes...

@jaswsinc https://github.com/jaswsinc Anything jumping out at you as a possible issue here? I thought that maybe OpenSSL/0.9.8b was vulnerable to HeartBleed, but I confirmed that it is not vulnerable. That said, it is an older version of OpenSSL, so that might still be the issue.

OpenSSL v0.9.8b jumps out at me as being the most likely issue. 0.9.8 was originally released back in 2005 and 0.9.8b was last updated in 2006. So it's about 10 years old now.

https://en.wikipedia.org/wiki/OpenSSL#Major_version_releases

Because our hosts have confirmed that it is a major PITA for them to reconfigure updates to curl, php, etc., and not something they are willing to do on VPS or standard reseller hosting.

Yep. It's an ongoing issue. Security and reliability vs. what is practical. While we do try to preserve back compat. in any way that we can, this is a case where security should take precedence in my view. There have been a number of SSL vulnerabilities over the past few years, and so it makes it very difficult for any popular site (e.g., any site powered by CloudFlare, Google, PayPal, Stripe, and many others) to leave support for older versions of cURL and/or OpenSSL, while still remaining secure.

In this specific case, you have a web server that is unable to connect to a site (our site) which is powered by CloudFlare. There are many sites across the web powered by CloudFlare. So resolving this problem will not only allow you to connect to our update server, but it will also make it possible for your web server to speak with other sites that also use enhanced SSL ciphers.

For this reason, I would suggest that you urge your host to reconsider and take the initiative to upgrade their software (especially security-related software) to a more modern version. Preferrably something from the last 2-3 years.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/websharks/comet-cache/issues/678#issuecomment-200151284

[jaswrks]

We do think you have an outstanding plugin, and recommend it to all of our users...but they are all similarly situated with a mix of older configurations.... so now they will face the same annoyance as we are

Thank you very much for saying so :-)

In other words... there does not seem to be anything about your core Comet Cache features that are in question here, only the auto-updates...and that feature does not (based on your last iteration) "require" you to move to this new method.

So "why" force it on us?

I understand. We don't want to force anyone to upgrade if it's not necessary, but this is a case where we have a username and license key being used to authenticate users against our pro database and so we want that to be secure. This change was part of security review of our website and SSL ciphersuite. Our site was recently upgraded to a more secure configuration, which now prevents older versions of cURL and perhaps older versions of OpenSSL also.

In order for us to bring back what we had, it would require us to revert back to an outdated SSL configuration and have a less secure website for all of our customers. We are still investigating all possible solutions to this issue, but I don't feel that security should be traded for compatibility with very old versions of cURL (or OpenSSL). So if we do come up with a workaround, it will need to be one that doesn't require us sacrifice strong security, such as using older SSL ciphers that are now vulnerable.

[1wdtv]

Appreciate your response ;-)

I look forward to a solution that doesn't require "state of the art" SSL for such a basic function as auto-updates.

We develop plugins/themes and provide our own auto updates without this burden, and have not found a single other author in the WP ecosystem creating a similar problem...why do you guys want to be the point of "friction?"

Love your plugin otherwise...have been recommending it at 1wd.tv "forever"... ;-)

On Tue, Mar 22, 2016 at 11:58 PM jaswsinc notifications@github.com wrote:

We do think you have an outstanding plugin, and recommend it to all of our users...but they are all similarly situated with a mix of older configurations.... so now they will face the same annoyance as we are

Thank you very much for saying so :-)

In other words... there does not seem to be anything about your core Comet Cache features that are in question here, only the auto-updates...and that feature does not (based on your last iteration) "require" you to move to this new method.

So "why" force it on us?

I understand. We don't want to force anyone to upgrade if it's not necessary, but this is a case where we have a username and license key being used to authenticate users against our pro database and so we want that to be secure. This change was part of security review of our website and SSL ciphersuite. Our site was recently upgraded to a more secure configuration, which now prevents older versions of cURL and perhaps older versions of OpenSSL also.

In order for us to bring back what we had, it would require us to revert back to an outdated SSL configuration and have a less secure website for all of our customers. We are still investigating all possible solutions to this issue, but I don't feel that security should be traded for compatibility with very old versions of cURL (or OpenSSL). So if we do come up with a workaround, it will need to be one that doesn't require us sacrifice strong security, such as using older SSL ciphers that are now vulnerable.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/websharks/comet-cache/issues/678#issuecomment-200182133

[raamdev]

For the record, I agree with @1wdtv that the update server should be more flexible.

The built-in Pro Updater is a feature that we provide to Pro users because Pro software cannot use the WordPress update servers. We provide this feature to avoid needing to manually update the software whenever a new version is available. (And we can make it even easier by adding automatic Pro updates.)

If updating the software is more difficult and more 'expensive' time-wise, it will not be done as frequently, which means more sites running older, outdated versions of the Pro software. That makes the web as a whole less secure, because we made it more difficult to keep our software up-to-date.

From the perspective of our servers, the security argument is, IMO, not a strong argument. What are we protecting against by requiring more recent SSL? Somebody sniffing the traffic and gaining access to a Pro license key? What could they do with that? Update the software?

It's not like we're running a bank API here, or something else that might be connecting to and transmitting sensitive data. The Pro software codebase is open-source. If somebody really wanted a free copy of the software, there are plenty of ways to get it.

So my vote goes to making our update server more flexible. One option might even be to have a second 'fallback' server running that Comet Cache can try connecting to if the connection to the first server fails. That fallback server could simply mirror the zip files from the primary server so that we don't need to worry about trying to publish updates to two servers.

[1wdtv]

Thanks @raamdev

I'm not trying to beat a dead horse, but you summed up my feelings well.

Since we "do" offer the very same solution (our LabPages plugin and Child Theme), we went back and forth on how to handle updates, and finally just settled on using Pippin's very simple and handy script for doing the same using our own servers (not WordPress). Done and Done.

It took us about six minutes to setup, and has worked flawlessly since...on ANY server.

It does strike me as counter-productive (on top of the already "unreal" name changes and reinstall of the core product) to now force me (and all our students whom we recommend your plugin) to ask our ISP's to do a painful (read: take server offline) update...just to use YOUR plugin (when not ONE OTHER author in WP world is requiring the same).

If you've been following the YOAST SEO "drama"... I think you would agree... taking a beloved plugin and (cough cough) "screwing it up royally at the expense of your existing fans" ... is not great for business.

[jaswrks]

@raamdev writes...

From the perspective of our servers, the security argument is, IMO, not a strong argument.

I respectfully disagree that it's not a strong argument. Any argument in favor of security over compatibility is a strong argument IMO, especially when the argument that I'm making is about compatibility with an SSL library that is 10 years old (or even 2 years old, which is ancient in the world of security these days). In short, I don't feel any obligation to remain compatible with a library that is that outdated, and my general feeling is that sacrificing security is a bad idea.

What are we protecting against by requiring more recent SSL? Somebody sniffing the traffic and gaining access to a Pro license key? What could they do with that? Update the software?

A public thread is probably the wrong place to discuss this. I will say though, that most of us working on Comet Cache have been around long enough to have experienced the pitfalls associated with sacrificing security for compatibility. Things are never as simple as they seem on the surface, especially when it comes to security-related protocols. By the time we finish discussing this, there will probably be another security-related concern that we need to address in one form or another; e.g., PCI compliance scans, forward compatibility, bugs, etc. For us to move backward in an effort to remain compatible with much older libraries—that is counterproductive in my view.

Don't get me wrong, I'm all for making things easy to work with; just not at the expense of sacrificing security. Time-management is a factor also. For instance, spending time to address compatibility issues with very old libraries; like the time it would take to setup a fallback server for the purpose of providing back compat. for outdated libraries, and ultimately needing to maintain that server. That's time that could be used to improve the software and/or add features being requested.

Whenever I work on Comet Cache, one of my primary objectives is to move the project forward, and I feel that the majority of our userbase would like us (expect us) to move the project forward. Making the update server more secure, while not ideal in this specific case, is another move in a forward direction. Does that require some folks to upgrade? Yes, that is the harsh reality. However, when you stop for a moment and consider the benefits associated with this it is clearly the right decision in my view.

As a quick example, consider that any site running very old versions of cURL or OpenSSL are going to have problems connecting to other sites across the web (or even their own site). Why? Because Comet Cache is not alone in the world of forward momentum. Some of the biggest sites on the web have the exact same requirements that our update server has. If you can't connect to our server, you can't connect to theirs either (or your own server, if you're keeping it up-to-date). Moving forward, this will only gain more and more momentum, making the upgrade more and more necessary for you to do. Our update server is not cutting-edge; i.e., the requirement is simply a version of cURL + OpenSSL that was last updated at some point in the last couple of years.

@raamdev writes...

So my vote goes to making our update server more flexible. One option might even be to have a second 'fallback' server running that Comet Cache can try connecting to if the connection to the first server fails. That fallback server could simply mirror the zip files from the primary server so that we don't need to worry about trying to publish updates to two servers.

I'm not totally against this. I remember suggesting that myself also, but then I thought about it again and I remember feeling like it was not a good use of time. In short, I'm still on the fence with this in some respects. It will require time to set that up and test it though, and it will sacrifice security in some respects, which I am against, so if we do it I would like to find a way that will not sacrifice security. That is Raam's call to make, as he is the lead on Comet Cache.

[jaswrks]

@1wdtv writes...

Our webhost is a smaller ISP and while they are cooperative, it requires them to take down the VPS, and reload the new configuration, with a turnaround of about two hours.

Are you planning to do that? It sounds like an excellent idea to me, but I'm curious to know, given the discussion above, if you are planning to upgrade or leave the old libraries as-is?

[1wdtv]

@jaswsinc - As they say "your ball, your decision whether to play with the other kids or go home".

I can't see the logic in creating "work" for your loyal subscribers over an issue that really has nothing to do with your core product function (which I recall is "caching", not "updating")...but it's your decision. We can only vote with our wallet the next time we decide whether to renew our subscription.

Here is what our ISP said in response to a request to upgrade. It wasn't "no" but it wasn't "ok" either...it was more like "yeah, we'll get to it when we can cause it's not really a priority". To me this reads as "more work for me to deal with"...especially the downtime part.

I'm pretty sure one would have even less responsiveness from an ISP like HostGator where you don't get right to the top of the management as we can with MDD.

Hello Spencer,

The CURL version is the latest that your VPS operating system supports. To have the latest version from the author we would need to.

1. Back up all of his accounts.
2. Take the current server offline.
3. Build a new VPS with the latest OS.
4. Restore the accounts to the new server.

This process should take around 2 hours however it could be much longer if a unexpected problem arises.

We will be upgrading the operating systems on the VPS platform soon, once their migrations are complete. I do not have a current ETA on this.

Thank you,

Tim M. MDDHosting - Professional Hosting http://www.mddhosting.com/

[jaswrks]

As they say "your ball, your decision whether to play with the other kids or go home".

I hear ya. I don't take a decision like this lightly either. Actually, it's not my decision to make, it is Raam's. I'm just trying to voice my opinion on the matter here, because I feel strongly about this.

Here is what our ISP said in response to a request to upgrade. It wasn't "no" but it wasn't "ok" either...it was more like "yeah, we'll get to it when we can cause it's not really a priority". To me this reads as "more work for me to deal with"...especially the downtime part.

I see. Thanks! :-) I'm going to send them a letter myself, as I did with HostGator also. I consider the argument that this is not a priority to be the weak one. Aside from millions of other sites, we can simply ask them to look at CloudFlare's 2,000,000+ customers. By not upgrading, they are willing to run servers that simply cannot speak to these over SSL; and it's worth noting that this company represents some of the biggest players on the web. https://www.cloudflare.com/customers/

If it's not a priority, it should be, in my view. If not for forward compatibility, for security.

[jaswrks]

Dialogue w/ HostGator thus far. I was away on vacation for two weeks shortly after I contacted them, so the conversation moved more slowly than I had hoped. Hopefully we are making some progress though.

[1wdtv]

Good Luck Don Quixote!

I'm sure you'll have no trouble convincing a company that makes tens or hundreds of millions of dollars a year to change all their servers for your one cache plugin ;-)

On Thu, Mar 24, 2016 at 12:34 AM jaswsinc notifications@github.com wrote:

Dialog w/ HostGator thus far. I was away on vacation for two weeks shortly after I contacted them, so the conversation moved more slowly than I had hoped. Hopefully we are making some progress though.

[image: 2016-03-23_21-30-56] https://cloud.githubusercontent.com/assets/1563559/14009225/b2a61c1e-f13e-11e5-824e-8babd57abd79.png?v=2

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/websharks/comet-cache/issues/678#issuecomment-200678642

[jaswrks]

@1wdtv writes...

one cache plugin ;-)

That comment you just made suggests that you don't understand the issue. It's not just our plugin, this is an issue that HostGator and MDDHosting both need to be made aware of. It impacts you, us, and many other site owners and services across the web.

[1wdtv]

Jaswinc i'm in the EXACT same business as you.... and I've been doing it since 2006, and have had some very high profile public "debate" on these very points... (feel free to google my name)

What I think you don't realize, is that all your points about security and how awesome CloudFlare may be.... fall on DEAF EARS by all the other providers in the ecosystem who (honestly) DON'T GIVE A DARN about your point.

Why? Because it's NOT their problem. AND IT'S NOT PROFITABLE TO FIX RIGHT NOW.

So...you're spending all this time and energy on trying to shove a round peg into a square hole, when you NEED everyone ELSE to agree to take a round peg into their holes...and you should (if you think about it) realize.... no one wants you to shove any pegs into their holes.

Take a breath...realize you have an AWESOME plugin...then stop trying to UPSET YOUR PAYING CUSTOMERS with this diversion...it's a waste of everyone's time, and reflects badly on your real product (because your otherwise "working" plugin is now "not working"...)

Read up on what YOAST did recently, and how it's caused a real backlash in their business.... and decide if it's really worth your "idealism" about SSL in a situation where SSL really isn't important (for simply updates).

Either way...love your plugin...but man, you respond like a pure developer mindset and not at all like a businessperson or marketer ;-(

On Thu, Mar 24, 2016 at 12:52 AM jaswsinc notifications@github.com wrote:

@1wdtv https://github.com/1wdtv writes...

one cache plugin ;-)

That comment you just made suggests that you don't understand the issue. It's not just our plugin, this is an issue that HostGator and MDDHosting both need to be made aware of. It impacts you, us, and many other site owners and services across the web.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/websharks/comet-cache/issues/678#issuecomment-200684825

[jaswrks]

So...you're spending all this time and energy on trying to shove a round peg into a square hole, when you NEED everyone ELSE to agree to take a round peg into their holes...and you should (if you think about it) realize.... no one wants you to shove any pegs into their holes.

I have given it serious thought, and I have the opinion that I have for the reasons I have stated. I'm not expecting those companies to change though. I agree on your points about that. They either will or they won't. However, that doesn't change the situation here. It is they who need to upgrade, and if folks like us don't bring that to their attention (whether they respond or not), then it will continue to be an issue moving forward; i.e., until they feel it is worth their time. Like us, hosting companies sometimes need a little nudge from the developers building applications that run on their platform.

So regardless of what decision is made here, I think HostGator and MDDHosting both should be contacted and made aware of this concern. I don't spend a lot of time doing that :-) It's easy.

Either way...love your plugin...but man, you respond like a pure developer mindset and not at all like a businessperson or marketer ;-(

I wear lots of hats. Wrong or right, that's how I feel about it.

[1wdtv]

Your feelings are your right... but it would be a shame to alienate your paying customers over a principal or your "feelings" if that really had no practical effect on your products main purpose for existing (which is caching, not updating).

Have a good evening ;-)

[phoenixMag00]

Here are my thoughts on this since I'm in the same boat as a few you guys on this thread. We use MediaTemple DVs that run CentOS. The latest supported version of cURL that CentOS uses is an older version. Could we try to update cURL to the latest and greatest even though it's not officially supported? Sure, but there is just too much risk and time involved for saving ~$200.

So we had to make a business decision and that was to move to another caching plugin since we promise our clients that we update sites on a daily basis. It's part of our hosting plan. And manually updating +50 sites just isn't a good use of potential billable time.

I still think Comet Cache is a great product and I used and loved it for over 5 years. But sometimes you have to part ways for business reasons. 100% nothing personal. I wish you guys the best of luck and maybe our paths will cross again. I also admire your commitment to taking the secure route over the easier route.

However, my big concern would be people not knowing their updater isn't working. I had no idea that I was a couple of versions behind because I didn't see that wonderful huge nagbar notifying me there was an update. So although this appears to only be happening to a small percentage of Comet Cache users, that might not really be the case.

Users might not even know their updater is broken. That would be my big concern right now.

You might want to take a step back and try to get the large picture of the situation. You should really consider notify users by email to check their updater and make sure it's connecting. I mean, it might be a very small percentage of users, it could also be a large percentage.

[jaswrks]

@phoenixMag00 Thanks for sharing your thoughts about this and your experience,

You might want to take a step back and try to get the large picture of the situation. You should really consider notify users by email to check their updater and make sure it's connecting. I mean, it might be a very small percentage of users, it could also be a large percentage.

I agree with that. At the very least, we do want to make this more apparent and try to offer some explanation so that site owners are made aware of this issue.

A decision about how to proceed with this has not been made yet, but if it does come down to us enforcing a higher standard for security over compatibility, then I agree that we need to provide clearer instructions about how to complete a manual upgrade by logging into your Comet Cache account and obtaining the latest version, as opposed to relying on an automatic upgrade that doesn't work due to WordPress running on an outdated hosting platform. Comet Cache should be able to detect that and provide an alternative. Based on Raam's prior comments, I think he agrees with that as well.

[jaswrks]

Noting that Raam is currently away from the office. He may not respond immediately here for that reason, but I feel certain that he will be back to review this carefully soon.

[jaswrks]

Noting that this issue also exists on a few servers at InMotion hosting. I contacted them on behalf of a client and they informed me that cURL is in fact outdated on some of their older servers, but not on their newer servers. They have been working to upgrade all of their clients. If you contact them about the issue they are happy to expedite the upgrade for you.

The issue being a lack of support for TLS v1.2.

[raamdev]

As Jason noted, I've been on vacation for the past few days, but I'm starting to catch up now.

I think it's important to remember what we're discussing here. I'm all for increased security and for requiring that servers be running newer, more secure versions of software. But what we're talking about here is updating Comet Cache Pro. That is the core thing we are addressing in this GitHub Issue.

How can we allow existing Comet Cache Pro users to easily update Comet Cache Pro?

If we want to eventually require more up-to-date versions of cURL, we need to have a plan in place for announcing that requirement over time to site owners who are running outdated versions of cURL, so that site owners have the opportunity to ask their web hosts to upgrade. In the meantime, we need to provide a fallback, an alternative method that allows site owners to continue being able to update Comet Cache Pro using the Pro Updater. My vote for how we do that is to set up a secondary update server that allows connections from older versions of cURL.

In my mind this is simply a matter of maintaining software with a large userbase. Imagine if WordPress updates suddenly stopped working on 50%+ of hosting servers out there. We have an existing userbase that we need to consider. That existing userbase is not comprised of only developers, or people who can easily turn off the server, upgrade, and then turn it back on.

[1wdtv]

Whew....common sense (finally) prevails :-) Good to have you back. Can't wait till this is implemented so we can fix all our broken sites. On Fri, Mar 25, 2016 at 9:38 AM Raam Dev notifications@github.com wrote:

As Jason noted, I've been on vacation for the past few days, but I'm starting to catch up now.

I think it's important to remember what we're discussing here. I'm all for increased security and for requiring that servers be running newer, more secure versions of software. But what we're talking about here is updating Comet Cache Pro. That is the core thing we are addressing in this GitHub Issue.

How can we allow existing Comet Cache Pro users to easily update Comet Cache Pro?

If we want to eventually require more up-to-date versions of cURL, we need to have a plan in place for announcing that requirement over time to site owners who are running outdated versions of cURL, so that site owners have the opportunity to ask their web hosts to upgrade. In the meantime, we need to provide a fallback, an alternative method that allows site owners to continue being able to update Comet Cache Pro using the Pro Updater. My vote for how we do that is to set up a secondary update server that allows connections from older versions of cURL.

In my mind this is simply a matter of maintaining software with a large userbase. Imagine if WordPress updates suddenly stopped working on 50%+ of hosting servers out there. We have an existing userbase that we need to consider. That existing userbase is not comprised of only developers, or people who can easily turn off the server, upgrade, and then turn it back on.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/websharks/comet-cache/issues/678#issuecomment-201316589

[jaswrks]

Last response from HostGator. I will reply back to clarify for them, because forcing the SSL version is not enough in those older versions of cURL. Basic TLS support is possible, but older versions of cURL contain a bug which prevents them from speaking to sites that use more modern ciphers.

HostGator response...

Hello,

Thank you for contacting Hostgator support. The version of curl we run on our Shared and Reseller farms are managed by the operating system itself- which has been maintained, but not updated to the most current version. The current version of curl we are running does in fact support TLS 1.2, which is what the plugins, CMSes, and etc are looking for.

Red Hat is planning on launching it’s new version of curl in April or May.

We believe that by editing said plugins to include the following (note: this would be development which is not directly in the scope of our support), that the plugins should work perfectly fine with our version of curl as it is now:

curl_setopt ($setuploginurl, CURLOPT_SSLVERSION, 6);

If you have any additional questions please feel free to contact us anytime, we will be happy to assist you.

Sincerely,

Paul C. Linux Systems Administrator

It's also worth noting that "by the operating system itself" is not an excuse. It's common for Linux distros to contain outdated libraries. Hosting companies putting together a widely-used platform are expected to update those older libraries to more recent versions before they make them available for public consumption. On RedHat, that's as simple as running a one-liner to update cURL.

Granted, it might be more complex than this at HostGator where I'm sure there are many other factors to consider (that's something only they would know), but it doesn't change the fact that there is a need for a newer version of cURL. That older version contains a bug which greatly limits the functionality in today's web.

[jaswrks]

Also reported here. Private/internal ticket: https://websharks.zendesk.com/agent/tickets/12001

[raamdev]

It's also worth noting that "by the operating system itself" is not an excuse.

It's important to keep in mind how web hosting companies operate.

Many web hosting companies are simply too small to maintain all aspects of a hosting environment. That's why companies like WHM/cPanel exist. They provide a platform for web hosting companies to run on, to make it possible to run a web hosting business. The web hosting company then relies on those 3rd parties (e.g., WHM/cPanel) to manage things like security fixes, software versions, etc., allowing the web hosting company to rest assured that whenever a new major version comes out they can feel confident that it's not going to break thousands of web sites (and cause all sorts of legal issues for the hosting company). WHM/cPanel integrates very tightly with specific OSs and specific OS versions. You can't simply update the entire OS version without updating WHM/cPanel as well.

The same can be said about the OS that many web hosting companies run. For example, a single shared server that hosts thousands of websites may be running CentOS 6. Upgrading the entire OS and affecting thousands of websites is not something that is taken lightly and such an event requires planning, time, testing, etc.

Now imagine a hosting company that has a hundred such servers, comprising tens of thousands of websites that must remain online (with no idea what exactly 'online' means or what the site is actually running) and you can start to see why many (most?) web hosting companies choose to install security-related patches as necessary, and as provided by the OS developers, as opposed to upgrading the entire OS and all the software on it (this is the difference between "maintained" and "not updated to the most recent version" in HostGator's last reply).

The point is, it's simply not realistic to assume that every web hosting company has the ability to run a few commands and update the version of cURL. cURL is just one tiny package that's part of a much greater ecosystem.

We cannot and should not cause our (Comet Cache Pro) users pain just because many web hosting companies are too big to handle upgrading the OS on all their servers overnight. We need to consider the reality here and the reality is that we need to allow access to updates of our software from servers running older versions of cURL.

[1wdtv]

Indeed @raamdev

So, as a pro user who has had this "pain" for two weeks or so and:

1) Sees a mislabeled update that is called "zen-cache" though my "comet-cache" keeps notifying me to update to it

2) Cannot update to it even manually, because it's "zen-cache" even though my latest "comet-cache" keeps annoying me daily when I log in

3) Cannot turn off the annoying update notice, because it won't "save" this change because this bug broke my ability to save my "update and display" preferences

4) Has a persistent console error "failed to parse source map" (see attached image) as well, in my primary business site

.... how LONG WILL WE HAVE TO BE IN PAIN?

I honestly find this entire line of conversation "maddening" given that your product was FREAKING AMAZING up until now.

Now, I feel like you have gone "Microsoft does Skype" or "Evernote does Skitch"...and taken what was nearly "perfect" and decided to start chasing "windmills" that have ABSOLUTELY NOTHING TO DO WITH YOUR PRODUCT or A CUSTOMER'S USE OF YOUR PRODUCT ... at the EXPENSE OF CUSTOMER PAIN.

Not nice. Imho, not good business.

Without further drama...please tell me how we can either revert back to Zen Cache, fix this "immediately" or something else...because I honestly feel this is your "jump the shark" moment. As one who informs tens of thousands of other WP users what products to use... this is obviously quite important to me that I have faith in the developers of a product. This is your moment to shine.

Regards, spence