ε - 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 Message Format
|
||||
|
||||
All commits use the `ε -` prefix:
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
<body>
|
||||
|
||||
<footer>
|
||||
ε - Short description of the change
|
||||
```
|
||||
|
||||
**Types**:
|
||||
- `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.
|
||||
For multi-line commits:
|
||||
|
||||
**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**:
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
---
|
||||
```
|
||||
ε - Fix memory leak in crypto module
|
||||
```
|
||||
|
||||
fix(core): prevent memory leak in crypto module
|
||||
|
||||
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.
|
||||
```
|
||||
ε - Update README for v0.3.0
|
||||
```
|
||||
|
||||
**Rules**:
|
||||
- Subject line: 50 characters or less
|
||||
- Subject: Imperative mood ("add" not "added" or "adds")
|
||||
- Subject: Lowercase (except proper nouns)
|
||||
- Subject: No period at end
|
||||
- Body: Wrap at 72 characters
|
||||
- Body: Explain what and why (not how)
|
||||
- Footer: Reference issues (Closes #123, Fixes #456)
|
||||
- Always start with `ε - `
|
||||
- Subject: imperative mood ("Add" not "Added")
|
||||
- Subject: 50 characters or less (after prefix)
|
||||
- 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