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 [email protected] 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
#678 (comment)

[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]

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 [email protected] 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
#678 (comment)

[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 [email protected] 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
#678 (comment)

[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

[raamdev]

@1wdtv writes...

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

That's a known bug (see #727), which has been fixed and will go out with the next release, which is scheduled to happen within the next week.

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

Yes, that is annoying. We'll be fixing that soon. See #681.

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

I'm not able to reproduce that at all. Have you tried clearing your browser cache?

---

@jaswsinc and I have settled our differences in a private chat. I'll provide another update here soon on how we're moving forward with this specific issue.

[1wdtv]

thank you for responding to those, and (cough cough cough)... yes, I think
I know how to "clear my cache" by now...given that I'm responding to the
authors of "XYZ-Cache" ... lol ;-)

It's an error in your plugin, that only shows on the update administrative
page where the "new" plugin is installed (try there).

I await your (hopefully) prompt solution to the most important problem...

thanks Raam

On Tue, Apr 5, 2016 at 1:03 PM Raam Dev [email protected] wrote:

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

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

That's a known bug (see #727
#727), which has been
fixed and will go out with the next release, which is scheduled to happen
within the next week.

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

Yes, that is annoying. We'll be fixing that soon.

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

I'm not able to reproduce that at all. Have you tried clearing your

browser cache?

@jaswsinc https://github.com/jaswsinc and I have settled our
differences in a private chat. I'll provide another update here soon on how
we're moving forward with this specific issue.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#678 (comment)

[raamdev]

@1wdtv writes...

It's an error in your plugin, that only shows on the update administrative
page where the "new" plugin is installed (try there).

It's not an error. It's a warning about being unable to parse the SourceMap, which is not required to run Comet Cache. I've opened a GitHub issue with details; see #732.

yes, I think
I know how to "clear my cache" by now...given that I'm responding to the
authors of "XYZ-Cache" ... lol ;-)

I wasn't referring to the page cache (which is what Comet Cache generates); I was referring to your local browser cache, which is what your browser generates. It's a separate cache that is not controlled by Comet Cache. In any case, given what I described in #732, your browser cache is likely not the issue--it's most likely the browser setting I described in #732.

[Reedyseth]

@raamdev Unfortunately I just migrated my site to HostGator, the odd thing is that I was able to upgrade ZenCache and s2Member using the automatic update but not Comet Cache, the curl version is 7.12.1, much much older that the one mentioned here. So for now my only SSL issue is with Comet Cache.

[raamdev]

Next Release Changelog:

• Bug Fix (Pro): Fixed a bug with the Pro Plugin Updater that resulted in "Unknown error. Please wait 15 minutes and try again." when attempting to update Comet Cache Pro. The issue affected sites on servers running an old version of cURL (< v7.36) and/or an old version of OpenSSL, which made them unable to connect to the Comet Cache Pro update server. The Pro Plugin Updater now attempts to connect to a secondary update server that is more compatible with older versions of cURL and OpenSSL. See Issue #678.

[1wdtv]

I'm sorry... did I miss something? IS there an update somewhere? I cannot find it here or on your site.

[raamdev]

The release candidate (v160412-RC) has been released and includes the fix for this issue. I'll be doing an official release within the next 24 hours.

[raamdev]

Comet Cache v160416 has been released and includes changes from this GitHub Issue. See the v160416 announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#678).