**Bug impact levels**
1. **Critical**
1. Functional error that makes an entire subsystem unusable.
2. //or// a vulnerability that allows a remote attacker to cause DoS or execute code/commands without authentication.
3. There is no workaround or it still amounts to making a subsystem unusable (e.g., the only way to avoid arbitrary code execution is to disable the vulnerable subsystem).
4. If a bug makes VyOS completely unusable on any supported platform (e.g., it fails to boot on it), it's automatically considered critical.
2. **Major**
1. Functional error that makes specific configurations completely unusable.
2. //or// a vulnerability that doesn't allow attackers to gain control of the system but can be exploited remotely to cause functionality degradation (complete process crash or overload).
2. A workaround may exist but isn't easy to execute (e.g., changing a `sysctl` option outside of the CLI fixes the problem)
3. **Minor**
1. Functional error that causes functionality degradation.
2. //or// a vulnerability that can only be exploited from the local system (since all users are admin users in VyOS now, they can `kill -9` any process or edit any file anyway).
3. There is an easy workaround //within the VyOS CLI// (e.g., changing a config option from its default fixes the problem).
4. **Trivial**
1. Has no impact on functionality (e.g., formatting issue in command output).
A **workaround** is a sequence of commands that users can execute on existing systems to make the bug go away (an updated package or a patch to apply in-place is a hotfix, that's a different story).
**Mitigation procedures for bugs in LTS releases**
1. **Critical** — immediate notification (if it's a vulnerability, a private email notification is sent to customers first), maintenance release ASAP.
2. **Major** — maintenance release ASAP, but no immediate notification necessary.
3. **Minor** — routine inclusion in the next maintenance release.
4. **Trivial** — may be left unfixed if higher priority issues exist.