Dropserver Progress - February 2024
This is the monthly progress report for Dropserver for February 2024. The previous report is here.
The Big Picture
This will be a short report because I spent half of this month on vacation, which limited my work. After Releasing 0.13 last month I am allowing myself some time to explore tangential projects while also chipping away at some Dropserver issues.
Getting Lume to Work
I have been trying to get Lume to work in a Dropserver app. I’d like to combine Lume, a static site generator (SSG), with a GUI frontend to make a Dropserver app that allows you to edit content in an online editor and publish it. It is meant to be a demo of the kind of app that can be built for DS. It is also a test of running a non-trivial project that was not intended to be run in Dropserver.
One issue I’ve run against is that Lume is clearly meant to be used as a CLI app, and not as a library within other code, especially if given limited permissions. The other issue is that Lume leverages existing libraries from the node ecosystem via Deno’s NPM support. While the NPM libraries work, they tend to expect full disk access permissions and fail hard when they don’t have it.
One such library is Browserslist, which is used by autoprefixer which is used in most projects that leverage PostCSS. The issue is that browserslist was not designed to run in a sandboxed environment like Deno. I decided to try to fix this.
Browserslist PR
PostCSS and autoprefixer are so commonly used in site generation tooling that I thought it would be worthwhile to try to help it run in Deno when permissions are limited. I submitted this issue and said I’d submit a patch.
It’s nice working on an existing and widely used project for a change. I spend a lot of time working on my own stuff, it feels good to get out of my shell.
I added an ENV variable that limits how far up the path Browserslist goes to look for config files. Credit to the maintainer, my PR was promptly merged (after I fixed linter errors – woops!) and a new version of bl was released, which is a nice feeling.
Since the Lume and autoprefixer devs are staying on top of dependencies, the current version of Lume requires the latest version of autoprefixer which requires the latest version of browserslist which includes my patch. Neat!
ENV vars in Dropserver sandbox?
I changed the browserslist library to limit its file reads via an environment variable, but the Dropserver sandbox has no mechanism to let developers specify environment variables for the sandbox. I’m contemplating adding this capability. I’ll consider it seriously if I find over and over again that a library wants to be controlled via environment variables.
I suspect this type of library is usually associated with CLI apps, and site generators. I do want to support site generators in Dropserver if possible. I think all the tools we build for the web that are CLI-based are a boon for technical people but leave regular users helpless.
Then again this may be a bridge too far. I haven’t thought much about it, but I imagine that letting app devs specify Environment variables is a big security issue.
(Note that there are other ways of preventing Browserslist from iterating up the path: put all the config files it looks for in the appspace data directory and it won’t go looking elsewhere for them. This is what I have been doing in my Dropserver Lume experiments.)
Make Appspace Data Directory the CWD
Since it is a CLI app, Lume puts a lot of stock in the CWD “Current Working Directory”. When the CWD is non-existent or unreadable, Lume errors out.
This one I could fix in Dropserver. I changed the sandbox code so that the appspace files dir is the CWD of the Deno sandbox. Easy peasy, and it makes it easier for app devs to interact with files in the appspace dir: they can just use relative paths instead of the helper functions that return the absolute path of the appsapce files.
I did run into a weird thing that caused me to spend a few days on this: Deno is a bit inconsistent with path normalization. When symlinks are involved, or when using different capitalizations of paths in a case-insensitive filesystem, Deno will fail to recognize that two paths are the same even if they are not character-for-character the same. I filed this issue.
Commit cec557.
What’s Next
I will work on a few more bugs and improvements before I release Dropserver 0.13.1. Beyond that I am not sure what comes next, but this is looming:
Deno 2.0 and Outbound Requests
I’m eagerly waiting for the arrival of the first public releases of Deno 2.0. Deno has been a boon for the Dropserver project, but it’s not openly developed so I wait patiently to see what I will have to contend with when it drops.
In particular, a sorely needed feature for Dropserver apps is the ability to make outbound requests. Letting an app do this opens up a number possible security issues, and Deno’s permission API plays a big role. As such, I want to see if they improve the net permissions before I do too much design work for outbound requests. See these issues for an idea of things that have been bugging me:
- #2705: Current design of –allow-net (stale-botted 😡)
- #21227: Deno should block access to local network unless explicitly permitted
Once I know what I’m dealing with, I’ll get to work enabling outbound requests from Dropserver apps.
In the meantime I’ll continue experimenting with IndieWeb, ActivityPub, and RSS, with an eye towards making Dropserver apps that demonstrate what can be built on the platform.
See you next time.
