Selfhosted

nope.

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.

About as much as I trust other drivers on the road.

As in I give it the benefit of the doubt but if something seems off I take precautions while monitoring and if it seems dangerous I do my best to avoid it.

In reality it means that I rarely check it but if anything seems off I remove it and if I have the time and energy I further check the actual code.

My general approach is minimalism, so I don't use that many unknown/small projects to begin with.

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.

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.

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

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.

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.

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.

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

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.

No, I pretty much only look at the number of contributors (more is better)

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.

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.

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

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?

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.