akkartik
/
teliva
1
1
Fork 0
Code Issues Pull Requests Releases Activity
teliva/manual_tests

40 lines
1.9 KiB
Plaintext
Raw Permalink Normal View History

why not keep manual tests in the repo?
2021-11-29 16:18:28 +00:00
run a program
run a program, edit
run a program, edit, make an edit, run | edit takes effect
run a program with error | big picture
run a program, edit, make an error, run
run a program, edit, ^g to a different definition, make an edit, ^e to run again
run a program, edit, ^g to a non-existent definition
run a program, edit, ^g to a different definition, ^g to a different definition, ^e to run again
start -> big picture -> edit -> move cursor -> run -> edit | cursor preserved
start -> big picture -> edit A -> move cursor -> big picture -> edit B | cursor initialized
start -> big picture -> edit -> move cursor -> run -> exit -> start | big picture (optional)
start -> big picture -> edit A -> move cursor -> run -> exit -> start -> ... -> edit B | cursor initialized
start -> big picture -> edit A -> move cursor -> run -> exit -> start -> ... -> edit B | big picture
syntax highlighting for line comments
syntax highlighting for multiline comments
stop leaking on the Lua stack, redux An empty stack is too rigorous a line to hold. Instead we'll just ensure we leave the stack the way we found it.
2021-12-17 04:07:59 +00:00
start -> big picture -> recent changes -> add note -> save | note visible
arrow keys in big picture view
2021-12-22 03:52:49 +00:00
start -> big picture -> arrow keys* | always exactly one definition highlighted
stop leaking on the Lua stack, redux An empty stack is too rigorous a line to hold. Instead we'll just ensure we leave the stack the way we found it.
2021-12-17 04:07:59 +00:00
It's very important not to leak space on the Lua stack, particularly
proportionate to keypresses. That's a recipe for segfaults.
This implies that bouncing around between big picture, editor, recent changes,
running app.. shouldn't grow the call stack either.
keep Teliva apps from pretending to be Teliva Kind of a subtle idea. Teliva the framework is intended to be trustworthy software that people install on their computers. The apps people run using Teliva may be less trustworthy. The whole point of Teliva is to provide a sandbox for running code before you trust it. One way (of many) apps can be malicious is by subtly getting between what people see and reality. Imagine, for example, an app that draws a fake menu bar and offers a different hotkey to edit source code. When someone presses that hotkey they think they're using the standard Teliva editor but they're really using an editor within the app, which the app uses to hide its most malicious bits from view. Down the road Teliva will have more bits of UI, such as for asking for permission to read sensitive data. It's important that people understand what they're granting permission to, that apps can't tamper with the communications channel between them and Teliva. This is likely just one of many ways for an app to break out of its sandbox. Teliva isn't sandboxed yet. I'm just taking my first steps on this journey. In particular, there are other mechanisms for asking for user input besides `getch()`. I don't yet have a big-picture view of the Teliva sandbox. It seems clear that I need to educate people on the difference between different parts of screen. Depending on the app you install, most of the screen may be a dark forest. It'll be important to know where the safe path is, where you can speak to trusted advisors while in the forest.
2021-12-21 23:13:52 +00:00
== security/privacy
program draws over menu -> getch -> Teliva menu is still visible
new potential threat vector
2022-02-02 05:06:17 +00:00
protect framework files from apps There's a separate open question here of where Teliva should store files like teliva_editor_state and teliva_editor_buffer. One school of thought is that apps should never be dropping crud into people's directories. On the other hand, I'm kinda encouraging people so far to just run apps from Teliva's directory. Perhaps that makes it ok?
2022-03-09 03:20:53 +00:00
app tries to read/write sensitive teliva files (teliva_edit_buffer, etc.) -> never allowed
TODO should we protect .c sources?
more thoughts on sandboxing
2022-02-05 21:10:39 +00:00
question raised during FOSDEM '22 https://fosdem.org/2022/schedule/event/lastmilesandboxing
2022-02-08 05:52:04 +00:00
TODO protect against DoS attack filling up disk
more thoughts on sandboxing
2022-02-05 21:10:39 +00:00
assumptions:
listing files in a directory is not worth sandboxing
since reading their contents is sandboxed
and since UNIX permissions protect system directories
rmdir() is not worth sandboxing, since it only succeeds on empty directories
no need to sandbox unlink() since it's not exposed