| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Carsten Lohrke wrote: |
| 5 |
|
| 6 |
> Multiple buffer overflows in <dev-db/firebird-1.5, no fix available, |
| 7 |
caused |
| 8 |
> |
| 9 |
> http://bugs.gentoo.org/show_bug.cgi?id=20837 |
| 10 |
> and |
| 11 |
> http://www.gentoo.org/security/en/glsa/glsa-200405-18.xml |
| 12 |
> |
| 13 |
> but the affected ebuilds never got package masked (until yesterday) |
| 14 |
and Meir |
| 15 |
> retired in between. I really appreciate the great work the |
| 16 |
security@g.o herd |
| 17 |
> is doing already, but wouldn't it be a good idea, if it would be ensured |
| 18 |
> (four eyes principle), that affected ebuilds either get fixed, package |
| 19 |
masked |
| 20 |
> or removed by the responsible developer? |
| 21 |
|
| 22 |
There is a rule in our security policy[1] that says that once the fixed |
| 23 |
ebuilds are put into portage with appropriate keywords, package |
| 24 |
maintainers should remove old affected ebuilds from the tree. But it is |
| 25 |
the maintainer responsability to do so. From a security perspective, |
| 26 |
IMHO it's not really important : removing the affected ebuilds will not |
| 27 |
make people with affected versions installed upgrade. It just avoids the |
| 28 |
case where people specifically choose to install a given old version. |
| 29 |
|
| 30 |
Our job is to make sure that people upgrading are protected, and that |
| 31 |
announcements are made so that people know it's time to upgrade, or so |
| 32 |
that glsa-check tells them. We do this by ensuring new versions of |
| 33 |
ebuilds are produced and marked with appropriate keywords. We can't |
| 34 |
really do much for people not upgrading or carefully selecting an |
| 35 |
affected version. For those who choose a specific old version and don't |
| 36 |
read GLSAs, yes, it's better if the affected ebuild is removed from |
| 37 |
portage. |
| 38 |
|
| 39 |
That's why policy dictates that package maintainer should clean their |
| 40 |
package tree, and that's why we currently aren't ensuring that it |
| 41 |
happens (tradeoff added-security/added-workload is not worth it). |
| 42 |
|
| 43 |
In the specific case you mention, we were probably so happy that the |
| 44 |
maintainer finally marked stable that version that we didn't remember |
| 45 |
him not to forget to remove all affected versions. |
| 46 |
|
| 47 |
[1] http://www.gentoo.org/security/en/vulnerability-policy.xml |
| 48 |
|
| 49 |
- -- |
| 50 |
Koon |
| 51 |
Gentoo Linux Security Team |
| 52 |
-----BEGIN PGP SIGNATURE----- |
| 53 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 54 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 55 |
|
| 56 |
iD8DBQFBDiZsvcL1obalX08RAs5cAKCP0z0BhSqN+E9xnilKzGMHRtTrRgCgq2r/ |
| 57 |
UQhRChtWnrZ/KkvZxGMlu0w= |
| 58 |
=r/m5 |
| 59 |
-----END PGP SIGNATURE----- |
| 60 |
|
| 61 |
-- |
| 62 |
gentoo-security@g.o mailing list |
Archives