proc-cli 1.3.3

A semantic CLI tool for process management
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

# Security Policy

## Supported Versions

| Version | Supported          |
| ------- | ------------------ |
| 1.2.x   | :white_check_mark: |
| 1.1.x   | :white_check_mark: |
| 1.0.x   | :white_check_mark: |
| < 1.0   | :x:                |

## Reporting a Vulnerability

We take security seriously. If you discover a security vulnerability in proc, please report it responsibly.

### How to Report

**DO NOT** create a public GitHub issue for security vulnerabilities.

Instead, please email security concerns to: **[me@yazeed.com](mailto:me@yazeed.com)**

Include the following information:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)

### What to Expect

1. **Acknowledgment**: We will acknowledge receipt of your report within 48 hours.

2. **Investigation**: We will investigate the issue and determine its severity.

3. **Communication**: We will keep you informed of our progress.

4. **Resolution**: We will work to resolve the issue as quickly as possible.

5. **Credit**: We will credit you in the release notes (unless you prefer to remain anonymous).

### Response Timeline

- **Critical vulnerabilities**: Patch within 24-48 hours
- **High severity**: Patch within 1 week
- **Medium severity**: Patch within 2 weeks
- **Low severity**: Patch in next regular release

## Security Considerations

### Design Principles

proc is designed with security in mind:

1. **No Network Access**: proc only accesses local system information. It does not make network requests or phone home.

2. **No Data Collection**: proc does not collect, store, or transmit any user data or telemetry.

3. **Minimal Privileges**: proc runs with the privileges of the invoking user. It does not require or request elevated privileges except when explicitly needed (e.g., killing processes owned by other users).

4. **Safe Defaults**: Destructive operations (like `kill`) require confirmation by default.

5. **Input Validation**: All user inputs are validated to prevent injection attacks.

6. **Memory Safety**: Written in Rust, which provides memory safety guarantees.

### Dependencies

We carefully vet all dependencies:

- Minimal dependency tree
- Only well-maintained, widely-used crates
- Regular dependency audits with `cargo audit`
- Pinned versions via `Cargo.lock`

### Known Limitations

1. **Process Information Access**: On some systems, proc may not be able to access information about processes owned by other users without elevated privileges.

2. **Signal Sending**: Killing processes owned by other users requires appropriate permissions (typically root/sudo).

3. **Port Information**: Retrieving port information may require elevated privileges on some systems.

## Security Best Practices for Users

1. **Review before killing**: Always verify the processes you're about to kill, especially when using wildcards or patterns.

2. **Use dry-run mode**: When uncertain, use `--dry-run` to see what would happen without making changes.

3. **Avoid running as root**: Run proc with regular user privileges when possible. Only use sudo when necessary.

4. **Keep proc updated**: Install security updates when available.

## Audit History

| Date | Type | Findings | Resolution |
|------|------|----------|------------|
| 2026-01-12 | v1.0.0 Release | N/A | N/A |

## Contact

For security concerns: [me@yazeed.com](mailto:me@yazeed.com)

For general questions: [GitHub Issues](https://github.com/yazeed/proc/issues)