Re: git dangerous operations on alioth
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 28/02/13 20:20, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2013-02-28 19:20:09)
>> On 28/02/13 13:15, Simon McVittie wrote:
>>> On 28/02/13 09:39, Daniel Pocock wrote:
>>>> Has anybody had experience controlling access to git
>>>> repositories, for example, to give users access but prevent
>>>> some of the following dangerous operations?
>>>
>>
>>> If you look at it from the appropriate angle, the combination
>>> of ftp.d.o and snapshot.d.o (particularly source packages) is a
>>> big, inefficient VCS, with a rather wider user-base than Alioth
>>> - what the maintainer says the git history of package "foo" is
>>> seems relatively unimportant when compared with what its upload
>>> history looks like. All DDs have the ability to "commit"
>>> wide-ranging changes to that "VCS", and we mostly regulate that
>>> by social conventions for what can and can't be in an NMU or a
>>> "team upload", discouraging hostile NMUs and hijacking, etc.,
>>> rather than by applying chmod.
>>
>> DD access is also an `all or nothing' scenario, and it is tightly
>> controlled in other ways.
>>
>> What I was anticipating is how we can provide more access for
>> upstreams and other non-DDs using the guest account mechanism or
>> potentially some kind of non-UNIX level access
>>
>> To give one example, one of my packages fails to build with clang
>> due to some other header file in package foo. Somebody actually
>> uploaded a fix for foo onto mentors long before the freeze, but
>> it got no further. It leaves me feeling that the DD community
>> could benefit from more automated ways to ramp up new members and
>> accept their contributions, but that would also mean taking the
>> sharp edges off some things.
>
> Well, to me a contribution "left at our doorstep", e.g. by
> uploading to mentors.debian.net, haven't really reached Debian yet:
> Someone (called a mentor) needs to take it the rest of the way.
> Concretely a mentor might have shown the contributor how to get in
> touch with you - either through the BTS or maybe (if your package
> permits that) by injecting the suggested code changes directly into
> the VCS of your package maintenance.
>
> I am in favor of making it easier to contribute, but maintainer
> teams may have sane reasons for e.g. wanting to talk to new
> contributors before letting them mess directly with their local
> infrastructure.
I wasn't suggesting that there would be some kind of shortcut or
bypassing all human contact with new contributors, just that there may
be opportunities to streamline the process
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJRL8DGAAoJEOm1uwJp1aqDOkoP/iZZY1YczvllO8pzcNFsaeAy
7GjbS/MK9/Vm9rEOjaiaBdwa3fO9TCTYvWkeXIfwoQAw5mLd32kh0gbg+E3rqQah
NMkK+7N3h5FIUEF4+KeP8uyhcjuZBe4ig4TYdwlgaxsS8L0f8Rdd1vrtBNvCrWMD
0E8VqXq7VTQeOhXiGPHK97qUVbuGGXc+b8a6Yjah7yzQtHfC/Va3PHEJg2zgtb7L
74m9Tec0oCJxa6EdCPS2u/Rws7kHhizf+j3/HcxeOGVzHYXBZO9cj3lnd9vdrquP
bUarFFj/EomOwnbHwu42XA83r8CKHD1FnCYvsuNQphz1N7koZSI2P7vgd0xy9imS
tPQevbwsSppYUH6zS52mINFbBmNFh7bJqIl3tK9PlwBBLIXJjgdZH8/8tSrR0fRL
DiXDlzb1sNEQz0LRtuh9h1Mp4ZlSkp7NdmJ7zc7ZF8OfDvrdZzO4aHRFsSZc0j0B
xoqDViC2WgpX9qjL2i0c63RXSLT4Fd7FWRY1+EsedW/Zg8CJ27W+T/Wsd9Y3pHX0
mj7yV9R1quTaIIhp6VWxo8pmKCEkW+0Qx7216IL4gMV6z3Em0F5p6c/yVrh9acop
4GXKuDexYO0ah42mg/rFLkmmGdFF9FMMVx7Rq4jAfApUmLp9jXxckr1lzD0LVGxI
N5uG4v+YCzkM32Mny1jB
=oHiH
-----END PGP SIGNATURE-----
Reply to: