RetroMC Change Management Policy

From RetroMC
Jump to navigation Jump to search

ℹ️ Notice: This policy is currently in draft form, and efforts should be made to adhere to its guidelines to the best extent possible.

As part of the RSPM, this policy set 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 and/or new plugin Operator Implementing a new plugin that replaces the current village system.
2. Minor feature addition 2 Admins or 1 Operator Adding a feature such as /hat, /mail to Discord, or something relatively small.
3. Bug/Security Patching Admin Implementing a new version of Poseidon or Essentials to patch security vulnerabilities or fix bugs affecting gameplay.

Changes should be tracked and authorised via a staff-only ticket.

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 contain malicious code. Precedence does exist for this type of attack within the legacy Minecraft community, and other servers such as MinecraftOnline have faced sophisticated attacks by 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 (preferably via ticket), including approvals and implementation details, should be maintained for transparency and accountability.

Implementation and Review

This policy is effective immediately upon approval and applies to all changes made to the RetroMC Minecraft server environment; additionally this 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
15/07/24 Made some formatting changes