3. Security considerations and other risks

All the yum commands I give in this HOWTO have to be run from the root prompt so the packages they fetch can be installed in your system space. This means there is a risk that your system could be compromised by a Trojan Horse RPM, either one inserted in one of the repositories you query or one slipped to you by a man-in-the-middle attack getting between you and a repository.

To control the latter risk, many repositories cryptographically sign their RPMs. You need to have a local copy of each repository's public key in order to integrity-check incoming packages; current versions of yum will dowmload one for you. This could be defeated by a man-in-the-middle attack spoofing the repo site and slipping you bogus keys as you set up your configuration; while this possibility is extremely unlikely, you should be aware of it.

A long-term risk that you accept by using the proprietary code referenced in this HOWTO is that of becoming dependent on the whims of a proprietary software vendor. It isn't necessary to have that old-time Free Software religion to see that this is a problem. Some of the software we'll cover here (the Sun Java JDK plugin is a good example) is distributed as closed-source freeware — which is all very well, but what happens if the vendor changes its mind in the future? You could be stranded.

It's unsafe to be dependent on proprietary software and proprietary formats. When you allow yourself to be dependent, you also harm others by helping vendors maintain an unhealthy monopoly lock on their market segment. So, if you must buy into these tools, please find some way to support open-source replacements — donate coding time or cash, or spend effort pressuring vendors to open up. Rip your CDs to Ogg Vorbis rather than MP3. Write a letter to your legislator urging repeal of the DMCA. The freedom you save will be your own.