Third Party Package Servers Provided by (Optional) Packages
In recent years, we have seen an increasing number of incidents involving third-party package servers, focusing on packages offered in the Plugin-Store.
In the interest of our customers, we have decided not to approve any new packages or updates that directly or indirectly (e.g. via optional packages) install third-party package servers. This explicitly only affects packages in the plugin store, there is no technical change in the core, it is still possible to create package servers via third-party packages or by manually adding them.
In this context, and in the interests of transparency, we would like to explain the primary reasons for our decision in the following.
Lack of Necessity for Products in the Plugin-Store
For extensions and styles from the plugin store, there is absolutely no need to install third-party package servers, because all updates are delivered directly from the Plugin-Store as soon as they are reviewed.
Distribution of Non-audited Updates
Some third-party vendors release updates for packages directly as soon as they are available and do not wait for the review in the plugin store. This is problematic because the final review of each new package and each update is done manually by a WoltLab GmbH employee.
On average, every third update is rejected at the first attempt due to substantial defects. Early delivery via third-party package servers undermines this review, which aims to reduce both security and stability issues.
Collision with Commercially Offered Products
A special case is the premature release of updates, where the product is offered both in the Plugin-Store and directly by the third-party vendor. This can lead to conflicts if no access data has been stored for the third-party vendor's package server and updates are therefore offered before they are published in the Plugin-Store.
Security Concerns Regarding Unaudited Packages and Updates
The strength of the package system is also one of the biggest weak spots, because extensions can make almost arbitrary changes, up to the execution of security-critical malicious code. This is made more difficult by the fact that package servers can offer updates for almost any package for download, the only exception being our products, which can only be delivered via the official package servers.
Unfortunately, incidents have occurred in which websites of third-party vendors have become the target of attacks, with both takeovers at the DNS level, i.e. the domains pointing to a foreign server, and the direct compromise of the server systems. This also means that an attacker gains control over the packet servers of these providers and can exploit them to deliver malicious code almost without being noticed. A look beyond the horizon reveals that this is by no means a fictitious scenario, but rather a recurring threat, for example with NPM or various Linux distributions, which could often only be prevented by a high level of protection.
Compatibility with the WoltLab Cloud
We will soon start to review extensions and styles in the Plugin-Store for compatibility with the WoltLab Cloud. Entries that pass this test will be marked by us; we do not plan to use some kind of "negative marking" at this time.
The criteria for determining compatibility are as follows:
- Compatibility with WoltLab Suite 5.2.
- Outgoing HTTP(S) connections consistently rely on the HTTPRequest class or handle the proxy configuration correctly.
- No outgoing connections to other TCP or UDP ports.
- No mass sending of emails.
- No overlapping with privileges that are subject to restrictions in the context of a managed service, such as direct database administration.
- Packages that install third-party packet servers are generally excluded.
These criteria are already met by the vast majority of packages, so no significant restrictions are to be expected.
kilde: Plugin-Store Guidelines and Compatibility with WoltLab Cloud - Neuigkeiten und Hinweise - WoltLab®
