| 1 |
[snip] |
| 2 |
|
| 3 |
> What I wanted to tell was that if I emerged PHP, I could only emerged |
| 4 |
> the 4.3.9 (stable) version, but with other distro I could install the |
| 5 |
> new, 5.0.2 version ... |
| 6 |
> |
| 7 |
> From all your mails I realized that I do not need to install the |
| 8 |
> newest version of packages if I want to keep my server secure. I |
| 9 |
> noticed that it is just important to emerge the security/bug fixes. Am I |
| 10 |
> right? |
| 11 |
> |
| 12 |
|
| 13 |
Yes, I would say. The example you provide is a good one. The flexibility |
| 14 |
and diversity inherent in portage and the gentoo development team means |
| 15 |
that new and cutting-edge packages such as PHP5 are committed to the tree |
| 16 |
rapidly (and are therefore available to those who choose to test and make |
| 17 |
use of them). |
| 18 |
|
| 19 |
However, the recognition is there that PHP4 is considered stable and |
| 20 |
should be the "default" version for some time to come. Should a security |
| 21 |
flaw be discovered in a given version then, in my experience, the Gentoo |
| 22 |
Security team resolve the situation very rapidly. As I believe Andrew |
| 23 |
pointed out in an earlier post (along with many other salient points with |
| 24 |
which I fully agree), the source-oriented nature of Gentoo and the portage |
| 25 |
system make this relatively easy. A developer needs only to commit a new |
| 26 |
ebuild (which applies one or more new patches), and to commit the ebuild |
| 27 |
to the portage tree along with the patches themselves. |
| 28 |
|
| 29 |
Thus, in the majority of situations you need only re-sync your tree and |
| 30 |
either upgrade world, or simply emerge the package in question again. |
| 31 |
Portage will always use the latest packages which are not "masked". You |
| 32 |
can use tools such as glsa-check to specifically test whether there are |
| 33 |
packages which must be upgraded for the sole purpose of correcting |
| 34 |
security flaws. |
| 35 |
|
| 36 |
In the case that you want to a masked package - for instance, PHP5 - then |
| 37 |
that can be easily accomplished. Ebuilds feature keywords which indicate |
| 38 |
two things: |
| 39 |
|
| 40 |
(1) Whether the package is compatible with a given architecture. For |
| 41 |
instance, x86, mips, ppc etc. |
| 42 |
(2) Whether the package is masked/unmasked for the architecture (analagous |
| 43 |
to stable/unstable). The symbol which indicates masked status is a tilde |
| 44 |
"~". Note also that packages can be hard-masked in |
| 45 |
/usr/portage/profiles/package.mask; keywords will not have an effect on |
| 46 |
these packages. |
| 47 |
|
| 48 |
In this sense, portage effectively has a stable and unstable tree governed |
| 49 |
by the keywords. To use the latest version of PHP (come hell or high |
| 50 |
water) you could define the following line in |
| 51 |
/etc/portage/package.keywords: |
| 52 |
|
| 53 |
dev-php/php ~x86 |
| 54 |
|
| 55 |
The choice is yours. In any case, it is not at all necessary to use the |
| 56 |
very latest packages in order to guarantee security (in fact, I would |
| 57 |
consider it to be foolish if security _and_ stability are your goal). |
| 58 |
|
| 59 |
Regards, |
| 60 |
|
| 61 |
--Kerin Francis Millar |
Archives