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

[james]

On 07/05/2016 01:17 PM, NP-Hardass wrote:
> On 07/05/2016 09:07 AM, 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.....
>>
>>
>> Thanks,
>> James
>>
>>
>
> Here's a solution that handles that doesn't require fancy git knowledge
> and uses Gentoo infrastructure:
>
> 1) Navigate to https://gitweb.gentoo.org/repo/gentoo.git (or any other
> gentoo repo)
> 2) Click "Tree"
> 3) Navigate to the level ABOVE the one you are interested in, for
> example, if you want app-misc/foobar, navigate into app-misc.
> 4) To the right of your desired entry, click "Log"
> 5) This will display the history of the package, allowing you to browse
> it at any time, (you in particular want the one before the ebuild was
> removed) (Click your desired commit)
> 6) Click the name of the category/package on the "Tree" line to view the
> tree at that point in time. ie,
> tree	02d93ae662fb1a813380775612e35e819d67e303
> /app-accessibility/SphinxTrain (you would click
> "app-accessibility/SphinxTrain"
> 7) View and download your desired files by clicking on "Plain" on the right
>
> Protips:
> *You can view the log of any package (removed or not) with:
> https://gitweb.gentoo.org/repo/gentoo.git/log/<category>/<pkgname>
>
> *You can view files as of last commit before removal of any package with:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/<category>/<pkgname>?id=<lastcommitbeforeremoval>
>
> * If you don't know the last commit before removal, juts load up the
> removal commit and copy the commit hash of the "Parent" link to get the
> commit before that
>
> Tada! Attic restored ^_~

Not bad, at first glance. Not too bad at all! Let me work with this a bit.

THANKS!

James