40 lines
1.9 KiB
Raw Normal View History

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
start -> big picture -> recent changes -> add note -> save | note visible
2021-12-22 03:52:49 +00:00
start -> big picture -> arrow keys* | always exactly one definition highlighted
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
2022-02-02 05:06:17 +00:00
app tries to read/write sensitive teliva files (teliva_edit_buffer, etc.) -> never allowed
TODO should we protect .c sources?
2022-02-05 21:10:39 +00:00
TODO protect against DoS attack filling up disk
2022-02-05 21:10:39 +00:00
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