Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
# Contributing to kapps

Thank you for your interest in contributing to kapps! This project builds signed applications for [Krux](https://github.com/selfcustody/krux) devices.

## Getting started

1. Fork the repository
2. Clone your fork with submodules: `git clone --recursive <your-fork-url>`
3. Install dependencies: `uv sync`
4. Install pre-commit hooks: `uv run pre-commit install --install-hooks`

## How to contribute

### Reporting bugs

- Open an [issue](https://github.com/selfcustody/kapps/issues/new?template=bug_report.md) with the bug report template
- Be specific about the steps to reproduce
- Include device model and firmware version

### Requesting features

- Open an [issue](https://github.com/selfcustody/kapps/issues/new?template=enhancement.md) with the enhancement template
- Describe the use case and expected behavior

### Submitting pull requests

1. Start a discussion or issue before working on large changes
2. Branch off `main`
3. Follow [Conventional Commits](https://www.conventionalcommits.org/) for commit messages:
- `feat:` new feature
- `fix:` bug fix
- `docs:` documentation
- `test:` tests
- `build:` build system
- `ci:` CI/CD
- `refactor:` code refactoring
- `style:` formatting
- `chore:` maintenance
- `i18n:` translations
4. Each PR should focus on solving one issue
5. Ensure all pre-commit hooks pass before submitting
6. Explain what the PR solves and why

### Changes checklist

- [ ] Code changes include tests
- [ ] Pre-commit hooks pass (`uv run pre-commit run --all-files`)
- [ ] Commit messages follow conventional commits

## Code style

- **Formatting**: [black](https://github.com/psf/black) (enforced by pre-commit)
- **Import sorting**: [isort](https://pycqa.github.io/isort/) with black profile
- **Linting**: [pylint](https://pylint.org/) (errors-only in pre-commit)
- **Dead code**: [vulture](https://github.com/jendrikseipp/vulture)
- **Spell checking**: [typos](https://github.com/crate-ci/typos)

## Writing a kapp

A kapp is a Python module in `src/` that runs on Krux devices. Kapps can use the full `krux` API (display, input, settings, pages, themes, etc.).

Each kapp should:

1. Have a corresponding test in `tests/kapps/`
2. Follow the existing code style
3. Import from `krux` for device interaction

## Questions?

Open a [discussion](https://github.com/selfcustody/kapps/discussions) or reach the community via the [Krux Telegram group](https://t.me/kraboratory).
40 changes: 40 additions & 0 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Security Policy

## Disclaimer

**WARNING:** This software has not yet been formally audited by a third party. Use at your own risk!

Kapps are signed applications that run on [Krux](https://github.com/selfcustody/krux) signing devices. While we take security seriously, the code handles sensitive cryptographic operations and should be treated accordingly.

## Supported versions

| Version | Supported |
|---------|-----------|
| Latest release | Yes |
| Previous releases | No |

## Reporting a vulnerability

If you discover a security vulnerability, please report it responsibly:

1. **Do not** open a public issue
2. Email the maintainers at `tadeubas@gmail.com` with:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
3. Allow reasonable time for a fix before public disclosure

## Security considerations

- Kapps handle private keys, mnemonics, and other sensitive data
- All kapps are compiled to `.mpy` and must be signed before execution on devices
- The device verifies kapp signatures before running them
- Review kapp source code before compiling and signing

## Best practices for kapp developers

- Never log or persist private keys or mnemonics
- Clear sensitive data from memory as soon as it is no longer needed
- Use the `krux` API for cryptographic operations rather than custom implementations
- Test edge cases around key handling and data validation