On Thu, Apr 26, 2012 at 13:43, Andreas Färber <afaer...@suse.de> wrote:
> Am 17.04.2012 22:45, schrieb Blue Swirl:
>> On Mon, Apr 16, 2012 at 21:47, Anthony Liguori <anth...@codemonkey.ws> wrote:
>>> On 04/16/2012 04:24 PM, Peter Maydell wrote:
>>>> On 16 April 2012 18:42, Anthony Liguori<anth...@codemonkey.ws>  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

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

Reply via email to