Skip to content

Commit 561a2a4

Browse files
authored
patch: update dependencies, improve setup configuration, and add Wind… (#4)
* chore: update dependencies, improve setup configuration, and add Windows-specific support * chore: update requirements to include pystray and Pillow for icon support; enhance logging for Npcap initialization * docs: enhance README and DEVELOPER documentation with new features, UI components, and system tray integration details * docs: add issue templates for feature requests and bug reports; create CODEOWNERS and contributing guidelines * ci: add test dependencies and improve test configuration; implement system requirements tests * ci: update GitHub Actions workflow for documentation build and deployment; upgrade actions and improve downloads page generation * ci: enhance CI workflows for macOS icon generation and add frontend CI/CD pipeline; include Vercel deployment configuration * ci: remove linting step from frontend CI workflow to streamline the process * ci: remove test step from frontend CI workflow to optimize deployment process * ci: update platform-specific dependency for pynsis in requirements-build.txt * ci: update pynsist dependency version for Windows platform in requirements-build.txt * ci: enhance CI workflows for icon generation on Windows and macOS; update frontend deployment process with Vercel integration * ci: remove frontend CI workflow to streamline deployment process * refactor: clean up code by removing unused dependency checks and fixing whitespace issues * ci: remove iconset directory creation step from CI workflow * refactor: improve error handling and code structure in build process * feat: add Flask and Flask-CORS to build requirements * refactor: enhance CI workflow and build process with improved dependency management and error handling * refactor: update dependency versions in requirements files to align with project specifications * refactor: enhance CI workflow and build process with improved artifact packaging and error handling * feat: add PyInstaller availability check and automatic installation of build dependencies
1 parent 1839227 commit 561a2a4

40 files changed

+4842
-10471
lines changed

.github/CODEOWNERS

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
# These owners will be the default owners for everything in
2+
# the repo. Unless a later match takes precedence,
3+
# @umerfarok will be requested for review when someone
4+
# opens a pull request.
5+
* @umerfarok
6+
7+
# Network monitoring core
8+
/networkmonitor/monitor.py @umerfarok
9+
/networkmonitor/npcap_helper.py @umerfarok
10+
11+
# Web interface
12+
/networkmonitor/web/ @umerfarok
13+
14+
# Build and deployment
15+
/.github/workflows/ @umerfarok
16+
/build.py @umerfarok
17+
/installer.nsi @umerfarok

.github/CODEOWNERS.md

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
# Code Owners Documentation
2+
3+
This document explains the code ownership structure of the NetworkMonitor project.
4+
5+
## Overview
6+
7+
The CODEOWNERS file is used to automatically request reviews from the appropriate team members when a pull request is opened.
8+
9+
## Current Ownership Structure
10+
11+
### Core Components
12+
- **Network Monitoring Core** (@umerfarok)
13+
- `/networkmonitor/monitor.py`
14+
- `/networkmonitor/npcap_helper.py`
15+
16+
### Web Interface
17+
- **Frontend Components** (@umerfarok)
18+
- `/networkmonitor/web/`
19+
20+
### Build & Deployment
21+
- **Build System** (@umerfarok)
22+
- `/build.py`
23+
- `/installer.nsi`
24+
- `/.github/workflows/`
25+
26+
## Review Process
27+
28+
1. When a pull request is opened, GitHub automatically requests reviews from the appropriate code owners.
29+
2. At least one approval from a code owner is required to merge changes.
30+
3. Code owners should review changes within their area of responsibility within 3 business days.
31+
32+
## Becoming a Code Owner
33+
34+
To become a code owner:
35+
1. Demonstrate expertise in the relevant area through contributions
36+
2. Request ownership by opening an issue
37+
3. Get approval from existing code owners
38+
39+
## Contact
40+
41+
For questions about code ownership, contact:
42+
- Umer Farooq (@umerfarok)

.github/CONTRIBUTING.md

Lines changed: 112 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
1+
# Contributing to NetworkMonitor
2+
3+
Thank you for your interest in contributing to NetworkMonitor! We welcome contributions from everyone.
4+
5+
## Getting Started
6+
7+
1. Fork the repository
8+
2. Clone your fork:
9+
```bash
10+
git clone https://github.com/your-username/networkmonitor.git
11+
```
12+
3. Create a virtual environment and install dependencies:
13+
```bash
14+
python -m venv venv
15+
source venv/bin/activate # or `venv\Scripts\activate` on Windows
16+
pip install -r requirements.txt
17+
pip install -r requirements-build.txt
18+
```
19+
20+
## Development Process
21+
22+
1. Create a branch for your changes:
23+
```bash
24+
git checkout -b feature/your-feature-name
25+
```
26+
27+
2. Make your changes, following our coding standards:
28+
- Follow PEP 8 style guide
29+
- Write descriptive commit messages
30+
- Include tests for new features
31+
- Update documentation as needed
32+
33+
3. Test your changes:
34+
```bash
35+
python -m pytest tests/
36+
```
37+
38+
4. Push your changes and create a pull request:
39+
```bash
40+
git push origin feature/your-feature-name
41+
```
42+
43+
## Pull Request Guidelines
44+
45+
1. Fill out the PR template completely
46+
2. Include tests for new features
47+
3. Update documentation if needed
48+
4. Ensure CI passes
49+
5. Request review from appropriate code owners
50+
51+
## Code Style
52+
53+
- Follow PEP 8 conventions
54+
- Use type hints where possible
55+
- Document public functions and classes
56+
- Keep functions focused and concise
57+
- Write descriptive variable names
58+
59+
## Commit Messages
60+
61+
Format:
62+
```
63+
type(scope): description
64+
65+
[optional body]
66+
[optional footer]
67+
```
68+
69+
Types:
70+
- feat: New feature
71+
- fix: Bug fix
72+
- docs: Documentation only
73+
- style: Code style changes
74+
- refactor: Code changes that neither fix bugs nor add features
75+
- test: Adding or modifying tests
76+
- chore: Maintenance tasks
77+
78+
Example:
79+
```
80+
feat(monitor): add packet filtering by protocol
81+
82+
Added support for filtering network packets by protocol type.
83+
Implements #123
84+
```
85+
86+
## Documentation
87+
88+
- Update README.md for user-facing changes
89+
- Update DEVELOPER.md for development changes
90+
- Add comments for complex code sections
91+
- Include docstrings for public APIs
92+
93+
## Testing
94+
95+
- Write unit tests for new features
96+
- Update existing tests when modifying features
97+
- Include integration tests where appropriate
98+
- Test on all supported platforms if possible
99+
100+
## Release Process
101+
102+
1. Version bumps are handled automatically via GitHub Actions
103+
2. Releases are created from the main branch
104+
3. Changelog is generated automatically
105+
4. Builds are created for all platforms
106+
107+
## Getting Help
108+
109+
- Check existing documentation
110+
- Ask in GitHub Discussions
111+
- Contact maintainers:
112+
- Umer Farooq (@umerfarok)
Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
---
2+
name: Bug report
3+
about: Create a report to help us improve NetworkMonitor
4+
title: '[BUG] '
5+
labels: bug
6+
assignees: ''
7+
---
8+
9+
**Describe the bug**
10+
A clear and concise description of what the bug is.
11+
12+
**To Reproduce**
13+
Steps to reproduce the behavior:
14+
1. Go to '...'
15+
2. Click on '....'
16+
3. Scroll down to '....'
17+
4. See error
18+
19+
**Expected behavior**
20+
A clear and concise description of what you expected to happen.
21+
22+
**Screenshots**
23+
If applicable, add screenshots to help explain your problem.
24+
25+
**Environment (please complete the following information):**
26+
- OS: [e.g. Windows 10]
27+
- Python Version: [e.g. 3.9.0]
28+
- NetworkMonitor Version: [e.g. 0.1.0]
29+
- Npcap Version: [e.g. 1.60]
30+
31+
**Log Files**
32+
Please attach the following logs if available:
33+
- NetworkMonitor log (`%LOCALAPPDATA%\NetworkMonitor\logs\networkmonitor.log`)
34+
- Debug log (`networkmonitor_debug.log`)
35+
36+
**Additional context**
37+
Add any other context about the problem here.
Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
---
2+
name: Feature request
3+
about: Suggest an idea for NetworkMonitor
4+
title: '[FEATURE] '
5+
labels: enhancement
6+
assignees: ''
7+
---
8+
9+
**Is your feature request related to a problem? Please describe.**
10+
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
11+
12+
**Describe the solution you'd like**
13+
A clear and concise description of what you want to happen.
14+
15+
**Describe alternatives you've considered**
16+
A clear and concise description of any alternative solutions or features you've considered.
17+
18+
**Additional context**
19+
Add any other context or screenshots about the feature request here.

.github/SECURITY.md

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# Security Policy
2+
3+
## Supported Versions
4+
5+
We currently support the following versions of NetworkMonitor with security updates:
6+
7+
| Version | Supported |
8+
| ------- | ------------------ |
9+
| 0.1.x | :white_check_mark: |
10+
11+
## Reporting a Vulnerability
12+
13+
We take security vulnerabilities seriously. Please follow these steps to report a security issue:
14+
15+
1. **DO NOT** open a public GitHub issue if the bug is a security vulnerability.
16+
2. Instead, please send an email to [email protected] with:
17+
- Subject line: "Security Vulnerability: NetworkMonitor"
18+
- Description of the vulnerability
19+
- Steps to reproduce (if possible)
20+
- Potential impact
21+
- Any suggested fixes (if you have them)
22+
23+
### What to expect:
24+
- Acknowledgment within 48 hours
25+
- Regular updates on the progress
26+
- Credit in the security advisory when the issue is fixed
27+
28+
## Security Best Practices
29+
30+
When using NetworkMonitor:
31+
32+
1. Always run with minimum required privileges
33+
2. Keep the software updated to the latest version
34+
3. Monitor logs for suspicious activity
35+
4. Follow network security best practices
36+
5. Report any security concerns immediately
37+
38+
## Disclosure Timeline
39+
40+
Our standard disclosure timeline:
41+
42+
1. **0 hours**: Initial report received
43+
2. **48 hours**: Initial acknowledgment
44+
3. **7 days**: Initial assessment completed
45+
4. **30 days**: Fix developed and tested
46+
5. **45 days**: Fix released
47+
6. **60 days**: Public disclosure
48+
49+
This timeline may be adjusted based on severity and complexity.
50+
51+
## Security Updates
52+
53+
Security updates are distributed through:
54+
- GitHub Releases
55+
- Security Advisories
56+
- Email notifications (for registered users)
57+
58+
## Code Security
59+
60+
We maintain security through:
61+
62+
1. Regular dependency updates
63+
2. Automated security scanning
64+
3. Code review requirements
65+
4. Security-focused testing
66+
5. Regular security audits
67+
68+
## Acknowledgments
69+
70+
We appreciate the security research community's efforts in responsibly disclosing vulnerabilities. Security researchers who have contributed will be credited in our Hall of Fame (unless they wish to remain anonymous).

.github/pull_request_template.md

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
## Description
2+
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
3+
4+
Fixes # (issue)
5+
6+
## Type of change
7+
Please delete options that are not relevant.
8+
9+
- [ ] Bug fix (non-breaking change which fixes an issue)
10+
- [ ] New feature (non-breaking change which adds functionality)
11+
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
12+
- [ ] This change requires a documentation update
13+
14+
## How Has This Been Tested?
15+
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
16+
17+
- [ ] Test A
18+
- [ ] Test B
19+
20+
## Checklist:
21+
- [ ] My code follows the style guidelines of this project
22+
- [ ] I have performed a self-review of my own code
23+
- [ ] I have commented my code, particularly in hard-to-understand areas
24+
- [ ] I have made corresponding changes to the documentation
25+
- [ ] My changes generate no new warnings
26+
- [ ] I have added tests that prove my fix is effective or that my feature works
27+
- [ ] New and existing unit tests pass locally with my changes
28+
- [ ] Any dependent changes have been merged and published in downstream modules

0 commit comments

Comments
 (0)