| 1 |
On Tue, 7 Apr 2020 12:47:33 +0200 |
| 2 |
Thomas Deutschmann <whissi@g.o> wrote: |
| 3 |
|
| 4 |
> Sure, that could have banal reasons like "No one audited the Linux |
| 5 |
> version yet". But in security you don't issue warnings if you aren't |
| 6 |
> sure. Because if you make false statements people will no longer trust |
| 7 |
> you. But trust is everything. |
| 8 |
|
| 9 |
Agree. |
| 10 |
|
| 11 |
In line with my other suggestions with exposing this via in-repo |
| 12 |
meta-data, there probably should be a facility in a future EAPI that |
| 13 |
allows one to both know about this /class/ of risk, and address it. |
| 14 |
|
| 15 |
So for instance: |
| 16 |
|
| 17 |
ACCEPT_ASPECTS="bug:45678 bug:14678 cve:COVID-19 trust:proprietary" |
| 18 |
|
| 19 |
Or something. |
| 20 |
|
| 21 |
The gist being that say, zoom could have: |
| 22 |
|
| 23 |
> net-im/zoom trust:proprietary |
| 24 |
|
| 25 |
As could anything that is both shipped as a binary blob, not produced |
| 26 |
by somebody on gentoo staff, and has no source available. |
| 27 |
|
| 28 |
For instance, if the source is available, but its a 3rd party binary, |
| 29 |
there could potentially be a step in shipping that puts unaudited code |
| 30 |
in the binary, so its not smart to say its entirely as-bad as something |
| 31 |
that is unaudited, but *some* caution should be taken. |
| 32 |
|
| 33 |
If a user locally wants to, by policy, avoid all packages that are |
| 34 |
either unaditable, or have some weaknesses around their auditabilty, we |
| 35 |
should provide tools to do that. |
| 36 |
|
| 37 |
Syntax above not expected verbatim, just food for thought, but its |
| 38 |
worth mentioning that bug/cve/trust levels don't always map 1:1 with packages, |
| 39 |
and also, that the nature of this metadata is that it SHOULD NOT be |
| 40 |
in the ebuild itself, as it is inherently "repo based", the installed |
| 41 |
values of these are worthless. |
| 42 |
|
| 43 |
Running with the idea a bit here: |
| 44 |
|
| 45 |
It would even be possible for a 3rd party overlay to contain *only* a |
| 46 |
trove of these aspects, and then a controlled deployment could have a local |
| 47 |
|
| 48 |
REQUIRED_ASPECTS="trust:team-sec" ( where team-sec is defined by said overlay ) |
| 49 |
|
| 50 |
Which requires all packages you install on your system have some sort |
| 51 |
of metadata indicating that they've been signed off by team-sec. ( |
| 52 |
either the whole cat/pn, or some versions there of ) |
Archives