this post was submitted on 29 May 2025
170 points (98.9% liked)

Selfhosted

46685 readers
716 users here now

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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

The question is simple. I wanted to get a general consensus on if people actually audit the code that they use from FOSS or open source software or apps.

Do you blindly trust the FOSS community? I am trying to get a rough idea here. Sometimes audit the code? Only on mission critical apps? Not at all?

Let's hear it!

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 1 week ago

All I do is look into the open issues, the community, docs etc. I don't remember auditing the code.

[–] [email protected] 1 points 1 week ago* (last edited 1 week ago)

Yes, but with an explanation.

You don't necessarily need coding skills to "audit", you can get q sense of the general state of things by simply reading the docs.

The docs are a good starting point to understand if there will be any issues from weird licensing, whether the author cares enough to keep the project going, etc. Also serious, repeated or chronic issues should be noted in the docs if its something the author cares about.

And remember, even if you do have a background in the coding language, the project might not be built in a style you like or agree with.

I'm pretty proficient at bash scripting, and I found the proxmox helper scripts a spaghetti mess of interdependent scripts that were simply a nightmare to follow for any particular install.

I think the overall message is do your best within your abilities.

[–] [email protected] 1 points 1 week ago

I look whether if someone has audited the code or not & even then I simply find Libre stuff trustworthy anyways

[–] [email protected] 4 points 1 week ago

no. ive skimmed through maybe 2 things overall but thats about it. i use too many apps to be able to audit them all and i dont have the proper skills to audit code anyway, and even if i did i would still have to re-audit after every update or every few years. its just not worth the effort

youre taking a chance whether you use closed or open source software, at least with open source there is the option to look through things yourself, and with a popular project theres going to be a bigger chance of others looking through it

[–] [email protected] 7 points 1 week ago

Nope! Not at all. I don't think I could find anything even if I tried. I do generally trust OS more than other apps but I feel like I'm taking a risk either way. If it's some niche thing I'm building from a git repo I'll be wary enough to not put my credit card info but that's about it

[–] [email protected] 12 points 1 week ago

no... I do just blindly trust the code.

[–] [email protected] 7 points 1 week ago

Yes. It's important to verify the dependencies and perform audits like automated scans on the source code and packages from repositories like PyPi and npm. Which is done on my day job.

Also before mirroring data, I look at the source code level if I see anything suspicious. Like phoning home or for example obfuscated code. Or other red flags.

Even at home, working on 'hobby projects', I might not have the advantage of the advance scanning source code tools, but I'm still suspicious, since I know there is also a lot of sh*t out there.

Even for home projects I limit the amount of packages I use. I tent to only use large (in terms of users), proven (lot of stars and already out for a long time) and well maintained packages (regular security updates, etc.). Then again, without any advance code scanning tool it's impossible to fully scan it all. Since you still have dependencies on dependencies with dependencies that might have a vurnability. Or even things as simple as openssl heartbleed bug or repository take overs by evil maintainers. It's inevitable, but you can take precautions.

Tldr: I try my best with the tools I have. I can't do more then that. Simple and small projects in C is easier to audit then for example a huge framework or packages with tons of new dependencies. Especially in languages like Python, Go and Javascript/typescript. You have been warned.

Edit: this also means you will need to update your packages often. Not only on your distro. But also when using these packages with npm and PyPi, go or php composer. Just writing your code once and deploy is not sufficient anymore. The chances you are using some packages that are vulnerable is very high and you will need to regularly update your packages. I think updating is just as important as auditing.

[–] [email protected] 4 points 1 week ago

Generally, no. On some cases where I'm extending the code or compiling it for some special case that I have, I will read the code. For example, I modified a web project to use LDAP instead of a local user file. In that case, I had to read the code to understand it. In cases where I'm recompiling the code, my pipeline will run some basic vulnerability scans automatically.

I would not consider either of these a comprehensive audit, but it's something.

Additionally, on any of my server deployments, I have firewall rules which would catch "calls to home". I've seen a few apps calling home, getting blocked but no adverse effects. The only one I can remember is Traefik, which I flipped a config value to not do that.

[–] [email protected] 29 points 1 week ago

Depends on what you mean by "audit".

I look at the GitHub repo.

  • How many stars?
  • Last commit?
  • Open issues
  • Contributer count

Do I read the whole code base? Of course not. But this is way more than I can do with closed source software.

[–] [email protected] 2 points 1 week ago (1 children)

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.

[–] [email protected] 0 points 1 week ago (1 children)

What if the software is just so flawlessly written that there are not CVEs?

/s

[–] [email protected] 5 points 1 week ago (1 children)

I maintained an open-source app for many years. It leveraged a crypto library but allowed for different algos, or none at all for testing.

Some guy wrote a CVE about "when I disable all crypto it doesn't use crypto". So there's that. It's the only CVE we got before or during my time.

But even we got one.

[–] [email protected] 1 points 1 week ago

Oh damn, haha.

[–] [email protected] 8 points 1 week ago

I rely on Debian repo maintainers to do this for me

[–] [email protected] 4 points 1 week ago

No, so I only use well known widely used open source programs. If I'm doing a code review I'm getting paid to do it.

[–] [email protected] 6 points 1 week ago

I don't have the know how to do so, so I go off of what others have said about it. It's at-least got a better chance of being safe than closed source software where people are FULLY guessing at if its safe or not, rather than what we have with at-least 1 person having poured over it that doesn't have ties to the creator.

[–] [email protected] 2 points 1 week ago* (last edited 1 week ago)

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.

[–] [email protected] 8 points 1 week ago

depends like for known projecte like curl i wont because i know its fine but if its a new project i heard about i do audit the source and if i dont know the lang its in i ask someone that does

[–] [email protected] 48 points 1 week ago (3 children)

Nah. My security is entirely based on vibes and gambling

[–] [email protected] 4 points 1 week ago
[–] [email protected] 4 points 1 week ago
[–] [email protected] 7 points 1 week ago

Hell yeah brother!

[–] [email protected] 5 points 1 week ago

some yes, I'm currently using hyde for hyprland and I've been tinkering with almost every script that holds the project together

[–] [email protected] 1 points 1 week ago

Depends on how the project and how long they have been around.

[–] [email protected] 2 points 1 week ago

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.

[–] [email protected] 7 points 1 week ago

If I can read it in around an afternoon, and it’s not a big enough project that I can safely assume many other people have already done so, then I will !

But I don’t think it qualifies as “auditing”, for now I only have a bachelor’s in CS and I don’t know as much as I’d like about cybersecurity yet.

[–] [email protected] 62 points 1 week ago (1 children)

If it's a project with a couple hundred thousands of downloads a week then no, i trust that it's been looked at by more savvy people than myself.

If it's a niche project that barely anyone uses or comes from a source i consider to be less reputable then i will skim it

[–] [email protected] 5 points 1 week ago
[–] [email protected] 3 points 1 week ago

I do sometimes, when I know the tech stack. (I wonder if GitHub Copilot could help in other situations?)

For example, I've been learning more about FreshRSS and Wallabag (especially now that Pocket is shutting down).

In any case, with open source, I trust that someone looks at it.

[–] [email protected] 3 points 1 week ago

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.

[–] [email protected] 5 points 1 week ago* (last edited 1 week ago)

I do not audit code line by line, bit by bit. However, I do due diligence in making sure that the code is from reputable sources, see what other users report, I'll do a search for any unresolved issues et al. I can code on a very basic level, but I do not possess the intelligence to audit a particular app's code. Beyond my 'due diligence' I rely on the generosity of others who are more intelligent than I and who can spot problems. I have a lot of respect and admiration for dev teams. They produce software that is useful, fun, engaging, and it just works.

[–] [email protected] 23 points 1 week ago (1 children)

I don't audit the code, but I do somewhat audit the project. I look at:

  • recent commits
  • variety of contributors
  • engagement in issues and pull requests by maintainers

I think that catches the worst issues, but it's far from an audit, which would require digging through the code and looking for code smells.

[–] [email protected] 7 points 1 week ago* (last edited 1 week ago)

Same here, plus

  • on the phone I trust F-droid that they have some basic checks
  • I either avoid very small projects or I rifle through the code very fast to see if its calling/pinging something suspicious.
[–] [email protected] 3 points 1 week ago* (last edited 1 week ago)

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.

[–] [email protected] 6 points 1 week ago

I do not, but I sleep soundly knowing there are people that do, and that FOSS lets them do it. I will read code on occasion, if I'm curious about technical solutions or whatnot, but that hardly qualifies as auditing.

[–] [email protected] 11 points 1 week ago

Of course I do bro, who doesnt have 6 thousand years of spare time every time they run dnf update to go check on 1 million lines of code changed? Amateurs around here..

load more comments
view more: next ›