ε - Add repo structure: CODEOWNERS, templates, SECURITY.md
Some checks failed
Discord Push Notification / notify (push) Has been cancelled
Some checks failed
Discord Push Notification / notify (push) Has been cancelled
Add branch protection infrastructure: - .github/CODEOWNERS for auto-assign - Issue templates (bug report, feature request) - PR template with checklist - SECURITY.md with disclosure policy - Update CONTRIBUTING.md with branch workflow and ε commit prefix
This commit is contained in:
Eun0us
parent
c94555d934
commit
920e8ec0bd
12
.github/CODEOWNERS
vendored
Normal file
12
.github/CODEOWNERS
vendored
Normal file
@ -0,0 +1,12 @@
|
|||||||
|
# Default owner for all files
|
||||||
|
* @Eun0us
|
||||||
|
|
||||||
|
# ESP32 firmware
|
||||||
|
espilon_bot/ @Eun0us
|
||||||
|
|
||||||
|
# C3PO server
|
||||||
|
tools/C3PO/ @Eun0us
|
||||||
|
|
||||||
|
# Tools
|
||||||
|
tools/deploy.py @Eun0us
|
||||||
|
tools/espmon/ @Eun0us
|
||||||
43
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
43
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
name: Bug Report
|
||||||
|
about: Report a bug in Espilon
|
||||||
|
title: "[BUG] "
|
||||||
|
labels: bug
|
||||||
|
assignees: Eun0us
|
||||||
|
---
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
A clear description of the bug.
|
||||||
|
|
||||||
|
## Steps to Reproduce
|
||||||
|
|
||||||
|
1. ...
|
||||||
|
2. ...
|
||||||
|
3. ...
|
||||||
|
|
||||||
|
## Expected Behavior
|
||||||
|
|
||||||
|
What should happen.
|
||||||
|
|
||||||
|
## Actual Behavior
|
||||||
|
|
||||||
|
What happens instead.
|
||||||
|
|
||||||
|
## Environment
|
||||||
|
|
||||||
|
- **Target**: ESP32 / ESP32-C3 / ESP32-S3
|
||||||
|
- **ESP-IDF version**: v5.x
|
||||||
|
- **Module(s) affected**: mod_xxx
|
||||||
|
- **C3PO version**: (if applicable)
|
||||||
|
- **OS**: Linux / macOS / Windows
|
||||||
|
|
||||||
|
## Logs
|
||||||
|
|
||||||
|
```
|
||||||
|
Paste relevant logs here.
|
||||||
|
```
|
||||||
|
|
||||||
|
## Additional Context
|
||||||
|
|
||||||
|
Any other context (screenshots, config, etc).
|
||||||
28
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
28
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
---
|
||||||
|
name: Feature Request
|
||||||
|
about: Suggest a new feature or module for Espilon
|
||||||
|
title: "[FEAT] "
|
||||||
|
labels: enhancement
|
||||||
|
assignees: Eun0us
|
||||||
|
---
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
What feature or module would you like?
|
||||||
|
|
||||||
|
## Use Case
|
||||||
|
|
||||||
|
Why is this needed? What problem does it solve?
|
||||||
|
|
||||||
|
## Hardware Requirements
|
||||||
|
|
||||||
|
- **Required hardware**: (e.g., MCP2515 for CAN bus, none for software-only)
|
||||||
|
- **Target chip**: ESP32 / ESP32-C3 / ESP32-S3
|
||||||
|
|
||||||
|
## Proposed Implementation
|
||||||
|
|
||||||
|
If you have an idea of how it should work, describe it here.
|
||||||
|
|
||||||
|
## Additional Context
|
||||||
|
|
||||||
|
Any references, links, or documentation.
|
||||||
22
.github/pull_request_template.md
vendored
Normal file
22
.github/pull_request_template.md
vendored
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
## Summary
|
||||||
|
|
||||||
|
Describe what this PR does and why.
|
||||||
|
|
||||||
|
## Changes
|
||||||
|
|
||||||
|
- ...
|
||||||
|
- ...
|
||||||
|
|
||||||
|
## Checklist
|
||||||
|
|
||||||
|
- [ ] Build tested locally (`idf.py build`)
|
||||||
|
- [ ] New module guarded with `#ifdef CONFIG_MODULE_XXX`
|
||||||
|
- [ ] Kconfig entries added (if new module)
|
||||||
|
- [ ] Module registered in `bot-lwip.c` (if new module)
|
||||||
|
- [ ] C3PO routes added (if new commands)
|
||||||
|
- [ ] Documentation updated
|
||||||
|
- [ ] No hardcoded credentials or secrets
|
||||||
|
|
||||||
|
## Breaking Changes
|
||||||
|
|
||||||
|
List any breaking changes (command renames, protobuf schema changes, etc), or "None".
|
||||||
@ -326,65 +326,74 @@ mypy tools/c2/
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## Branch Workflow
|
||||||
|
|
||||||
|
### Branch Structure
|
||||||
|
|
||||||
|
- `main` — stable releases only, protected (no direct push)
|
||||||
|
- `ε-dev` — main development branch
|
||||||
|
- `feat/xxx` — feature branches (e.g., `feat/mod-ble`)
|
||||||
|
- `fix/xxx` — bug fix branches (e.g., `fix/crypto-leak`)
|
||||||
|
|
||||||
|
### Workflow
|
||||||
|
|
||||||
|
1. Create a feature branch from `main`: `git checkout -b feat/mod-ble main`
|
||||||
|
2. Develop and commit on your branch
|
||||||
|
3. Open a Pull Request to `main`
|
||||||
|
4. Merge after review / validation
|
||||||
|
|
||||||
|
### Rules
|
||||||
|
|
||||||
|
- Never push directly to `main`
|
||||||
|
- Feature branches are deleted after merge
|
||||||
|
- Keep branches short-lived (one feature per branch)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Commit Guidelines
|
## Commit Guidelines
|
||||||
|
|
||||||
### Commit Message Format
|
### Commit Message Format
|
||||||
|
|
||||||
|
All commits use the `ε -` prefix:
|
||||||
|
|
||||||
```
|
```
|
||||||
<type>(<scope>): <subject>
|
ε - Short description of the change
|
||||||
|
|
||||||
<body>
|
|
||||||
|
|
||||||
<footer>
|
|
||||||
```
|
```
|
||||||
|
|
||||||
**Types**:
|
For multi-line commits:
|
||||||
- `feat`: New feature
|
|
||||||
- `fix`: Bug fix
|
|
||||||
- `docs`: Documentation changes
|
|
||||||
- `style`: Code style (formatting, no logic change)
|
|
||||||
- `refactor`: Code refactoring
|
|
||||||
- `test`: Add or modify tests
|
|
||||||
- `chore`: Build system, dependencies, etc.
|
|
||||||
|
|
||||||
**Scope** (optional): Module or component affected
|
```
|
||||||
|
ε - Short description
|
||||||
|
|
||||||
- `core`, `mod_network`, `mod_fakeap`, `mod_tunnel`, `mod_redteam`, `mod_honeypot`, `mod_canbus`, `c2`, `docs`, etc.
|
Longer explanation of what changed and why.
|
||||||
|
Reference issues with Closes #123 or Fixes #456.
|
||||||
|
```
|
||||||
|
|
||||||
**Examples**:
|
**Examples**:
|
||||||
```
|
|
||||||
feat(mod_network): add ARP scanning functionality
|
|
||||||
|
|
||||||
Implements ARP scanner with batch processing to discover
|
```
|
||||||
devices on local network. Scans /24 subnet in ~30 seconds.
|
ε - Add BLE scanner module
|
||||||
|
|
||||||
|
Implements mod_ble with passive scanning, device tracking,
|
||||||
|
and beacon spoofing. Uses built-in ESP32 BLE controller.
|
||||||
|
|
||||||
Closes #42
|
Closes #42
|
||||||
|
```
|
||||||
|
|
||||||
---
|
```
|
||||||
|
ε - Fix memory leak in crypto module
|
||||||
|
```
|
||||||
|
|
||||||
fix(core): prevent memory leak in crypto module
|
```
|
||||||
|
ε - Update README for v0.3.0
|
||||||
Free allocated buffer after Base64 encoding.
|
|
||||||
Fixes memory leak that caused crashes after ~1000 messages.
|
|
||||||
|
|
||||||
Fixes #55
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
docs(install): add GPRS setup instructions
|
|
||||||
|
|
||||||
Adds detailed wiring diagrams and configuration steps
|
|
||||||
for SIM800 module integration.
|
|
||||||
```
|
```
|
||||||
|
|
||||||
**Rules**:
|
**Rules**:
|
||||||
- Subject line: 50 characters or less
|
- Always start with `ε - `
|
||||||
- Subject: Imperative mood ("add" not "added" or "adds")
|
- Subject: imperative mood ("Add" not "Added")
|
||||||
- Subject: Lowercase (except proper nouns)
|
- Subject: 50 characters or less (after prefix)
|
||||||
- Subject: No period at end
|
- Body: explain what and why (not how)
|
||||||
- Body: Wrap at 72 characters
|
- Footer: reference issues (Closes #123, Fixes #456)
|
||||||
- Body: Explain what and why (not how)
|
|
||||||
- Footer: Reference issues (Closes #123, Fixes #456)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
39
SECURITY.md
Normal file
39
SECURITY.md
Normal file
@ -0,0 +1,39 @@
|
|||||||
|
# Security Policy
|
||||||
|
|
||||||
|
## Supported Versions
|
||||||
|
|
||||||
|
| Version | Supported |
|
||||||
|
|---------|-----------|
|
||||||
|
| v0.3.x | Yes |
|
||||||
|
| < v0.3 | No |
|
||||||
|
|
||||||
|
## Reporting a Vulnerability
|
||||||
|
|
||||||
|
If you discover a security vulnerability in Espilon, please report it responsibly.
|
||||||
|
|
||||||
|
**Do NOT open a public issue.**
|
||||||
|
|
||||||
|
Send an email to: **espilon-security@proton.me**
|
||||||
|
|
||||||
|
Include:
|
||||||
|
- Description of the vulnerability
|
||||||
|
- Steps to reproduce
|
||||||
|
- Impact assessment
|
||||||
|
- Suggested fix (if any)
|
||||||
|
|
||||||
|
You will receive a response within 72 hours. We will work with you to understand and address the issue before any public disclosure.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
This policy covers:
|
||||||
|
- ESP32 firmware (`espilon_bot/`)
|
||||||
|
- C3PO control server (`tools/C3PO/`)
|
||||||
|
- Cryptographic implementation (ChaCha20-Poly1305, HKDF)
|
||||||
|
- Network protocols and command dispatch
|
||||||
|
|
||||||
|
## Responsible Disclosure
|
||||||
|
|
||||||
|
We ask that you:
|
||||||
|
- Allow reasonable time to fix the issue before public disclosure
|
||||||
|
- Do not exploit the vulnerability beyond what is necessary to demonstrate it
|
||||||
|
- Do not access or modify data belonging to others
|
||||||
Loading…
Reference in New Issue
Block a user