I use nix-shell -p for infrequently used commands, or nix shell flake#packagename for flakes. I prefer the shell environment because I rarely need to run something only one in a session. Usually I forget the cli arguments, and then have to run --help and so on.
For anything I need more frequently, I usually install either via home manager if I care about a specific/newer version, or just as a system package (I don’t use NixOS).
Yes, I do lock it down. It’s still worth securing it because “internal servers” can still get exposed and touched, even though there are less paths to them, and it’s not as punishing to slip up vs a public server. For example, One of the wireguard client devices downloads a virus, and now you have a cyberattacker with access.
Another problem is supply chain issues. If the distributor of a docker container is hacked, it’s not that bad… as long as your kernel is up to date and is protected against some of the recent vulns, that would enable someone to break out of a docker container
Blajah.zone’s lemmy instance was hacked partially becuase internal servers weren’t being held to the same security standards as the public ones:
https://pen.blahaj.zone/supakaity/weve-been-hacked
I had not patched these internal servers that nobody should have access to against this. Rebooting DB servers causes downtime, and in my hubris – I thought nobody should (nay COULD) be on my servers except me, right?
I have a comment on that post with some potential solutions, that would have cut off attack paths.
Though, I guess, it still does depend. Like if it’s just gonna you wireguarding in and no one else, then the data on your devices is probably worth more than the data on the server, so no, it wouldn’t be worth spending too much effort to secure less valuable data.
But if you are handing out internal access to people, including to some relative who keeps falling for scammers, then yeah, I’d take some time to harden the systems.
I don’t like the less serious licenses because they often don’t explicitly declare that your software is distributed with no warranty.
This makes you liable to be sued in certain jurisdictions, where simply distributing software is assumed to also provide support, or you could be held responsible for damage it causes or misuse.
Of course, the chance of someone suing you is extremely slim. And courts are ran by humans, who can interpret the spirit of the law, rather than the letter, so I would hope they would be gracious and understanding of the open source model. But it’s better to just not take chances.
https://programming.dev/comment/24515044
Same problem is present here. Uses JWT’s for auth.
Edit:
Using jwt’s for auth isn’t bad, it’s good and quite common The problem is when they are used in place of actual bearer/cookie/session auth methods. As I understand it at least, a jwt token with a lifespan greater than 5 minutes is a red flag.
This is a browser extension that shows you the non fandom instances of wiki’s, if they exist. Or, it can also use breezewiki as a privacy preserving frontend to fandom pages.
The indie wiki’s aren’t usually federated, though.
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.
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.
Uses google as a backend and was also bought by an ad company.
I still use it, since google sometimes cuts deals with sites like reddit such that reddit is only scrapable by google. But it’s a last resort, after duckduckgo.
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.
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.
Yes. Under the hood, gnome controls the power profiles daemon.
You can configure it from the cli via
powerprofilesctl.powerprofilesctl getgets the currently active mode.powerprofilesctl set performanceset’s it to performance mode.There are three modes: ‘power-saver’, ‘balanced’, ‘performance’