Re: [gentoo-dev] why is the security team running around p.masking packages

[Alan McKinnon]

On 05/07/2016 15:07, james wrote:
> On 07/05/2016 06:25 AM, Rich Freeman wrote:
>> On Mon, Jul 4, 2016 at 11:26 PM, Aaron Bauman <bman@g.o> 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.....


s/github/git/g

Big difference. Gentoo's tree is not hosted on github, and infra isn't
going to put an attic equivalent there.




-- 
Alan McKinnon
alan.mckinnon@×××××.com