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.
