I fucking hate feature macros. Egregious discharge of our
division-of-labor-obsessed society. People should be able to introduce
names. People should be able to give up names to lower levels of
abstraction when they encounter conflicts.
Feature macros seem to exist[1] to support more than two levels of
abstraction. You try to build, one of your libraries fails to build
because of a conflict between it and one level down. You don't want to
modify this library. Just fucking https://catern.com/change_code.html
already. But no, I have to litter my code with feature macros even
though I just want the abstraction the original library provides.
[1] https://man7.org/linux/man-pages/man7/feature_test_macros.7.htmlhttps://lwn.net/Articles/590381
I made the changes reverted here out of a mistaken sense that
big-picture edits would interfere with Teliva's memory of what is
currently being edited (teliva_editor_state).
Going to big picture from doc:bp still goes to the default
auto-generated big picture view.
While doc:bp provides some programmability, it's also far klunkier than
the default view. Rendering is worse, and it's always in edit mode
because I'm trying to avoid complicating the UX with a notion of
rendered markup. That means cursor movement is less convenient. It's
also easy to accidentally edit the big-picture view.
NetBSD still uses curses by default. One _could_ install ncurses, but I
don't have access to a NetBSD box with permissions to install ncurses,
so I'm experimenting to see how far we can get with just curses. So far
most of the apps seem to work, with the exception of one bug that I'll
commit next.
No way to select between them. That complicates the UI too much when we
do so much with the cursor. But it's still useful to suggest things to
type in after ctrl-g.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Examples:
- you try to write file but disk is full
- you have two Teliva files being edited at the same time
Both are situations where it's impossible to avoid some data loss.
However, we should now at least have some valid state of the .tlv file
saved to disk where we'd previously end up with a zero-size file or
garbage.
Teliva emits timestamps in multi-line format end in a newline. As a
result, notes get rendered on the next line and are then immediately
overwritten by the contents of the definition.
This bug was masked by my hacky 'original' timestamps which don't use
multi-line format.
This reverts commit 7c1b9d0b91.
The 'big hammer' isn't good enough. The recent changes view seems to
need state on the stack across invocations of the editor.
This is a complete mess. I want to abstract reading multiline strings
behind a function, but the lookahead requirements for that are quite
stringent. What's a reasonable abstraction here?
I really wanted to avoid getting into defining or parsing new file
formats. However, using the entire power of Lua is not ideal, as
described earlier in Konrad Hinsen's bug. In addition to everything
else, it's a vector for arbitrary code execution when someone loads an
untrusted image.
I could use JSON, but it requires ugly string escaping. Seems cleaner to
just use YAML. But YAML is complex and needs its own dependencies. If
I'm going to do my own, might as well make the multi-line string format
really clear.
I can't yet write the new format.
Steps to reproduce:
* Run teliva with some app.
* Press ctrl-e to edit the app.
* Select some function.
* Press ctrl-g and type in some Lua keyword like 'function' or 'while'
(Since the first word in a function is often 'function', it becomes
the default if you press ctrl-g immediately after entering the editor
for a function.)
* Type nothing. Run the app.
Desired behavior: app continues to run. The definition for the keyword
is silently ignored (in future we may want to provide an error message)
Behavior before this commit: app silently exited with non-zero status,
and refused to restart thereafter until the .tlv file was manually
edited to delete the definition for the Lua keyword.
Behavior after this commit: app throws an error message like these:
* For `function`:
```
src/teliva: x.tlv:99: '(' expected near '='
sorry, you'll need to edit the image directly. press any key to exit.
```
* For `while`:
```
src/teliva: x.tlv:99: unexpected symbol near 'while'
sorry, you'll need to edit the image directly. press any key to exit.
```
You still need to edit the .tlv file manually, but the steps for
recovery are a bit more discoverable.
To fix this properly I also need to fix a looming security hole I've
been thinking about for some time. The long-term goal of Teliva is to
put the human running apps in control of what they do, by sandboxing
accesses to the file system, network and so on. However, even after we
build gates on all of Lua's standard libraries, we're still parsing .tlv
files as Lua, with all of its power available.
Solution: load .tlv files as some sort of JSON-like subset of Lua. Maybe
I should just use JSON, and rely on code that's already in Teliva, even
if I'm introducing a new notation in the process.
It turns out Lua has been providing us this information all along! I'd
just not created the space on screen to show it. Make it persist better.
Kilo now no longer tracks its own status messages, which is a regression
in a rare condition.
^/ works on Linux but not on Mac
^- emits the same character code on Mac
^_ seems to be the underlying character code, and works on both
ctrl-7 also emits the same character code
On a Thinkpad X13, the `delete` key emits `^[[3~` outside of Teliva.
Within Teliva, ncurses converts it to character code 330 (0x14a), which
it fails to recognize as KEY_BACKSPACE. Why?
My backspace is converted to character code 263, which ncurses does
recognize as KEY_BACKSPACE.
ctrl-h is character code 8.
Both 330 and 263 are valid Unicode code points, which feels really ugly
and ambiguous.
I still don't understand the entire state space here, so I'm trying to
err on the side of improving discoverability of the `ctrl-h` escape
hatch. Without requiring too wide a window to show all hotkeys on the
menu.
So far I've been trying to make Teliva follow the default colorscheme of
the terminal, but that easily ends up with illegible color combinations.
New plan: always start with a light background within Teliva. People who
want a dark background will currently need to mess with C sources.
This should somewhat fix https://github.com/akkartik/teliva/issues/1.
It's still not clear whether the default should be a dark or light
background. While dark background is more common in terminals, I believe
newcomers to terminals will prefer a light background. Then again, I'm
biased since I use a light background in my terminals.
Kartik K. Agaram