Orb update 02 21

.dockerignore

@@ -3,7 +3,6 @@
 GPLv3.txt
 LICENSE
 README.md
-TGS3.json
 .github
 .gitignore
 .gitattributes

.git-blame-ignore-revs

@@ -16,3 +16,7 @@
 0f435d5dff0a7957e8cba60a41a7fc10439064c3
 # Remove one errant disposals pipe
 cc78227c693a3246e8d4d2930ee97242f6546246
+# Reorganized the sound folder
+58501dce77aba5811fa92a6d7de7d0cc0a1e56ac
+# Compress all sounds using optivorbis
+436ba869ebcd0b60b63973fb7562f447ee655205

.github/CODEOWNERS

@@ -182,6 +182,10 @@
 /code/modules/atmospherics/ @Pickle-Coding
 /code/modules/power/ @Pickle-Coding
 
+# Sadboysuss
+
+/sound/ @Sadboysuss
+
 # MULTIPLE OWNERS
 
 /SQL/ @Jordie0608 @scriptis

.github/guides/STANDARDS.md

@@ -23,11 +23,18 @@ You can avoid hacky code by using object-oriented methodologies, such as overrid
 
 ### Develop Secure Code
 
-* Player input must always be escaped safely, we recommend you use stripped_input in all cases where you would use input. Essentially, just always treat input from players as inherently malicious and design with that use case in mind
+* Player input must always be escaped safely, we recommend you use stripped_input in all cases where you would use input. Essentially, just always treat input from players as inherently malicious and design with that use case in mind.
+	* This extends to much further than just numbers or strings. You should always sanity check that an input is valid, especially when it comes to datums or references!
+	* Input stalling is a very common exploit / bug that involves opening an input window when in a valid state, and triggering the input after exiting the valid state. These can be very serious, and allow players to teleport across the map or remove someone's brain at any given moment. If you check the player must be in a specific context before an input, you should generally check that they are still in the context AFTER the input resolves.
+		* For example, if you have an item which can be used (in hand) by a player to make it explode, but you want them to confirm (via prompt) that they want it to explode, you should check that the item is still in the player's hands after confirming. Otherwise, they could drop it and explode it at any moment they want.
+	* Another less common exploit involves allowing a player to open multiple of an input at once. This may allow the player to stack effects, such as triggering 10 explosions when only 1 should be allowed. While a lot of code is generally built in a way making this infeasible (usually due to runtime errors), it is noteworthy regardless.
+		* You should also consider if it would make sense to apply a timeout to your input, to prevent players from opening it and keeping it on their screen until convenient.
 
 * Calls to the database must be escaped properly - use sanitizeSQL to escape text based database entries from players or admins, and isnum() for number based database entries from players or admins.
 
 * All calls to topics must be checked for correctness. Topic href calls can be easily faked by clients, so you should ensure that the call is valid for the state the item is in. Do not rely on the UI code to provide only valid topic calls, because it won't.
+	* Don't expose a topic call to more than what you need it to. If you are only looking for an item inside an atom, don't look for every item in the world - just look in the atom's contents.
+		* You rarely should call `locate(ref)` without specifying a list! This is a serious exploit vector which can be used to spawn Nar'sie or delete players across the map. Try narrowing it down via a list - such as `locate(ref) in contents`, to find an item in an atom's contents.
 
 * Information that players could use to metagame (that is, to identify round information and/or antagonist type via information that would not be available to them in character) should be kept as administrator only.
 
@@ -74,8 +81,6 @@ var/path_type = "/obj/item/baseball_bat"
 
 * Changes to the `/config` tree must be made in a way that allows for updating server deployments while preserving previous behaviour. This is due to the fact that the config tree is to be considered owned by the user and not necessarily updated alongside the remainder of the code. The code to preserve previous behaviour may be removed at some point in the future given the OK by maintainers.
 
-* The dlls section of tgs3.json is not designed for dlls that are purely `call()()`ed since those handles are closed between world reboots. Only put in dlls that may have to exist between world reboots.
-
 ## Structural
 ### No duplicated code (Don't repeat yourself)
 Copying code from one place to another may be suitable for small, short-time projects, but /tg/station is a long-term project and highly discourages this.

.github/workflows/docker_publish.yml

@@ -6,7 +6,7 @@ on:
 jobs:
   publish:
     if: ( !contains(github.event.head_commit.message, '[ci skip]') )
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-24.04
     steps:
       - uses: actions/checkout@v4
 

_maps/RandomRuins/IceRuins/icemoon_underground_syndielab.dmm

@@ -246,7 +246,6 @@
 /turf/open/floor/mineral/plastitanium/red,
 /area/ruin/syndielab)
 "oA" = (
-/obj/structure/syndicate_uplink_beacon,
 /turf/open/floor/iron/dark/textured,
 /area/ruin/syndielab)
 "oY" = (
@@ -267,10 +266,6 @@
 	pixel_x = -5;
 	pixel_y = 8
 	},
-/obj/item/traitor_bug{
-	pixel_y = 6;
-	pixel_x = 6
-	},
 /turf/open/floor/mineral/plastitanium/red,
 /area/ruin/syndielab)
 "qy" = (