Matsubaa
941a9da928
- Added goals for defining personal data categories and retention obligations. - Included exit criteria for user-level moderation, personal collections, and self-service data export. - Expanded Phase 2 goals to include remote actor moderation and shareable block lists. chore: Update flake.nix to specify main program - Set the main program for the project in the flake configuration. feat: Add issue templates for bug reports, feature requests, and questions - Created structured templates to streamline issue reporting and feature suggestions. docs: Add pull request template for consistent contributions - Introduced a PR template to guide contributors on providing necessary information. docs: Establish a Code of Conduct for community behavior - Implemented a Code of Conduct to promote a respectful and inclusive environment. docs: Create Diversity, Equity, and Inclusion (DEI) statement - Outlined commitment to diversity and inclusion within the FeDIY community. docs: Define Code Review Guidelines for constructive feedback - Established guidelines to ensure respectful and effective code reviews. docs: Implement Security Policy for vulnerability reporting - Created a security policy detailing how to report vulnerabilities and our commitment to addressing them.
94 lines
4.2 KiB
Markdown
94 lines
4.2 KiB
Markdown
# Security Policy
|
|
|
|
## Reporting Security Vulnerabilities
|
|
|
|
FeDIY takes security seriously. If you discover a security vulnerability in the project, we appreciate your help in disclosing it responsibly.
|
|
|
|
**Please do not open a public GitHub issue for security vulnerabilities.**
|
|
|
|
Instead, please report security issues by emailing [security@moturpin.com] with:
|
|
|
|
- A clear description of the vulnerability
|
|
- Steps to reproduce the issue (if possible)
|
|
- Potential impact on users and systems
|
|
- Any proposed fixes you may have
|
|
|
|
You can also use GitHub's private vulnerability reporting feature by navigating to the Security tab of the repository and clicking "Report a vulnerability."
|
|
|
|
## What We Commit To
|
|
|
|
- **Acknowledge receipt** of your report within 48 hours
|
|
- **Provide an initial assessment** of the vulnerability within 5 business days
|
|
- **Keep you informed** of progress toward a fix
|
|
- **Publish security advisories** for confirmed vulnerabilities, with credit to the reporter (unless you prefer to remain anonymous)
|
|
- **Work toward a coordinated disclosure** timeline with you
|
|
|
|
## Security Expectations
|
|
|
|
While we work to maintain FeDIY's security, please understand:
|
|
|
|
- FeDIY is an open source project maintained by volunteers. Response times may vary.
|
|
- We follow responsible disclosure practices and expect the same from reporters.
|
|
- We ask that you allow us a reasonable time (typically 30-90 days) to release a patch before public disclosure.
|
|
- If you'd like to discuss timeline adjustments, please let us know.
|
|
|
|
## Security Best Practices for Users
|
|
|
|
### Running FeDIY
|
|
|
|
- **Keep dependencies updated.** Rust dependencies are managed via Cargo. Regularly run `cargo update` to get security patches.
|
|
- **Use HTTPS.** When deploying FeDIY, use HTTPS for all connections to prevent eavesdropping.
|
|
- **Secure your database.** PostgreSQL (or SQLite) instances should be properly secured with strong authentication and restricted network access.
|
|
- **Audit access.** Regularly review who has administrative access to your FeDIY instance.
|
|
- **Monitor logs.** Watch logs for suspicious activity and configure alerting for authentication failures.
|
|
|
|
### ActivityPub Federation
|
|
|
|
- FeDIY federates via ActivityPub. Be aware that activities may be shared with other federated instances.
|
|
- Instances should enforce their own content policies and block malicious instances if needed.
|
|
- User data shared via federation should be treated as public and potentially persistent.
|
|
|
|
## Development Security
|
|
|
|
Contributors should:
|
|
|
|
- **Review code carefully.** Security vulnerabilities can hide in unexpected places. Code review is our first defense.
|
|
- **Use secure coding practices.** Avoid SQL injection, XSS, CSRF, and other common vulnerabilities. See [OWASP Top 10](https://owasp.org/www-project-top-ten/) for reference.
|
|
- **Validate all input.** Never trust user input. Always validate and sanitize data before processing.
|
|
- **Use type safety.** Rust's type system prevents many classes of vulnerabilities. Use it effectively.
|
|
- **Document security decisions.** If you make security-related changes, document the reasoning in commit messages or ADRs.
|
|
|
|
## Supported Versions
|
|
|
|
| Version | Status | Security Updates |
|
|
|---------|--------|------------------|
|
|
| 0.1.x | Alpha | Best effort |
|
|
| Future | TBD | Will be defined |
|
|
|
|
**Note:** During the early alpha phase (v0.1), security patches may be released ad-hoc. As the project matures, we will establish a formal versioning and patching policy.
|
|
|
|
## Vulnerability Disclosure
|
|
|
|
When we discover or are notified of a security vulnerability, we will:
|
|
|
|
1. Confirm the vulnerability and assess its severity
|
|
2. Develop and test a fix
|
|
3. Coordinate a release with security patches
|
|
4. Publish a security advisory with details and credit
|
|
5. Acknowledge and thank the reporter
|
|
|
|
## Security Contacts
|
|
|
|
- **Email:** security@moturpin.com
|
|
- **GitHub Security Advisory:** Use the "Report a vulnerability" tab in the GitHub repository
|
|
|
|
## Additional Resources
|
|
|
|
- [OWASP Application Security](https://owasp.org/)
|
|
- [Rust Security Guidelines](https://anssi-fr.github.io/rust-guide/)
|
|
- [CISA Secure Software Development Framework](https://csrc.nist.gov/projects/secure-software-development-framework/)
|
|
|
|
---
|
|
|
|
**Last Updated:** May 2026
|