about summary refs log tree commit diff stats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* a sharp edge in Lua's dorequire()Kartik K. Agaram2022-04-111-1/+1
| | | | | You can't call it on a file that isn't a module, i.e. that doesn't return something at the end. Use dofile() instead.
* actually _use_ the ask permissionKartik K. Agaram2022-04-071-1/+29
|
* new perm: files under dir specified at commandlineKartik K. Agaram2022-04-051-1/+16
| | | | | | I think we can now use a file browser app with relative safety. Just give it inargs permissions, and provide a top-level directory at the commandline to gain access to everything under it.
* new permission: any file specified at commandlineKartik K. Agaram2022-04-051-0/+19
|
* experiment: ask for permission on file operationsKartik K. Agaram2022-04-052-34/+83
| | | | | | | | | | | | | | | | | | | | | | I'm not quite sure how to think about asking for permissions with respect to my red/orange/green color codes. On the one hand, it seems safer than many alternatives. On the other hand, it's liable to lead to fatigue and blindly allowing apps to do stuff. For now I consider ask to be orange. Ask + network allowed = red in summary, though it's orange on the permissions screen since there's more space to convey nuance. Then again, nobody may heed the nuance. The summary up top on the permissions screen is definitely still a work in progress. And there's a chicken-and-egg problem here: I can't really get a good feel for real-world bugs in the permissions screen until _other programmers_ are building apps to use the permissions screen, but they're almost certain to have a crappy time of it. I considered introducing a primitive called ask() in the Lua interpreter, but it doesn't really make sense to validate it and so on. I'm also not really supporting mixing Ask with other features so far. This is a major step towards turning my permissions screen into spaghetti; monitoring closely.
* show common suggestions when editing permissionsKartik K. Agaram2022-04-052-1/+17
| | | | | | Computer owners shouldn't get in the habit of trusting app authors regarding permissions. But they have to trust somebody, and they already trust the Teliva platform if they are running it.
* reorgKartik K. Agaram2022-03-201-2/+5
|
* disallow all relative paths (./ or ../)Kartik K. Agaram2022-03-204-1/+25
| | | | | | | | | Teliva's model doesn't include any way to change directory. We just have relative paths and absolute paths. Relative paths should not be able to reach into parent directories. The current test is a bit hacky; it also disallows directories ending in a period. Hopefully not an issue.
* fix a warningKartik K. Agaram2022-03-181-1/+1
|
* show current definition being editedKartik K. Agaram2022-03-182-6/+8
| | | | | | | | | | This serves two purposes: - Things get confusing if function being defined doesn't match the definition name. Displaying the current definition helps diagnose this situation. - We're already able to see callers at a glance even if the cursor is below the fold. The name of the current definition is arguably more important in that situation.
* stale references to callerKartik K. Agaram2022-03-181-2/+2
|
* fake to stand in for start_reading in testsKartik K. Agaram2022-03-181-0/+44
|
* sandbox os.removeKartik K. Agaram2022-03-171-5/+18
|
* fix some warningsKartik K. Agaram2022-03-171-3/+3
|
* function names from globals rather than debug infoKartik K. Agaram2022-03-161-22/+22
| | | | | | | | | | | This reclaims all the slowdown in sieve.tlv, and it also is now smart enough to detect calls to global bindings that pass through variables. On the flip side, we lose names for non-globals. But that's not very useful anyway in Teliva's context. This is still not enough to detect callers through coroutines (intervening anonymous functions), though.
* bring back hack when caller is mainKartik K. Agaram2022-03-161-0/+2
| | | | Partially undoes commit f2d29c22f86a88.
* cache function namesKartik K. Agaram2022-03-161-10/+46
| | | | This brings down the slowdown in sieve.tlv from 50% to 25% (15s).
* standardize some namesKartik K. Agaram2022-03-163-11/+12
|
* stop running task.scheduler by defaultKartik K. Agaram2022-03-163-21/+3
| | | | | sieve.tlv is 50% slower (18s vs 12s) with the new function call instrumentation.
* delete dead codeKartik K. Agaram2022-03-161-25/+0
|
* simplify function call instrumentationKartik K. Agaram2022-03-163-41/+20
| | | | | | | | src/ldo.c now has a minimal diff with Lua 5.1. It might be a bit slower than it was before, but not noticeably so.. This approach doesn't support indirect calls.
* drop a headerKartik K. Agaram2022-03-161-1/+0
|
* drop a forward declKartik K. Agaram2022-03-161-8/+7
|
* start cleaning up function call instrumentationKartik K. Agaram2022-03-161-2/+2
| | | | | | It's a mess. I calculate call-graph depth one way and calculate caller names another way. At least one of the ways fails to work with indirect calls. Hopefully the other way works?
* stop using tasks in start_reading/start_writingKartik K. Agaram2022-03-162-71/+36
| | | | | We just need queues/streams for file I/O. No need to complect concurrency concerns with them.
* Teliva's been broken 2 days while I mess with docsKartik K. Agaram2022-03-151-1/+1
|
* drop the lfs libraryKartik K. Agaram2022-03-145-1165/+1
| | | | | I can't feel confident about its sandboxing story yet. And if we can't build a file navigator, what are we even doing with it.
* delete debug libraryKartik K. Agaram2022-03-133-401/+1
| | | | | There's security issues here, and they're subtle. Dropping for now until I or someone else finds a need for them.
* drop string.dump, clean up docs around itKartik K. Agaram2022-03-132-20/+5
|
* less confusing error when apps get past mainKartik K. Agaram2022-03-131-4/+6
|
* leak checkKartik K. Agaram2022-03-101-0/+6
|
* support fixing >1 test failure from within TelivaKartik K. Agaram2022-03-101-0/+2
| | | | | This bug was caused by me forgetting that lua_setglobal affects the stack.
* zet.tlv: first screen testsKartik K. Agaram2022-03-101-0/+3
| | | | In the process I found a couple of bugs in fake screen primitives.
* protect framework files from appsKartik K. Agaram2022-03-082-8/+33
| | | | | | | | There's a separate open question here of where Teliva should store files like teliva_editor_state and teliva_editor_buffer. One school of thought is that apps should never be dropping crud into people's directories. On the other hand, I'm kinda encouraging people so far to just run apps from Teliva's directory. Perhaps that makes it ok?
* just always temp files to be createdKartik K. Agaram2022-03-076-10/+26
| | | | | Implication: os.rename now needs to be sandboxed. Hopefully it's tractable to treat it as conceptually identical to opening two files.
* stop loading libraries after app codeKartik K. Agaram2022-03-071-7/+2
| | | | This whole approach of disallowing overriding is suspect.
* purge all support for per-function permissionsKartik K. Agaram2022-03-073-53/+9
| | | | | | | | | We're now back to the problem of how to transparently allow Teliva to create temporary filenames without every app having to explicitly allow them. I think I may need to define start_writing in C, so that it can use a non-sandboxed version of io.open.
* hokey primitive to create temporary fileKartik K. Agaram2022-03-072-1/+26
| | | | | | | | | | | | | | The trouble with os.tmpname() is that it always creates in /tmp. If /tmp is in a different volume from our real filename, os.rename() will fail. This new primitive doesn't support primitive paths yet. I'm also again nervous about the security implications of my whole approach. What if we create an inner function called start_writing? Would we be able to do anything inside it? I'm starting to suspect this whole approach of going by caller name is broken. An app could also create inner functions called 'main'..
* slightly firm up phases in pmainKartik K. Agaram2022-03-071-2/+9
|
* fix the security vulnerabilityKartik K. Agaram2022-03-071-2/+4
| | | | | | | | | We now have a notion of libraries that we load after app code, to prevent them from getting overridden. Should I just load all libraries after the app? There might be value in allowing apps to override library functions. Disallowing that too much may be going against Lua's dynamic nature.
* call app's main() from within Lua pmainKartik K. Agaram2022-03-073-7/+7
|
* zet.tlv: switch file writes to new APIKartik K. Agaram2022-03-073-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The interface for apps looks much nicer now, see 'main' in zet.tlv. However there are some open issues: - It can still be confusing to the computer owner that an app tries to write to some temporary file that isn't mentioned anywhere. - File renames can fail if /tmp is on a different volume. - What happens if an app overrides start_writing()? The computer owner may think they've audited the caller of start_writing and give it blanket file permissions. Teliva tunnels through start_writing when computing the caller. If the app can control what start_writing does, the app could be performing arbitrary malicious file operations. Right now things actually seem perfectly secure. Overriding start_writing has no effect. Our approach for loading .tlv files (in reverse chronological order, preventing older versions from overriding newer ones) has the accidentally _great_ property that Teliva apps can never override system definitions. So we have a new reason to put standard libraries in a .lua file: if we need to prevent apps from overriding it. This feels like something that needs an automated test, both to make sure I'm running the right experiment and to ensure I don't accidentally cause a regression in the future. I can totally imagine a future rewrite that tried a different approach than reverse-chronological.
* extract a common function callKartik K. Agaram2022-03-073-4/+5
|
* zet.tlv: switch file reads to new APIKartik K. Agaram2022-03-071-2/+2
| | | | In the process I found a couple of bugs in parsing JSON string escapes.
* decode json from channelsKartik K. Agaram2022-03-062-0/+328
|
* use method syntax where possibleKartik K. Agaram2022-03-061-2/+2
| | | | | | Perhaps this is a bad idea. It feels arbitrary, what methods Lua happens to include in string and table objects without having to go through the respective modules.
* reading from file a character at a timeKartik K. Agaram2022-03-061-0/+20
|
* local functions broke start_reading/start_writingKartik K. Agaram2022-03-061-2/+2
| | | | | Looks like Lua's local functions lose access to outer scopes (upvalues) or something like that..
* move start_reading/start_writing out of templateKartik K. Agaram2022-03-062-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When should code go in the template used by new apps vs the .lua files distributed with Teliva? - from a privilege perspective there's no difference - from a compatibility perspective stuff in .tlv will not get upgraded with Teliva. - for me the maintainer, functions in .lua files are easier to upgrade in a single place. - for the reader of an app, functions in .lua files will not show up to be edited. They can still be overloaded, but the current version isn't as discoverable. Putting something in the app is a slight nudge to readers that they're encouraged to mess with it. - Stuff in .lua files can use local functions and so have more internal complexity. Apps can also hide details within functions, but that'll make them more likely to run into limitations with Teliva's editing environment. I'm not yet sure how to reason about the second point in practice. - Stuff in .tlv files I don't have to worry about compatibility guarantees for. - Stuff in .lua files I _do_ have to worry about compatibility guarantees for. Perhaps this means I'm doing things exactly wrong in this commit? Functions like map/reduce/filter/append seem more timeless, whereas I'm still just feeling my way around with start_reading and start_writing. We'll see. For now I'm ruled by the fourth point. Messing with tasks and the scheduler is much more advanced than anything else in template.tlv; it seems to make sense to add some friction to modifying them. Bottomline: Complex sub-systems go in .lua files. Simple, self-contained definitions go into apps. Both are probably equally burdensome now from a compatibility perspective.
* extract a helperKartik K. Agaram2022-03-061-1/+5
| | | | | | I'm starting to get quite indisciplined about where I introduce global bindings. Seems reasonable since any modules in Teliva will come from within the framework.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-16 03:30:28 +0000