major refactoring

Author: tatanus

policy/CODE_OF_CONDUCT.md .github/CODE_OF_CONDUCT.mdpolicy/CODE_OF_CONDUCT.md renamed to .github/CODE_OF_CONDUCT.md

@@ -1,6 +1,6 @@
-# Contributing to BASH
+# Contributing
 
-Welcome to the **BASH** project! We're excited to have you contribute. Whether you're fixing a bug, improving documentation, or proposing a new feature, your contributions are greatly appreciated. Follow the guidelines below to ensure a smooth and productive collaboration.
+Welcome to the project! We're excited to have you contribute. Whether you're fixing a bug, improving documentation, or proposing a new feature, your contributions are greatly appreciated. Follow the guidelines below to ensure a smooth and productive collaboration.
 
 ---
 
@@ -29,8 +29,8 @@ This project adheres to the [Contributor Covenant Code of Conduct](https://www.c
 1. **Fork the repository** to your own GitHub account.
 2. **Clone your fork**:
    ```bash
-   git clone https://github.com/<your-username>/BASH.git
-   cd BASH
+   git clone https://github.com/<your-username>/<project>.git
+   cd <project>
    ```
 3. **Set up the project**:
    - Ensure you have the latest version of Bash installed.
@@ -90,31 +90,24 @@ Documentation improvements are highly valued! If you see errors or areas to enha
 
 ---
 
-## Style Guide
-
-- **Shellcheck and Shfmt**:
-  - Run `shellcheck` with the repository's `.shellcheckrc` file to ensure consistent linting:
-    ```bash
-    shellcheck --shell=bash --external-sources -x -S style -f gcc <your-script.sh>
-    ```
-  - Format all scripts with the following `shfmt` options:
-    ```bash
-    shfmt -i 4 -ci -bn -kp -sr -ln bash -d .
-    ```
-- **Comments**: Use the following template for functions:
-  ```bash
-  ###############################################################################
-  # FUNCTION_NAME
-  # ==============================
-  # Description:
-  # ------------------------------
-  # Usage: FUNCTION_NAME <arg1> <arg2>
-  # Returns: <expected return values>
-  ###############################################################################
-  ```
-- **Naming**: Use descriptive, lowercase function and variable names. Use underscores for multi-word names.
-- **Error Handling**: Always use `set -euo pipefail` for robust error handling.
-- **Modularity**: Break larger scripts into smaller reusable modules.
+## Style Guide & Best Practices
+
+This project uses the tatanus Bash Style Guide (for Bash-based scripts). When contributing scripts or modifications, observe:
+- Strict mode: use set -uo pipefail and IFS=$'\n\t'; do not use set -e.
+- Function documentation: include a proc-doc header with Purpose, Usage, Arguments, Returns, Globals.
+- Naming:
+- Functions: snake_case_name
+- Variables: snake_case
+- Constants: UPPERCASE
+- Logging / output: use printf, not echo -e.
+- Testing conditionals: prefer [[ ... ]] and (( ... )) forms.
+- Pipelines & readability: use display pipes (put | at start of continuation lines).
+- No UUOC: avoid unnecessary cat.
+- Signal handling: trap SIGINT and SIGTERM and exit with a proper code (128 + signal).
+- Dependency validation: scripts should early-check commands or environment (e.g. validate_commands).
+- Linting / formatting: all scripts must pass shellcheck and be formatted with shfmt (as above).
+
+If you’re unfamiliar with any of these rules, see the [bash_style_guide](https://github.com/tatanus/bash_style_guide) repository for full context.
 
 ---
 
@@ -137,6 +130,6 @@ Documentation improvements are highly valued! If you see errors or areas to enha
 
 If you have any questions, feel free to reach out via:
 
-- **Issues**: Use the [Issues](https://github.com/tatanus/BASH/issues) tab.
+- **Issues**: Use the Issues tab in the repository.
 
 Thank you for contributing and helping make **BASH** better!

policy/CONTRIBUTING.md .github/CONTRIBUTING.mdpolicy/CONTRIBUTING.md renamed to .github/CONTRIBUTING.md

@@ -56,7 +56,7 @@ Please complete the checklist below to ensure your PR meets the project standard
   ```bash
   shfmt -i 4 -ci -bn -kp -sr -ln bash -d .
   ```
-- [ ] I have verified that my changes are consistent with the project's [Style Guide](./STYLEGUIDE.md).
+- [ ] I have verified that my changes are consistent with the project's [Style Guide](https://github.com/tatanus/bash_style_guide).
 - [ ] I have updated or added relevant tests (e.g., unit tests, test scripts).
 - [ ] All existing tests pass successfully after my changes.
 - [ ] I have added or updated documentation as needed, and linked any relevant PRs in related repositories (e.g., documentation or tools).

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,76 @@
+# Security Policy
+
+## Supported Versions
+
+The following versions of the project are actively supported for security updates:
+
+| Version   | Supported          |
+|-----------|--------------------|
+| `v1.x`    | ✅ Fully supported |
+| `<v1.0`   | ❌ No longer supported |
+
+Please ensure you're using the latest version of the project to receive the most up-to-date security fixes.
+
+---
+
+## Reporting a Vulnerability
+
+If you discover a security vulnerability in the project, please follow these steps:
+
+1. **Do not disclose the vulnerability publicly**.  
+   - Report it directly to the maintainers so a fix can be developed before disclosure.  
+2. **Submit a private report**:  
+   - Alternative: open a [private security advisory on GitHub](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/creating-a-repository-security-advisory) if available.  
+3. **Wait for acknowledgment**:  
+   - You should receive confirmation within **3 business days**. If you don’t, please follow up.
+
+---
+
+## Vulnerability Disclosure Process
+
+1. Upon receiving a report, the maintainers will:  
+   - Confirm the vulnerability.  
+   - Investigate and develop a fix or mitigation.  
+
+2. Once a fix is ready:  
+   - The reporter will be notified.  
+   - A patch or release will be prepared.  
+   - Security advisories will be drafted.  
+
+3. Public disclosure:  
+   - The vulnerability will be disclosed publicly alongside the fix, after a reasonable grace period to allow users to update.  
+
+---
+
+## Security Best Practices for Contributors
+
+To help keep the project secure, contributors should follow these practices:
+
+1. **Validate Inputs**:  
+   - Always sanitize and validate user inputs to prevent injection vulnerabilities.  
+
+2. **Principle of Least Privilege**:  
+   - Avoid running scripts or code with unnecessary privileges.  
+
+3. **Protect Secrets**:  
+   - Never hardcode sensitive information (e.g., credentials, tokens, API keys).  
+   - Use environment variables or secret managers.  
+
+4. **Static Analysis / Linters**:  
+   - Run project-specific security tools before submitting contributions.  
+   - For Bash projects, this includes:  
+     ```bash
+     shellcheck --shell=bash --external-sources -x -S style -f gcc <script.sh>
+     shfmt -i 4 -ci -bn -kp -sr -ln bash -d .
+     ```
+
+5. **Secure Storage**:  
+   - Encrypt sensitive files and data at rest, or store them in secure locations only.
+
+---
+
+## Contact
+
+For additional security concerns or questions, please contact:  
+- Email: `<security@project.org>`  
+- GitHub Issues: Use the [Issues](../../issues) tab for **non-sensitive reports** only.

.github/SECURITY.md

@@ -0,0 +1,26 @@
+# Support
+
+Thanks for using this project. We aim to keep support lightweight and transparent.
+
+## Where to get help
+- **Questions / How-to**: Open a *Discussion* (Q&A category).
+- **Bugs**: Open an *Issue* using the Bug template. Include:
+  - steps to reproduce, expected vs. actual behavior
+    - OS / distro and version (e.g., Ubuntu 22.04, macOS 14)
+      - `bash --version` and relevant logs (with secrets redacted)
+      - **Feature requests**: Open an *Issue* with the use-case and proposed UX.
+      - **Security issues**: **Do not** open a public issue. See `SECURITY.md` for private reporting.
+
+      ## Service levels (community project)
+      - First response target: **3 business days**
+      - Resolution: best-effort; prioritized by impact and maintainers’ availability
+      - Supported environments (target): Ubuntu LTS (22.04/24.04), macOS 13+ with Homebrew
+
+      ## Before filing
+      - Run the linters/tests locally (see `README.md` and `Makefile`).
+      - Search existing issues/discussions.
+
+      ## Useful links
+      - `README.md` – Quickstart and usage
+      - `CONTRIBUTING.md` – Dev environment, style, commit guidelines
+      - `SECURITY.md` – Security policy and reporting

.github/SUPPORT.md

@@ -68,3 +68,5 @@ build/
 
 .state/
 outputs/
+
+menu_timestamps

.gitignore

@@ -1,4 +1,3 @@
 [submodule "lib/common_core"]
-	branch = main
 	path = lib/common_core
 	url = https://github.com/tatanus/common_core

.gitmodules

@@ -1,6 +1,6 @@
 default: true
 MD013:
-  line_length: 120   # setup docs tend to have longer command lines
+  line_length: 100
   code_blocks: false
 MD024:
   siblings_only: true

.markdownlint.yaml

@@ -0,0 +1,13 @@
+cff-version: 1.2.0
+message: "If you use this software, please cite it as below."
+title: "pentest_setup"
+abstract: "Opinionated Bash-based setup tooling with tests, linting, and CI for consistent developer environments."
+version: "0.9.0"
+date-released: "2025-09-11"
+authors:
+  - given-names: "Adam"
+      family-names: "Compton"
+      repository-code: "https://github.com/tatanus/pentest_setup"
+      license: "MIT"
+      keywords: ["bash", "automation", "setup", "dotfiles", "dev-environment"]
+

CITATION.cff

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2025 Adam Compton
+Copyright (c) 2024 Adam Compton
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal