moonpiedumplings

I don't use a UI.

I don't use flux's kustomize (there is also kustomize by kubernetes.

I use flux for installing helm charts, mostly.

Repo: https://github.com/moonpiedumplings/flux-config

It's not up right now though. I am currently revamping it, which will also involve reorganizing the repo. I really dislike that I didn't use (flux's) kustomize, which is one of the things I would like to fix.

I'm on my phone rn, if I get to this post again from my computer later I will add longer/further thoughts.

Did you try installing without ventoy?

Sometimes ventoy causes issues. Although every time I've had an issue I thought was a Ventoy issue it had turned out to lie somewhere else, but it's important to isolate variables.

i2p is based on freenet (back when it was known at freenet).

I don't think it supports storage though, just routing.

You can enable filename, and even fulltext indexing on windows. It will then cause search to be much faster, and even search file contents.

Not enabled by default though.

Edit: hmmm, I actually read the post now.

Maybe you can interact with the index under the hood, via interfaces other than explorer?

This is very impressive. The battery life on this must be insane.

It's tough. The problem is that, on the tech side, technically, torrents don't have to seed. People have made fake torrent clients that only pretend to seed, but actually only download. The IP's are detected and then banned, but it's a cat and mouse game.

Enforcing it with backups is a similar struggle. There exist paid solutions, that use crypto to pay for decentralized storage. You "rent" out some of your storage, or by some using crypto. Filecoin, sia, storj, and so on.

But these have flaws too. Often, there level of decentralization is questionable, and the maker of the crypto takes a cut, plus there are issues with using a custom crypto coin as well. The coin's value can fluctuate — there are challenges with it simultaneously be an investment, AND a currency, but that's what often happens.

A better solution, is just to trade hard drives with your friends, who you know in person. Or maybe trust online, at least. Just give them an encrypted backup. And then they give you an encrypted backup.

In my opinion "encrypted, decentralized backups", is the kind of problem that is extremely difficult to solve technically, but is trivially solved via touching grass. I don't really like the technical solutions people have presented to this problem, and a local community is a much simpler way to solve these challenges.

Second comment, but if you need/want Caddy we can help that too. It looks like the documentation link in the github page you linked is dead, and the correct one is: https://caddyserver.com/docs/json/apps/tls/automation/policies/issuers/acme/

I found that from this page: https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148

Setup legit Let’s Encrypt as wildcard locally to test services at *example.domain.com, then put them into production on mainsite wildcard *.domain.com on VPS or similar.

Just to be clear, why wouldn't simply provisioning a certificate for each subdomain under the wildcard work?

Like, if you have a test site test.example.domain.com, you could have nginx (using acme) create a certificate for that. And then when you move to test.domain.com, nginx would do the same thing.

Now, technically letsencrypt does have a rate limit, but it's a fairly generous rate limit:

Up to 50 certificates can be issued per registered domain (or IPv4 address, or IPv6 /64 range) every 7 days. This is a global limit, and all new order requests, regardless of which account submits them, count towards this limit. The ability to issue new certificates for the same registered domain refills at a rate of 1 certificate every 202 minutes.

I would do my testing this way,, and I didn't hit any limits, although I was careful to keep certificates and reuse them, and to not spam.

If you need more domains with SSL than that rate limit would provide, then it would make sense to investigate Caddy with porkbun, since DNS-01 challenges are the only way to get wildcard certificates, which apply to a whole wildcard.

Debian unstable/sid (the rolling branch) was affected. Debian is not special.

Debian stable, Red Hat, and Ubuntu LTS were not affected. They also happen to be popular on servers, because of things like this.

This specific attack was discovered early,

Debian only updates packages on a new distro release, every 4 years. Red Hat does so every 13 years. There is a huge difference between a 6+ year window to detect packages, and a less than a week's notice because you are keeping up with the latest from upstream.

The stable distro model is broken.

I will address this one at the end, since it's a longer point.

Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones.

Okay. And? We are talking about supply chain security here.

There is a huge difference between vetting packages once every 6 years, and the continuous, ongoing, toilsome process that you are made to in order to maintain systems like cargo's build system.

despite actually shipping the compromised xz version? It’s Arch. Why? Because they didn’t patch systemd with xz support thinking they can outsmart an upstream.

The XZ utils backdoor could have easily effected any distro that uses xz for any form of root/system level service. The backdoor makers decision to not do this doesn't actually make Arch or other distros that did this more secure. Debian stable did not receive vulnerable code in the first place. Big difference.

Distros pull from upstreams anyway (code has to exist somewhere), crates.io included.

This is because rust and crates makes it impossible to do any form of dynamic linking. Which is why some people have gripes with rust and avoid it.

But for C, Java, and other languages, it is possible for distros to ship and manage libraries, which has the benefit that the various libraries can have their security issues fixed automatically.

What makes you think JAVA or its ecosystem(s)

The Java ecosystem, and it's various language specific package managers have lots of problems. But I am specifically talking about the Java ecosystem available from stable Linux distros, like Red Hat or Debian.

So. Why would I want a stable distro? Why would I want "old" packages? The reason is very simple: The absolute guarantee of compatibility between the security updates, of the programs themselves, and dynamically linked libraries.

If I make, say, a Java program, and tie it to Java packages available from the stable distro, when programs in that

The model of vendoring dependencies, breaks this. With Cargo (or uv or etc), the programs move very fast, and updates break things. In order to prevent their program from breaking, developers pin packages. And then, they don't update them. This results in them shipping code with CVE's to their users, even though the CVE has already been fixed in an upstream version.

I like to run cargo-audit, or the go equivalents on the open source projects I look at, and I almost always find vulnerabilities of varying degrees of criticallity. Here is cargo-audit ran against radicle-tui: https://gist.github.com/moonpiedumplings/7e71121b76c58ecaba4176be9bb827c4

With a mere 5 months of not being touched, there are now present CVE's that are critical on the scoring system (radicles top repo had none yippee! and their second to top repo had a few mediums). It irritates me to see them in software that interacts with networked systems.

I only very rarely find programs that are empty of CVE's. Usually only the most well resourced, active projects are able to keep their audit clean. It's a lot of work —

Work that a stable distro automates. With a stable Linux distribution like Debian, I can be confident that if I make a program tied to libraries or programs that the distro provides, this stuff will automatically be patched and handled for me.

Look, you don't have to use a stable distro on your own personal Linux desktop. I use Arch on my laptop. But for servers, not using pinned dependencies, and instead linking against libraries provided by distros means saving thousands of hours of toil doing basic cleanup of updating libraries and figuring out what the newer version of libraries broke. With a stable distro, you just do that once every six years.

I am writing a report about this which I am not sure if I should send or not.

When asked if you are complying with whatever polices you say you are unable to determine that without X tool.

Second comment, but make sure to put stuff like that into an email. Project yourself by making those permanent, semi public notes.

Just curious, what RMM software are you using?

So, the way Active Directory policies work is quite interesting under the hood. They are essentially served over SMB, and then clients query them, before applying them locally, or you can "push", requesting clients to do this. To be explicit: group policies are the same local security policies, but synced. Of course their is a little bit more nuance, technically they are separate but group policies always win in case of conflict. Regardless, what I mean is that it's not magic, it's not really technically superior to other ways to do it, and you could theoretically get something of equivalent resilience.

scripts are not reliable and tend to break with updates, they won’t stack well

The cool thing about Active Directory policies, is that they are declarative, and idempotent. This means, that rather than say, editing a config file, or installing some program, you are just setting variables to values. A script that sets secpols.whatever to X value won't really care about things like the order of the script, or whether the value has already been set, or whatever.

Because of this group/security policies this way will be fairly reliable. Using powershell to set goup/security policies, isn't really the same thing as doing scripting that does logic. Like, say I have a script that checks for something, then does something else — that's where things begin to get brittle.

Now, this is one half of the end, system management. The other half of what Active Directory provides is centralized accounts (IDM/IAM). Other services connect to active directory for authentication, so people use it to log into say, their file server, or their firewall, or the servers, or whatever. When a user leaves, or is compromised, or whatever, you can simply lock their account. This is much, much better, both in security wise, and ease of use wise for provisioning/onboarding users. The previous model, is "password sprawl". Where a spreadsheet of passwords for services gets passed around, and sometimes makes it into the hands of attackers. There is no easy way to audit all the services, ensure that the passwords are up to date

Now, if you are avoiding Active Directory, there exist alternatives for centralized accounts. For example, you can use Microsoft's Cloud stuff, and then use that to authenticate the local machines. Don't give the users admin, and then managing the group/security You can then use Microsoft 365, or Entra ID as a centralized authentication point for external, non microsoft cloud services.

This can be superior to Active Directory for a few reasons. One reason is that Active Directory is a hard, toilsome service to deploy and secure. You have to sit on top of it, watch for CVE's, and patch them. On the other hand, a small, specialized RMM server is much easier to secure, and way less attack surface. Also, if it's push based to agents, it can be updated without any downtime, compared to users not being able to log into services when LDAP goes down. By offloading security onto cloud services like Microsoft's authentication methods, you can gain a big increase in uptime and security, at a very low cost.

Another is cost. A smaller RMM will be cheaper... or free if you are using an open source solution (like TacticalRMM which is built on Meshcentral (but Meshcentral can also be deployed seperately)). Active Directory on the other hand, costs money.

"this is how we were advised to proceed”

But, let's be honest. What I wrote above is a charitable interpretation, where I am assuming what they are doing is good. What is described above is cool, but only 0.01% of environments you encounter will have novel, well thought solutions like this. It is way more likely that intuition is correct, and the infrastructure is simply brittle and insecure.

Now, you probably want to change it, and that's good! But you need to understand, that changing it is not so simple. At many businesses, security is treated as an expense with no benefit. It doesn't actively make a profit, or save money, so it is ignored. Even free solutions that cost labor will be tough to push through. Active Directory is paid, but is honestly not that much ­— but the migration and deployment phase might cost a lot. You need to understand that, you are trying to fight through that, when convincing people in charge of making these decisions.

You also need to understand, that when you argue or make points towards AD, or any better security solution, the people you are arguing with will not always be honest about the reasons. Perhaps they themselves don't understand why.

If you attempt to debate, you are may hear a bunch of excuses that obfuscate the real reason why better security isn't pursued.

• "this is how we were advised to proceed”
• "We need administrators trained"
• Various technical reasons, ranging from absurd BS to legitimate critique
  • "Our firewalls block SMB"
  • "Laptops"
  • "We have Linux servers"
• AD Costs money

And then, even if you grind down all these arguments, sometimes you are still just met with simple flat out rejection.

So. If you want to increase security, you have to think like them. You have to translate it to $$$, and put that on a page, on a report, that you can summarize and present. One assumption I would like to correct in advance is the idea that "Labor hours = dollars". From what I've seen, arguing that "automating xyz process saves my engineering hours" arguments, don't really seem to work. What is arguably the most effective, is presenting a way to either save money (and I mean raw cash, not engineering hours), or make money, that incidentally increases security.

Of course, not everybody is motivated by dollars. Sometimes it's a senior engineer who wants things done "their way", for specific reasons. Sometimes an executive is incapable of remembering a password other than "Password123!". You have to understand why and work with their motivations.

This is politics. Balancing peoples interests, making concessions, and granting them what they want in order to advance your own interests. Unfortunately, it's a skill, that you will probably need in order to advocate for security.

Good luck.

Maybe this?

https://github.com/risujin/cellwriter

It's the only thing I found in this list here: https://wiki.archlinux.org/title/List_of_applications/Utilities#On-screen_keyboards

Last updated 9 years ago though...