Home / server / Questions / 406464
Accepted
Univ426
Asked: 2012-07-11 08:39:07 +0800 CST

Avoiding Dependancy Hell in a Restrictive Environment

  • 772

This may be a canonical question, and it may simply be a function of my inexperience, but I'm curious to know if there are best practices aimed at avoiding dependency hell when you find yourself in an environment with limited access to common, open repositories.

In our specific case, our struggle is working within the context of a large corporation with security policies that severely diminish the ability to access outside repos for packages when installing various software.

How do you balance security with the need for access to public repos? Is there a way to limit the dependance on external repos without making the installation of Linux software impossible? What kind of arguments can be made for the security and reliability of yum or apt-get repos?

A broad question I know - I hope it's appropriate here - but I'm very curious to see what other people's experience in this area has been.

security repository

1 Answers

  1. Best Answer

    You avoid dependency hell (and a whole raft of other things) better when you limit the number of external repositories you use. Since you can't guarantee the quality, long-term availablility, and timeliness of the contents of those repositories, it is a very poor move to rely on their contents (and continued existence).

    As a concrete example, I've previous seen examples where semi-official third-party repositories of packages for a stable Linux distribution had packages come and go over time. This caused a great deal of trouble, because we might build up a few machines at one time, which all got the same version of a critical package. Some time later, when we went to build more machines, the version we had specified was no longer available (superceded by a newer, shinier version) and we had to test everything again to make sure the newer package still worked properly.

    This isn't the worst possibility. What if we didn't test the new package, and it had a critical bug in it? Bummer. Of course, the version we choose may turn out to have a security flaw in it, but that's OK, because as responsible packagers we keep an eye on upstream security announcements and ensure that any vulnerabilities are patched appropriately.

    The cautious administrator only installs packages onto his/her systems from two places:

    • The distribution's official repositories (appropriately cryptographically verified for authenticity, of course), where the policies and practices of the manner in which packages are added and removed is known and complies with your own risk management assessment; and
    • An internally managed package repository or repositories (again, cryptographically verified).

    The contents of that internal repository set can be populated by several different means:

    • Download packages from external, third-part repositories, verify their utility and stability in a testing environment, and then add them to the repo.
    • If you are moderately paranoid, you rebuild the source packages from the above repos, then test and add.
    • If you're properly paranoid, you shut yourself in a small room without any computers or electronic equipment whatsoever.
    • 3