| 1 |
Gavin Vess wrote: |
| 2 |
|
| 3 |
>How to communicate with Gentoo users meaningful information that helps them make informed decisions regarding configuration/upgrade options? |
| 4 |
> |
| 5 |
> |
| 6 |
I think this is the key. |
| 7 |
We need multiple levels here. The base kern / os, the framework that |
| 8 |
apps are run in, and finally the apps themselves. The Hardened project |
| 9 |
could focus on the base layers and as you build higher you could |
| 10 |
introduce more options. I think the spirit of the docs is very good. |
| 11 |
ie- we support syslog, metalog etc... but if you don't care then use |
| 12 |
metalog - here are details for metalog..... That doc does a good job of |
| 13 |
informing the user as to the differences and nudging them to choose the |
| 14 |
writers favorite. |
| 15 |
|
| 16 |
>Finding Critical Mass |
| 17 |
>================= |
| 18 |
>Jerome wrote: |
| 19 |
> |
| 20 |
> |
| 21 |
>>However I also feel that if it is made easy for Gentoo users to update with _all_ security |
| 22 |
>>patches, the Hardened options would be that much more attractive. |
| 23 |
>> |
| 24 |
>> |
| 25 |
> |
| 26 |
>Brilliant. |
| 27 |
> |
| 28 |
>On Monday another serious flaw was found was in the latest 0.9.6 and 0.9.7 branches affecting most openssl apps, including Apache with SSL. The scope of impact is broad. By simultaneously considering the security needs of the entire Gentoo community along with those desiring a hardened version, I sincerely think successful critical mass is much more likely through a broader appeal. Also, supporting hardening through options, rather than fully separate packages avoids the potential of evolving yet another distro (e.g. without critical mass needed to sustain quality |
| 29 |
> |
| 30 |
I like this a lot as well. |
| 31 |
I wonder if there is a way to use RSYNC to retroactively tag packages |
| 32 |
that have known security holes. So rather then force the user to |
| 33 |
upgrade thier openSSL there should be a way that they can: |
| 34 |
|
| 35 |
emerge rsync |
| 36 |
emerge --patch security_risks |
| 37 |
|
| 38 |
That would only apply special "patch" ebuilds or do something that could |
| 39 |
be maintainable by the ebuild author and not spawn 1000's of extra ebuilds. |
| 40 |
|
| 41 |
-Aaron |
Archives