On 07/05/2016 06:25 AM, Rich Freeman wrote:
On Mon, Jul 4, 2016 at 11:26 PM, Aaron Bauman <[email protected]> wrote:
The subject of this particular mailing list post is a little alarming and
over reactive. We are not running around p.masking everyone's packages, but
issues that have been outstanding for years often result in such courses of
action. I personally told Anthony I should have requested his assistance
initially on the matter, and I do apologize for that. He is an active
developer who would respond in a timely manner. So once again, I do
apologize.
Thanks, and my intent wasn't to suggest that I thought there was any
kind of a trend here. I just wanted to agree that this shouldn't be
how it happens. It sounds like we're already on the same page, which
isn't surprising since this was the first complaint I've heard in a
while.
Finally, that does not dissolve the developer of providing usable,
substantiated, and verifiable information regarding the vulnerabilities.
The idea that a developer gets to choose whether or not they do so should
not be considered.
Also agree. I think we need to have a reasonable security policy, but
clearly there can't be unresolved questions about whether a particular
package-version is vulnerable or not. If we don't get a question like
that resolved in a timely manner then the version should be masked.
Users can then make an informed decision as to whether they want to
take the risk in unmasking it.
Our security policies are a tree-wide QA commitment that our users
rely on. We shouldn't advertise a security policy that we aren't
willing to enforce.
As an old C hack, and user of gentoo for over a decade, I understand the
positions being articulated herein. However, I think there is a
fundamental perspective that is missing, so I shall attempt to
illuminate that perspective. 'C' is still a magical and most important
language. It is the transitive language between large, complicated
systems, and hardware. Like it or not, without hardware, there are no
systems.
There are many new and modern languages with wonderful features. I get
that, and appreciated that they are needed and desired. But modern
(security and usefulness) metrics are being applied to old codes that
are useful for a variety of reasons, beyond compiling them and using them.
There is an intersection between minimal unix (minimal gentoo in our
case) and embedded systems. Docker, many would cite as the leader in
commercial container deployments, has realized that minimal is better,
faster, easier to secure and can always be 'scaled up' by adding more
codes (hence they subsumed Alpine Linux).
Gentoo has a rich, legacy in old, simpler codes that bridge embedded
linux to (bloated/full-featured) linux. Those old codes that appear to
many as useless, indeed form a narrow bridge to both the past and the
logic/tricks/methods to get various types of hardware working in a
minimal or embedded environment. They are often 'single function' codes
without the complexity of a gui or bloated formations. They are easy to
read and with a CLI focus, allow a developer to see how some things
work. Those old codes, folks are quick to purge now, often contain
logical information on how to talk to hardware. (think ethernet for one).
So when we had 'the attic' I was fine with codes being purged by
whomever. There is no easy to use equivalent in github (and believe me,
I'm a noooooob at github), so I have much anxiety about what, from my
perspective, appears to be needless purging of many old codes. I have no
problem with removal from the official tree, but I'd like to keep them
around, regardless of any security, brokeness or un-maintained status.
I completely OK with tree-cleaning, just a soon as the ink dries on the
new wiki pages that guarantee archival of old codes. Security, is
important, but not the main issue from my perspective. Maintenance of
old codes, particularly written in C and related to hardware or logic of
minimal systems, is keenly important to me. If gentoo remains 'a good
stuart' of these codes, it just another mechanism
to distinguish our distro, imho.
So I would ask (beg if necessary) the kind folks that are the gentoo
devs to figure out a way to archive those old codes, and document how to
retrieve them, via github, as the attic too is probably like sunrise and
such, headed towards deprecation and the chopping block.....
Thanks,
James
