about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* sandbox: new scenarioKartik K. Agaram2021-12-251-0/+4
|
* more sandboxing scenariosKartik K. Agaram2021-12-251-0/+9
|
* .Kartik K. Agaram2021-12-251-4/+4
|
* .Kartik K. Agaram2021-12-251-1/+1
|
* a little more reorgKartik K. Agaram2021-12-252-82/+87
| | | | | | | | Put stuff people messing with Teliva apps are likely to need above the C interface. The state of documentation for Teliva app creators is still quite poor. All they really have to go on is the example apps.
* reorg: pull Teliva-specific stuff out of lua.cKartik K. Agaram2021-12-259-1061/+1071
| | | | It should now be easier to diff against the Lua 5.1 sources upstream.
* .Kartik K. Agaram2021-12-251-2/+2
|
* make the case for sandboxing in the ReadmeKartik K. Agaram2021-12-251-24/+45
|
* back to sandboxing; focus on files and socketsKartik K. Agaram2021-12-251-0/+2
|
* drop stdin/stdout/stderr and Lua default filesKartik K. Agaram2021-12-252-115/+18
| | | | | | | This isn't necessarily for sandboxing, but they don't really work right now in the presence of ncurses, and it seems better to not include broken stuff. Maybe we can get them to coexist with ncurses down the road.
* drop advent.tlvKartik K. Agaram2021-12-251-199/+0
| | | | It's not really an ideal use case for Teliva.
* sandbox: no popenKartik K. Agaram2021-12-254-58/+3
| | | | Again, too difficult to sandbox for now.
* tlv format for transient editor stateKartik K. Agaram2021-12-252-18/+21
| | | | | Stop interpreting arbitrary Lua code when loading editor state. We don't need that power or security risk.
* sandbox: UXKartik K. Agaram2021-12-251-1/+3
|
* sandbox: another scenario, some UX ideasKartik K. Agaram2021-12-251-0/+8
| | | | | | | | | | | | | I'd originally thought of allowing policies to be influenced by arbitrary code. But that may be overkill: - it's probably not a good idea to allow policies to read/write from file system - it's even less a good idea to allow policies to access the network - particularly since it's difficult (error-prone) to distinguish GET/POST in arbitrary protocols - once you allow file system and network, you're pretty close to owned So let's first focus on the simplest policy, the one that is easiest to secure. We'll add capabilities to policies as we gain confidence we can secure them.
* sandbox: record scenarios I've thought of so farKartik K. Agaram2021-12-251-4/+24
|
* sandbox: no system()Kartik K. Agaram2021-12-252-8/+5
| | | | | Too hard to sandbox. Maybe we'll get back to it if there's some use case only it can satisfy.
* .Kartik K. Agaram2021-12-251-2/+2
|
* stop futzing around and start sandboxingKartik K. Agaram2021-12-244-0/+937
|
* clarify 'hardcoded colors' in the ReadmeKartik K. Agaram2021-12-241-1/+2
|
* .Kartik K. Agaram2021-12-231-0/+7
|
* toot-toot: support backspace on MacKartik K. Agaram2021-12-231-1/+1
|
* toot-toot: cursor_down now handles wrapping linesKartik K. Agaram2021-12-231-8/+31
|
* clean up debug printsKartik K. Agaram2021-12-231-9/+0
|
* toot-toot: plug width into cursor movementKartik K. Agaram2021-12-231-3/+4
|
* cleaner test messageKartik K. Agaram2021-12-231-3/+2
| | | | Was printing over passing tests for some reason.
* toot-toot: reorg definitionsKartik K. Agaram2021-12-231-209/+113
|
* toot-toot: clean up historyKartik K. Agaram2021-12-231-233/+60
|
* toot-toot: cursor_up now handles wrapping linesKartik K. Agaram2021-12-231-6/+12
|
* snapshot: more tests for cursor_upKartik K. Agaram2021-12-231-0/+208
| | | | I think this may be all the tests. Now to make them pass..
* toot-toot: more elaborate cursor_upKartik K. Agaram2021-12-221-12/+59
|
* toot-toot: more verbose but clearer cursor_downKartik K. Agaram2021-12-221-16/+44
| | | | I actually got all tests to pass on the first try.
* clean up my debug conlangKartik K. Agaram2021-12-221-6/+0
| | | | | This isn't the ideal implementation either. Pure spaghetti. But I need to clean up the debug prints to see that.
* toot-toot: redo cursor_down as an experimentKartik K. Agaram2021-12-221-9/+30
| | | | | | | I want to support cursor movement across wrapped lines, and the old implementation doesn't seem on the right track for that. Interesting that this required me to add the new symmetric test.
* .Kartik K. Agaram2021-12-221-1/+1
|
* errors during tests are now handledKartik K. Agaram2021-12-221-1/+8
| | | | | | | | | | | | | | | | I should have documented that I'd never actually seen that code path trigger before. Here's a minimal test that did it just now: function test_foo() return a+1 end E2: [string "test_foo"]:2: attempt to perform arithmetic on global 'a' (a nil value) A simple missing variable doesn't do it since it just evaluates to nil. Without this commit, the above test was silently continuing to the main app after failing tests.
* toot-toot: a few more testsKartik K. Agaram2021-12-221-1/+16
| | | | ..before a change in approach.
* .Kartik K. Agaram2021-12-221-29/+19
|
* more precise control over menu orderKartik K. Agaram2021-12-226-12/+26
| | | | I can't believe I didn't notice this until now.
* gemini: back buttonKartik K. Agaram2021-12-221-0/+8
|
* .Kartik K. Agaram2021-12-221-1/+1
|
* .Kartik K. Agaram2021-12-221-8/+4
|
* fix arrow keys in big picture view on MacKartik K. Agaram2021-12-211-5/+5
| | | | Turns out arrow keys are considered `isprint()` on Mac.
* gemini: linksKartik K. Agaram2021-12-211-19/+101
|
* bugfix: ensure definition to edit has some nameKartik K. Agaram2021-12-211-4/+6
|
* less confusing nameKartik K. Agaram2021-12-212-12/+10
|
* arrow keys in big picture viewKartik K. Agaram2021-12-212-12/+105
|
* gemini: echo urls while typing inKartik K. Agaram2021-12-211-0/+3
| | | | Let's see how much we need to tweak this solution.
* gemini: slightly cleaner rendering of owner inputKartik K. Agaram2021-12-211-0/+7
| | | | | | | This still only works if I remove the call to `refresh()` inside `Wgetch()`. With that call no keystrokes are displayed. Looks like ncurses doesn't include user input when refreshing the window. Unclear if there's an easy way to support that while keeping the menu visible.
* nail down trusted Teliva channels a little moreKartik K. Agaram2021-12-219-14/+16
| | | | | | | | | | | | | | | | | | | | | | In each session, Teliva has to bootstrap a trusted channel with the computer owner while running arbitrarily untrusted code. So let's get really, really precise about what the trusted channel consists of: - the bottom-most row of screen containing the menu - the keystrokes the owner types in - ncurses COLOR_PAIR slots 254 (menu) and 255 (error) One reason the menu colors are important: we don't want people to get used to apps that hide the menu colors by setting default foreground/background to invisible and then drawing their own menu one row up. The error COLOR_PAIR I don't see any reason to carve out right now, but it seems like a good idea for Teliva the framework to not get into the habit of apps doing some things for it. I'm not sure how realistic all this is (I feel quite ill-equipped to think about security), but it seems worthwhile to err on the side of paranoia. Teliva will be paranoid so people don't have to be.