I used to use innoextract to extract the launchers, and the the system wine to run it. Although sometimes I have to run extra installers that put dlls in the right spots.

You should probably just run the installer in lutris (which ships a proton distributution) or bottles.

Edit: I can’t read smh my head.

Check this out: https://github.com/lutris/docs/blob/2b116519c5b67254733234f36ab33a60f14f1358/WineDependencies.md

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.

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?

Google actually managed to get song recognition runnning locally: https://research.google/blog/googles-next-generation-music-recognition/

They had a longer research paper about how they did it, but I can’t find it rn.

So it is theoretically possible to be done open source and locally, but all current implementations that I can find are proprietary.

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.

TeamPCP is very interesting, since they actually reused an open source secrets scanner to find secrets:

https://github.com/trufflesecurity/trufflehog

So if you wanted to know, I’d start by looking there.

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.

One downside is that the cached file is not independently archived so it could be tampered with. Thanks for the idea.

You could have multiple researchers archive it and store copies independently. Then tampering would show up accross copies.

Unfortunately, central hosting doesn’t guarantee that it is tamper free. The host could be hacked, or could be malicious. Archive.is was caught tampering with their archived pages:

https://en.wikipedia.org/wiki/Wikipedia:Archive.today_guidance

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.

Check out Zotero: https://www.zotero.org/

Zotero is an open source bibliography manager. It’s my main go to tool for generating works cited pages, like during essays.

But, it also has a browser extension, which can download, and archive sites or academic articles you are adding to the sources. I would then use the fulltext search that zotero provides for easy searching of sources.

Unfortunately, it’s not hosted, which would make it difficult to share.

EDIT: It does look like the server component is open source, AGPLv3: https://github.com/zotero/dataserver/

But, I cannot find any deployment instructions. But, it looks like their hosted version lets users create groups of shared items, including sharing archived snapshots of the various items.

and nothing would happen. No error message, just nothing. To say the least, that doesn’t lend itself to troubleshooting.

Try again on a live USB sometime.

I suspect that the problem here is that programs on Linux are not executable by default, for security concerns. You have to adjust the permissions, usually using the command chmod +x filename to mark them as able to be executed. But, often you no longer need to to this, and many Linux distros/desktop environments will now prompt you when you double click, if you would like to execute the file and mark it as executable. Then it would work.

But if you were using a distro from before that was a feature, then you might have hit that papercut, where nothing happened.

One issue I have with rust is that it adds another layer of trusting the compiler isn’t backdoored. All UNIX/Linux systems use the gcc toolchain

They are probably also referring to this: https://kerkour.com/rust-supply-chain-nightmare

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

Cargo and crates are basically just as bad as npm, just less popular, which is why they haven’t been hit yet… And it’s currently very difficult to build rust programs without cargo.

Stable linux distributions have extremely strong supply chain security in comparison to language specific package managers. Debian, for example, was not affected by the xz utils backdoor, due to it’s policy of only doing cherry picked security patches, and ignoring feature or bugfixes for the most part. Given the:

installation instructions for Debian-based distros: here

That’s probably what the author was going for. Unfortunately I am too lazy to load up tor browser right now, to check the Debian installation instructions. I suspect they have their own repo with signed keys, just like Radicle does.

Of course, C is still questionable. I would prefer Java if you cared strongly about supply chain security, since its a memory safe language with a mature ecosystem, and many packages available from Debian’s repositories. But, it would be slower than C.

Calling an enterprise-grade platform

Except you use JWT’s for auth, which is idiotic and a security nightmare. No enterprise that cares about security would ever accept this.

More info: https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452

There are other problems, some of which I can see… and some of which I can’t. The problem is that I am not a comprehensive expert, I can only spot a few things here and there. Even if I was an expert, why would I audit your software for free lmao? Pay me for that shit.

What I do know, is that vibecoded apps are bad at security. Many, many vibecoded apps have been hit by horrific security bugs like remote code execution, xss, or authentication bypasses. That shit is simply unacceptable and should be extremely rare in modern apps. The fact that I’m not skilled enough to find them reliably makes me even more cautious and concerned around apps like yours.

It’s not just about the app architecture, but also about you. When a known community figure creates an app, I have confidence that they will have a good security posture and architecture. With vibecoding… not so much.

If you have an actual architectural critique

Nice bait, but the problem is this: Just because you get people to audit “critique” your software, doesn’t fix the root cause of those problems — you. Just because you manage to re-vibecode the app to not use JWT’s or to fix any other number of issues someone would point out, doesn’t actually mean more issues exist that that person missed. Like if someone specialized in python, then they might miss database issues, and so on. The second problem is that inevitably, you will expand this software, adding more features… and vulnerabilities. That is to say, even if you manage to fix the architecture and security now, you have not demonstrated the requisite skill needed in order to keep it fixed.

I am trying to use nix and firejail only, but it is pretty rough and barely documented which is kinda insane as firejail is THE tool. Unlike crabjail, bubblejail and what else is out there

I was investigating sandboxing with Nix. Here is a dump of my saved notes:

General Nix Based

github.com/nixpak/nixpak

github.com/Naxdy/nix-bwrapper

https://todo.sr.ht/~alexdavid/jail.nix

LLM Specific Nix based

Projects to sandbox AI agents:

https://github.com/archie-judd/agent-sandbox.nix

https://github.com/myme/jaillm/blob/main/flake.nix

https://github.com/gfauredev/nix-agents-jail

https://github.com/azuwis/fence-agent.nix

github.com/kohane27/jailed-ai-agents/blob/main/llm.sh

Someone told me that if you take these things and then replace the entrypoint with bash, you get a sandboxed shell environment

What if the new account user, who is working on a product that integrates with what the vast majority of selfhosters run, just found Lemmy?

This happens on Reddit, and basically my problem is that these users often don’t have enough experience to be able to actually give solutions. Reddit is full of people who think they have a good solution, dealing with comments of people explaining that what they are struggling with is actually a solved problem (or a skill issue). No one cares about your vibecoded slop that implements 1% of the features of an existing open source solution (they used to not be vibecoded but we still didn’t care). It being paid and proprietary is just even more annoying.

My idea of requirement to engage with the community is also about being able to ensure that the users are technically competent. If they are experienced, it will show up in the discussions we can see and review. For their benefit, if they lurk, then they can take a look at what is being used, and what problems actually exist, instead of making assumptions.

If they really believe their product is so good, they can spend a few weeks helping people with Linux questions and sharing their (non product related) insightful thoughts on Lemmy so I don’t dismiss them instantly when they finally advertise it.

Not everybody does. It’s just sometimes.

If the tarball was dynamically linked against specific distro’s libraries though, then it wouldn’t work on all distros.

They also often provide RPM packages for Red Hat systems. Not always though, and I use Arch (btw) anyways.

snap is likely the most secure by avoiding user namespaces, using AppArmor only and thus being very flexible (also for use for kernels, drivers, browsers …) but it is proprietary, nobody likes it and Canonical doesnt wanna stop somehow.

Snap does seem to support user namespaces. Although I want to comment that user namespaces are not universally insecure. When an application is confined within a user namespace, seccomp rules restrict it from being able to interact with the user namespaces subsystem, walling it off from the increased attack surface.