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.

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.

I do not. But then again, I don’t audit the code of the closed source software I use either.

I run projects inside Docker on a VM away from important data. It allows me to test and restrict access to specific things of my choosing.

It works well for me.

It’s not feasible. A project can have 10s or 100s of thousand lines of code and it takes months to really understand what’s going on. Sometimes you need domain specific knowledge.

I read through those installers that do a curl gitbub... | bash. Otherwise I do what amounts to a “vibe check”. How many forks and stars does it have? How many contributors? What is the release cycle like?

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

I trust the community, but not blindly. I trust those who have a proven track record, and I proxy that trust through them whenever possible. I trust the standards and quality of the Debian organization and by extension I trust the packages they maintain and curate. If I have to install something from source that is outside a major distribution then my trust might be reduced. I might do some cursory research on the history of the project and the people behind it, I might look closer at the code. Or I might not. A lot of software doesn’t require much trust. A web app running in its own limited user on a well-secured and up-to-date VPS or VM, in the unlikely event it turned out to be a malicious backdoor, it is simply an annoyance and it will be purged. In its own limited user, there’s not that much it can do and it can’t really hide. If I’m off the beaten track in something that requires a bit more trust, something security related, or something that I’m going to run it as root, or it’s going to be running as a core part of my network, I’ll go further. Maybe I “audit” in the sense that I check the bug tracker and for CVEs to understand how seriously they take potential security issues.

Yeah if that malicious software I ran that I didn’t think required a lot of trust, happens to have snuck in a way to use a bunch of 0-day exploits and gets root access and gets into the rest of my network and starts injecting itself into my hardware persistently then I’m going to have a really bad day probably followed by a really bad year. That’s a given. It’s a risk that is always present, I’m a single guy homelabbing a bunch of fun stuff, I’m no match for a sophisticated and likely targeted nation-state level attack, and I’m never going to be. If On the other hand if I get hacked and ransomwared along with 10,000 other people from some compromised project that I trusted a little too much at least I’ll consider myself in good company, give the hackers credit where credit is due, and I’ll try to learn from the experience. But I will say they’d better be really sneaky, do their attack quickly and it had better be very sophisticated, because I’m not stupid either and I do pay pretty close attention to changes to my network and to any new software I’m running in particular.

nope.

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…

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.

Let me put it this way: I audit open source software more than I audit closed source software.

Lol. I download a library or program to do a task because I would not be able to code it myself (to that kind of production level, at least). Of course I’m not gonna be able to audit it! You need twice the IQ to debug a software compared to the one needed to even write it in the first place.

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.

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