| 1 |
On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mikemol@×××××.com> wrote: |
| 2 |
> |
| 3 |
> For security's sake, even mature software needs, at minimum, routine auditing. |
| 4 |
> Unless someone's doing that work, the package should be considered for |
| 5 |
> removal. (Call that reason # π, in honor of TeX.) |
| 6 |
> |
| 7 |
|
| 8 |
Are you suggesting that we should ban any package from the tree if we |
| 9 |
don't have evidence of it having recently being subjected to a |
| 10 |
security audit? We might literally have 3 packages left in the tree |
| 11 |
in that case, probably not including the kernel (forget the GNU/Linux |
| 12 |
debate, we might be neither). |
| 13 |
|
| 14 |
The fact that a project gets 47 commits and 100 list posts a week |
| 15 |
doesn't mean that it is being security audited, or that security is |
| 16 |
any kind of serious consideration in how their workflow operates. |
| 17 |
|
| 18 |
I tend to be firmly in the camp that a package shouldn't be removed |
| 19 |
unless there is evidence of a serious bug (and that includes things |
| 20 |
blocking other Gentoo packages). If somebody wants to come up with a |
| 21 |
"curated" overlay or some way of tagging packages that are considered |
| 22 |
extra-secure that would be a nice value-add, but routine auditing is |
| 23 |
not a guarantee we provide to our users. The lack of such an audit |
| 24 |
should not be a reason to treeclean. |
| 25 |
|
| 26 |
-- |
| 27 |
Rich |
Archives