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

[NP-Hardass]

On 07/05/2016 10:43 PM, Aaron Bauman wrote:
> On Wednesday, July 6, 2016 9:00:12 AM JST, Anthony G. Basile wrote:
>> On 7/4/16 11:26 PM, Aaron Bauman wrote:
>>
>>> 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.  Anthony's verbiage on Freenode
>>> was very frank, in that if he chose to do so he would.  We ask for
>>> all ...
>>
>> 1) In bug #473770 upstream gave sufficient information.  I stated so in
>> comments #1 and #2 with links.  You ignored this fact and proceeded to
>> p.mask in comment #3.  This CVE should never have been filed.  Its junk.
>>
>> 2) Bug #459274 is not a security bug.  A CVE request was filed by Ago
>> which, as far as I can tell, went no where.  The log file in question
>> does not disclose much more than one could obtain with just ps and
>> netstat.  I fixed a related issue with access.log in bug #459274.
> 
> That CVE request was not from Ago.  It was from the respective OSS ML
> referenced in the URL field of the bug report.  Not to mention, you as a
> maintainer were able to discover another issue with that package and fix
> it.
> 
>>
>> 3) My point on IRC is that you are acting on junk CVEs and I question
>> your judgment.  You can't produce "substantiated and verifiable
>> information" on junk.  Your above paragraph eclipses that side of my
>> argument and strawmans me.
>>
> 
> Why is this so difficult?  All of the follow up information you gave,
> after the p.mask and inquiry from Alex, is exactly what we need from the
> maintainers.  If the CVE is junk, which often happens, then the
> verifiable and substantiating information is perfectly acceptable from
> the maintainer. No one here is challenging your ability to provide such
> information, but given the multitude of security related bugs we need
> cooperation from the maintainers.  We are not familiar with every
> package in the tree, but we do our best to ensure any potential
> vulnerability is mitigated.  Again, you are the only developer who has
> had an issue with this.  As previously mentioned, a p.mask is not the
> end of the road, it is just an obligation to ensure the user is warned
> of longstanding security issues.  If they choose to unmask it then so be
> it.
> 
>> I personally would like to see only QA oversee any forced p.maskings and
>> have the security team pass that task over to QA for review.  By forced
>> I mean without the cooperation of the maintainer.
>>
> 
> Again, no one else has had an issue with this except you.  The one who
> doesn't want to cooperate.  I apologized for not pinging an active
> developer, but you cannot reciprocate the professionalism here and work
> with us.  Why can't you just work the issue like you did following the
> p.mask and we can move on?  Inevitably proving the point of why the
> p.mask is an option.  Look at the myriad of security bugs and you will
> see such examples of developers working together in order to validate,
> mitigate, and close these bugs.  Sometimes this process highlights the
> reality that CVE's are not perfect in their descriptions or assessments.  
> -Aaron
> 

I think it is a little bit of a stretch to say that he's the only one to
have an issue.  Now, I've spoken with the parties involved, so my issue
is resolved, but I had a package of mine bumped in the name of security
without being pinged/consulted at all.  I'm not attempting to point
blame at anyone, but merely show that there are others who have been
affected by security workflow sometimes going around the maintainer.  I
don't think there should be any harm in acknowledging that, and striving
to make sure it doesn't happen in the future, where possible.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: gdesklets.eclass

[Michał Górny]

# @DEAD
# This eclass is deprecated and no longer used. It will be removed
# in 30 days, #587814.

# @ECLASS: gdesklets.eclass

-- 
Best regards,
Michał Górny



pgpYvNG4f8qjB.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: dev-python/charade

[Michał Górny]

On Wed, 6 Jul 2016 04:35:25 +0200
Michał Górny  wrote:

> # Michał Górny  (8 Jul 2016)
> # Deprecated upstream. Replaced by dev-python/chardet.
> # Removal in 30 days, #548866.
> dev-python/charade

I'm sorry, the subject was incorrect. It was supposed to say
dev-python/charade.

-- 
Best regards,
Michał Górny



pgpXRJtgxz62E.pgp
Description: OpenPGP digital signature

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

[Aaron Bauman]

On Wednesday, July 6, 2016 9:00:12 AM JST, Anthony G. Basile wrote:

On 7/4/16 11:26 PM, Aaron Bauman wrote:


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.  Anthony's verbiage on Freenode
was very frank, in that if he chose to do so he would.  We ask for all ...


1) In bug #473770 upstream gave sufficient information.  I stated so in
comments #1 and #2 with links.  You ignored this fact and proceeded to
p.mask in comment #3.  This CVE should never have been filed.  Its junk.

2) Bug #459274 is not a security bug.  A CVE request was filed by Ago
which, as far as I can tell, went no where.  The log file in question
does not disclose much more than one could obtain with just ps and
netstat.  I fixed a related issue with access.log in bug #459274.


That CVE request was not from Ago.  It was from the respective OSS ML 
referenced in the URL field of the bug report.  Not to mention, you as a 
maintainer were able to discover another issue with that package and fix 
it.




3) My point on IRC is that you are acting on junk CVEs and I question
your judgment.  You can't produce "substantiated and verifiable
information" on junk.  Your above paragraph eclipses that side of my
argument and strawmans me.



Why is this so difficult?  All of the follow up information you gave, after 
the p.mask and inquiry from Alex, is exactly what we need from the 
maintainers.  If the CVE is junk, which often happens, then the verifiable 
and substantiating information is perfectly acceptable from the maintainer. 
No one here is challenging your ability to provide such information, but 
given the multitude of security related bugs we need cooperation from the 
maintainers.  We are not familiar with every package in the tree, but we do 
our best to ensure any potential vulnerability is mitigated.  Again, you 
are the only developer who has had an issue with this.  As previously 
mentioned, a p.mask is not the end of the road, it is just an obligation to 
ensure the user is warned of longstanding security issues.  If they choose 
to unmask it then so be it.



I personally would like to see only QA oversee any forced p.maskings and
have the security team pass that task over to QA for review.  By forced
I mean without the cooperation of the maintainer.



Again, no one else has had an issue with this except you.  The one who 
doesn't want to cooperate.  I apologized for not pinging an active 
developer, but you cannot reciprocate the professionalism here and work 
with us.  Why can't you just work the issue like you did following the 
p.mask and we can move on?  Inevitably proving the point of why the p.mask 
is an option.  Look at the myriad of security bugs and you will see such 
examples of developers working together in order to validate, mitigate, and 
close these bugs.  Sometimes this process highlights the reality that CVE's 
are not perfect in their descriptions or assessments.   


-Aaron

[gentoo-dev] Last rites: dev-util/rootstrap

[Michał Górny]

# Michał Górny  (8 Jul 2016)
# No development since 2012, upstream repository removed in Jan 2016.
# No longer builds. Removal in 30 days, #582448.
dev-util/rootstrap

-- 
Best regards,
Michał Górny



pgpgwIiGdCmNn.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/chardet

[Michał Górny]

# Michał Górny  (8 Jul 2016)
# Deprecated upstream. Replaced by dev-python/chardet.
# Removal in 30 days, #548866.
dev-python/charade

-- 
Best regards,
Michał Górny



pgp_5syxEIewe.pgp
Description: OpenPGP digital signature

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

[Anthony G. Basile]

On 7/4/16 11:26 PM, Aaron Bauman wrote:

> 
> 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.  Anthony's verbiage on Freenode
> was very frank, in that if he chose to do so he would.  We ask for all
> developers to assist and work together with us to fix these issues.  You
> can see the fruits of such information from the developer following Alex
> Legler's comments on the bug and my follow up actions.
> 
> -Aaron
> 

1) In bug #473770 upstream gave sufficient information.  I stated so in
comments #1 and #2 with links.  You ignored this fact and proceeded to
p.mask in comment #3.  This CVE should never have been filed.  Its junk.

2) Bug #459274 is not a security bug.  A CVE request was filed by Ago
which, as far as I can tell, went no where.  The log file in question
does not disclose much more than one could obtain with just ps and
netstat.  I fixed a related issue with access.log in bug #459274.

3) My point on IRC is that you are acting on junk CVEs and I question
your judgment.  You can't produce "substantiated and verifiable
information" on junk.  Your above paragraph eclipses that side of my
argument and strawmans me.

I personally would like to see only QA oversee any forced p.maskings and
have the security team pass that task over to QA for review.  By forced
I mean without the cooperation of the maintainer.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Alan McKinnon]

On 05/07/2016 21:53, james wrote:

* 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


James,

As an old-time C hacker, to wrap your brains around git, forget 
everything you ever learned about CVS, SVN and similar tools.


Then recall everything you ever learned in C about pointers, linked 
lists (all the juicy types), and structs.


Now look at git again, you should feel in much more familiar territory. 
You still have to get used to Linus' quite bizarre names he gave commands.


But then again, he does say git isn't really a source-code repo, he says 
it's a filesystem. Because that's what he does - writes filesystems.


Alan

[gentoo-dev] [warning] the bug queue has 94 bugs

[Alex Alexander]

Our bug queue has 94 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

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  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 noob 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 

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

[Peter Stuge]

Rich Freeman wrote:
> > do not be shy to suggest reading materials
..
> Do NOT skip descriptions of blobs/trees/commits/objects/reference/etc.
> If you don't understand the data model, you'll never get it.

I have an intro here:

http://peter.stuge.se/git-data-model


//Peter

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  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 noob 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 

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

[Rich Freeman]

On Tue, Jul 5, 2016 at 12:53 PM, james  wrote:
>
> OK, but with the attic, you can browse by category, read descriptions to get
> an idea of what is available. Correct me if I'm wrong, but with github, you
> have to know the name of the packages and that is a limitation when looking
> back. The attic just makes browsing and retrieval a snap, imho.
>

More or less.  You could probably write a script to go back and find
all deleted files and restore them.  It is also trivial to take a look
at the Gentoo repo as of a particular point in time.

Or something like this:
https://stackoverflow.com/questions/6017987/is-there-a-way-in-git-to-list-all-deleted-files-in-the-repository

>
> OK, I'll give that a whirl. But if I want to go casually looking at old
> codes, removed from the tree, that I have never used before, but  are
> vaguely referred to in some old post, how do I do that with git?

Just follow the guides I linked.  If you have a reference you should
have a filename.  If not then hunt from the log/etc.  Also, if you
have a timestamp on that old post just checkout the tree on that date
and you have exactly what they were working with.

>
> So, I guess I'll read up and try to set up my own git repo, so I do not have
> to delete files as they are pruned from the official portage tree.
> That is what you are suggesting, right?

No, you clone the Gentoo repo so that you can search it.  As files are
deleted in the repo they'll be deleted in your clone, but you can
search for them.

If you just wanted to mirror the repo without ever deleting it you
could do that with rsync, a directory tree, and cron.  You should
stick with git: that's what its for.

Don't worry, your questions just reflect your unfamiliarity with git.
You really need to grok it to work with it well.  We all take some
time to get there...

> Granted my ignorance of git is a big factor here, so do not be shy to
> suggest reading materials Often I read docs on git and well, I might
> as well be reading Hieroglyphics. It's easier to follow examples, imho, and
> that makes support more straight forward and consistent should others need
> to retrieve old ebuilds and source files.

I get it, but until you actually understand git, the examples will
eventually get you into trouble.

I'll see if I can find something decent.  I had linked something
earlier and here is another guide:
http://www.gitguys.com/table-of-contents/

Do NOT skip descriptions of blobs/trees/commits/objects/reference/etc.
If you don't understand the data model, you'll never get it.
Everything is content-hashed with the resulting COW behavior and that
has a big impact on how it all works.

-- 
Rich

Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions

[waltdnes]

On Tue, Jul 05, 2016 at 01:08:13AM -0500, Austin English wrote
> 
> My goal is clang support parity with gcc. If you are opposed to these
> sort of checks, then why don't we deprecate and remove those functions?
> I want to know why gcc deserves special treatment, either all compilers
> should have easy way to check major/minor/full versions, or none should.
> Obviously I'm not saying gcc should be removed now, but it could
> certainly be marked deprecated so the usage doesn't spread (hopefully)
> further.

  This is reminiscent of the web-browser situation.  I use Pale Moon.
It's feature-compatible with Firefox, but has not gone berserk with the
version numbering.  The current Firefox is 49-point-something.  Stupid
webpages see Pale Moon 26.3.3 and whine about "out-of-date-web-browser"
and kick the user out.  But if the user sets the user agent (i.e. lies
to the webpage) that he's using Firefox 49.1, it works just fine.

  It's not unique to the current FOS world, either.  Some old MS-DOS
applications would only run when the OS reported a certain narrow range
of versions.  When you updated MS-DOS, some older applications would
refuse to run, even though the newer MS-DOS was perfectly capable of
running it.  Things got so bad that Microsoft introduced the SETVER
command https://support.microsoft.com/en-us/kb/96767 to deliberately
lie about the MS-DOS version number, when queried by specific
applications.

   How is the version checking done?  Does the check parse the file name
of the compiler?  Can we get the GCC and CLANG people to agree to a
common command/parameter that returns a compatibility level for
"version-checking"?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[james]

On 07/05/2016 08:05 AM, Rich Freeman wrote:

On Tue, Jul 5, 2016 at 8:58 AM, Alan McKinnon  wrote:

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



Either way admittedly git makes finding deleted files a bit of a pain.
However, it is certainly possible:
https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-file-in-the-project-commit-history



OK, but with the attic, you can browse by category, read descriptions to 
get an idea of what is available. Correct me if I'm wrong, but with 
github, you have to know the name of the packages and that is a 
limitation when looking  back. The attic just makes browsing and 
retrieval a snap, imho.



I think this is just one more reason that "power users" should
seriously consider just syncing from git.  It is really useful to have
a git repo, and once you have one, it is going to be a lot faster to
just use it as your daily driver since it syncs so quickly/etc



OK, I'll give that a whirl. But if I want to go casually looking at old 
codes, removed from the tree, that I have never used before, but  are 
vaguely referred to in some old post, how do I do that with git?
For example, I have conversed on numerous occasions with the old physics 
professor that wrote sys-cluster/wulfware. We have prospectives that are 
similar. Although he does not actively, at this time, support wulfware, 
he has architected  a more conservative approach to HPC than many of the 
current, more-prominent projects.  He has quite a proposal for me to 
move the code forward, should I want to take it over. Yet, a 
tree-cleaner probably has marked it for removal.


Old code is often wonderful, ymmv. It's old school, 'C' centric and 
there are many other old useful codes. Not that this reference is any 
big deal, but there is a lot more than me out there with similar 
beliefs. It's exciting to see something old (PVM) return in part as  a 
new project (OrangeFS). Oh, OrangeFS is all the new-rage with some HPC 
folks and it making a return via kernel-4.6 (I believe).


So, I guess I'll read up and try to set up my own git repo, so I do not 
have to delete files as they are pruned from the official portage tree.

That is what you are suggesting, right?

In a way I have been doing that manually by syncing up a separate 
/usr/portage/distfiles/   and putting lots of codes into 
/usr/local/portage/. I would hope, some devs would put thought into this
and formalize a few methods and a document so that in effect, I can 
manage my own gentoo attic, going forward, and likewise others could 
too, or a partial archive, according to their interests.


Granted my ignorance of git is a big factor here, so do not be shy to 
suggest reading materials Often I read docs on git and well, I might
as well be reading Hieroglyphics. It's easier to follow examples, imho, 
and that makes support more straight forward and consistent should 
others need to retrieve old ebuilds and source files.



Thanks for the info and ideas.
James

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

[Rich Freeman]

On Tue, Jul 5, 2016 at 8:58 AM, Alan McKinnon  wrote:
> Big difference. Gentoo's tree is not hosted on github, and infra isn't
> going to put an attic equivalent there.
>

Either way admittedly git makes finding deleted files a bit of a pain.
However, it is certainly possible:
https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-file-in-the-project-commit-history

I think this is just one more reason that "power users" should
seriously consider just syncing from git.  It is really useful to have
a git repo, and once you have one, it is going to be a lot faster to
just use it as your daily driver since it syncs so quickly/etc.

-- 
Rich

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  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 noob 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.mckin...@gmail.com

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

[james]

On 07/05/2016 06:25 AM, Rich Freeman wrote:

On Mon, Jul 4, 2016 at 11:26 PM, Aaron Bauman  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 noob 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

Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions

[Austin English]

On 07/05/2016 12:00 AM, Michał Górny wrote:
> On Mon, 4 Jul 2016 19:16:55 -0500
> Austin English  wrote:
> 
>> On 07/01/2016 03:02 PM, Michał Górny wrote:
>>> On Mon, 27 Jun 2016 17:04:41 -0500
>>> Austin English  wrote:
>>>   
 From ec0be3d1a808ea0c5bdd081a4bb935f86bf78d44 Mon Sep 17 00:00:00 2001
 From: Austin English 
 Date: Mon, 27 Jun 2016 16:58:07 -0500
 Subject: [PATCH 2/2] eclass/toolchain-funcs: add clang version functions  
>>>
>>> Why do you even ask for review if you can't wait till the weekend
>>> before committing?  
>>
>> There's no set time limit that I could find anywhere. I checked with my
>> mentor first, who said a few days was enough (as there were no comments
>> by anyone).
>>
>>> I've already told you twice that I'm opposed to adding version querying
>>> functions for clang, especially for the use case you proposed. You
>>> should check for features, and not keep a huge list of supported gcc,
>>> clang, pathcc, icc... versions. With every random compiler pretending
>>> to be a random version of every other compiler.  
>>
>> I did not use in the original intended case, however I think that these
>> helpers are still useful. Why do we allow gcc version checks then?
> 
> Because the ebuilds are full of that nonsense, and developers using
> them don't help you remove it.

Ack.

> If we committed every single thing someone thought someone else might
> find useful one day, the eclass would be huge hogs full of useless code
> that is only used because someone noticed the function and suddenly
> came to conclusion it's a good idea to use it because someone added it.
> 
> Now let's add 4 additional functions for every single compiler that
> someone may decide to support one day. I'm even strongly opposed to
> adding functions that are used only theoretically.
> 
>> There's no deprecated comment for these functions. By that logic, you
>> should not have added tc-is-{gcc,clang}, 2 weeks ago in
>> 6984a5b149a215dd96a9759d3d1f251354faf38f. You should be testing for
>> compiler features directly, not keep a list of what compilers are
>> supported in the code...
> 
> Yes, I can revert this if you insist. And don't mind that all those
> horribly broken ebuilds checking gcc versions will suddenly fail with
> clang.

So fix them properly, by detecting compiler features, not compiler name ;)

>> The point of eclasses is to share code and make ebuild maintenance
>> easier. I don't see how allowing version checks for GCC only, when clang
>> is supported by a lot of ebuilds, makes that easier. Again, if you're so
>> opposed to compiler specific checks, then please remove them from
>> ebuilds using them and from toolchains-funcs.eclass (or at least mark
>> them as deprecated).
> 
> How does ebuild maintenance become easier when you have to test a dozen
> of versions of different compilers to figure out which one is
> supported?

My goal is clang support parity with gcc. If you are opposed to these
sort of checks, then why don't we deprecate and remove those functions?
I want to know why gcc deserves special treatment, either all compilers
should have easy way to check major/minor/full versions, or none should.
Obviously I'm not saying gcc should be removed now, but it could
certainly be marked deprecated so the usage doesn't spread (hopefully)
further.

-- 
-Austin
GPG: 00B3 2957 B94B F3E1



signature.asc
Description: OpenPGP digital signature