Security Updates & Even More Patches
With the recent Patch Level releases for earlier versions, we have done some rethinking regarding security for various functions. As a result, VaultWiki 4.0.2 offers new permission settings for actions that did not have them before or that previously relied on other settings. Additionally, 4.0.2 now checks an article's protection status for more actions than prior versions did.We believe that VaultWiki 4.0.2 is our most secure release ever. However, while considering the security improvements for 4.0.2, we noticed the existence of 2 existing permissions-workaround vulnerabilities: one in the feeds system, a feature that was added in 4.0.0, and one that has existed in the books system since the 2.x series.
The feed vulnerability makes it easy for malicious users to vandalize many feeds.
The books vulnerability requires specific permissions combinations to create an unexpected condition which may allow users to vandalize a book's table of contents.
Thus, we have also issued the following Patch Level releases:
- 4.0.1 Patch Level 3
- 4.0.0 Patch Level 3
- 4.0.0 RC 5 Patch Level 2
- 4.0.0 RC 4 Patch Level 3
- 4.0.0 RC 3 Patch Level 4
- 4.0.0 RC 2 Patch Level 4
- 4.0.0 RC 1 Patch Level 4
The feeds vulnerability affects all supported versions of VaultWiki 4.x since 4.0.0 (stable), including VaultWiki Lite. The books vulnerability affects all paid versions of VaultWiki 4.x, 3.x, and some 2.x versions, but does not affect VaultWiki Lite.
If you have the Feeds or Books features from these versions enabled in a production environment (default: enabled), we HIGHLY recommend upgrading to 4.0.2 or updating to one of the aforementioned patched releases.
New permission settings in 4.0.2 allow for more fine-tuned control over both feeds and books in the newest release, but for the Patch Level releases we had to make changes to some permission calculations that may have undesired results for some use cases. For this reason, we recommend using 4.0.2 rather than one of these patches if you can.
Alternatively, you can prevent vandalism to your content by disabling the Feed and Book content-types entirely until you are able to upgrade. In the wiki's Admin Panel, go to Structures > Content Types, and ensure "Feeds" and "Books" are disabled.
Open Graph Support
VaultWiki 4.0.2 includes built-in support for social networks that use Open Graph technology. This support means improving tracking of wiki content with Open Graph-based analytics and cleaner, more useful previews when sharing pages on Facebook or Google+. Shares via Twitter should now use Twitter cards.These improvements apply automatically, whether or not your site already has built-in sharing functions for any social media site. The reasoning is that users can share your wiki content anyway if they know the URL, and this content should always be presented as attractively as possible to their followers.
Special:Credits
VaultWiki 4.0.2 includes a new Special:Credits page, which uses the same permissions as the Special:Version page. This new Special page lists the names of developers and other people who have contributed to VaultWiki over the years.Special:Credits also includes a "Special Thanks" section, which includes the names of those who have previously contributed donations towards VaultWiki development, specifically fulfilling "Infamy" and higher-level perks from our IndieGogo campaign that ended in January.
Special:Credits currently only names donors from this IndieGogo campaign. If you have made a donation directly to VaultWiki development in the past, and you would also like your name included, please shoot pegasus a PM.
Development Notes
We would like to apologize for the delay in the release of 4.0.2. Due to the recent "Moderation Security Vulnerability" that was discovered around the expected release date, we delayed 4.0.2 in order to make further improvements to security.We have also been having trouble recently with our in-house packaging system, which uses a custom PHP script that interacts with our Mercurial repository. With the past few regular updates, we have had issues where the checkout process for a release would use excessive server resources and often never finish. These issues came to a culmination about a week ago, and we had to refactor and redesign how changesets were compiled and retrieved, or we would not be able to generate any release packages going forward.
We were finally able to resolve these issues without a costly server upgrade, and we reduced our system's packaging time by as much as 4,100%.
Notes on the Earlier Release of 4.0.0 Patch Level 1
After the updates to our system mentioned above, we noticed that the recent 4.0.0 Patch Level 1 was actually a clone of 4.0.0 RC 5 Patch Level 1. Thus users of 4.0.0 who then updated to Patch Level 1 may have noticed regressions in features and bug fixes, and users who upgraded from 4.0.0 RC 5 would have noticed little change.We would like to apologize also for this inconvenience.
4.0.0 Patch Level 3 now takes precedence over PL 1 anyway, and it is based on the expected version. Users of this version may wish to run the upgrade script again to ensure that the database is on the correct version as well.
Note that this issue should not apply to anyone who is already using 4.0.1 or higher.