about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* Teliva's been broken 2 days while I mess with docsKartik K. Agaram2022-03-151-1/+1
|
* .Kartik K. Agaram2022-03-141-9/+10
|
* drop the lfs libraryKartik K. Agaram2022-03-147-1285/+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.
* .Kartik K. Agaram2022-03-141-1/+4
|
* update link to manualKartik K. Agaram2022-03-141-6/+6
|
* typoKartik K. Agaram2022-03-141-1/+1
|
* doc: cursesKartik K. Agaram2022-03-141-8/+260
|
* doc: flesh out tasks and channelsKartik K. Agaram2022-03-141-1/+51
|
* doc: correct and flesh out jsonKartik K. Agaram2022-03-141-4/+44
|
* typoKartik K. Agaram2022-03-141-1/+1
|
* document functions that are sandboxedKartik K. Agaram2022-03-131-0/+13
|
* drop docs for 2 functions removed from LuaKartik K. Agaram2022-03-131-25/+0
|
* delete debug libraryKartik K. Agaram2022-03-135-680/+1
| | | | | There's security issues here, and they're subtle. Dropping for now until I or someone else finds a need for them.
* standard markupKartik K. Agaram2022-03-131-18/+18
|
* .Kartik K. Agaram2022-03-131-2/+2
|
* one more highlightKartik K. Agaram2022-03-131-1/+1
|
* rudimentary docs for libraries added to TelivaKartik K. Agaram2022-03-133-3/+104
|
* drop string.dump, clean up docs around itKartik K. Agaram2022-03-133-39/+5
|
* rip out most references to C and userdata in docsKartik K. Agaram2022-03-131-143/+30
|
* starting to spend some time improving docsKartik K. Agaram2022-03-132-0/+19
|
* less confusing error when apps get past mainKartik K. Agaram2022-03-131-4/+6
|
* toot-toot.tlv: scrollingKartik K. Agaram2022-03-121-1/+109
|
* more extensive deletions from the Lua manualKartik K. Agaram2022-03-103-3776/+17
| | | | | | | I'm trying to represent where Teliva borrows from Lua, but without making it seem identical. Please support the Lua project!
* zet.tlv: thoroughly test rendering single zettelKartik K. Agaram2022-03-101-11/+47
|
* 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.
* reconcile template in all appsKartik K. Agaram2022-03-101-8/+47
|
* zet.tlv: first screen testsKartik K. Agaram2022-03-103-6/+111
| | | | In the process I found a couple of bugs in fake screen primitives.
* screen tests: support bold, reverse, colorKartik K. Agaram2022-03-082-6/+198
| | | | | We can't test combinations of these yet because Lua 5.1 doesn't support bitwise operators. Reason #1 to upgrade.
* protect framework files from appsKartik K. Agaram2022-03-083-12/+35
| | | | | | | | 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-075-882/+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.
* yup, this whole caller-based approach is bustedKartik K. Agaram2022-03-071-0/+415
| | | | | How can we scope anything to a subset of an app that is user-visible in such a dynamic language as Lua?! X(
* 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
|
* hide test app a bitKartik K. Agaram2022-03-072-0/+2
|
* fix the security vulnerabilityKartik K. Agaram2022-03-072-10/+8
| | | | | | | | | 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
|
* pin down a security vulnerabilityKartik K. Agaram2022-03-071-0/+418
| | | | | | | We aren't actually secure as the previous commit said. The hole here is that you can't override start_writing by typing in 'start_writing' into the big picture. However you _can_ override it by typing in _anything else_.
* zet.tlv: switch file writes to new APIKartik K. Agaram2022-03-074-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-072-2/+40
| | | | 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-069-80/+80
| | | | | | 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-065-144/+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.
* use the new file API in most placesKartik K. Agaram2022-03-061-4/+6
| | | | | Really everywhere except zet.tlv. toot-toot is intended to emit throwaway files anyway.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-16 02:39:22 +0000