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 Thursday, July 07, 2016 06:37:09 AM Duncan wrote:
> J. Roeleveld posted on Wed, 06 Jul 2016 20:22:57 +0200 as excerpted:
> > On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
> >> # Aaron Bauman (30 Jun 2016)
> >> # Unpatched security vulnerability per bug #509920.
> >> # Removal in 30
J. Roeleveld posted on Wed, 06 Jul 2016 20:22:57 +0200 as excerpted:
> On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
>> # Aaron Bauman (30 Jun 2016)
>> # Unpatched security vulnerability per bug #509920.
>> # Removal in 30 days www-apps/egroupware
>
> Why is this bug being used to t
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 Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
> # Aaron Bauman (30 Jun 2016)
> # Unpatched security vulnerability per bug #509920.
> # Removal in 30 days
> www-apps/egroupware
Why is this bug being used to treeclean egroupware?
Why is bug 461212 not being used to actually resolve 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
26 matches
Mail list logo
