As we stabilize the 1.8 branch for future support with development eventually switching focus to 1.9, we’d like to draw your attention to the following advisories.

CAPTCHA Bug

Version 1.8.27 has introduced a bug affecting two of MyBB’s supported CAPTCHA mechanisms: reCAPTCHA v3 and hCaptcha invisible. For those, the CAPTCHA may appear broken, and the verification can reject or accept attempts incorrectly.

If your forum uses those systems, we advise to either:

• temporarily switch to another mechanism using the CAPTCHA Images for Registration & Posting setting (ACP: Configuration → Settings → General Configuration), or
• applying the upcoming changes to source code files manually.

This problem will be resolved in the next maintenance release.

Parser Output Validation

The upcoming maintenance release enforces validation of XHTML code generated by the MyCode parser in order to improve security.

MyBB 1.8.27 included this feature in report-only mode, meaning that any problems are already being saved to the configured error log. After upgrading, validation errors will continue to be logged, but messages with problematic MyCode will not be displayed to prevent potential XSS attacks against your forums.

Forum administrators should verify that their error logging is configured properly, and monitor the log for errors that may indicate necessary changes to their customizations like custom MyCodes, theme templates, username styles, and plugins. These errors can be triggered when forum content that uses MyCode is viewed.

We created a relevant Docs section that details pinpointing the origin, debugging using a dedicated tool, and disabling the validation requirement for boards that are not yet ready for this change.

Examples of Fixed Validation Errors

To help demonstrate what actions may need to be taken, let’s take a look at some validation failures that turned up so far:

• Case 1: Attributes Without Value in Default Templates

  MyBB’s default theme included HTML attributes without values. These caused validation errors such as:

  • Specification mandates value for attribute
  • attributes construct error

  To fix this, we simply added ="true" fragments where needed.

• Case 2: Redundant Tags in Username Style

  In a support thread, unnecessary HTML in a customized username style, present in a forum post, resulted in a logged failure that mentioned:

  • Opening and ending tag mismatch

  • Extra content at the end of the document

  This could be resolved by cleaning up the HTML code in the Username Style field for the problematic user group by removing stray closing tags.

• Case 3: Self-Closing Tags in Custom MyCode

  In another support thread, a custom MyCode included an unclosed <hr> HTML tag, which resulted in a validation failure that mentioned:

  • Opening and ending tag mismatch

  • EndTag: '</' not found

  For correct XHTML validation, tags that don't have an equivalent closing tag should include a forward slash: <hr />.

• Case 4: Invalid Placeholder Format

  A plugin that inserted invisible markers in the <example#0> format resulted in errors referring to attribute parsing and missing end tags. This format was changed to <example id="0" /> to pass the validation.

If you have trouble resolving validation failures, visit our support platforms and include the full logged error.

PHP Compatibility

MyBB aims to support most recent versions of web browsers, servers, database systems, and PHP interpreters. Due to significant changes in PHP 8.0, however, we recommended using PHP up to 7.4 while the code was being adjusted.

The upcoming MyBB release includes another batch of such adjustments, and removes some unnecessary side-effects of version-related PHP Warnings. We also pay attention to PHP 8.1, which is not expected to cause major problems after these updates.

Even though more issues may still be discovered when running MyBB on latest versions of PHP, we encourage administrators and extension developers to verify the stability of their forums and extensions on PHP 8, and to watch out for any errors that may appear in the error log, starting with the next maintenance release. Numerous web hosts already support switching to PHP 8.0, and MyBB can easily be tested locally using Docker.

Any suspected issues related to compatibility, as usual, can be reported on our support platforms.

Some of you may be aware back in October 2016 with the release of MyBB 1.8.8 & Merge System 1.8.8 we ended the support for the current MyBB Merge System. The plan at that time was to rebuild the system from the ground up alongside the release of MyBB 2.0. As MyBB 2.0 has been put on hold indefinitely and a growing number of users are experiencing problems using the Merge System, I am pleased to confirm we are planning to reverse that decision and continue supporting the existing Merge System for the foreseeable future.

The current repository remains on GitHub and we will be using Git as normal to track issues and releases. The current plan is to release the next version with MyBB 1.8.23. A number of PR’s have already been merged since the official end of support in 2016 including bug fixes for PHP 7.2’s compatibility and support added for XenForo 2 . Please bear with us while we try to get on top of the issues reported some time ago and re-familiarising ourselves with the system again.

On a side note, Happy New Year to you all and we hope 2020 is a success.

Thanks,

MyBB Team

With the continuous Community effort to improve the quality of our stable branch in the background, the work on remaining features of MyBB 1.9 moves on.

One of the completed changes that will make its way into MyBB 1.9’s highlights — other than the theme system — is the introduction of modern password hashing. The md5-based hash function, used in MyBB since its very beginning, will be replaced by bcrypt, making it much more difficult to obtain original passwords basing on new hash values in case of a data breach.

The current blocking task for other areas is rebasing the 1.9 branch on top of the 1.8 branch. Due to the way that Git (the tool we use to manage development) works, 1.9 is worked on in a separate branch whilst 1.8 development progresses. As the 1.8 branch moves forward, the 1.9 branch slowly goes out of sync, missing the recent changes from 1.8.

At the current moment, the 1.9 branch is in line with MyBB 1.8.17, leaving us with 4 versions’ worth of changes that we need to merge into 1.9. This, unfortunately, is not an easy process due to the nature of code changes in 1.9 and there are a lot of conflicts which need to be resolved manually. To ease this process we have decided to rebase one version at a time. Some MyBB 1.8 releases contain a smaller amount of changes than others, and these are considerably easier to rebase too.

Once the re-base is complete, there are still a couple of other tasks for 1.9 before we can release our first Alpha and Beta releases. Some of these issues include:

• Implementing a new email system. The current MyBB email system causes no end of support threads due to its limited support for slight variations in the way email servers “speak” the SMTP protocol. We’re proposing that we adopt an existing well tested and support email sending library to manage the sending of emails. From a core point of view, this should be relatively simple since almost every email sent uses a single standard function (my_mail()).

  We’re proposing that we adopt the new symfony/mailer library which provides easy ways to send email via SMTP as well as various email APIs such as Postmark.

• Reviewing any missed templates from the Twig conversion. During the rebase effort, we’ve noticed some lingering uses of the old template system within the core. These need to be rounded up and eliminated to ensure the template system usage throughout is consistent.

• Updating the ACP to allow editing of Twig template files. So far, the Team have all been editing Twig templates directly through their respective files. While this is a great way to work (who doesn’t want to use their own editor of choice?), being able to edit templates easily within the Admin Control Panel is a useful feature that needs updating to work with the new template system. There is some discussion about looking at the JavaScript code editor that we use when editing templates to see if there are any better options on the market. An often requested feature has been the ability to edit multiple templates within tabs at the same time, an enhancement which would be very handy when working with new templates.

  We’re also looking at the possibility of leaving certain level of support for the old template format to reduce the number of changes required in MyBB 1.8-based plugins to work with MyBB 1.9.

  Open the 1.9 Theme System Issue issue to see what design problems we’ll be aiming to solve, and to participate in the discussion, whether you’re an Extension guru or have previously noticed friction when dealing with themes in MyBB.

  

We will also be starting to update and introduce documentation for 1.9. If there are any documentation pages that you would like to see updated or improved, now would be a great time to bring them to our attention!

Keeping MyBB boards secure is a team effort. Security issues discovered and reported by external researchers and our core developers are analysed, fixed and included in final packages. The process doesn’t end there however: it is essential that administrators are notified to update their forums as soon as possible in order to prevent the addressed vulnerabilities from being exploited in an attack on their boards and users.

Our recently published summaries, recommendations and links to reviewed guides in the SECURITY.md file contain many resources forum administrators can use to secure their boards against both opportunist and experienced digital criminals. First and foremost though, we always recommend that users keep their MyBB installs up to date. We also suggest using the new subscription feature for all used plugins and themes on Extend.

Based on our experience, even large discussion boards that don’t have dedicated technicians tend to use outdated versions of MyBB and the situation in the area of extensions might be equally concerning. Not unlike other software, periodical updates are the main method of delivery for security patches — most MyBB releases contain fixes plugging security holes ranging from theoretical risks to critical vulnerabilities.

The need for continuous response to vulnerability reports is a strong argument for making the reduction of manual effort needed to keep our packages up to date a long-term goal.

In this post we’ll explore what keeps our developers up at night that also affects MyBB’s ability to introduce automated updates, and how the mechanism might be actually implemented once the system — currently being rebuilt for version 1.9 and subsequent branches — is ready.

Continue reading →

Every meaningful set of development activity in open-source projects like MyBB is followed by an official release that merges in additional lines of production, like security updates, and wraps it up with descriptions and instructions easy to understand for non-developers and site maintainers. Currently the most popular way of distributing updates to PHP-based software is file packages: project managers have to scramble to gather and bundle all files and associated documentation while site administrators are expected to keep track of (and sometimes interpret) this information.

This, to convenience of site administrators and ours, is planned to improve upon adoption of concepts like continuous integration that put emphasis on making all products deployable after every change to the code, and the integration of tools like Composer, which ease the pains of managing third-party solutions and allow to separate one big product into small, handy modules. Even though conveniences like fully automated updates will take time to become reality with informal open-source projects (where the technicalities are much easier to implement than procedures that provide a reasonable level of security), MyBB moves closer to that with eliminating manual tasks covering a broad range of activities that precede each release—the last 4 versions of MyBB (starting with 1.8.12) have been build using the recently published package builder.

Rewriting Memos in XML & PHP

The core part of the builder’s logic is Phing, an Apache Ant-based PHP task build system. This engine enables developers to specify operations related i.a. to git & patch (extensively used to apply sensitive patches before the release), file encoding and archiving saved in an XML build file. It’s also used to call sub-scripts that list changed files and calculate archive size and checksums, but also perform some project-specific operations like counting modified language files, searching for templates that changed between versions or update plugin hook locations with line number precision. Since the Jekyll-powered MyBB.com website is generated from Markdown & Front Matter data files, the builder also prepares the version’s YaML metadata ready to be put into the repository allowing Release Notes and the Release Blog Post content to be generated.

You Want to Run it on What?

Another important role plays Docker, a platform introducing container systems. You might recognize it from the recently put out image recipe that can be used to deploy MyBB 1.8, however this environment is also used whenever packages need to be assembled. No matter who, where or when participates in the building process, they should be able to use the same precisely defined tools—by running the script inside a container we can assure a degree of confidence in that, given the separation from the host operating system. Our Docker image, based on a trimmed down version of Debian, contains an unsuspicious development toolset including basic packages and a PHP interpreter with customized configuration and the strip-nondeterminism tool that normalizes the output to make it possible to arrive with byte-to-byte equal archives identified by matching checksums. This practice is called build reproducibility which will serve as a vital part in download verification.

Real output (with real git errors) when building MyBB 1.8.15 packages

Visit the mybb/mybb-build repository to set up own production line basing on our code and compare against the latest MyBB release packages (starting with 1.8.15, releases on GitHub include a build package with input necessary to reproduce the output).

Automated packaging does not only leave more time for other aspects of running large-scale projects, but also assures that every update is brought to users without potential mistakes that could have been made otherwise with manual assembling. Furthermore, whenever mistakes are spotted, the archives can be quickly rebuilt and pushed out—less emphasis will be put on singular releases and more on their continuous delivery with seamless upgrades that MyBB will be working on.

Not long ago, we started a new project to gather information about the PHP versions that various web hosts support. The aim of this project was to gather a list of web hosting companies who would be able to host the upcoming MyBB 2.0 release.

Since starting that project, we have received several contributions. However, we’ve also since changed the PHP version requirements that we will require for 2.0. As such, we are closing the mybb/2.0-Hosts repository and instead asking that users please make use of the PHP Versions website to track the PHP versions on offer at different hosts. This website operates in a similar way to the old MyBB project, but is much more widely used and already contains information for lots of different hosts. For more information on contribution to the PHP Versions website, please see the contributing guide.