RetroMC Change Management Policy
RetroMC Change Management Policy
ℹ️ Notice: This policy is currently in draft form, and efforts should be made to adhere to its guidelines to the best extent possible.
This policy outlines the procedures for managing changes, particularly regarding the implementation of plugins on the Minecraft server.
Types of Changes, Approving Authority, and Examples
| No. | Type of Change | Approving Authority | Example |
|---|---|---|---|
| 1. | Major Feature/New Plugin | Operator | Implementing a new plugin that replaces the current Village System.
Example: Introducing a new plugin that completely changes the in-game village mechanics. |
| 2. | Minor Feature | 2xAdmin or Operator | Adding a feature such as /hat, /mail to Discord, or something relatively small.
Example: Adding new commands to Discord for cosmetic changes in-game. |
| 3. | Bug/Security Patching | Admin | Implementing a new version of Poseidon or Essentials to resolve a player exploit.
Example: Updating critical plugins to patch security vulnerabilities or fix bugs affecting gameplay. |
Plugin Implementation Guidelines
When implementing new plugins on the server, special precautions must be taken to ensure security and stability:
- Avoid using JAR files provided directly by developers to mitigate the risk of compromised code. Malicious actors may provide JARs that don't match the source code that could potentially contain malicious code. Precedence does exist for this type of attack within the Legacy Community, and other servers such as Minecraft Online have faced sophisticated attacks by developers. One such example is the Gradle Wrapper Attack (https://blog.gradle.org/wrapper-attack-report) that occurred in 2023 and was a novel type of attack previously unknown by the Gradle developers.
- Preferentially use JAR files compiled from trusted sources, such as GitHub actions. Before deployment, verify the commit history between the current production version and the new version to confirm the absence of malicious code.
- In cases where a developer-provided JAR is necessary or any public plugin is introduced, decompile the plugin when feasible to inspect for potentially malicious code.
- Staff members are encouraged to delay implementation if there is uncertainty about the integrity of a JAR file, pending further verification and review.
- The Community Management team can request the Development team to verify the safety of plugins, ensuring there is no conflict of interest (e.g., ensuring developers are not closely affiliated).
- Documentation of all changes, including approvals and implementation details, should be maintained for transparency and accountability.
Implementation
This policy is effective immediately upon approval and applies to all changes made to the RetroMC Minecraft server environment.
Review
This policy will be reviewed annually to incorporate any necessary updates based on changing security threats or operational needs.
Changelog
All changes to this policy are to be documented accordingly.
| Date (DD/MM/YY) | Change | Author |
|---|---|---|
| 29/06/24 | First draft of the RetroMC Change Management Policy |
