Adam ShiervaniandGitHub
8e7b6ce4e3
* fix(ota): reject empty signature and require prerelease opt-in for bypass Two OTA signature verification vulnerabilities: 1. Empty signature bypass: downloadSignature accepted a 0-byte response, which caused verifyFile to skip GPG verification entirely via the len(signature) > 0 guard. An attacker serving an empty .sig file could bypass signature checks on any stable release. 2. Prerelease bypass without opt-in: shouldBypassSignatureCheck only checked whether the remote version had a prerelease suffix, not whether the device had opted into the dev channel. A compromised server could push a version like "99.0.0-dev.1" to any device and skip signature verification regardless of include_pre_release setting. Fixes: - downloadSignature now returns an error when signature bytes are empty - shouldBypassSignatureCheck takes includePreRelease param and requires it to be true before allowing prerelease bypass Unit tests added for: empty signature, hash mismatch, non-200 sig download, valid signature happy path, and prerelease opt-in table tests. Made-with: Cursor * test(e2e): add OTA signature edge case and prerelease rejection tests Add wrong-key signature, empty signature, and prerelease-without-opt-in E2E tests to catch signature bypass vulnerabilities on real devices. Made-with: Cursor * refactor(e2e): use Playwright projects and remove OTA shell scripts Organize E2E tests into named Playwright projects (core, ota-signed, ota-prerelease-unsigned, etc.) so each test suite can be run with --project=<name>. Remove 5 OTA wrapper scripts that were just boilerplate env-var setup, and inline them into the Makefile via a shared OTA_ENV macro. Rename z-ota-* specs to ota-* now that ordering is controlled by project selection, not alphabetical filename sorting. Made-with: Cursor * fix(ci): use Go 1.25 for golangci-lint to match build workflow golangci-lint v2.1.6 (built with Go 1.24) panics when type-checking code that requires Go 1.25. Align the lint workflow with build.yml by using go-version: ^1.25.1 instead of oldstable. Made-with: Cursor
JetKVM is a high-performance, open-source KVM over IP (Keyboard, Video, Mouse) solution designed for efficient remote management of computers, servers, and workstations. Whether you're dealing with boot failures, installing a new operating system, adjusting BIOS settings, or simply taking control of a machine from afar, JetKVM provides the tools to get it done effectively.
Features
- Ultra-low Latency - 1080p@60FPS video with 30-60ms latency using H.264 encoding. Smooth mouse and keyboard interaction for responsive remote control.
- Free & Optional Remote Access - Remote management via JetKVM Cloud using WebRTC.
- Open-source software - Written in Golang on Linux. Easily customizable through SSH access to the JetKVM device.
Contributing
We welcome contributions from the community! Whether it's improving the firmware, adding new features, or enhancing documentation, your input is valuable. We also have some rules and taboos here, so please read this page and our Code of Conduct carefully.
I need help
The best place to search for answers is our Documentation. If you can't find the answer there, check our Discord Server.
I want to report an issue
If you've found an issue and want to report it, please check our Issues page. Make sure the description contains information about the firmware version you're using, your platform, and a clear explanation of the steps to reproduce the issue.
Development
JetKVM is written in Go & TypeScript. with some bits and pieces written in C. An intermediate level of Go & TypeScript knowledge is recommended for comfortable programming.
The project contains two main parts, the backend software that runs on the KVM device and the frontend software that is served by the KVM device, and also the cloud.
For comprehensive development information, including setup, testing, debugging, and contribution guidelines, see DEVELOPMENT.md.
For quick device development, use the ./dev_deploy.sh script. It will build the frontend and backend and deploy them to the local KVM device. Run ./dev_deploy.sh --help for more information.
Backend
The backend is written in Go and is responsible for the KVM device management, the cloud API and the cloud web.
Frontend
The frontend is written in React and TypeScript and is served by the KVM device. It has three build targets: device, development and production. Development is used for development of the cloud version on your local machine, device is used for building the frontend for the KVM device and production is used for building the frontend for the cloud.