Types Plugins Temporarily Removed from the WPORG Repo, Back on Monday

   Amir

Announcements

November 5, 2016
43

Yesterday night (Friday, midnight here), we got a message from the WPORG repo maintainers that we need to address something in Types. In parallel with sending us this courtesy message, Types was removed from the repo and not available for download.

Update Nov/7/2016: Types 2.2.3 is now available again from our own site. To get it, log in to your Toolset account and click on Downloads. We sent everything needed to the WPORG repo managers and are awaiting their feedback, so that Types becomes available there too. Everyone with Toolset accounts has access to Types right now. If you need an account to download Types, you can register for free.

Of course that we’re going to address that issue and update Types. As a lesson from this incident, we will start offering Types for download directly from wp-types.com. We cannot do this today and tomorrow (Sunday) because everyone is off here. We’ll make that change first thing Monday morning.

I’m very sorry for this inconvenience. Obviously, this is a problem for all our clients, for Types-users and for Toolset team. We already have folks working on it during the weekend and will have an update on Monday.

In the meanwhile, we hope that everyone is having a good weekend and that this doesn’t ruin it for you.

 

Comments 43 Responses

  1. Hi,

    Anything that we should be concerned from this removal and when wp-types will be available again in WPORG Repo.

    Jone

    • Not really. The WordPress repo folks have reported a technical issue to us, which we should handle. Of course we’re handling it. We were a little surprised that at the same moment of reporting to us, they also took down the downloads page. It’s their policy. We already fixed the reported issue, but now the repo folks are on their weekend. Anyway, on Monday morning, we’re moving Types download to wp-types.com, so that this sort of service interruption will not repeat.

    • Thanks. This entire thing caught us by complete surprise. Of course we’re doing our best to respond quickly to reported issues, but who is supposed to debug code on Friday midnight? Our developers already worked on the reported issue on Saturday and committed the changes requested. From next week, downloads will come from wp-types.com.

  3. always best to keep the control in your own hands. The worry I have about the setup with WordPress.org is they decide when to drop you and then you can not get your fix out till they decide to check it.
    Is there anywhere we can get the fixed version?
    a lifetime member

  4. What a bad timing… removing it directly after notifying… with the weekend ahead.

    Thanks for the info and solution offering it from here Toolset website also.

    Herre

  5. May I ask what the technical problem was?

    I have issues with siteground.com hosting when I switch a site to PHP 7, some of these issues seams to originate from the types plugin..

    Fatal error: Uncaught Error: Class ” not found in /wp-content/plugins/types/application/controllers/admin.php:36
    Stack trace:
    #0 /wp-content/plugins/types/application/controllers/admin.php(24): Types_Admin->on_init()
    #1 /wp-content/plugins/types/application/controllers/admin.php(19): Types_Admin->__construct()
    #2 /wp-content/plugins/types/application/controllers/main.php(50): Types_Admin::initialize()
    #3 /wp-includes/plugin.php(524): Types_Main->on_init(”)
    #4 /wp-settings.php(411): do_action(‘init’)
    #5 /wp-config.php(86): require_once(‘/home/constr62/…’)
    #6 /wp-load.php(39): require_once(‘/home/constr62/…’)
    #7 /wp-admin/admin.php(31): require_once(‘/home/constr62/…’)
    #8 /wp-admin/plugins.php(10): require_once(‘/home/constr62/…’)
    #9 {main} thrown in /wp-content/plugins/types/application/controllers/admin.php on line 36

    Could this be related to the reason why the plugin was pulled from WPORG?

    • The issue that you’ve reported is unrelated to what triggered the folks in the WPORG repo. We also use PHP7 on all our sites and we run full tests with PHP7 before releasing new versions. We can debug what you’re reporting. Can you create a ticket in our support forum for that? Our supporters will likely need a backup of your site, so they can run it through a debugger and see what’s happening.

      • Just to confirm – I use Toolset with PHP7 – also with HHVM (Hack) – and have no problems at all.

        SiteGround use their own caching system, etc. It’s possible it needs a hard flush or they’ve configured something unique.

  6. Hi,

    Will Types still be available for download in the WP Repo (after everything is sorted out).

    What I’m asking, is if you will make Types available on your own site as a backup/alternative download source, as well as keeping it in the wporg repo?

    One of the main benefits of the strict policy of wporg, is that if something is reported to them then they take immediate action to remove the plugin until the issue is resolved.

    It might be inconvenient for some, embarrassing for the developer, but ultimately it is good for the user.

    If an issue is reported to a private repo admin, then they can choose how and when to deal with it, meaning we may never hear about it. (not saying you would do this, just pointing out a concern).

    Personally i like having the safety net of a very large public repo, because if there is a major issue with a plugin, then word gets around much faster, while private and premium plugin issues we may know nothing about a problem until it is too late.

    • Going forward, we’re going to consider our own site as the primary download location and the WPORG repo an optional alternative.

      I’m not going into an argument about the WordPress.org policies. However, I don’t see them enforced in a consistent way. We all apply security updates for WordPress, Apache, Linux, etc. Of course, there are security exploits reported for every popular software on a regular basis. I haven’t seen any case where the WordPress team decided to take down their own downloads page until a security report is handled.

      BTW, the security team will take down a plugin when there’s a report and something looks suspicious, not even when it’s confirmed.

      In the past, we’ve dealt with serious security issues without drama. There are very simple ways for people to contact us, so I’m not worried about security issues discovered and not handled.

      Our responsibility spans functionality, security, performance, compatibility, stability, usability, design and everything that Web software needs to cover. We appreciate the help of the repo team very much, but we are the ones responsible for the service our clients get.

      • Hi Amir,

        Great, thanks very much for the additional detail, it definitely helps set my own mind more at ease, and was just the reassurance I was looking for.

  8. Hello,

    Thanks for the update.

    Was there a security issue?
    I have found 2 cases where sites using Types + Layouts have been hacked (generally by adding content to a page or a post).

    Regards
    Pat

    • This is a security update. If you know of even think that sites got hacked, please let us know about this ASAP. I want to make sure that there’s no exploit that we’re not aware of. I’ll send you an email, so you can reply privately.

      • Hi Amir,
        How can I send you needed info?
        DO you have private message ?
        I have a Toolset account if needed.
        Regards
        Pat

        • I sent you an email about 10 minutes ago. It might be hiding in your SPAM. You can write to me at amir (dot) helzer (at) onthegosystems.com.

  9. Hi Amir,

    It is too bad that it could not have been resolved without removing the plugin from the repository, but stuff like this happens and I guess the best thing to do is to look at it philosophically. Thank you for taking quick action to fix any issues.

    Regards,

    David

  11. I’m sorry, I didn’t get any newsletter regarding this issue from OnTheGoSystems so far.

    Amir, can you please make clear: is this a security issue or not?
    So is it necessary to take immediate action and update to 2.2.3 as quickly as possible?

    If so, the title of this post should clearly be “types plugin: update to version 2.2.3 from wp-types.com due to serious security issue”.

    If not, you should clearly state it that is only a minor technical problem (but what would that be so the Worpress.org team decided to immediately remove your plugin from their site?) that we as your (often) paying customers don’t need to care of.

    Also, looking at https://toolset.com/download/toolset-types/#changelog, there isn’t any valuable information on version 2.2.3 that enables me to decide whether it’s necessary to install the update or not. Why is it so difficult to clearly state what has happened and why?

    Thanks for the clarification!

    Best regards,
    Stefan

    • Types 2.2.3 includes a patch for a security issue, which happens in a very specific case (not for all sites). It’s a good idea to update to this version.

      • Ok thanks for quick response, so please provide us with details! (at least in form of a proper changelog for you registered customers)

        What are the conditions that must be fulfilled for this security issue and what about the possible risks?

        Our company has a lot of work todo (= time & money!) to update your plugins to recent versions (nearly impossible to do without a precise changelog) – so we must decide whether we are affected by this issue or not or what would be the possible consequences if we decide to not immediately update it.

        It’s so sad that we have to bother you to provide details, instead of OnThe GoSystems clearly communicating these in the first place.

        I think (as you stated above) it is common sense today that EVERY software potentially has security issues, so we’re not going to blame you, but it is absolutely needed to transparently communicate it in the first place so all affected customers can decide what to do.

        I think it’s in your company’s interest to make clear your plugin hasn’t been kicked of wordpress.org repo because you didn’t responsively respond to a security issue as it can be expected by the users of your software -> it’s all about trust, isn’t it?

        • We updated our sites, so this security exploit doesn’t apply to us anymore, but I’m sure that there are many sites that didn’t get updated. If we describe here the exact conditions and how to exploit it, this would compromise the security of everyone else. When fixing security issues, it’s a bad idea to explain the exploit. I’m sure that you updated your own sites already. But you wouldn’t want to have your exploited because we explained too early how to do it. Right?

          When WordPress and other problems have security patches, they would never explain how to exploit them. They would say that there is a security issue and you should update. Sometimes, people publish how to exploit holes. I think that this is very irresponsible and is made only to promote the ego of the person reporting. It only harms people who didn’t yet manage to update.

          Next year, when we’re sure that everyone already updated (and trust me, some will still not), we can explain it in more details. Right now, it’s only to cause damage.

          • You didn’t get me right. I’m not asking to explain the exploit, I’m asking for details about the conditions that must be met for the exploit to be possible.

            So e.g., is your plugin exploitable only by registered wordpress users, does it affect the frontend, the backend, both? Or can it be exploited by anonymous users without valid logins on our sites?
            And what are the possible consequences? XSS, reflected XSS, remote code execution? Do you consider it’s severity low, medium, high?

            I think that are really standard details we need to know. Simply stating “we updated our own sites so we aren’t vulnerable anymore” and “just update all your sites NOW” is not very helpful. If I simply update your plugin to recent version, I surely will have broken sites and am loosing money and customer satisfaction.

            Please think about improving your communication & security policies, I’m sure most professionals would agreee that transparency is the only way to go here.

            It would be nice if you would also publish our subsequent comments on this issue, so maybe there is a chance for other customers to participate in this (important) discussion.

            Thanks,
            Stefan

            • Stefan – In all fairness to Amir, your question was, “What are the conditions that must be fulfilled for this security issue …?” I understood that just as Amir did – to expain what the exploit details were, not as you clarified in your third post here as affecting front-end, back-end, registered WP users (not even sure what you meant by that) etc. I think, under the circumstances of Wp.org surprising OTGS with this at the “midnight hour” (literally) on a weekend, Amir and company have done a pretty good job at fixing the problem and making the Types download available from wp-types.com, while awaiting for WP.org to approve the update.

              My bigger concern here is really what criteria WP.org might be using to immediately bump a plugin off the repos. Do they have a sort of rating/grading system or is it up to one person to make that decision. For instance, how many people have reported the security issue? How many steps are required for the issue to occur? What is the likelihood the issue will cause a catastrophic outbreak over the next 2 days (weekend) versus giving the developer a chance to fix it during business hours? Unless this exploit was truly deemed a “10” for vulnerability, the quick measure to remove Types seems like a quick and happy trigger. Most repos I know with and deal with always attempt to work with the dev first.

              Jeff
              ——-

            • None of us here understand the logic behind this policy. Once an exploit it known, the best thing to do is fix it and update all sites using the software. By blocking us from releasing the update on wporg, how does this serve to improve the security of everyone running the plugin? The only way for us to notify users is via a channel that’s now blocked.

              Our own sites are updated, but most of our users don’t even know that they are insecure and need an update. I just don’t get it.

        • There’s some deeper politics going on in wp org. A lot of agendas, egos and views that conflict logic. Some are opposed to anything resembling a “framework” (which has a seemingly flexible definition according to who’s speaking.) Others have commercial aspects in their sites. Some just seem to have missed eating their Cornflakes in the morning.

    • Right.

      Types just got reinstated in WPORG, but they told us that “some meta data may be out of sync”. We didn’t manage to completely understand this, so I don’t know what new issues this is causing for automatic updates. I suggest that you do this:

      1. Disable Types (no data will be lost, guaranteed)
      2. Delete the plugin folder manually
      3. Download the current version and activate again

      I’m very sorry for this mess. We had no idea that it’s coming and we’re trying our best to even understand what the repo is sending now.

      You can probably imagine that we’re not entirely happy with this situation. Going forward, we’re going to make sure that there is no dependency on the WPORG repo for plugin installs or updates. This will happen in the next major release of Types.

  13. Hi!

    I’m trying to reinstall Types in WP, and the installation fails, “It says that the folder already exists”. do you know how I can solve this?

    • Types just got reinstated in WPORG, but they told us that “some meta data may be out of sync”. We didn’t manage to completely understand this, so I don’t know what new issues this is causing for automatic updates. I suggest that you do this:

      1. Disable Types (no data will be lost, guaranteed)
      2. Delete the plugin folder manually
      3. Download the current version and activate again

      I’m very sorry for this mess. We had no idea that it’s coming and we’re trying our best to even understand what the repo is sending now.

      You can probably imagine that we’re not entirely happy with this situation. Going forward, we’re going to make sure that there is no dependency on the WPORG repo for plugin installs or updates. This will happen in the next major release of Types.

  14. Sorry guys, I didn’t want to blame anyone here doing his/her best to solve problems and help the customers.

    But to make it clear again: as soon as a vulnerability is confirmed and an update is available, you should do everything possible to inform your customers about it.

    And just publishing a blog post titled “Types Plugins Temporarily Removed from the WPORG Repo” simply isn’t the correct response to a major vulnerability in your code.

    A last thought regarding your “security by obscurity” philosophy:
    as your plugin repository on wp.org is online again now, everyone interested can simply generate a diff of the newest version and see all details about the vulnerabilities. So I think it is not irresponsible to inform your clients properly and help them deciding whether they should update or not, as the bad guys simply can get much more detail anyway.

    • Why no updates? You can download Types from wp-types.com and now also (again) from the WP repo. The current version is 2.2.3.

  16. Hi Amir,

    I currently have the 2.2.2 version installed on one of my websites. When trying to update to 2.2.3, I get the following message: Toolset Types cannot update because your site’s registration is not valid. Please register Toolset again for this site first.

    Does this has anything to do with the plugin being removed from the repository?

    Thank you!

    • I’m not sure why this started happening. We changed nothing on our side. The WP repo folks wrote to us that “some meta information for Types may be incorrect in the next few days”. We don’t know about the internal data inside the WordPress repo. If you’re getting this message, I suggest to update Types manually now (deactivate, delete, download again).

      Going forward, we’re going to stop relying on the WordPress repo and we’ll make our own site the main point for service all of Toolset components, including Types. We haven’t yet made any such change. The issues that we’re seeing now in the upgrade process appear to be a result of this down/up action on the WP repo.