Am 10.01.2012 14:39, schrieb Andreas Färber:
> Am 10.01.2012 14:33, schrieb Kevin Wolf:
>> Am 10.01.2012 14:22, schrieb Anthony Liguori:
>>> On 01/10/2012 06:58 AM, Kevin Wolf wrote:
Probably we need to attack the reviewing problem first: That I review
all block patches myself worked well
Am 07.01.2012 11:42, schrieb Stefan Hajnoczi:
> On Sat, Jan 7, 2012 at 3:09 AM, Peter Maydell
> wrote:
>> On 6 January 2012 20:42, Anthony Liguori wrote:
>>> On 01/06/2012 02:02 PM, Andreas Färber wrote:
i) Unless it's a build fix, I propose defining a minimum review time
before a patc
Am 10.01.2012 14:22, schrieb Anthony Liguori:
> On 01/10/2012 06:58 AM, Kevin Wolf wrote:
>> Probably we need to attack the reviewing problem first: That I review
>> all block patches myself worked well as long as we were two or three
>> people in that area, but today it doesn't scale any more with
Am 10.01.2012 16:41, schrieb Peter Maydell:
> On 10 January 2012 13:39, Andreas Färber wrote:
>> If you want an incentive, just put up a rule that every patch needs to
>> be reviewed by at least the submaintainer and one person apart from the
>> author (i.e., SoB + RB/AB + SoB). If a patch is lack
On 10 January 2012 13:39, Andreas Färber wrote:
> If you want an incentive, just put up a rule that every patch needs to
> be reviewed by at least the submaintainer and one person apart from the
> author (i.e., SoB + RB/AB + SoB). If a patch is lacking that additional
> review, the author will pin
On 01/10/2012 07:33 AM, Kevin Wolf wrote:
Am 10.01.2012 14:22, schrieb Anthony Liguori:
On 01/10/2012 06:58 AM, Kevin Wolf wrote:
Probably we need to attack the reviewing problem first: That I review
all block patches myself worked well as long as we were two or three
people in that area, but t
Am 10.01.2012 14:33, schrieb Kevin Wolf:
> Am 10.01.2012 14:22, schrieb Anthony Liguori:
>> On 01/10/2012 06:58 AM, Kevin Wolf wrote:
>>> Probably we need to attack the reviewing problem first: That I review
>>> all block patches myself worked well as long as we were two or three
>>> people in that
On 01/10/2012 06:58 AM, Kevin Wolf wrote:
Probably we need to attack the reviewing problem first: That I review
all block patches myself worked well as long as we were two or three
people in that area, but today it doesn't scale any more without
lowering the review standards - and I don't want to
On Fri, Jan 6, 2012 at 11:19 PM, Anthony Liguori wrote:
> Hi,
>
> I had an idea I wanted to share and see what level of interest there was in
> participating and if anyone knows of a process that other projects follow
> for this.
>
> I'd like to start a more formal and transparent security audit o
On Sun, Jan 8, 2012 at 2:01 PM, Dor Laor wrote:
> On 01/06/2012 07:25 PM, Chris Wright wrote:
>>
>> * Corey Bryant (cor...@linux.vnet.ibm.com) wrote:
>>>
>>> Count me in for step 2. A good approach may be to run a static
>>> analysis tool against the code, followed by a manual scan of the
>>> cod
On 01/06/2012 07:25 PM, Chris Wright wrote:
* Corey Bryant (cor...@linux.vnet.ibm.com) wrote:
Count me in for step 2. A good approach may be to run a static
analysis tool against the code, followed by a manual scan of the
code for common vulnerabilities that static analysis can't find.
Good i
Am 06.01.2012 17:01, schrieb Stefan Hajnoczi:
On Fri, Jan 06, 2012 at 09:19:45AM -0600, Anthony Liguori wrote:
Would folks be interested in participating in something like this?
If so, I can start organizing it.
I enjoy bug hunting and would volunteer.
Stefan
So do I.
Stefan
On Sat, Jan 7, 2012 at 3:09 AM, Peter Maydell wrote:
> On 6 January 2012 20:42, Anthony Liguori wrote:
>> On 01/06/2012 02:02 PM, Andreas Färber wrote:
>>> i) Unless it's a build fix, I propose defining a minimum review time
>>> before a patch is applied to a (sub)maintainer's queue.
>
>> I disag
On 6 January 2012 20:42, Anthony Liguori wrote:
> On 01/06/2012 02:02 PM, Andreas Färber wrote:
>> i) Unless it's a build fix, I propose defining a minimum review time
>> before a patch is applied to a (sub)maintainer's queue.
> I disagree here. If anything, I think we wait a bit too long for pe
On 01/06/2012 02:02 PM, Andreas Färber wrote:
Am 06.01.2012 16:19, schrieb Anthony Liguori:
I'd like to start a more formal and transparent security audit of QEMU.
The way I'd imagine it working is something like this:
I'd like to propose something else: We should define a more formal
process
Am 06.01.2012 16:19, schrieb Anthony Liguori:
> I'd like to start a more formal and transparent security audit of QEMU.
> The way I'd imagine it working is something like this:
I'd like to propose something else: We should define a more formal
process for reviewing and applying patches in the fir
* Anthony Liguori (aligu...@us.ibm.com) wrote:
> 2) Two people walk through a particular piece of code and
> independently flag anything that looks like a potential security
> issue.
Auditing is always helpful, but won't ever get full coverage. qtest +
fuzz is another great way to identify proble
* Corey Bryant (cor...@linux.vnet.ibm.com) wrote:
> Count me in for step 2. A good approach may be to run a static
> analysis tool against the code, followed by a manual scan of the
> code for common vulnerabilities that static analysis can't find.
Good idea. Folks are already running things lik
On 01/06/2012 10:19 AM, Anthony Liguori wrote:
Hi,
I had an idea I wanted to share and see what level of interest there was
in participating and if anyone knows of a process that other projects
follow for this.
I'd like to start a more formal and transparent security audit of QEMU.
The way I'
On Fri, Jan 06, 2012 at 09:19:45AM -0600, Anthony Liguori wrote:
> Would folks be interested in participating in something like this?
> If so, I can start organizing it.
I enjoy bug hunting and would volunteer.
Stefan
Hi,
I had an idea I wanted to share and see what level of interest there was in
participating and if anyone knows of a process that other projects follow for this.
I'd like to start a more formal and transparent security audit of QEMU. The way
I'd imagine it working is something like this:
21 matches
Mail list logo
