about summary refs log tree commit diff stats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* undo accidental color scheme commitKartik K. Agaram2021-12-251-1/+1
|
* 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.
* 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
|
* .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.
* a little more reorgKartik K. Agaram2021-12-251-79/+84
| | | | | | | | 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.
* drop stdin/stdout/stderr and Lua default filesKartik K. Agaram2021-12-251-115/+13
| | | | | | | 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.
* sandbox: no popenKartik K. Agaram2021-12-252-57/+1
| | | | 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: no system()Kartik K. Agaram2021-12-251-7/+1
| | | | | Too hard to sandbox. Maybe we'll get back to it if there's some use case only it can satisfy.
* cleaner test messageKartik K. Agaram2021-12-231-3/+2
| | | | Was printing over passing tests for some reason.
* 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.
* more precise control over menu orderKartik K. Agaram2021-12-221-2/+10
| | | | I can't believe I didn't notice this until now.
* fix arrow keys in big picture view on MacKartik K. Agaram2021-12-211-5/+5
| | | | Turns out arrow keys are considered `isprint()` on Mac.
* 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-211-12/+104
|
* gemini: echo urls while typing inKartik K. Agaram2021-12-211-0/+3
| | | | Let's see how much we need to tweak this solution.
* nail down trusted Teliva channels a little moreKartik K. Agaram2021-12-214-9/+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.
* keep Teliva apps from pretending to be TelivaKartik K. Agaram2021-12-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* pay more attention to where we display the cursorKartik K. Agaram2021-12-181-1/+2
| | | | | It's still just in app control; I'm resisting the urge to introduce "smarts".
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-03 09:39:07 +0000