This is an academic project with no production deployment and no commercial use. Under the EU Cyber Resilience Act (CRA), non-commercial free and open-source software is exempt from the mandatory requirements that apply to commercial manufacturers. This project voluntarily adopts CRA-aligned security practices anyway — not because it is required, but because it is the right thing to do.
Only the latest version on the master branch is supported. There are no
long-term support versions.
| Version | Supported |
|---|---|
Latest (master) |
Yes |
| Older commits | No |
These are known, accepted limitations — not bugs to report:
-
Wide character rendering in Windows PowerShell / CMD: PowerShell and CMD replace CJK ideographs and many emoji with
?before the characters reach the JVM. The library handles wide characters correctly (verified by the automated test suite), but interactive testing from those terminals is not possible. Use IntelliJ's built-in terminal or Windows Terminal withchcp 65001. -
Supplementary-plane emoji (U+1F300 and above):
Cellstores characters aschar(a UTF-16 code unit). Code points above U+FFFF are detected correctly but stored with loss of the high surrogate. This is a known trade-off documented in the README. -
No input validation at network or process boundaries: This is an in-process data structure library. It does not handle untrusted external input and does not perform sanitization. Callers are responsible for validating input before passing it to the buffer.
-
Scrollback access is O(n): Random access by index iterates the internal
ArrayDeque. This is a performance characteristic, not a security issue.
- Memory safety issues in buffer operations (e.g.
resize,insertText) - Incorrect data isolation between screen and scrollback (e.g. mutation of scrollback rows after they are pushed off-screen)
- Logic errors that could cause data loss or silent corruption of buffer state
- Wide character rendering in Windows PowerShell / CMD (see Known Limitations)
- Performance issues that do not affect correctness or data safety
- Theoretical vulnerabilities with no realistic attack vector given the library's use case (in-process data structure, no network, no I/O)
Do not open a public GitHub issue for security vulnerabilities.
Send an email to ignacio.garbayo@rai.usc.es with:
- Subject:
[SECURITY] terminal-text-buffer — <brief description> - A description of the vulnerability and its potential impact
- Steps to reproduce or a minimal reproducing example
- Any suggested fix, if you have one
Subject:
[SECURITY] terminal-text-buffer — resize allows negative widthCalling
buf.resize(-1, 24)throws an uncheckedNegativeArraySizeExceptioninstead of the documentedIllegalArgumentException, causing the buffer to enter an inconsistent state if the exception is caught upstream.Reproducer:
TerminalBuffer buf = new TerminalBuffer(80, 24, 100); try { buf.resize(-1, 24); } catch (Exception e) { /* ignored */ } // buf is now broken
| Stage | Target time |
|---|---|
| Acknowledgement | 72 hours |
| Initial assessment | 14 days |
| Fix or mitigation | Best-effort (academic project, no SLA) |
These timelines are targets, not guarantees. This is a student project — exams and coursework take priority. If you do not hear back within 72 hours, a follow-up email is welcome.
This project follows coordinated disclosure:
- You report privately.
- The maintainer confirms and works on a fix.
- A fixed version is released.
- The vulnerability is disclosed publicly, with credit to the reporter if desired.
Public disclosure should not happen before 90 days from the initial report, unless both parties agree otherwise.
This is a student academic project. There is no bug bounty programme.