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

[NP-Hardass]

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 ^_~


-- 
NP-Hardass