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,
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
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
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 nu
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 dr
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 t
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
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
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 whate
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
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 me
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 enoug
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 lea
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
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 i
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.
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 Anth
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 is
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 p
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 bump
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
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, i
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.
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
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 fo
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
>>> vuln
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 wheth
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 ve
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.
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
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
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
>>> pac
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 att
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 i
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
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
>>> packag
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 oft
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.
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
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, t
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. B
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 we
42 matches
Mail list logo
