about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* commentKartik K. Agaram2022-01-031-1/+1
|
* renameKartik K. Agaram2022-01-031-2/+2
|
* extract a functionKartik K. Agaram2022-01-033-21/+24
|
* events view: jump to a functionKartik K. Agaram2022-01-031-7/+27
|
* toot-toot: gracefully handle lack of permissionsKartik K. Agaram2022-01-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | This opens up a whole new can of worms: Teliva's ability to show clear error messages hinges on apps having decent error handling. I suppose that's ok. A new app someone downloads that throws out strange error messages and puts them in the equivalent of the console doesn't exactly engender trust. It's reasonable to treat poor error handling as breakage. Here's my running list of open questions from working on the permissions screen so far: - how to teach people to care about the difference between: - permissions known to be unsafe - permissions unknown to be safe - how to show syntax errors in the permissions screen - how to detect syntax errors in the permissions screen (lots of stuff only shows up when running) - how to deal with apps with poor error handling (this commit; punt for now) - how to engender skepticism in people towards what apps tell them ("oh, just go into the permissions screen and type ___ to fix this error") - how to help people judge the quality of their permissions (mode == 'r' vs mode ~= 'w')
* rendering improvementKartik K. Agaram2022-01-021-3/+2
|
* error handling when editing file permissionsKartik K. Agaram2022-01-021-1/+21
| | | | | | | Still highly non-ideal. Lua is a dynamic language, and has low ability to detect syntax errors within functions. Perhaps I should run a test call after every edit.
* bugfix: policies must end in newlineKartik K. Agaram2022-01-021-3/+3
| | | | I believe kilo kinda naturally enforces that. We'll see.
* instrument some obvious syscallsKartik K. Agaram2022-01-023-1/+31
|
* indentKartik K. Agaram2022-01-021-6/+6
|
* start on a view of audit eventsKartik K. Agaram2022-01-023-2/+73
|
* .Kartik K. Agaram2022-01-021-3/+0
|
* editing file permissionsKartik K. Agaram2022-01-022-42/+76
|
* make some space for callers of a functionKartik K. Agaram2022-01-021-13/+26
|
* start parameterizing viewport for editorKartik K. Agaram2022-01-021-8/+18
|
* drop os.getenvKartik K. Agaram2022-01-021-7/+1
|
* editable file permissionsKartik K. Agaram2022-01-024-51/+192
| | | | | | | | | | | | | | | | | | | | | Extremely cruddy implementation: - I'm still unclear on how to represent the advice function: - How to handle errors when loading user configuration? Currently I refuse to start. - Whole function? More errors to handle in header and so on. What if the function is renamed? - Just body? Needs more structured editing support. - Lots of duplication, particularly between the permissions in the menu and the permissions screen. I don't know how to show the hostname at the time of connect() or bind(), so networking is going to remain a boolean for now. It's also unclear what effective constraints we can impose on what gets discussed with a specific hostname. Everything outside the computer is out of one's control. One trick I learned is for consistently grabbing ASan logs on abort: It's always safe to redirect stderr with ncurses!
* fork a new editor widget for non-codeKartik K. Agaram2022-01-022-2/+49
|
* better follow kilo's naming conventionsKartik K. Agaram2022-01-022-6/+6
|
* start peeling out an editor for non-codeKartik K. Agaram2022-01-021-14/+21
|
* .Kartik K. Agaram2022-01-022-1/+3
|
* copy tweakKartik K. Agaram2022-01-021-3/+4
|
* renameKartik K. Agaram2022-01-024-31/+31
|
* .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
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-13 10:46:13 +0000