7

I use Debian Jessie, and the Debian repo has many open source packages. I understand there's a process that checks these before they get used in the repository.

While I understand it's impossible to find every bug (heartbleed, for example), I would like to know if some kind of review of the application occurs. For example, if a password manager sends every saved password to a central server for "statistical purposes". There is a lot of middle ground between a obscure bug and blatant malware, and I'd like to know where (if anywhere) the appropriate-for-repo line is drawn.

This review may not necessarily be reading every line of source, but perhaps checking that the app doesn't connect to weird servers unexpectedly, or write plain text files to disk, or any malware-type behaviour.

So my question: what process do open source applications go through before being accepted into a repository?

(And to avoid the X-Y problem: I'm asking because I would like to install a password manager from the repo and I want to trust it isn't giving my passwords away in the background)

closed as too broad by S.L. Barth, Stephane, Xander, Steve, John Deters Oct 11 '16 at 17:23

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I think this is more of a question for each Linux distro, and not a security question. – schroeder Oct 8 '16 at 8:53
  • Can of worms opened ;) – kubanczyk Oct 8 '16 at 9:25
  • The answer will vary from distro to distro – Limit Oct 8 '16 at 13:36
  • @Limit - Not that much, there are pretty much only three ways this is done: debian, redhat (and stuff like suse), and arch/gentoo. All other distros simply copy from those repos. – grochmal Oct 8 '16 at 14:11
  • @schroeder - I've made a one word edit which I think brings it on topic – paj28 Oct 9 '16 at 9:07
4

where (if anywhere) the appropriate-for-repo line is drawn.

This will probably seem disheartening but a lot of it is simply common sense. Namely, if no one is reporting a problem then things should be fine.

This isn't as bad as it may sound at first. There are a lot of phases during which someone can report issues. To see how these things are done (and to make a you believe this info at something more than face value), let's walk through the process of getting a package into an official repository on some Linux distros. Although there are dozens of distros out there, we have pretty much only three major base repos from which other distros draw their own repos:

  • Debian - from which Kali or Ubuntu take packages, and then Ubuntu is spin again into Mint for example.
  • RedHat - which test packages for inclusion through Fedora (or SUSE which test package inclusions with OpenSUSE).
  • Arch/Gentoo - that have huge user contributed sets of packages that are included in the main repos if enough people use them (more distros come from her as well, Majaro or BlackArch are spins of Arch, for example).

Let's look a the phases each of these models use, and about extra effort use to check these packages. But first some general concerns:

General

Software that is used by many people (and I really mean many, e.g. httpd) is also maintained by many people. Such an environment will first have coding reviews and ways of reporting a user that tries to vandalize the code.

Also, in software that is used by so many people, CVE hunters (e.g. researchers that happen to study that piece of software at the time) would catch a piece of intentional malware within hours.

Apart from people that may look at the source code of the piece of software itself, distros have package maintainers for each package. If a dodgy feature was pushed into the code repository of a piece of software, and the package maintainer of this package in a distro notices it, he will report it (and not update his package in the distro).

Moreover, adding a new release of a piece of software into a repository (which requires compilation and functional testing) takes 20-30 hours in the extremely optimistic cases (the best I saw recently was Vim 8, was added to the Arch repos 17 hours after the official release). If there is a known CVE, caused by vandalism, in the next release, a package maintainer will not update a package in the repository (in any distro).

Debian

Debian has debian testing and debian unstable where Debian users can (and often do) use packages that are unstable. Debian unstable is most often used package by package by the package maintainers. Debian testing is widely used by people that want the newest software quicker. It is advised by Debian that packages in debian testing are often not a secure as the stable release with security updates enabled.

The extremely critical software (e.g. httpd or openssl) receive extra scrutiny. The security team of the Debian developers go through the most important packages (not as far checking every line of code, but tey do a lot of checking) and through pretty much all CVEs. Their bug tracker is pretty efficient at finding and fixing issues.

As an extra, I am aware of at least one of the members of the Debian security team who runs the CBMC compiler on some packages.

RedHat

Inclusion of package in RedHat (and similar distros) is performed by using an open distro as a testing ground. For RedHat that is Fedora. But it isn't that packages can be simply added to Fedora. By the contrary, there is a good deal of scrutiny over packages to be included: the packaging guidelines of Fedora are thorough.

There is more, before entering the repos for RedHat a package must be well behaved in the main Fedora repos, but to enter the main fedora repos the package should be in the EPEL repos first. And the EPEL repos are also reviewed according to the package guidelines.

Arch

This is a mix of the two above. To enter the main repos on Arch the package must have been well behaved (and popular) on AUR.

Yet there is a community security team for CVEs, like in Debian.

Extra notes

Therefore, the package is checked at the development stage by its community. If the community is small (let's say, only the author), the second person to look at it will be the package maintainer on the distro. If a single package maintainer or community member raises a red flag about a change, that will likely fall into the hands of a security team (or a CVE hunter) and be dealt with.

All this may still seem sketchy, since it depends on people reporting things. Yet, if you think statistically, there is little to gain from attacking a package used by 3 people. Adding a dodgy code change to a package used by millions would be profitable, but then it would need to pass the scrutiny of hundreds looking at it. Having a single guy reading every line of code going into the distro is likely to be less effective at determining security flaws than the current use of community eyes.


The real danger lies in the language specific (and operating system independent) repositories: akin of pip (python), gem (ruby) or even CPAN (perl). There are people looking at the packages in there alright, but you can publish a package there that contains malware, and it can go unnoticed for days.

3

This really is an XY question.

To avoid the password manager leaking your password, you can use an AppArmor profile to deny network access.

Other answers have pointed out that repository controls are focused on functionality, not vulnerabilities or backdoors. Creating an AppArmor profile is a stronger control.

  • 1
    +1, I agree. If you are concerned about security of installed applications AppArmor is your best defence. – grochmal Oct 9 '16 at 17:29
1

Debian Policy Manual is your go-to resource for all questions regarding Debian packages.

Debian have a strict policy of requiring all packages in main and contrib to be "free software" according to Debian Free Software Guideline. Software that are open source but doesn't comply with DFSG is separated into the non-free repository, which must be enabled explicitly by the user.

The Debian Policy Manual requires that all packages in the official repositories "must not be so buggy that we [Debian Developer] refuse to support them". This is rather vague, but essentially it is written so that it allows buggy packages only if there are maintainers willing to spend extraordinary effort to fix those issues.

Many important packages are also build with a reproducible build process, to ensure that the compiled binary package you installed matches the source code it claims to have come from.

There are a number of reasons why Debian may reject packages to be included in their repositories. For the most part, packages may be rejected for any reasons that the Debian Developer raises, but mostly packages are rejected due to licensing issues or it doesn't play well with dpkg (e.g. packages that can't be uninstalled cleanly) or it fails to follow quality policies (e.g. having good package description, having manpages, following the standard filesystem hierarchy). Packages may also be implicitly rejected if it fails to attract interest from Debian Developers.

connect to weird servers unexpectedly

As Debian packages must comply with DFSG, which requires source code to be open, there's really no such thing as "unexpected" behaviour. Since the source code is open, you could reasonably argue that everything that is clearly written in the source code is "not unexpected". So that leaves us with obfuscated implementation of unexpected/undocumented backdoor, rather than a trivial malware.

Some high quality Debian packages may also ship with AppArmor profiles which can restrict unexpected behaviours in these applications to some extent.

  • "source code to be open, there's really no such thing as "unexpected" behaviour" cute – CodesInChaos Oct 9 '16 at 9:13