Support auto update from different branches

.secrets.baseline

@@ -149,7 +149,7 @@
         "filename": "config/slips.yaml",
         "hashed_secret": "4cac50cee3ad8e462728e711eac3e670753d5016",
         "is_verified": false,
-        "line_number": 304
+        "line_number": 322
       }
     ],
     "dataset/test14-malicious-zeek-dir/http.log": [
@@ -7176,5 +7176,5 @@
       }
     ]
   },
-  "generated_at": "2026-04-27T14:39:21Z"
+  "generated_at": "2026-05-04T20:22:30Z"
 }

README.md

@@ -165,6 +165,11 @@ Slips can be run on different platforms, the easiest and most recommended way if
 # Configuration
 Slips has a [config/slips.yaml](https://github.com/stratosphereips/StratosphereLinuxIPS/blob/develop/config/slips.yaml) that contains user configurations for different modules and general execution.
 
+Do not edit the default `config/slips.yaml` directly. Create a copy for your local configuration changes and run Slips with `-c`, for example `./slips.py -c config/my_slips.yaml -f dataset/test7-malicious.pcap`.
+
+The same applies to `config/whitelist.conf`: keep the default file unchanged, create a copy, and set `whitelists.local_whitelist_path` in your copied Slips config file to point to your copied whitelist file.
+Slips aborts updating to new versions when there are changes to Slips local config files.
+
 * You can change the timewindow width by modifying the ```time_window_width``` parameter
 * You can change the analysis direction to ```all```  if you want to see the attacks from and to your computer
 * You can also specify whether to ```train``` or ```test``` the ML models

config/slips.yaml

@@ -1,6 +1,11 @@
 # This configuration file controls several aspects of the working of Slips.
+################ 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 #########################
+##                DO NOT MODIFY THIS FILE. EVER.                                                      #
+##      IF YOU NEED TO CHANGE ANYTHING, MAKE A COPY AND USE THAT COPY WITH slips.py -c                #
+################ 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 #########################
 
 ---
+
 update:
   # Enable automatic live updates of the installed Slips version.
   # This setting is separate from the feeds_update_manager module, which only
@@ -10,6 +15,19 @@ update:
   # Instead, create separate config files with different names and use those.
   auto_update_slips: false
 
+  # Select which update channel Slips should auto-update from.
+  # Available update channels:
+  # - stable:  uses origin/master
+  # - unstable: uses origin/develop
+  # - testing:  specify your branch name in the testing_branch_to_update_slips_from parameter below.
+  channel_to_update_slips_from: stable
+
+  # This branch is used only when channel_to_update_slips_from is set to
+  # testing.
+  # Must be a remote origin/<branch> ref.
+  # Example: origin/your_branch_here
+  testing_branch_to_update_slips_from: origin/your_branch_here
+
 output:
   # Define the file names for the default output.
   stdout: slips.log

config/whitelist.conf

@@ -1,6 +1,12 @@
+;;;;;;;;;;;;;;;; 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 ;;;;;;;;;;;;;;;;;;;;;;;;;
+;;                DO NOT MODIFY THIS FILE. EVER.                                                      ;
+;;      IF YOU NEED TO CHANGE ANYTHING, MAKE A COPY AND USE THAT COPY WITH slips.py -c                ;
+;;;;;;;;;;;;;;;; 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 ;;;;;;;;;;;;;;;;;;;;;;;;;
+
+
 ; NOTE:
-; USER COMMENTS START WITH ;
-; COMMENTED OUT WHITELIST LINES START WITH #
+; USER COMMENTS START WITH ; (aka any english comment like this one that doesnt contain TI)
+; COMMENTED OUT WHITELIST LINES (lines with TI that you don't want slips to use ) START WITH #
 ; FOR SLIPS TO BE ABLE TO REMOVE THEM FROM THE CACHE DATABASE
 
 ; A whitelist of IPs, domains, organisations or mac addresses

docs/contributing.md

@@ -62,6 +62,36 @@ Here's a very simple beginner-level steps on how to create your PR in Slips
 11. Open a PR in Slips, remember to set the base branch as develop.
 12. List your changes in the PR description
 
+## How to test the auto update functionality
+
+To test Slips auto update using the `testing` channel, follow these steps:
+
+1. Create a new temporary branch from the branch you want to test, for example `origin/yourname-autoupdate-test`.
+2. Edit [update.json] in your new branch and update the `testing` channel entry:
+   - increase the `version` value so this branch appears newer than the version currently available
+   - keep `"backwards_compatible": true`
+   - keep `"has_new_dependencies": false`
+   - set the testing branch entry to your new branch name e.g `origin/yourname-autoupdate-test`
+3. Commit the `update.json` change in that temporary branch and push the branch to your remote.
+4. Check out your original old branch again. Before continuing, make sure there are no merge conflicts and no modified Slips files in this branch.
+5. Create a copy of [config/slips.yaml](config/slips.yaml) .
+6. In your copied config file, enable auto update and configure the testing channel:
+
+   ```yaml
+   update:
+     auto_update_slips: true
+     channel_to_update_slips_from: testing
+     testing_branch_to_update_slips_from: origin/<yourname-autoupdate-test>
+   ```
+
+7. Run Slips on an interface and point it to your copied config file using `-c`, for example:
+
+   ```bash
+   ./slips.py -i <interface_name> -c config/<your_test_config>.yaml
+   ```
+
+8. While Slips is running, it should detect the higher version in the `testing` channel and auto update to the branch you pushed in step 3.
+
 
 ## Rejected PRs
 

docs/features.md

@@ -1068,7 +1068,7 @@ to one of the above alerts, slips does not detect it assuming it's a false posit
 internally by slips.
 
 
-You can change this behaviour by updating ```config/whitelist.conf```.
+You can change this behaviour by copying ```config/whitelist.conf```, updating the copy, and pointing ```whitelists.local_whitelist_path``` in your copied ```slips.yaml``` file to that copied whitelist.
 
 ## Ensembling
 

docs/immune/updating_slips.md

@@ -40,7 +40,7 @@ Old Slips running
         ↓
 Check for compatible update
         ↓
-git pull origin master
+git fetch <configured branch> && git checkout <configured branch>
         ↓
 Start new Slips with -u
         ↓
@@ -61,6 +61,8 @@ Slips checks for updates once per day.
 This is handled by the UpdateManager, which:
 
 - checks whether auto-update is enabled in the config file
+- resolves the configured update channel
+- resolves the configured testing branch when the channel is `testing`
 - checks whether a new version exists
 - checks compatibility before attempting update.
 
@@ -72,10 +74,51 @@ This file includes metadata about the new version such as:
 - latest version,
 - backwards compatibility,
 - whether new dependencies are needed.
-
+- update branch/channel metadata.
 
 The compatibility parser was added so we avoid updating to incompatible new releases.
 
+`update.json` now supports either a single object or a list of objects. When a
+list is used, each entry should define both:
+
+- `branch`: the git branch name without the `origin/` prefix
+- `channel`: the Slips update channel name (`stable`, `unstable`, `testing`)
+
+Slips first tries to match the configured branch, then falls back to the
+configured channel. For backward compatibility, older list entries that only
+use `branch` with channel aliases are still accepted.
+
+Example:
+
+```json
+[
+  {
+    "version": "1.1.20",
+    "release_date": "2026-04-30T14:39:56+03:00",
+    "backwards_compatible": true,
+    "has_new_dependencies": false,
+    "branch": "master",
+    "channel": "stable"
+  },
+  {
+    "version": "1.1.19",
+    "release_date": "2026-04-30T14:39:56+03:00",
+    "backwards_compatible": true,
+    "has_new_dependencies": false,
+    "branch": "develop",
+    "channel": "unstable"
+  },
+  {
+    "version": "1.1.19",
+    "release_date": "2026-04-30T14:39:56+03:00",
+    "backwards_compatible": true,
+    "has_new_dependencies": true,
+    "branch": "feature/your_branch_here",
+    "channel": "testing"
+  }
+]
+```
+
 
 **The update is aborted if:**
 
@@ -141,10 +184,38 @@ PS: the new updated slips version starts reading flows before the old one starts
 
 ## How to use it
 
-enable ```auto_update_slips``` in ```config/slips.yaml``` and run slips on your interface.
+Enable `auto_update_slips` in `config/slips.yaml`, set
+`channel_to_update_slips_from`, and run slips on your interface.
+
+Available channel mappings:
+
+- `stable` -> `origin/master`
+- `unstable` -> `origin/develop`
+- `testing` -> use `testing_branch_to_update_slips_from`
+
+Examples:
+
+```yaml
+update:
+  auto_update_slips: true
+  channel_to_update_slips_from: stable
+```
+
+```yaml
+update:
+  auto_update_slips: true
+  channel_to_update_slips_from: testing
+  testing_branch_to_update_slips_from: origin/feature_branch
+```
+
+When the channel is `testing`, Slips sanitizes
+`testing_branch_to_update_slips_from` before using it in git operations. If the
+channel or testing branch is invalid, it falls back to `stable`.
 
 now whenever a new version of Slips is available, it will update itself and the new slips will use the same CLI as the old one.
 
+During this live update, Slips also updates its git submodules. If local P2P is enabled, the restarted updated process rebuilds the `p2p4slips` binary before the P2P module starts.
+
 ## Manual update
 
 If you do not use `auto_update_slips`, update Slips manually using the method
@@ -166,7 +237,7 @@ repository, then rebuild the image so the new code and dependencies are availabl
 into the container:
 
 ```bash
-git pull --recurse-submodules && git submodule update --init --recursive
+git pull --recurse-submodules origin <branch> && git submodule update --init --recursive
 docker build --target amd --no-cache -t slips -f docker/Dockerfile .
 ```
 
@@ -183,7 +254,7 @@ Then start a new container from the rebuilt image.
 For native installations, first update the repository and all submodules:
 
 ```bash
-git pull --recurse-submodules && git submodule update --init --recursive
+git pull --recurse-submodules origin <branch> && git submodule update --init --recursive
 ```
 
 Then run the installer script:

docs/installation.md

@@ -179,7 +179,8 @@ If you cloned Slips in '~/StratosphereLinuxIPS', then you can build the Docker i
 	cd ~/StratosphereLinuxIPS
 	docker build --target amd --no-cache -t slips -f docker/Dockerfile .
 	docker run -it --rm --net=host slips
-	./slips.py -c config/slips.yaml -f dataset/test3-mixed.binetflow
+	cp config/slips.yaml config/my_slips.yaml
+	./slips.py -c config/my_slips.yaml -f dataset/test3-mixed.binetflow
 
 If you don't have Internet connection from inside your Docker image while building, you may have another set of networks
 defined in your Docker. For that try:

docs/usage.md

@@ -335,6 +335,21 @@ request to the DNS server 1.2.3.4 asking for slack.com will still be shown.
 
 This whitelist can be enabled or disabled by changing the ```enable_local_whitelist``` key in `config/slips.yaml`.
 
+Do not modify the default ```config/whitelist.conf``` in place. Create a copy, update your copy, and set ```whitelists.local_whitelist_path``` in the Slips config file you are using to point to that copy.
+
+Example:
+
+```bash
+cp config/whitelist.conf config/my_whitelist.conf
+cp config/slips.yaml config/my_slips.yaml
+```
+
+Then set ```local_whitelist_path: config/my_whitelist.conf``` in ```config/my_slips.yaml``` and run Slips with:
+
+```bash
+./slips.py -c config/my_slips.yaml -f dataset/test7-malicious.pcap
+```
+
 The attacker and victim of every evidence are checked against the whitelist. In addition to all the related IPs, DNS resolutions, SNI, and CNAMEs of the attacker and teh victim. If any of them are whitelisted, the flow/evidence is discarded.
 
 Whitelists now use bloom filters to speed up the process of checking if an IoC is whitelisted or not.
@@ -393,7 +408,9 @@ The tranco list is updated daily by default in Slips, but you can change how oft
 Tranco whitelist can be enabled or disabled by changing the ```enable_online_whitelist``` key in `config/slips.yaml`.
 
 ### Whitelisting Example
-You can modify the file ```config/whitelist.conf``` file with this content:
+Do not edit the default ```config/whitelist.conf``` directly. Copy it, set ```local_whitelist_path``` in your copied Slips config file to the copied whitelist file, and modify that copied whitelist instead.
+
+For example, your copied whitelist file can contain:
 
 
     "IoCType","IoCValue","Direction","IgnoreType"
@@ -458,6 +475,15 @@ Even when Slips is run using sudo, it drops root privileges  in modules that don
 
 Slips has a ```config/slips.yaml``` the contains user configurations for different modules and general execution. Below are some of Slips features that can be modifie with respect to the user preferences.
 
+Do not modify the default ```config/slips.yaml``` in place. Keep it as the shipped baseline, create a copy for your local changes, and run Slips with that copy using ```-c```.
+
+Example:
+
+```bash
+cp config/slips.yaml config/my_slips.yaml
+./slips.py -c config/my_slips.yaml -f dataset/test7-malicious.pcap
+```
+
 ### Generic configuration
 
 **Time window width.**
@@ -497,6 +523,12 @@ This setting is separate from the runtime ```feeds_update_manager``` module, whi
 
 Automatic Slips updates may overwrite the default config files shipped with Slips. If you want to keep local config changes safe, do not modify the default config files. Create and use your own config files with different names instead.
 
+Use ```update.channel_to_update_slips_from``` in slips.yaml to choose the update channel:
+
+- ```stable``` -> ```origin/master```
+- ```unstable``` -> ```origin/develop```
+- ```testing``` -> uses the branch specified in ```update.testing_branch_to_update_slips_from```
+
 
 
 <div class="zoom">
@@ -746,7 +778,7 @@ this file can be used for training Slips RNN module.
 
 ## Slips parameters
 
-- ```-c``` or  ```--config``` Used for changing then path to the Slips config file. default is config/slips.yaml
+- ```-c``` or  ```--config``` Used for changing then path to the Slips config file. default is config/slips.yaml. It is recommended to copy ```config/slips.yaml``` and pass your copy with ```-c``` instead of editing the default file.
 - ```-v``` or  ```--verbose``` Verbosity level. This logs more info about Slips.
 - ```-e``` or  ```--debug``` Debugging level. This shows more detailed errors.
 - ```-f``` or  ```--filepath``` Read and automatically recognize a Zeek dir, a Zeek conn.log file, a Suricata JSON file, Argus, PCAP.

managers/redis_manager.py

@@ -66,7 +66,7 @@ def log_redis_server_pid(self, redis_port: int, redis_pid: int):
                         "Save the DB\n"
                     )
 
-                zeek_dir = self.main.db.get_zeek_output_dir()
+                zeek_dir = self.main.args.output
 
                 f.write(
                     f"{now},{self.main.input_information},{redis_port},"