Konform Browser and other bits and bobs.
Thanks for the detailed review
I wouldn’t call that detailed. It was what glared at me from skimming for a couple of minutes.
was calling pip install --break-system-packages at runtime, which is indefensible
“You” still have three instances left of runtime pip install --break-system-packages without user interaction, one of which dead code.
I think the follow-up beautifully clarified the “is this vibecoded?” question too.
Labeling it 1.0.0 seems premature to say the least.
Is this vibecoded or is there thinking behind why it will silently reuse existing user SSH keys by default? For an app like this I would expect it to exclusively use its own keys. Same for PGP.
I also find the ways dependencies are handled a bit unorthodox and surprising (possibly system-breaking even). For a python project it would make more sense with a lockfile and using a package manager for dependencies installed remotely via pip.
I also wonder why it bundles minified js for Quill editor v1.3.7 (from 2019) when unminified version would be easier to audit and maintain, and v2.0.3 was released in 2024?
No mention if it is EME-Free (no DRM playback possible)
DRM/EME/WidevineCDM integration disabled by default. They can still be enabled via the usual preferences. They will also be fully enabled like in FF (including downloading and installation of trusted binaries) if user enables “Just Make it Work” preset.
Settings and prefs and bookmarks sync is a strong want from me, I just want to do so self-hosted, and not via Mozilla’s servers.
Konform Browser still supports enabling that and has UI to make configuring custom Sync- and Accounts server endpoints more straightforward.
Separately, profile import feature also supports other Firefox-based browsers as of recently.
Not like Apple cared to look at it when people reported it to them. So much for App Store safety.
A dedicated Forgejo instance f.example.com.
For a small set of trusted “base” images (e.g. docker.io/alpine and docker.io/debian): A Forgejo Action on separate small runner, scheduled on cron to sync images to f.example.com/dockerio/ using skopeo copy.
Then all other runners have their docker/podman configuration changed to use that internal forgejo container registry instead of docker.io.
Other images are built from source in the Forgejo Actions CI. Not everything needs to be (or even should) be fully automated right off. You can keep some workflows manual while starting out and then increase automation as you tighten up your setup and get more confident in it. Follow the usual best practices around security and keep permissions scoped, giving them out only as needed.
Git repos are mirrored as Forgejo repo mirrors, forked if relevant, then built with Forgejo Actions and published to f.example.com/whatever/. Rarely but sometimes is it worth spending time on reusing existing Github Workflows from upstreams. More often I find it easier to just reuse my own workflows.
This way, runners can be kept fully offline and built by only accessing internal resources:
Same idea for npm or pypi packages etc.
Set up renovate1 and iterate on its configuration to reduce insanity. Look in forgejo and codeberg infra repos for examples of how to automate rebasing of forked repo onto mirrors.
I would previously achieve the same thing by wiring together more targeted services and that’s still viable but Forgejo makes it easy if you want it all in one box. Just add TLS.
1: Or anyone have anything better that’s straightforward to integrate? I’m not a huge fan of all the npm modules it pulls in or its github-centric perspective. Giving the same treatment to renovate itself here was a little bit more effort and digging than I think should really be necessary.
Nice try, NSA
Unnecessary hostility. They can not and are not retroactively changing license on past contributions. The only thing affected is upstream future contributions. If nothing was lost, how can it be “theft”?
Yes. As long as you also comply with license.