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 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
