Okay, I hath returned. Here is what I am doing with FLuxCD and it’s method of installing helm charts:
Okay, I’m cheating. :/ . I’m using Flux’s method where you can have a secret that has values, and then I’m just including those.
But yeah, using an ENV var that pulls from a secret is probably better.


Are you using flakes? I think this is a flakes specific thing.
This is a message to remind myself to share my config later.
I will state that I a, using cloudnativepg for postgres.


The way forgejo actions works, is that it is not a universal thing for every repo. Each repo, can have it’s own forgejo actions instance connected to it, running stuff.
The big benefit of that, is that you can make users bring their own actions servers, and not bother to deploy your own.


Maybe: https://xyproblem.info/ ?
If you want to use syncthing remotely tha the answer is probably wireguard/other vpn.




Void auth, or kanidm look like easier alternatives.


Flatpak sandboxing uses bubblewrap, which uses seccomp and can filter syscalls.
LXD/Incus can run qemu-kvm virtual machines in addition to containers. In fact, I like the security posture of LXD/Incus better here because they use cgroups, namespaces, seccomp, to sandbox the qemu process, which libvirt also does but proxmox does not.


Journalists communicating with sources in censored regions
Whistleblowers sharing information securely
You and your peer agree on an encryption key (any string).
This is unacceptably unsecure for the usecases you mention. There is a reason why the most secure messaging apps don’t use symetric encryption, don’t use passphrases, and they also possess forward secrecy.
It’s pointless to push this as a censhorship circumvention method when many other methods exist that already do so 10x better, in a secure way, over decentralized, hidden and unblockable infrastructure. (Tor’s meek-azure bridges use microsoft’s infrastructure, which nobody is able to block because everybody depends on it, even China).
I appreciate the project, and I am always happy to see people learning, progressing, and publishing their results, but you need to be honest about the weaknesses of your software compared to established solutions. It’s not impossible for you to one day produce a secure messaging app, but today is not the day. Right now, using this is just a fast way to get killed.


Also try wireguard over port 53. Often (udp) traffic to port 53 is unblocked because it’s needed for DNS.
What is special about this setup is that it can sometimes get around captive portal wifi.


See this old but still relevant comment I made on another thread: https://programming.dev/post/11284326/8200514 . TLDR: There are plenty of ways to do it. But you have to do it yourself and it’s not an all in one solution. Users are the easiest part though. Servers are second easiest. Clients are more difficult.
Further solutions and quick notes since then:
I’m going to focus on clients because users and servers are basically solved although you will have to pick and implement a solution.
If I was in an all linux environment… it depends on how much control I have over the current setup. The best would probably be to push configuration (but that also supports regular pull as well) from the top down to the users, via something like building immutable images or NixOS configs and then shipping them to clients. This would be an all in one solution that comprehensively covers every part of config.
I do agree with the other user in the thread, that user config management is a bit more difficult. Firefox policies cover the biggest thing, the browser, but the rest is annoying. Nix user config, or home manager config could do it, but hmmm.
And then the other thing is client security. When it comes to the specific kind of client security that IT environments want, Linux isn’t as ahead. I would really want an alternative AppLocker, or something similar to restrict app execution. I can guess three possible ways to do this:
But, I think you would want to restrict software installation and execution. Not just to prevent malware, but having users install proprietary licensed software in an enterprise environment without actually purchase it could quickly turn into a nightmare for everybody.
edit: ooh, check this out:
https://talks.nixcon.org/nixcon-2024/talk/R8ZBWW/
https://clan.lol/docs/25.11/getting-started/creating-your-first-clan
https://github.com/nix-community/awesome-nix?tab=readme-ov-file#deployment-tools
Edit2: also check out meshcentral.


It’s codeberg pages… It is generated directly from codeberg, which has doesn’t allow private repos.
Source code: https://codeberg.org/purpleweb/Riddles_0-385_App


hides as regular HTTPS traffic so it’s not blockable by Firewalls
From OP’s post, of course. If OP does not need to evade firewalls that are that aggressive, then they should have settled for a less stealthy VPN solution, as many of these HTTPS proxy solutions have performance and usability (can often only proxy TCP traffic) tradeoffs.
Perhaps they have already tried the wireguard on port 443 solution, and it didn’t work for them. My high school would auto detect and block wireguard to any port. Perhaps they are in a similar situation.


Seems to be the case:
https://github.com/anyproto/anytype-ts?tab=License-1-ov-file#readme
https://github.com/anyproto/anytype-kotlin?tab=License-1-ov-file#readme
The sync server is MIT though: https://github.com/anyproto/any-sync?tab=MIT-1-ov-file#readme
Interesting.


Many of the prominent https VPN protocols are for evading the great firewall of China. OP had that as a requirement, so it is not an unreasonable assumption.
If you are evading less locked down firewalls, then you don’t need as stealthy VPNs.


Yes because they are all designed to evade the great firewall of China, which automatically catches almost all other VPN’s and proxies.
Github is blocked in China. The fact that these repos are on Github and Chinese is proof of their effectiveness.
If you are not a Gitea customer, you are not being informed of security updates in a timely manner:
Gitea repeatedly makes choices that leave Gitea admins exposed to known vulnerabilities during extended periods of time. For instance Gitea spent resources to undergo a SOC2 security audit for its SaaS offering while critical vulnerabilities demanded a new release. Advance notice of security releases is for customers only.
https://forgejo.org/compare-to-gitea/#security
Also, ForgeJo was promising federation which is still a WIP several years later.
Oh no, it doesn’t do the big feature™. I guess it’s unusable now.
I wish people would realize that software still works and is excellent even without the various flagship features. I use Kubernetes on a single node. I know there are people who use matrix without federation and e2ee because it’s actually a really good chat app, it just struggles with the performance demands of federation, and the e2ee ux isn’t quite there yet.


I spun up a test, and it doesn’t let you edit encrypted notes :(. It’s so nice though, I might be willing to give it up e2ee for less sensitive data.
Yes. But this is a lot. It may be easier to use Forgejo’s built in migration tools, to copy over repositories along with their issues and other info. You would have to rebuild the admin parts of the site, like “organizations” and user privileges. (Well if you are using oauth and mapping users from oautb groups then you don’t…). And I don’t know if it’s automated for a many, many repos. But it’s just a click click click in the gui.
I remember there was a tool, I think it was related to forgefed, that could do batch repo migrations via the cli. I can’t find it anymore though.
I don’t think anubis can proxy webdav. So that breaks.
Instead of putting anubus at 443, put it at the port 80 block. Or at the 5555 block.
What you probably need to do is make it so that webdav traffic isn’t proxied through anubis.