Re: [Qemu-devel] [RFC 00/14] MAINTAINERS cleanups - please read

[Blue Swirl]

On Thu, Apr 26, 2012 at 13:43, Andreas Färber <address@hidden> wrote:
> Am 17.04.2012 22:45, schrieb Blue Swirl:
>> On Mon, Apr 16, 2012 at 21:47, Anthony Liguori <address@hidden> wrote:
>>> On 04/16/2012 04:24 PM, Peter Maydell wrote:
>>>>
>>>> On 16 April 2012 18:42, Anthony Liguori<address@hidden>  wrote:
>>>>>
>>>>> On 04/16/2012 12:17 PM, Peter Maydell wrote:
>>>>>>
>>>>>> Here's my stab at it:
>>>>>>            Maintained:  Someone actually looks after it. The maintainer
>>>>>>                         will have a git subtree for this area and
>>>>>> patches
>>>>>>                         are expected to go through it. Bug reports will
>>>>>>                         generally be investigated.
>>>>>
>>>>>
>>>>> * For something to be marked Maintained, there must be a person on M: and
>>>>> there must be a git tree for the subsystem.
>>>>
>>>>
>>>> Do you mean "there must be a git tree" or "there must be a git tree
>>>> listed under T: for this area" ? We have I think several subsystems
>>>> where things do come in via pullreq for a submaintainer tree but that
>>>> tree isn't officially public except in as much as the branch name
>>>> for the pullreq is always the same...
>>>
>>>
>>> I'd like to record T: as part of a way to validate pull requests.  I get
>>> slightly nervous about pull requests because it's an easy way to sneak code
>>> into the tree if you're malicious.
>>
>> Wouldn't signed PULL requests help? They need a very recent git though.
>
> Signed PULL requests can authenticate the person sending the PULL but
> not authorize what areas the contents of the PULL is allowed to touch.

Yes, but was that the problem Anthony had with PULLs? For a person
with malicious intentions, a pull would not necessarily be the tool of
choice, since it could lead to banning and investigations after
discovery. I thought Anthony was talking about MITM (or kernel.org
style breach) scenarios, there signed PULLs and/or signed commits
could help.

> Any definition of key -> files (just like email -> files) is going to be
> surrounded by grey zones and exceptions to the rule, so I guess
> verifying each PULL's diff stat and good judgment are the only weapons
> against malicious PULLs, given that PULLs have become quite popular
> these days and are no longer limited to recurring block, pci, ppc, etc.

How is a PULL any different from email, can you do something in a PULL
which is not possible with email? I think signed PULLs and commits
would give higher level of integrity and non-repudiation than unsigned
email.

>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg