about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* .Kartik K. Agaram2022-01-021-1/+1
|
* sandbox: tweaks to warning copyKartik K. Agaram2022-01-021-7/+8
|
* sandbox: color tweaksKartik K. Agaram2022-01-021-4/+4
|
* spacingKartik K. Agaram2021-12-261-0/+2
|
* gemini.tlv: stop using default backgroundKartik K. Agaram2021-12-251-2/+2
|
* undo accidental color scheme commitKartik K. Agaram2021-12-251-1/+1
|
* gemini: better error-handlingKartik K. Agaram2021-12-251-5/+9
|
* start persisting sandboxing settingsKartik K. Agaram2021-12-251-0/+86
| | | | Zero guarantees of compatibility at this point.
* reorgKartik K. Agaram2021-12-251-24/+24
|
* network calls are now sandboxedKartik K. Agaram2021-12-251-1/+10
| | | | | | | I _think_ I don't need to gate other socket calls; you can't do anything without bind() and connect(). And they should be good places to dump more precise details later about the kind of server or client connection being attempted.
* file open() is now sandboxedKartik K. Agaram2021-12-253-15/+36
| | | | | | | In the process we now also have a mechanism for Teliva to overlay errors while apps run. Might make sense to make that available to apps as well. But I'm starting to realize that any app access to the Teliva areas of the screen is fraught with risk.
* remove disabled functions from life.tlvKartik K. Agaram2021-12-251-2/+1
|
* flesh out very preliminary UIKartik K. Agaram2021-12-253-19/+154
| | | | | | | Our sandboxing model is a blunt caricature, just two booleans. But let's see how far this gets us. Still doesn't persist, and definitely has no effect.
* fix a couple of colorsKartik K. Agaram2021-12-251-2/+2
|
* delete a couple more hacky function prototypesKartik K. Agaram2021-12-253-4/+3
|
* sandbox: more scenariosKartik K. Agaram2021-12-251-0/+5
|
* .Kartik K. Agaram2021-12-251-2/+8
|
* mock sandbox status and some initial colorsKartik K. Agaram2021-12-252-1/+30
| | | | | | | | Current plan: - two booleans to gate file and network access, respectively - false shows as green, true shows as orange - if _both_ booleans are true, then both show as red to indicate that there are no protections.
* update all places when changing color schemeKartik K. Agaram2021-12-251-0/+1
|
* fix menu colors in all color schemesKartik K. Agaram2021-12-251-1/+2
| | | | | | | | It looks like attron doesn't actually enable colors near 256, even though https://linux.die.net/man/3/attron suggests it does. > COLOR_PAIR values can only be OR'd with attributes if the pair > number is less than 256.
* 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..