Can you really trust pre-compiled open source software?
So many open-source programs are either huge (firefox and chromium are 20gb+), take several hours to compile, or are dependency nightmares. For most people it is virtually impossible to run a system where everything is self-compiled.
Can you really trust that random dude that supplies binaries?
Hell, can you trust your disto's repositories?
It's still substantially more trustable than closed source, since someone with time on their hands can do the work of compiling it, then you can compare hashes
>he actually thinks this
LMAOOOOOOOOOOOOO
Arch had malware in it's repos earlier this year.
Their official response was they were "surprised it doesn't happen more often".
install gentoo
How do you even know the binary was compiled with a standard compiler and not evil compiler?
The only distros that do reproducible builds are Debian and some others, like GuixSD has a scheme for checking if builds are the same
I believe binaries have to be signed by whatever distro compiles it.
There was maleware in the AUR which isn't part of the arch repos you fucking applefagging nigger. Literally every guide tells you to become careful when it comes to the AUR but you never give a shit until it's too late
So you just want to read 100gigs of source code yourself?
I can't trust a hoe that looks like pic OP
I feel there's no realistic choice but to trust them. Hopefully security researchers are testing the binaries and would publish if a security issue was found. The researchers would probably be able to sell such a scandal (I hope)
dude..
just quick search in source code for words like "botnet, keylogger, virus, malware, backdoor" or other evil words
that's it
Nou, is easier to compile the code yourself with the same compiler and options and see if you get the same binaries, even if you have to guess, is still faster than to audit a compiled binary.
Compiler trap doors see 'Reflections on Trusting Trust' by Ken Thompson or read Kargers & Shells Multics report section 3.4 or something like that....
>become careful when it comes to the AUR
i wonder how many people are though lol
i guess n00bs are literally 3D anti-virus lmao
I don't have the time to audit compiled binaries or source code. I imagine it's much easier to audit a binary if the source code is available though.
I know what you mean, but for that scenario, yours and the repo compiler needs to be compromised, otherwise you will get different hashes.
Not to mention it's not at all easy to do reproducible builds, took Debian like 4 years to get to 90% reproducible because of dependency chain and optimization hell.
You can if you want build anything in C with the andrew appel verified C compiler but it will be unoptimized so you can compare builds at least vst.cs.princeton.edu
and where did you get 'your' compiler? From the distro's repo?
You still have to audit the binary, remember optimizations galore happen which can introduce problems in corner cases. Generally they will reverse a binary, extract a control flow graph from it and run SAT solvers to look for things. Otherwise a small binary, like say dropbox app, you can reverse yourself and just by hand check through it for anything phoning home out of the ordinary or trying to hijack a process, or make itself persistent.. no starch press full of these reverse malware books.
Kinda, if you're looking for example to connections to external servers that the program shouldn't make, sure is easier to detect that way, but if the connections are programmed to happen after a certain date in the future, you can't catch them until is too late.
user don't be dumb.
The answer to your question is, it depends. If the software has a large userbase of knowledgeable hackers then the answer is probably yes. There are always horror stories of obfuscated code with hundreds of thousands of lines that no one besides the person that wrote it has actually comprehensibly read.. I think you guys can name a few projects..
Yes you just need to sha256 or md5 hash check it
How am I being dumb?
It is a very real possibility that both compiler could be tainted if certain government agencies wanted too.
OpenVPN comes to mind. Pretty sure nobody anywhere understands what it does, the source is pure spaghetti code
Also not to mention you can weaponise compiler bugs. Reading the source code you may think a certain lines does X, but because of a known compiler bug the author has wrote the line for it does Y.
If you're a security researcher that is investigating the software provided by a certain distro, your first instinct would be to distrust anything coming from it including compilers.
The issue I was raising was where do you get a trustworthy compiler from? Very few people could write their own minimal C compiler used to bootstrap the compilation of GCC or whatever.
Stupid question.
>since someone with time on their hands can do the work of compiling it, then you can compare hashes
Wrong.
Non-deterministic builds means you cannot do this. Little major open source software has deterministic builds. Firefox certainly doesn't.
Maybe nigger tier windows software doesnt release identical files but linux devs do.
then get the binary built by someone you trust
Firefox does not have deterministic builds on any platform.
There's no such thing as a stupid question
I never install from the AUR without checking every line of the scripts. Even things that seem trustworthy. Everything I've installed had been legitimate so far over the past 5 years.
>Hopefully security researchers are testing the binaries and would publish if a security issue was found
yes, there are security researchers testing every piece of open source software to make sure the contents are the same
a popular trend going on now is to install arch fully configured using 3rd-party scripts, which includes a lot of packages from the AUR
That's just dumb. They get what they deserve I guess.
the AUR != arch repos you raging faggot
besides, if you use the AUR properly you read over the PKGBUILD when you install or update, its literally like a simpler bash script.
You should at least be able to recognize an iffy curl | bash type entry in there.
After performing heuristic analysis, yes
It's definitely possible to set up systems to create trustworthy binaries from open source code. Reproducible Builds is the largest effort I'm aware of:
reproducible-builds.org
>The issue I was raising was where do you get a trustworthy compiler from?
You can cross-check compilers against each other. It's tricky, but unless your threat model is Skynet then it's possible to detect tainted compilers.
>Little major open source software has deterministic builds.
Deterministic builds are fairly rapidly being adopted. For example, about 94% of packages for Debian Stretch on amd64 are deterministic.
tests.reproducible-builds.org
Just verify the checksum value. There are a lot of loosers checking it trying to publish some security article... So it is well supervised
The open source community is almost completely vulnerable to malicious binaries as things currently stand.
I suppose after there are some major episodes of malware spread the community will move more to signed binaries. Although this will still rely on trust as the means of safety.
>Literally every guide tells you to become careful when it comes to the AUR
How are you supposed to do that though? "Be careful" doesn't say anything.
Just use Gentoo lmao
>only two gentoo posts
Jow Forums officially hates gentoo now
No. Install Gentoo
no! I vet every single line of code I ever use.
>phones home or hijacks a process only at certain times of the day or after a certain period
lol fuck you
>>Deterministic builds are fairly rapidly being adopted. For example, about 94% of packages for Debian Stretch on amd64 are deterministic.
That 94% that has deterministic builds are the trivial 94%. Getting a major project like firefox to have a deterministic build is a hell of a lot more complicated than getting cowsay to build deterministically.
The software that the most users use and that is the hardest for people to build themselves is also the software that is the hardest to build deterministically.
Because when I implement a keylogger in the Linux kernel I'm going to put
// this is a keylogger
>That 94% that has deterministic builds are the trivial 94%.
I don't think there is a "trivial 94%".
>The software that the most users use and that is the hardest for people to build themselves is also the software that is the hardest to build deterministically.
The security implications of something "trivial" being compromised is just as bad as Firefox being compromised. And while more people might know the name of Firefox, there's still a lot of software that ends up on most/all Debian systems that's no longer a possible target for that kind of attack.
no, you have to read everything
trust nobody not even youreself
did any of you stupid twats actually understand what the guy said
>>I don't think there is a "trivial 94%".
Compare cowsay to firefox. If you can't tell me one is trivial compared to the other, you've got brain damage.
>The security implications of something "trivial" being compromised is just as bad as Firefox being compromised. And while more people might know the name of Firefox, there's still a lot of software that ends up on most/all Debian systems that's no longer a possible target for that kind of attack.
Not actually true, because there are more users of Firefox than there are Debian. Windows and Mac users are also forced to trust non-deterministic builds of Firefox.
Furthermore it's easier to slip something nasty into a very large binary, something that's already intended for network access won't raise many eyebrows when it makes an illicit connection, and most of the information an attacker might want to exfiltrate goes through the browser in the first place.
So you see, while a corrupted cowsay binary that gives the attacker a remote shell on your system might royally fuck you over, in practice a corrupt browser binary makes for a cleaner more straight forward attack.
He's fucking with you retarded autismo.
What user couldn't realize was, that one post was also a ruse.
>trusting anyone
Sure :^)
>Several hours to compile
Not with ryzen
Do you trust cloverOS builds, lads? Surely Jow Forums wouldn't alter software, right?
>Compare cowsay to firefox.
94% of Debian isn't Cowsay. There's a tonne of libraries and system programs in there, and they're at least as tempting targets as FF.
>Not actually true, because there are more users of Firefox than there are Debian. Windows and Mac users are also forced to trust non-deterministic builds of Firefox.
I don't understand how that's relevant. The Windows and Mac FF users aren't using Debian's FF build.
>Furthermore it's easier to slip something nasty into a very large binary, something that's already intended for network access won't raise many eyebrows when it makes an illicit connection, and most of the information an attacker might want to exfiltrate goes through the browser in the first place.
There's plenty of other places that are also potential targets for some or all of those reasons.
>So you see, while a corrupted cowsay binary that gives the attacker a remote shell on your system might royally fuck you over, in practice a corrupt browser binary makes for a cleaner more straight forward attack.
Stop pretending everything else is Cowsay - the 94% includes things like OpenSSL and X11. Excluding those programs from corrupted binary attacks is a huge gain for security, even without 100% of packages protected.
You clearly have no idea how packages are built on Arch Linux do you? How do you think you be careful? How about you use your peanut brain for once or just look up the answer.
You can trust it but it isn't safe. Of course you can't trust open source software that you haven't read either.
>How do you think you be careful?
I'm not the person your replying to, but I'd have no idea what to do if a repository tells me to "be careful" (with regard to security).
Should I be trying to check that the devs are legitimate? I don't have anything to go on but a website.
Should I be reading all the source code? Then how do I trust the build process?
Should I be re-compiling the binaries? Then what do I need the repo for?
The only "careful" option I can think of is avoiding that repository completely.
Yes. You left out the most important thing. Check the package build scripts.
>Should I be re-compiling
If your going to wave your dick around in another conversation you could at least read the conversation. This is about the AUR. You make the packages yourself using the build script of a user that isn't trusted. It's pretty fucking obvious what the main issue is here.
>firefox and chromium over 20GB
Opinions discarded.
I've wondered about this myself.
The software you use may be open source and trustworthy up there in the git repos, but what's on your computer is not "open source" and not necessarily the same thing from the git repos.
It's compiled binaries you have no feasible way of auditing.
Your program didn't simply teleport itself from the git repo to your machine where it magically turned out compiled.
It went through multiple points in between and it may have been tampered with at any of them.
So, unless you're using a mature and well established distro with confirmed good security practices and trustworthy maintainers which have been around as active community members for long enough and are known to be principled men of integrity, the "open source" software you end up with comes not only with the same uncertainty which is intrinsic to any closed source software, but the kind of uncertainty that comes with a pirated copy of Windows sold to you on a CD by some gook in a back alley.
I'm installing gentoo for the first time in a VM right now, but it's one of those long projects I'm hitting when I have free time.
Or just clone the repo and compile from source
Why do people not think this is a solution?
>muh untrusted make files
You can read make files.
unless there's a ken thompson style compiler hack
>not building it yourself
Those are detectable with double-compiling.
>several hours to compile
Looks like we have a corelet boys
> Several hours to compile
Looks like someone fell for the C++ meme
Why's that 12 year old boy wearing make-up?
>filename
If you have a compile you can trust...
Also Ken Thompson didn't come up with the idea he popularised it, Karger & Schell came up with the idea. Ken also mentions the compiler is just the begining you can go lower and lower if you have the resources and therefore defeat DDC.
You don't need to trust any single compiler. You can test against a diverse set of compilers, with different histories and targets.
unless every compiler is compromised
If you actually read the double diverse compiling paper you'd see the author talks about writing your own C compiler. Because that is the only one you can trust.
Testing more compilers is easier than writing malware which affects more compilers. And there are a LOT of compilers out there.
>If you actually read the double diverse compiling paper you'd see the author talks about writing your own C compiler. Because that is the only one you can trust.
What? No, that's missing the point.
The whole point of DDC is that by cross-checking you can improve your confidence in a set of compilers. Writing your own may help, but it's far from nessisary.
Also, AFAIKT the only mention of writing your own compiler in the paper is this: "It is also possible to write a new trusted compiler from scratch."
It's a user repository. It literally says that anyone can add whatever they want to it and to use with caution. It's the same thing as if you trusted a download that you got from a search engine.
Yeah, there's never any malware in Google links
Hell no!
>For most people it is virtually impossible to run a system where everything is self-compiled.
install gentoo ,like i did, and stop worrying you colossal faggot
You can't even trust a compiler you compiled yourself without jumping through a bunch of hoops. Then you can't trust basically any hardware newer than 20 years old.
Computing is fucked.
Do you review every line of code before compile the software ?
Do you trust yourself to notice any bullshit While reading it
no. you also can't trust their source code. our your os. or your compiler. or your firmware. or your hardware.
This.
This is why I use proprietary software, because what's the difference then? At least proprietary software just works.
Malware in aur package is added by replacing url the aur package downloads source code / binaries from, so you check the url source in package build script to check it belongs to the official source of the program. For example many aur packages fetch from official github repository for the project so you just have to check that the package script url is that github repository.
> can't trust your compiler
ken thompson said this in the 80s, and yet things have yet to implode
99% of popular public code & executables is scrutinized by someone somewhere, and if anyone dares screw with binaries or source code to put malicious code someone will know eventually.
You should just rely on hashes, when possible, if someone has reported the hash (Sha1, md5..) of a certain file to be malicious, and you have downloaded a file with said hash you know you are screwed, but if no such reports have occured for over weeks, you're probably safe.
Utilizing virus total is always a good idea, just so you know the file has been scrutinized. If virus total comes up with fresh results, you are risking it.
I doubt everything in the arch repos is audited considering the sheer size of that stuff and its constant growth