RetroMC Change Management Policy: Difference between revisions

Latest revision as of 20:45, 14 July 2024

ℹ️ 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.
- One such case study is the 2023 Gradle Wrapper Attack and was a novel type of attack hitherto 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 (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	JohnyMuffin
15/07/24	Made some formatting changes	Noggisoggi

@@ Line 1: / Line 1: @@
 [[Category:Server internals]]
 [[Category:Guides]]
+{{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.
 __NOTOC__
-== 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 ===
 {| class="wikitable"
@@ Line 14: / Line 10: @@
 ! No. !! Type of Change !! Approving Authority !! Example
 |-
-| 1. || '''Major Feature/New Plugin''' || '''Operator''' || Implementing a new plugin that replaces the current Village System.
+| 1. || Major feature and/or new plugin || Operator || Implementing a new plugin that replaces the [[JVillage|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.
+| 2. || Minor feature addition || 2 Admins or 1 Operator || Adding a feature such as <code>/hat</code>, <code>/mail</code> 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.
+| 3. || Bug/Security Patching || Admin || Implementing a new version of Poseidon or Essentials to patch security vulnerabilities or fix bugs affecting gameplay.
-   Example: Updating critical plugins to patch security vulnerabilities or fix bugs affecting gameplay.
 |}
+Changes should be tracked and authorised via [[Ticket system|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 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.
+* 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.
+** One such case study is the [https://blog.gradle.org/wrapper-attack-report 2023 Gradle Wrapper Attack] and was a novel type of attack hitherto 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.
+* 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.
-- 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).
-- Staff members are encouraged to delay implementation if there is uncertainty about the integrity of a JAR file, pending further verification and review.
+* Documentation of all changes ([[Ticket system|preferably via ticket]]), including approvals and implementation details, should be maintained for transparency and accountability.
-- 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 and Review ==
-=== Implementation ===
+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.
-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 ==
@@ Line 56: / Line 41: @@
 |-
 | 29/06/24 || First draft of the RetroMC Change Management Policy || {{user-bust|JohnyMuffin}}
+|-
+| 15/07/24 || Made some formatting changes || {{user-bust|Noggisoggi}}
 |}