5

I have a question about Open Source programs. How can I sure an open source program is safe and isn't spying on me? For example, I installed Firefox on Linux and how can I sure this program is safe! It is true that Firefox is open source, but who can read a million lines of code!. Users using open source software and trust to them because they are open source and all people can read and examine codes, but no one does that. I guess some companies and programmers abuse from this mindset of users and can do anything. Closed Source programs don't have any confidence and I think it is true for large Open Source programs too.

7

It is true that the developer of the original application can be malicious: Ken Thompson's famous (and seminal, and also very readable) paper "Reflections on Trusting Trust" makes clear just how deep that rabbit hole can go. Absolute security is very difficult to achieve, and free software is not a perfect remedy for this. But between absolute security and no security there is quite a gulf, and not all locations in that gulf are equivalent.

There are other people who could be malicious, against whom free software can help defend you. Commercial developers can, and frequently do, write software which is at least partially inimical to the interests of their users. You have no way of knowing what that software is doing - certainly none so easy as examining the source code, for all that that is difficult.

There are many other people other than the developer involved in the software packaging and distribution chain who might wish you ill, and here, too, free software can help. The Reproducible Builds movement aims to enable people independent of the distributors to build software from the sources provided; you can then compare the checksums of your binaries with those they produce, to have greater confidence that the software you're running is indeed a faithful representation of the source code to which you are entitled.

So no, free software is not perfect. But it's a great deal better than running some random binary that comes on a CD-R with the strange webcam you've just bought off the internet.

| improve this answer | |
  • I agree. Security is impossible. – Nongeek Oct 17 at 20:24
  • @Nongeek Perfect security is impossible. My point is that not all imperfect securities are equally bad; imperfect as free software is, it's nothing like as bad as proprietary software. – MadHatter Oct 18 at 8:02
1

You can not be.

The only difference is, that with an opensource software, there is at least some chance that a backdoor is revealed. In the case of closed source, the chance is close to zero (maybe if the most honored producer commits a mistake).

Note, actually searching for security holes in a software is a different skill than developing it, thus the complexity of the code does not defends it against a security audit so strongly as we would think with layman's eyes. There are many tricks to use, for example, by checking always for the differences of the code, or using various software tools to check for possible vulnerabilities and then analyzing them by human brain.

What could work, if you use a combination of opensource softwares where to break your system, one needs to break both of them. For example, using opensource app in a virtual machine - to crack your host machine, both of the VM and the app needs to be cracked.

| improve this answer | |
  • Some security holes are intentionally. – Nongeek Oct 17 at 20:25
  • 3
    @Nongeek Yes. Typically, core developers of well-known, security-sensitive opensource projects could be recruited by some... "agencies". But this can be done with closed source, too, and with closed source, much better. – peterh - Reinstate Monica Oct 17 at 21:24
-1

How can I [be] sure an open source program is safe[, that it] isn't spying on me?

You can not be.

But I do have a couple couple notes,

"open source" doesn't do anything at all for security, there is no mechanical limitation that requires your software vendor builds their software programs from the public source code they may share. (or for that matter, use a sane compiler, or computer)


"copyleft" is a license that many label as open source which ensures you own the software you run, which means that at-worst you could rebuild the program from source/scratch yourself, and remove or change any and all parts of it you don't like or don't have a license to use, (there are many examples of this happening in the browser space, such as chromium, and iceweasel).

Building it from source still doesn't do anything to secure you against against your software source-code vendor.

Building from source only gives you the capability to secure yourself from yourself.
Not all "open source" code permits you the right to modify, remove parts, or even use at-all, the source code you may be able to find and read.


"building software" as https://opensource.stackexchange.com/a/10567/4370 mentions, an essay "Reflections on Trusting Trust", talks about how the software build tools can silently, transparently, and perpetually inject malware with real examples. I summarize this for myself to the effect of "any computer can lie to you without you knowing at any time", (this is the premise of hacking culture, invisible lies). This can seemingly only sorta be remedied by compiling all your critical build software by hand with your own brain, and then trusting that you as a human computer was not compromised, and then ensuring the software supply chain end to end you trust, (which then implies that only ever use physical computers you trust, trust not to do the same thing software can do and transparently inject perpetual malware, so we add the step of building a computer from scratch by yourself with components simple enough that they alone cannot compromise the integrity of your computer). Both of these are even more herculean task than simply reviewing a lot of source code.

this rabbit hole does not end.


"trust", there are many trust-models each with various theories of operation of their trust model

One popular trust-model is the "web of trust",

I trust my good friend Bob, 
I know for an indisputable fact that Bob trusts Alice as much as I trust Bob
Via this logical chain of trust I can imply to myself that I trust Alice

Suppose I know six people who all trust Alice,
Eventually I these six people reasonably enough, 
with enough of a "web of trust" bridging any two people, 
I can establish how much trust I can assign to Alice, or any identity.

In this way, I can then 'trust' that if I get a program emailed to me from Alice, I can probably run it and expect it not to spy on me, at least not by Alice's intention. Except, an email address guarantees no authenticity of the data within the message, nor any integrity checks that the message is not corrupt. (more on this later.)

A more widespread trust model is the "chain of trust", similar to the web of trust except it relies only on a single path.

Lets say I choose to trust Google, or Mozilla; 
both trust some parts of Digicert
Digicert trusts example.org and certifies their authenticity (usually with a financial relationship)

in this way; when I visit example.org, I assume I can trust example.org because I trust mozilla

This is how HTTPS on the internet works, by-in-large (it is not the only way it can work).

A note on space-time;

Anything that can be secured across space(distance), must also be secure across time. Meaning, if I can securely copy something from example.org to my computer, then whatever I copied must also be secured between the time the copy started, to the time the copy's authenticity was asserted. In the web, this usually takes less than a second, but note that it is not instantaneous. It is possible for this time gap to be quite large, all the maths and assertions we do can also function over a large span of time say between the year 1999, and 2020, in fact, many HTTPS certificate authorities, have certificates themselves that are valid for a decade!


"cryptographic signatures", a tool to assert with maths, that my copy is authentic (and necessarily not corrupt)

"end-to-end encryption", a way to prohibit, with maths, anyone who isn't my recipient from reading my message to my recipient

"checksum", a tool that asserts with maths, that two copies are identical, cheaply.

PGP 'asc' and 'sig' files are cryptographic signatures. for example this older version of firefox offers a checksum protected with a PGP signature (a common practice to reduce computational expense):

https://releases.mozilla.org/pub/firefox/releases/3.6.13/

(note!! please use extreme care when using obsolete browser programs)

In this example if we want to believe that we trust in whats happening, consider this:

we choose to trust Mozilla, we somehow magically acquire their signing key securely, 
(doing so is quite hard, reflections on trusting trust tell us we are probably already compromised by this point)
we use that signing key to assert that this SHA1SUMS file is authentic (came from someone mozilla trusts)
we use this checksum to assert that ./linux-i686/en-US/firefox-3.6.13.tar.bz2 is not corrupt, implying it is probbaly authentic
we now have our firefox program,
we open it, and use it to open example.org
our browser checks that example.org's response is authentic by checking that it is signed by Digicert, trusted by Mozilla
(done)

That is a lot of work, especially to ask of a large body of individuals.


"software repository" is a storage location for software packages, often including meta data, maybe even metadata on how to automatically test each program for authenticity, often offering a custom tool to fetch and install these packages automatically.

There are a ton of these if you go looking for them, almost every programming language has their own, almost every operating system, and major tech company has their own. I've worked extensively with debian's apt, either way we're simply adding one more layer onto the code signing lasagna, consider:

we choose to trust debian, we somehow magically acquire their signing key and apt securely

debian already built a custom version of firefox themselves in a very well documented and public way
debian already checked that the software license permits them to use it as we want to
debian already provides packages checksums so that we can trust our copy is the same as theirs
debian already signed their packages so that we can trust that the file came from them
debian already has an automatic build system to ease production of packages and modifications
debian already has a reproducible builds initiative
https://wiki.debian.org/ReproducibleBuilds
we can in some cases already check if we can reproduce a software build to assure we aren't the target of anything but an extremely sophisticated personal attack
debian already defined and publish documentation and policies to govern its repository
we do have to blindly trust whatever happened to produce debian repository packages followed policy
we do have to blindly trust software origins were verified before they are published


we use `apt` to install the package `firefox`,
apt downloads debian's custom version of firefox
apt verifies everything is correct as we before did by hand

if we ever had a doubted that this is program is spying on us
we can download everything needed to build it automatically ourselves
we can know we have the right to modify it as we see fit
either way, we can know that the surface for attack is much smaller, 
an attacker would have to compromise the debian package itself, 
and such an attack would be capable of attacking a large body of computers, not just ours
not just take advantage of our individual computer use and behavior

I use debian an the example here because I think they are an extremely good learning resource for the curious, similar stuff is probably happening behind almost every major software distribution platform, but often in an opaque way where any trust is necessarily more blind.

One poor example in the software industry is that python's pypi, and pip, do not (at time of writing) check any software-author cryptographic signatures, and rely entirely on the HTTPS connection to provide on-the-fly signatures dynamically, and user account system which likely means pypi packages authenticity is only protected by a package author's password.

But its all house of cards anyway, no? Does it really matter that pypi's house is one/two stories tall and not six, seven, or more?

How did You start to form the foundation of your trust, your security? Did your hardware manufacturer mail you an operating system that you've trusted blindly? Did you download your operating system, your programs? Where did your upstream provider get these programs it? Did they fabricate it from scratch, by hand? Could their computers that generated it really be trusted? Does the organization that produced the program have an incentive to spy on you? Is the program really prohibited from using the hardware, operating system; in your hands, in ways you do not want it to? (a ongoing problem in the smart phone space at time of writing)


We all have to take some risk, and the risk tolerance is an individual choice.

So long as you are using a software repository that has a software front end, which is currently maintained, used by a large body of people, you are probably, on average, incurring less risk by trusting these programs, than you are by otherwise running any program at all.

Weather or not your specific platform's software distributors spends the energy necessary to have the high assurances that form the foundation of reasonable security is entirely up to the software, and hardware supply chains therein.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.