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

[Alec Warner]

On Fri, Jul 8, 2016 at 9:02 AM, Andrew Savchenko  wrote:

> On Wed, 6 Jul 2016 23:13:55 +0300 Andrew Savchenko wrote:
> > On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
> > > What kind of policing would you like to see councilman?  Would you
> like to
> > > see me removed from the project, because your precious package was
> > > p.masked?  You have ignored every thing I have said regarding your
> > > inability to work with the security team.  Even after an apology from
> me
> > > and a request to work with us you continue on with the rhetoric of
> powers.
> > > It displays a lot about your inability to work with others.
> > >
> > > No other developer is complaining... it is *literally* only you.
> >
> > It is really not just him. I do not agree with media-video/motion
> > pmask with 30-days removal term. But I had not pushed this issue
> > hard, since I'm not a maintainer of this package.
> >
> > If this package would have been masked without removal term, I can
> > at least accept if not agree with such action. But there is no
> > other alternative for this package and security bugs are not
> > critical (at least they do not affect many use cases at all). So
> > removal from the tree will harm our users sufficiently.
> >
> > When approach is "mask until issues are resolved, so that users are
> > informed about security hazard" — it sounds reasonable, and we
> > already have several packages in the tree this way. But when
> > approach is to purge package from the tree in 30 days regardless of
> > severity of security flaws and ignoring the fact that there is
> > nothing to replace this package with — this is not a kind of the
> > policy I'd like to see in Gentoo.
> >
> > Please understand me correctly: I'm not blaming you or security
> > team for this or that issue. But it looks like security team indeed
> > needs to review some policies and approaches to suit needs of
> > Gentoo users better in both of terms of security and usability, to
> > find some reasonable compromise between them, which will satisfy
> > most users. For these very issues it looks like canceling "removal
> > in 30 days" clause from p.mask action will do the job.
>
> One more package to the list: app-cdr/xcdroast. It was being tree
> cleaned[1] due to a minor security flaw (o+r on suid binary) on
> optional functionality disabled by default (so users have to enable
> that suid binary themselves each time after package update).
>
>
The treecleaning policies are pretty clear:

https://wiki.gentoo.org/wiki/Project:Treecleaner/Policy

Packages should probably not live in the tree for years with open security
issues. If nothing else, someone (e.g. a maintainer) should decide that the
issue is minor and fix it. No one had done so for Xcdroast, and so it was
slated for removal.

For instance, they could remove suid entirely (force people to use sudo to
burn or similar setups.)

And despite multiple calls from users (see user comments on [1]
> and read whole thread [2]) saying they need this package, they were
> asked by security team to "stop spamming this bug"[3]. Such actions
> in my opinion make more harm then good by deteriorating user
> experience and number of choices available, while bringing only
> small and not always meaningful security improve.


Yeah that is not great, but in the end we would prefer someone step up and
maintain the package. Its not clear that the status quo was a great
situation (regardless of what the users thought.)


>
> So it looks like that both security and treecleaners teams need to
> review their policies or at least discuss these problems publicly
> in more detail. Looks like one such discussion is emerging in
> thread [4].
>

Xcdroast hasn't had a new release in 8 years, and is unmaintained. So if no
one in Gentoo is going to maintain it, I do question why we keep it around;
someone should be keeping an on eye it (minimally media-optical, which
seems dead?)

-A


>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=345337
> [2]
> https://archives.gentoo.org/gentoo-user/message/6ef4447b7ffa34910ed203f4fff73cfc
> [3] https://bugs.gentoo.org/show_bug.cgi?id=345337#c18
> [4]
> https://archives.gentoo.org/gentoo-dev/message/b39c9b7365f0482ed1d5236d9ae2f6f4
>
> Best regards,
> Andrew Savchenko
>

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

[Andrew Savchenko]

On Wed, 6 Jul 2016 23:13:55 +0300 Andrew Savchenko wrote:
> On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
> > What kind of policing would you like to see councilman?  Would you like to 
> > see me removed from the project, because your precious package was 
> > p.masked?  You have ignored every thing I have said regarding your 
> > inability to work with the security team.  Even after an apology from me 
> > and a request to work with us you continue on with the rhetoric of powers.  
> > It displays a lot about your inability to work with others.
> > 
> > No other developer is complaining... it is *literally* only you.
> 
> It is really not just him. I do not agree with media-video/motion
> pmask with 30-days removal term. But I had not pushed this issue
> hard, since I'm not a maintainer of this package.
> 
> If this package would have been masked without removal term, I can
> at least accept if not agree with such action. But there is no
> other alternative for this package and security bugs are not
> critical (at least they do not affect many use cases at all). So
> removal from the tree will harm our users sufficiently.
> 
> When approach is "mask until issues are resolved, so that users are
> informed about security hazard" — it sounds reasonable, and we
> already have several packages in the tree this way. But when
> approach is to purge package from the tree in 30 days regardless of
> severity of security flaws and ignoring the fact that there is
> nothing to replace this package with — this is not a kind of the
> policy I'd like to see in Gentoo.
> 
> Please understand me correctly: I'm not blaming you or security
> team for this or that issue. But it looks like security team indeed
> needs to review some policies and approaches to suit needs of
> Gentoo users better in both of terms of security and usability, to
> find some reasonable compromise between them, which will satisfy
> most users. For these very issues it looks like canceling "removal
> in 30 days" clause from p.mask action will do the job.

One more package to the list: app-cdr/xcdroast. It was being tree
cleaned[1] due to a minor security flaw (o+r on suid binary) on
optional functionality disabled by default (so users have to enable
that suid binary themselves each time after package update).

And despite multiple calls from users (see user comments on [1]
and read whole thread [2]) saying they need this package, they were
asked by security team to "stop spamming this bug"[3]. Such actions
in my opinion make more harm then good by deteriorating user
experience and number of choices available, while bringing only
small and not always meaningful security improve.

So it looks like that both security and treecleaners teams need to
review their policies or at least discuss these problems publicly
in more detail. Looks like one such discussion is emerging in
thread [4].

[1] https://bugs.gentoo.org/show_bug.cgi?id=345337
[2] 
https://archives.gentoo.org/gentoo-user/message/6ef4447b7ffa34910ed203f4fff73cfc
[3] https://bugs.gentoo.org/show_bug.cgi?id=345337#c18
[4] 
https://archives.gentoo.org/gentoo-dev/message/b39c9b7365f0482ed1d5236d9ae2f6f4

Best regards,
Andrew Savchenko


pgpXpl0MilrPI.pgp
Description: PGP signature

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

[J. Roeleveld]

On Wednesday, July 06, 2016 11:13:55 PM Andrew Savchenko wrote:
> On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
.

> Please understand me correctly: I'm not blaming you or security
> team for this or that issue. But it looks like security team indeed
> needs to review some policies and approaches to suit needs of
> Gentoo users better in both of terms of security and usability, to
> find some reasonable compromise between them, which will satisfy
> most users. For these very issues it looks like canceling "removal
> in 30 days" clause from p.mask action will do the job.

+1 on this. Please don't simply tree-clean packages because of security 
issues. Masking them with a reference to the security issues should be 
sufficient.

Some applications can easily be used safely even with gaping security holes. 
(A heavily firewalled box or air-gap comes to mind).

--
Joost


signature.asc
Description: This is a digitally signed message part.

OrangeFS support in Gentoo (Was: Re: [gentoo-dev] why is the security team running around p.masking packages)

[Andrew Savchenko]

On Tue, 5 Jul 2016 11:53:49 -0500 james wrote:
> 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).

Yeah, OrangeFS is a fascinating project. We used it on our HPC
cluster, but had some stability issues. There is
orangefs-2.9_beta20130530-r1 ebuild available in my overlay (as
well as for some older versions). It is outdated and will not work
on kernels > 3.4, but fuse client can be used.

The most pain to support this package was out-of-tree kernel
module. Its inclusion into 4.6 kernel is a really great achievment
of OrangeFS team. So I have plans to update it to 2.9.5 and include
in the tree. If gods will bless me with more spare time :)

Best regards,
Andrew Savchenko


pgpx9jGbJeL9q.pgp
Description: PGP signature

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

[Andrew Savchenko]

On Tue, 5 Jul 2016 09:05:59 -0400 Rich Freeman wrote:
[...]
> 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.

A bit of warning here: gentoo.git tree doesn't contain commits
prior to git migration, thus can't be used as a full attic on its
own. However, historical git repo can be grafted[1] to gentoo.git.
Resulting tree will be quite large and slow for some operations
(like git log), but will be the real attic.

Thus I usually have three trees on my dev boxes:
/usr/portage
~/gentoo
~/gentoo-full

[1] 
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Grafting_Gentoo_history_onto_the_active_repository

Best regards,
Andrew Savchenko


pgpnFVT9vdg2f.pgp
Description: PGP signature

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

[Andrew Savchenko]

On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
> What kind of policing would you like to see councilman?  Would you like to 
> see me removed from the project, because your precious package was 
> p.masked?  You have ignored every thing I have said regarding your 
> inability to work with the security team.  Even after an apology from me 
> and a request to work with us you continue on with the rhetoric of powers.  
> It displays a lot about your inability to work with others.
> 
> No other developer is complaining... it is *literally* only you.

It is really not just him. I do not agree with media-video/motion
pmask with 30-days removal term. But I had not pushed this issue
hard, since I'm not a maintainer of this package.

If this package would have been masked without removal term, I can
at least accept if not agree with such action. But there is no
other alternative for this package and security bugs are not
critical (at least they do not affect many use cases at all). So
removal from the tree will harm our users sufficiently.

When approach is "mask until issues are resolved, so that users are
informed about security hazard" — it sounds reasonable, and we
already have several packages in the tree this way. But when
approach is to purge package from the tree in 30 days regardless of
severity of security flaws and ignoring the fact that there is
nothing to replace this package with — this is not a kind of the
policy I'd like to see in Gentoo.

Please understand me correctly: I'm not blaming you or security
team for this or that issue. But it looks like security team indeed
needs to review some policies and approaches to suit needs of
Gentoo users better in both of terms of security and usability, to
find some reasonable compromise between them, which will satisfy
most users. For these very issues it looks like canceling "removal
in 30 days" clause from p.mask action will do the job.

Best regards,
Andrew Savchenko


pgprpxhxydZL9.pgp
Description: PGP signature

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

[Paul Varner]

On 07/06/2016 10:11 AM, Rich Freeman wrote:
> On Wed, Jul 6, 2016 at 10:02 AM, Kristian Fiskerstrand  
> wrote:
>> On 07/06/2016 03:49 PM, Rich Freeman wrote:
>>
>>> I understand that.  However, I just sometimes wonder whether that
>>> approach makes sense.  The result of the current system is that we
>>> don't release GLSAs until well after a bug is fixed, sometimes after
>>> months.
>> It makes sense for long term server management where you don't want to
>> update the full tree too often, but I agree GLSAs needs to be put out
>> more timely
>>
> Another way to do it is to have a system like this:
> 1.  Vulnerability is logged into database.
> 2.  After embargo period (if any), entry is published.  Tools
> available to the user make them aware they have a vulnerable package
> installed and the realtime status of whether a fix is available.
> 3.  Once a package is stable, the tools let the user auto-update the package.
> 4.  Once all archs are cleaned up, publish the GLSA by email as usual.
>
> So, this is like the current state, except tools like glsa-check use a
> realtime-updated database (or at least one as up-to-date as the latest
> sync) and not a database that is only updated after the last arch is
> stable.  We don't need to send users 14 emails as archs are
> stabilized.  But, the tools they likely would want to use do use the
> latest info.
>
> Sure, in the early days it would just tell them they're vulnerable
> with no suggested fix, since we don't have a fix yet.  But, that is
> still information the user can use to their advantage.
>
> Ideally the early phases of this would be tied into bugzilla so that
> somebody isn't manually updating GLSA xml files every time something
> changes.
>
(Speaking with my tools-portage lead hat on)

While I don't like touching glsa-check within gentoolkit, due to the
nature of what it does. I will fully support and work with the security
team on updating the tool if something like this is desired.

Regards

Paul

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

[Rich Freeman]

On Wed, Jul 6, 2016 at 10:02 AM, Kristian Fiskerstrand  wrote:
> On 07/06/2016 03:49 PM, Rich Freeman wrote:
>
>> I understand that.  However, I just sometimes wonder whether that
>> approach makes sense.  The result of the current system is that we
>> don't release GLSAs until well after a bug is fixed, sometimes after
>> months.
>
> It makes sense for long term server management where you don't want to
> update the full tree too often, but I agree GLSAs needs to be put out
> more timely
>

Another way to do it is to have a system like this:
1.  Vulnerability is logged into database.
2.  After embargo period (if any), entry is published.  Tools
available to the user make them aware they have a vulnerable package
installed and the realtime status of whether a fix is available.
3.  Once a package is stable, the tools let the user auto-update the package.
4.  Once all archs are cleaned up, publish the GLSA by email as usual.

So, this is like the current state, except tools like glsa-check use a
realtime-updated database (or at least one as up-to-date as the latest
sync) and not a database that is only updated after the last arch is
stable.  We don't need to send users 14 emails as archs are
stabilized.  But, the tools they likely would want to use do use the
latest info.

Sure, in the early days it would just tell them they're vulnerable
with no suggested fix, since we don't have a fix yet.  But, that is
still information the user can use to their advantage.

Ideally the early phases of this would be tied into bugzilla so that
somebody isn't manually updating GLSA xml files every time something
changes.

-- 
Rich

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

[Anthony G. Basile]

On 7/6/16 8:11 AM, Rich Freeman wrote:
> Like I said, one mistake doesn't make a trend, and we shouldn't
> over-react to a mistake.  However, the way to handle a mistake is for
> everybody to say "this was a mistake," not "you're the only person who
> has a problem with this."  Let's just fix whatever broke (if it isn't
> already fixed) and move on.  We don't need to defend mistakes.

+1

So what we don't want happening again moving forward is where a
developer (me in this case) thinks he's provided the information needed
for security, then the bug goes dormant 3 years, and then out of the
blue a p.mask with 30 days notice until removal.  Especially if it the
security issue is minor.

The security@g.o list has 500+ open bugs going back years.  We don't
want this uncertainty to loom over all developers heads.  A reasonable
policy here would help create clear expectations for security and other
developers.

I don't think I need to add more to this since K_F appears to be working
on something that will address this.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Kristian Fiskerstrand]

On 07/06/2016 03:49 PM, Rich Freeman wrote:

> I understand that.  However, I just sometimes wonder whether that
> approach makes sense.  The result of the current system is that we
> don't release GLSAs until well after a bug is fixed, sometimes after
> months.

It makes sense for long term server management where you don't want to
update the full tree too often, but I agree GLSAs needs to be put out
more timely

> GLSAs should almost follow the lifecycle of vulnerabilities, or maybe
> be issued per-arch.  Lots of ways to handle it.

Indeed. The easiest way in many ways is a discussion on which
architectures should qualify for security support to begin with, given
stabilization times etc the list for discussion would likely start off
with only amd64.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Rich Freeman]

On Wed, Jul 6, 2016 at 8:19 AM, Kristian Fiskerstrand  wrote:
> On 07/06/2016 02:11 PM, Rich Freeman wrote:
>
>> announcement (which is something we lack - we issue GLSAs sometimes
>> ages after something is fixed on x86/amd64).  Granted, that should be
>> news enough that people are getting the message in other ways unless
>> it is Gentoo-specific.
>
> GLSA is a separate discussion, but amd64 and x86 are not the only stable
> architectures in Gentoo, and the GLEP isn't sent until stabilized across
> the supported arches. That.. and a lower than wanted manpower to write
> up the GLSAs vs scouting, wrangling and auditing work.
>

I understand that.  However, I just sometimes wonder whether that
approach makes sense.  The result of the current system is that we
don't release GLSAs until well after a bug is fixed, sometimes after
months.

So, GLSAs don't tell you if you're vulnerable to a known problem (even
discounting embargo periods).  They only tell you if you have been
slower in updating your system than every stable arch team and the
GLSA team (and that is ignoring the occasional false positive).  To be
really secure you either need to just accept every update in the tree,
or carefully follow bugzilla for security bugs.  Either way the GLSA
doesn't add much.

GLSAs should almost follow the lifecycle of vulnerabilities, or maybe
be issued per-arch.  Lots of ways to handle it.

But I agree that it is out of the scope of this discussion.  And I
just say that as a suggestion - I accept that I haven't volunteered to
retool the GLSA system and it has historically been woefully
undermanned.

-- 
Rich

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

[Kristian Fiskerstrand]

On 07/06/2016 02:11 PM, Rich Freeman wrote:

> Is everybody here at least agreed that this particular situation was
> not handled well?

Indeed

> announcement (which is something we lack - we issue GLSAs sometimes
> ages after something is fixed on x86/amd64).  Granted, that should be
> news enough that people are getting the message in other ways unless
> it is Gentoo-specific.

GLSA is a separate discussion, but amd64 and x86 are not the only stable
architectures in Gentoo, and the GLEP isn't sent until stabilized across
the supported arches. That.. and a lower than wanted manpower to write
up the GLSAs vs scouting, wrangling and auditing work.


> I believe we already have a security severity classification system of
> some kind with targeted response times, so maybe we can tie policy
> into that?

Makes sense

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Rich Freeman]

On Wed, Jul 6, 2016 at 7:48 AM, Anthony G. Basile  wrote:
>
> It doesn't matter, there is a problem here which needs to be addressed.
> I'm complaining because we need to fix a problem in our workflow.  It
> sounds like K_F is working on a glep for that, which I applaud.
>

Is everybody here at least agreed that this particular situation was
not handled well?  That was my sense of it earlier in the thread, but
it seems like we're trying to argue over whether it was.

If so, then let's move forward with better policy/etc.  One-offs don't
concern me much.  However, it seems pretty obvious to me that if a
typical package is suspected of creating a world-readable log file the
reaction shouldn't be to mask it before talking to the maintainer.
About the only thing that should warrant something like that is
something like an sshd bug that lets arbitrary remote attackers
connect as arbitrary users without authentication, and then the
solution shouldn't be just a mask, but also some kind of immediate
announcement (which is something we lack - we issue GLSAs sometimes
ages after something is fixed on x86/amd64).  Granted, that should be
news enough that people are getting the message in other ways unless
it is Gentoo-specific.

I believe we already have a security severity classification system of
some kind with targeted response times, so maybe we can tie policy
into that?

Like I said, one mistake doesn't make a trend, and we shouldn't
over-react to a mistake.  However, the way to handle a mistake is for
everybody to say "this was a mistake," not "you're the only person who
has a problem with this."  Let's just fix whatever broke (if it isn't
already fixed) and move on.  We don't need to defend mistakes.

-- 
Rich

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

[Anthony G. Basile]

On 7/6/16 7:30 AM, Kristian Fiskerstrand wrote:
> On 07/06/2016 01:15 PM, Anthony G. Basile wrote:
>> I'm also disappointed that no one else in the security team has
>> recommended any internal policing in response to this.  I maintain that
>> forced p.masking and version bumping should not be done by the security
>> team but passed to QA for review.  Only QA is mandated with such powers
>> by GLEP 48.
> 
> We're discussing this in another thread already (i.e possibly a GLEP for
> Security project), I'm discussing that as a member of security.
> 
> As for any internal policing outside of public policies it is done
> within the team and not on a public mailing list. The relevant public
> policies are:
> https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide
> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
> 
> But I agree these needs reviewing and codification in the form of a
> GLEP, but as said in the other thread, need to discuss that within the
> project first (I'm not lead, but have requested a team meeting already)
> 


I like this.  So let's make sure we have clear expectations and an
escalation process with review before we pull the p.mask with 30 days
till poof.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Anthony G. Basile]

On 7/6/16 7:23 AM, Aaron Bauman wrote:
> On Wednesday, July 6, 2016 8:15:24 PM JST, Anthony G. Basile wrote:
>> On 7/6/16 6:54 AM, Aaron Bauman wrote:
>>> On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote: ...
>>
>> Except that I state such facts BEFORE the p.mask and you ignored it.
>> Referring to bug #473770:
>>
>> 
>>
>> (In reply to Anthony Basile from comment #1)
>>> The CVE for this has gone nowhere.  See
>>>
>>> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2183
>>>
>>> There are no references and I can't get at the upstream bug report
>>> anymore
>>> since they moved to github.
>>
>> Actually, I found it.  Its fixed:
>>
>> https://github.com/monkey/monkey/issues/93
>>
>> 
>>
>> 
>>
>> Aaron Bauman gentoo-dev Security 2016-07-01 01:39:40 UTC
>>
>> # Aaron Bauman  (1 Jul 2016)
>> # Unpatched security vulnerabilities and dead upstream
>> # per bugs #459274 and #473770  Removal in 30 days
>> www-servers/monkeyd
>>
>> 
>>
>>
>> People reading following this can clearly see the problem here.
>>
>> I'm also disappointed that no one else in the security team has
>> recommended any internal policing in response to this.  I maintain that
>> forced p.masking and version bumping should not be done by the security
>> team but passed to QA for review.  Only QA is mandated with such powers
>> by GLEP 48.
>>
> 
> What kind of policing would you like to see councilman? 

Policing also has the meaning of policy-ing.  I'd like to see better
policies within the security team for escalation of security bugs.  I'm
suggesting passing the review onto QA, but it looks like K_F (from his
other email) has other ideas which may better for a workflow.


> Would you like
> to see me removed from the project, because your precious package was
> p.masked?

I never said anything to that effect.  I'm arguing a point for better
policy-ing and I'm not satisfied by your solution that developers need
to just better document when a security issue is fixed.

monkeyd is an important package.

>  You have ignored every thing I have said regarding your
> inability to work with the security team.  Even after an apology from me
> and a request to work with us you continue on with the rhetoric of
> powers.  It displays a lot about your inability to work with others.

The problem is not an apology which I appreciate.  The problem is we
need better expectations of when a package is going to get p.masked on
you.  p.masking a package which a notice of 30 days until removal sends
a very bad message to users who depend on it.  Proceeding as the
security team has, there is no way for a developer to know what's about
to happen.  Consider, I thought I'd answered the issue with bug #473770
with comment #2.

> 
> No other developer is complaining... it is *literally* only you. 
> NP-Hardass's case was not even a security bug nor handled by the
> security team.  One of the bugs for monkeyd led to additional discovery
> of insecurities regarding log files, but it took a p.mask to get your
> attention.  Quit pushing an agenda and work with others to make Gentoo
> more secure.  Everyone else is.
> 
>>

It doesn't matter, there is a problem here which needs to be addressed.
I'm complaining because we need to fix a problem in our workflow.  It
sounds like K_F is working on a glep for that, which I applaud.

> 
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Kristian Fiskerstrand]

On 07/06/2016 01:15 PM, Anthony G. Basile wrote:
> I'm also disappointed that no one else in the security team has
> recommended any internal policing in response to this.  I maintain that
> forced p.masking and version bumping should not be done by the security
> team but passed to QA for review.  Only QA is mandated with such powers
> by GLEP 48.

We're discussing this in another thread already (i.e possibly a GLEP for
Security project), I'm discussing that as a member of security.

As for any internal policing outside of public policies it is done
within the team and not on a public mailing list. The relevant public
policies are:
https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide
https://www.gentoo.org/support/security/vulnerability-treatment-policy.html

But I agree these needs reviewing and codification in the form of a
GLEP, but as said in the other thread, need to discuss that within the
project first (I'm not lead, but have requested a team meeting already)

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Aaron Bauman]

On Wednesday, July 6, 2016 8:15:24 PM JST, Anthony G. Basile wrote:

On 7/6/16 6:54 AM, Aaron Bauman wrote:

On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote: ...


Except that I state such facts BEFORE the p.mask and you ignored it.
Referring to bug #473770:



(In reply to Anthony Basile from comment #1)

The CVE for this has gone nowhere.  See

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2183

There are no references and I can't get at the upstream bug report anymore
since they moved to github.


Actually, I found it.  Its fixed:

https://github.com/monkey/monkey/issues/93





Aaron Bauman gentoo-dev Security 2016-07-01 01:39:40 UTC

# Aaron Bauman  (1 Jul 2016)
# Unpatched security vulnerabilities and dead upstream
# per bugs #459274 and #473770  Removal in 30 days
www-servers/monkeyd




People reading following this can clearly see the problem here.

I'm also disappointed that no one else in the security team has
recommended any internal policing in response to this.  I maintain that
forced p.masking and version bumping should not be done by the security
team but passed to QA for review.  Only QA is mandated with such powers
by GLEP 48.



What kind of policing would you like to see councilman?  Would you like to 
see me removed from the project, because your precious package was 
p.masked?  You have ignored every thing I have said regarding your 
inability to work with the security team.  Even after an apology from me 
and a request to work with us you continue on with the rhetoric of powers.  
It displays a lot about your inability to work with others.


No other developer is complaining... it is *literally* only you.  
NP-Hardass's case was not even a security bug nor handled by the security 
team.  One of the bugs for monkeyd led to additional discovery of 
insecurities regarding log files, but it took a p.mask to get your 
attention.  Quit pushing an agenda and work with others to make Gentoo more 
secure.  Everyone else is.

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

[Anthony G. Basile]

On 7/6/16 6:54 AM, Aaron Bauman wrote:
> On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote:
>> On 7/5/16 10:52 PM, NP-Hardass wrote:
>>> 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 ...
>>
>> I agree that a ping is the necessary first step, but I'm afraid of a
>> dispute between the maintainer and the security team.  Bug #459274,
>> which I discussed in my previous email, should never have been file and
>> should never have been acted on.  If the security team feels they must
>> touch a package, I'd like to have QA review it.  The QA leadership is
>> ratified by the council and has a long history of dealing with these
>> sorts of issues which are tried and true.
>>
>>
> 
> So just state such facts, as you did following the p.mask, and all would
> be well.  It really has been and continues to be that simple.
> 

Except that I state such facts BEFORE the p.mask and you ignored it.
Referring to bug #473770:



(In reply to Anthony Basile from comment #1)
> The CVE for this has gone nowhere.  See
>
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2183
>
> There are no references and I can't get at the upstream bug report anymore
> since they moved to github.

Actually, I found it.  Its fixed:

https://github.com/monkey/monkey/issues/93





Aaron Bauman gentoo-dev Security 2016-07-01 01:39:40 UTC

# Aaron Bauman  (1 Jul 2016)
# Unpatched security vulnerabilities and dead upstream
# per bugs #459274 and #473770  Removal in 30 days
www-servers/monkeyd




People reading following this can clearly see the problem here.

I'm also disappointed that no one else in the security team has
recommended any internal policing in response to this.  I maintain that
forced p.masking and version bumping should not be done by the security
team but passed to QA for review.  Only QA is mandated with such powers
by GLEP 48.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Aaron Bauman]

On Wednesday, July 6, 2016 11:52:46 AM JST, NP-Hardass wrote:

On 07/05/2016 10:43 PM, Aaron Bauman wrote:

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


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.



As discussed, that issue was not a security bug nor handled by the security 
team.  So it is irrelevant.

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

[Aaron Bauman]

On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote:

On 7/5/16 10:52 PM, NP-Hardass wrote:

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


I agree that a ping is the necessary first step, but I'm afraid of a
dispute between the maintainer and the security team.  Bug #459274,
which I discussed in my previous email, should never have been file and
should never have been acted on.  If the security team feels they must
touch a package, I'd like to have QA review it.  The QA leadership is
ratified by the council and has a long history of dealing with these
sorts of issues which are tried and true.




So just state such facts, as you did following the p.mask, and all would be 
well.  It really has been and continues to be that simple.

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

[Kristian Fiskerstrand]

On 07/06/2016 10:37 AM, Anthony G. Basile wrote:
>> > If council approval of special projects as lead is an important factor,
>> > maybe we should rather also approve security leads?
>> > 
> Approving a security lead is not sufficient.  QA is governed by GLEP 48.
>  The very procedure of producing a glep means scrutiny by the community
> as to its scope, mandate, procedure and powers.  By the security team
> simply thinking it has the powers to p.mask and bump packages, its is
> essentially circumventing Gentoo governance.  If it needs these powers,
> it should go through QA.

I'm not aware of any security policy that indicates bumping packages as
being a role for security (it really is up to maintainer), but it is an
interesting point for p.mask that is part of the written policies of the
project.

A GLEP for the security project would make a great deal of sense in
general and is on overtime. I will stop the discussion of any specifics
on that at this point though, as it hasn't been discussed within the
project which in any case is a natural first step to things.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Anthony G. Basile]

On 7/6/16 4:25 AM, Kristian Fiskerstrand wrote:
> 
> That said, the reason the mask is questionable in this case is the low
> severity of the bug, but that isn't a general case.

Bug #582240 - sys-devel/gcc: multiple vulnerabilities

If the security team proceeded with gcc as it did with monkeyd, it would
be masking it now.  It doesn't have to be a general case.  Looking
through the security bugs there's so much link, its hard to tell what's
good and what's not.

> 
> If council approval of special projects as lead is an important factor,
> maybe we should rather also approve security leads?
> 

Approving a security lead is not sufficient.  QA is governed by GLEP 48.
 The very procedure of producing a glep means scrutiny by the community
as to its scope, mandate, procedure and powers.  By the security team
simply thinking it has the powers to p.mask and bump packages, its is
essentially circumventing Gentoo governance.  If it needs these powers,
it should go through QA.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Kristian Fiskerstrand]

On 07/06/2016 10:04 AM, Anthony G. Basile wrote:
> Having people review your work is a good idea, no?  So in cases where
> security wants to touch a packages, why not ping the maintainer first
> and in case of a dispute or no response, escalate the issue to QA who
> will review the problem and act.
> 
> Are you okay with this change in procedure?

It really depends on the severity of the security issue and QA response
time. In general it seems like additional complexity, and the use of
package masks are rare in general (and questionable in the specific
context being discussed, so generalizing from that is bad form)

If a bug should not be a security bug, why not mention as much in the
bug report? I'm looking at 459274 and there is no maintainer response to
it in more than 3 years. For 473770 there is no mention of which package
it is fixed in, and generally bad tracking that even includes a move to
github losing old references and a "I can't reproduce this" concluding
it is fixed for all systems.

In areas like this maintainers are the ones that needs to track upstream
development of packages, and point out which released versions contains
fixes or which patched version downstream does. Security can't in any
case keep track of all packages in tree, in particular with the low bar
there seems to be for adding new ones.

That said, the reason the mask is questionable in this case is the low
severity of the bug, but that isn't a general case.

If council approval of special projects as lead is an important factor,
maybe we should rather also approve security leads?

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Anthony G. Basile]

On 7/5/16 10:52 PM, NP-Hardass wrote:
> 
> 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.
> 

I agree that a ping is the necessary first step, but I'm afraid of a
dispute between the maintainer and the security team.  Bug #459274,
which I discussed in my previous email, should never have been file and
should never have been acted on.  If the security team feels they must
touch a package, I'd like to have QA review it.  The QA leadership is
ratified by the council and has a long history of dealing with these
sorts of issues which are tried and true.


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

[Anthony G. Basile]

On 7/5/16 10:43 PM, Aaron Bauman wrote:
> 
> 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.
> 

You never bothered to follow that OSS ML link.  For others reading this
email, here is the link:

http://www.openwall.com/lists/oss-security/2013/02/24/5

Here's a copy of that entire email:



Date: Sun, 24 Feb 2013 20:00:57 +0100
From: Agostino Sarubbo 
To: oss-secur...@...ts.openwall.com
Subject: CVE request: monkeyd world-readable logdir

Monkeyd, a small, fast, and scalable web server, produces, at least on
gentoo a world-readable log.

# ls /var/log/monkeyd/master.log -la
-rw-r--r-- 1 root root 0 Feb 24 19:56 /var/log/monkeyd/master.log

Upstream site: http://www.monkey-project.com/

-- 
Agostino Sarubbo
Gentoo Linux Developer




That is what you p.masked on.  That's it.  Neither you nor Ago really
understood the issue with monkeyd's logging.  There were no followup
emails and no CVE was assigned.  Its junk.

By both initiating and following through on such low quality bugs, you
are damaging the reputation of the security project.


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

Having people review your work is a good idea, no?  So in cases where
security wants to touch a packages, why not ping the maintainer first
and in case of a dispute or no response, escalate the issue to QA who
will review the problem and act.

Are you okay with this change in procedure?


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

[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

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

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

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] 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] why is the security team running around p.masking packages

[Aaron Bauman]

On Tuesday, July 5, 2016 6:09:38 AM JST, Rich Freeman wrote:

On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko  wrote:

The same applies for the tree-cleaners team. While their job is
very important, sometimes they are too hasty, like in commit
34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and
works fine, have no critical bugs opened, the sheer fact that
upstream as inactive and package has no maintainer is no valid to ...


++

To treeclean a package it should be both unmaintained and have a
significant QA issue of some kind.  Simply having open bugs shouldn't
be sufficient, and of course if it works fine there is no reason to
boot it.  Now, if the package is a blocker on some EAPI retirement or
other tree-wide operation, that would be a great reason to treeclean
it if it is unmaintained.

Security issues should warrant masking fairly easily, but only if the
maintainer is unresponsive or the package is unmaintained (or we're
talking an end-of-the-world security issue).  If the maintainer is
about to commit a fix or disputes that the issue applies in the
package, it is best to just work with them.  Otherwise users will just
end up putting entries in package.unmask that could cause them issues
later.



That is exactly what happened here.  We worked with Anthony following the 
p.mask, and we have always done so with all packages that resulted in a 
mask.  Often, it simply highlights to the maintainer that a security issue 
is outstanding and needs attention.  It also protects the user regardless 
of the vulnerabilities severity.  Sometimes this a failure on upstream, 
which also raises additional concerns if multiple vulnerabilities exist.  
In this particular case the issues were outstanding for years.


Most developers coordinate very well with us regarding their packages.  
Sometimes that involves relocation of sources upstream, reversioning 
upstream, etc.  While we try to resolve it on our own, the expertise of the 
developer on that package is a tremendous asset in ensuring the package is 
no longer vulnerable.  We even patch or verify source code changes 
ourselves to resolve bugs.


In regards to the media-video/motion mask, you can follow up with the bug 
and see the continued efforts.  Users have responded with relocated sources 
that have a fix for the package.  Something that only familiarity or 
endless digging would bear fruit on.  We are actively working to mitigate 
the vulnerability and get the package unmasked for the community.  We are 
not just trying to kill things to kill them.


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.


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

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

[Rich Freeman]

On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko  wrote:
>
> The same applies for the tree-cleaners team. While their job is
> very important, sometimes they are too hasty, like in commit
> 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and
> works fine, have no critical bugs opened, the sheer fact that
> upstream as inactive and package has no maintainer is no valid to
> remove package. The reason "are still sitting in ~arch" is even
> less valid, since it is absolutely fine that package never mades it
> into stable (some people do not use stable at all).
>

++

To treeclean a package it should be both unmaintained and have a
significant QA issue of some kind.  Simply having open bugs shouldn't
be sufficient, and of course if it works fine there is no reason to
boot it.  Now, if the package is a blocker on some EAPI retirement or
other tree-wide operation, that would be a great reason to treeclean
it if it is unmaintained.

Security issues should warrant masking fairly easily, but only if the
maintainer is unresponsive or the package is unmaintained (or we're
talking an end-of-the-world security issue).  If the maintainer is
about to commit a fix or disputes that the issue applies in the
package, it is best to just work with them.  Otherwise users will just
end up putting entries in package.unmask that could cause them issues
later.

-- 
Rich

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

[Andrew Savchenko]

On Thu, 30 Jun 2016 22:51:51 -0400 Anthony G. Basile wrote:
> I'm going to ask the security team to please stop running around
> p.masking packages without acknowledgement from the maintainers.  I'm
> referring in particular to commit
> 135b94c85950254f559f290f4865bce8b349a917 regarding monkeyd.  Both of the
> cited "security bugs" were long fixed, and even if the were not, they do
> not merit masking because they were at best some information leakage
> with minor impact.  I have reverted that commit and would ask that
> security stop this practice.

Seconded here, the same applies to commit
61de68f69fdf7dd0aaa53303517c0e59738034c3, since security issues
doesn't affect most popular use cases, and at least first security
bug is fixed in [1]. Haven't tested the other bug, though.

The same applies for the tree-cleaners team. While their job is
very important, sometimes they are too hasty, like in commit
34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and
works fine, have no critical bugs opened, the sheer fact that
upstream as inactive and package has no maintainer is no valid to
remove package. The reason "are still sitting in ~arch" is even
less valid, since it is absolutely fine that package never mades it
into stable (some people do not use stable at all).

[1] https://github.com/Mr-Dave/motion

Best regards,
Andrew Savchenko


pgp0tJifYcOSA.pgp
Description: PGP signature