I vet lesser known projects, but yea I do end up just taking credibility for granted for larger projects. I assume that with those projects, the maintainers team with pull access is doing that vetting before they accept a pull.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
I implicitly trust FOSS more than closed source but because that trust has been earned through millions of FOSS projects.
On occasion, I will dive deep into a codebase especially if I have a bug and I think I can fix it.
You can't do this with closed source or even source available code because there is no guarantee that the code you have is the code that's been compiled.
nope.
I usually just look for CVEs. The biggest red flag is if there's 0 CVEs. The yellow flag is if the CVEs exist, but they don't have a prominent notice on their site about it.
Best case is they have a lot of CVEs, they have detailed notices on their sites that were published very shortly after the CVE was published, and they have an bug bounty program setup.
What if the software is just so flawlessly written that there are not CVEs?
/s
Packaged products ready to use? No.
Libraries which I use in my own projects? I at least have a quick look at the implementation, often a more detailed analysis if issues pop up.
It depends on the provenance of the code and who (if anyone) is downstream.
A project that's packaged in multiple distros is more likely to be reliable than a project that only exists on github and provides its own binary builds.
If it looks sketchy I'll look at it and not trust the binaries. I'm not going to catch anything subtle, but if it sets up a reverse shell, I can notice that shit.
Nah not really...most of the time I'm at least doing a light metadata check, like who's the maintainer & main contributors, any trusted folks have starred the repo, how active is development and release frequency, search issues with "vulnerability"/"cve" see how contributors communicate on those, previous cve track record.
With real code audits... I could only ever be using a handful of programs, let alone the thought of me fully auditing the whole linux kernel before I trust it 😄
Focusing on "mission critical" apps feels pretty useless imho, because it doesn't really matter which of the thousands of programs on your system executes malicious code, no? Like sure, the app you use for handling super sensitive data might be secure and audited...then you get fucked by some obscure compression library silently loaded by a bunch of your programs.
Having gone through the approval process at a large company to add an open source project to it's whitelist, it was surprisingly easy. They mostly wanted to know numbers. How long has it been around, when was the last update, number of downloads, what does it do, etc. They mostly just wanted to make sure it was still being maintained.
In their eyes, they also don't audit closed source software. There might also have been an antivirus scan run against the code, but that seemed more like a checkbox than something that would actually help.
I look whether if someone has audited the code or not & even then I simply find Libre stuff trustworthy anyways
Full code audit is very time consuming. It's impossible to audit all software someone uses. However if I know nothing about project, I do a short look at the code to understand if it follows best practices or not and make some assumptions about the code quality. The problem is that I can't do this if I'm unfamiliar with the programming language the project is written in, so in most cases I try to avoid such projects.
I don't because I don't have the necessary depth of skill.
But I don't say I "blindly" trust anyone who says they're FOSS. I read reviews, I do what I can to understand who is behind the project. I try to use software (FOSS or otherwise) in a way that minimizes impact to my system as a whole if something goes south. While I can't audit code meaningfully, I can setup unique credentials for everything and use good network management practices and other things to create firebreaks.
Depends on how the project and how long they have been around.
No, I pretty much only look at the number of contributors (more is better)
I don’t know enough about programming to do it myself so I like to look at what the community says. This is one thing we’re AI could be very helpful no?
Well my husband’s work place does audit the code they deploy but they have a big problem with contractors just downloading random shit and putting it on production systems without following proper review and in violation of policy.
The phrase fucking Deloitte is a daily occurrence.
Fucking Deloitte!