Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On Fri, Mar 08, 2013 at 02:52:48PM +0100, Thomas Koch wrote: Hi Daniel et al, I'm also thinking a lot about how to improve Debian by improving our Git tooling. Therefor I'm packaging Gerrit (#589436). But gerrit and its dependencies is a big project... Now that Git slowly becomes the de facto standard VCS for Debian[1] (resistance is futile) it might be time to review our setup and think whether we could improve our Git infrastructure. Should we start a wiki page to collect thoughts? [1] http://www.lucas-nussbaum.net/blog/?p=751 My thoughts are: - I'd like to have support for reviews (e.g Gerrit) - pull requests (e.g Gerrit) - I'd like continuous integration (triggered e.g. by Gerrit[2]) Gerrit's Jenkins integration is awesome. Verifying if a package still builds and runs its autopkgtests after a commit would be a huge step forward. Is that what you're after? Do you run a test system somewhere for that already? Should we start setting something like this up? Cheers, -- Guido - Easy for anybody to submit patches (e.g Gerrit) - A frontpage that doesn't take ages to load - Easier project creation without the need to SSH into alioth - regular fetching of the upstream branch from upstreams master [2] http://openstack-ci.github.com/publications/ I was also thinking whether Debian should cooperate with other projects so that the workload of maintaining such a setup could be shared. I started to collect candidates for collaboration here: http://wiki.debian.org/Alioth/OtherForges Best regards, Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201303081452.50647.tho...@koch.ro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130322204421.ga12...@bogon.sigxcpu.org
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-22 21:44:21 +0100 (+0100), Guido Günther wrote:
Gerrit's Jenkins integration is awesome.
[...]
OpenStack CI has some additional tools which help avoid the need to
interact directly with Jenkins too much. There's Zuul (the
gatekeeper) which watches the Gerrit event stream and triggers jobs
in Jenkins as a result of matching again patterns defined a YAML
configuration file--the gerrit-trigger plugin for Jenkins lacked
enough AI for our needs. Also Jenkins Job Builder which allows you
to keep your Jenkins jobs in a templated YAML format rather than
resorting to its WebUI or editing XML configs. And we've also got a
Gearman plug-in in the works for Jenkins, so that Gearman queues can
be used to gain finer-grained control over Jenkins jobs and slaves.
https://github.com/openstack-infra/zuul
https://github.com/openstack-infra/jenkins-job-builder
https://github.com/openstack-infra/gearman-plugin
We're always happy to see others putting this stuff to use if it
suits their needs, and welcome outside contributions as well.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130322210818.ge29...@yuggoth.org
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-22 21:08:18 + (+), Jeremy Stanley wrote:
[...]
watches the Gerrit event stream and triggers jobs in Jenkins as a
result of matching again patterns defined a YAML configuration
file
[...]
Yeesh. I clearly shouldn't write E-mail when I'm rushing off to eat.
What I meant to say is that Zuul triggers jobs in Jenkins as a
result of matching Gerrit events against patterns defined in a YAML
file, and also uses a predictive pipeline heuristic to merge and
oversee parallel tests on sequences of patches. We enqueue approved
changes from Gerrit (some dependent on one another, others
independent of each other), and ensure that they only make it into
the target branch if they pass a battery of unit and integration
tests when merged on the patches ahead of them in the pipeline.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130322234722.gf29...@yuggoth.org
Re: RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
]] Thomas Goirand Did anyone try buildbot? It might be better for what I need. Buildbot is pretty crap at managing slaves that disappear and come back and such. I quite disliked the fact that most of Jenkins is done through a web GUI, which was in fact, more a nuisance than anything else. Maybe buildbot would fit my needs better, so I would really appreciate if anyone can share his experience with it. Just use jenkins-job-builder? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2uyunzx@qurzaw.varnish-software.com
Re: RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
Hi Tollef, Tollef Fog Heen tfh...@err.no writes: Buildbot is pretty crap at managing slaves that disappear and come back and such. This works fine for me, I have never had any trouble with that (and yes, my build slaves have disconnected/reconnected quite a few times). Using buildbot since more than a year to do after-push builds of Debian/Ubuntu packages for i3wm.org, see http://i3wm.org/docs/buildbot.html I am pretty happy with buildbot. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6k3p5bz3j@midna.zekjur.net
Re: git dangerous operations on alioth
Stefano Zacchiroli zack at debian.org writes: Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) anonssh can help lower the chance of that: (this link is wrapped; GMane would not allow me to post otherwise, just remove the newline after the question mark) https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi? p=evolvis-platfrm/anonssh.git It does allow sftp though… both by design. (This version does SFTP, git and svn; the one in MirBSD does cvs and rsync; extending it is pretty easy.) SFTP and rsync can, arguably, remove a repository. With malintent. But then, it’s a #ifdef… Maybe permit rsync only for some anonymous user, so only receiving but not writing is enabled… you can easily install varying anonssh flavours (and put them into the allowed shells table in the gforge database). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130313t160420-...@post.gmane.org
Re: git dangerous operations on alioth
]] Thomas Goirand I wasn't discussing what can be done for backing up a Git repository, I was asking what is *currently installed* in production as a backup for Alioth. da-backup. Look at /etc/da-backup/* for the configuration. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boap90f7@xoog.err.no
Re: RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 03/09/2013 12:36 AM, PICCA Frédéric-Emmanuel wrote: I start to really love the CI thing. I first invested a bit of time in setting-up everything, do you have a step by step cookbook for your setup. Maybe on the debian wiki ? Unfortunately, no. But it's really easier than what I thought. I might try writing such a cookbook if I find the time, and reinstall everything from scratch on a new server. Also, with Jenkins, you just start a script who builds for you. What I wrote is quite a hack, I'm not sure if I want to publish that... :) Or probably with lots of !!!warning!!! added... I also would like to add some goodies to it (like piuparts tests, lintian runs, etc.). I also need to understand how to secure Jenkins. Because by default, it's impressive how much Jenkins is a security hole where you can execute any command. I was tempted to file a bug report against the package because of it. Then I saw #697617 and #700761, then gave up... :) So yeah, Jenkins is nice, but I wouldn't leave it on a public facing internet without any sort of protection (like an htpass over HTTPS). Did anyone try buildbot? It might be better for what I need. I quite disliked the fact that most of Jenkins is done through a web GUI, which was in fact, more a nuisance than anything else. Maybe buildbot would fit my needs better, so I would really appreciate if anyone can share his experience with it. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513b565b.1040...@debian.org
Re: RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-09 23:33:47 +0800 (+0800), Thomas Goirand wrote:
[...]
I also need to understand how to secure Jenkins. Because
by default, it's impressive how much Jenkins is a security
hole where you can execute any command. I was tempted
to file a bug report against the package because of it. Then
I saw #697617 and #700761, then gave up... :)
[...]
Yes, it's a chore to keep up with the security vulnerabilities for
Jenkins, particularly if you're following mainline instead of stable
since updates become a grab bag of (sometimes unintended) API
changes as well as new bugs and regressions. We try to be as
proactive as we can, scrape the security index on their wiki and
just plain shutdown Jenkins services on our servers until we can
validate the security fixes and get them applied in production. It's
not for the faint of heart.
At this point we're close enough to having Jenkins interactions
externally integrated with our other systems that its WebUI isn't
much use except for administrative functions. I expect it's not too
far in the future that we'll be able to lock it down such that only
administrators will have access to that interface.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130309155027.gg29...@yuggoth.org
Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
Hi Daniel et al, I'm also thinking a lot about how to improve Debian by improving our Git tooling. Therefor I'm packaging Gerrit (#589436). But gerrit and its dependencies is a big project... Now that Git slowly becomes the de facto standard VCS for Debian[1] (resistance is futile) it might be time to review our setup and think whether we could improve our Git infrastructure. Should we start a wiki page to collect thoughts? [1] http://www.lucas-nussbaum.net/blog/?p=751 My thoughts are: - I'd like to have support for reviews (e.g Gerrit) - pull requests (e.g Gerrit) - I'd like continuous integration (triggered e.g. by Gerrit[2]) - Easy for anybody to submit patches (e.g Gerrit) - A frontpage that doesn't take ages to load - Easier project creation without the need to SSH into alioth - regular fetching of the upstream branch from upstreams master [2] http://openstack-ci.github.com/publications/ I was also thinking whether Debian should cooperate with other projects so that the workload of maintaining such a setup could be shared. I started to collect candidates for collaboration here: http://wiki.debian.org/Alioth/OtherForges Best regards, Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201303081452.50647.tho...@koch.ro
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-08 14:52:48 +0100 (+0100), Thomas Koch wrote:
[...]
http://openstack-ci.github.com/publications/
[...]
I'm one of the core developers for the team which manages all that
tooling and integration for the OpenStack Project, so I'm happy to
discuss some of the nitty-gritty details, any gotchas/unpleasantness
we experience and how we work around it.
A better starting URL is http://ci.openstack.org/ and we're also
very active on freenode in #openstack-infra for those who desire
more synchronous conversation.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130308143448.gv29...@yuggoth.org
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 03/08/2013 10:34 PM, Jeremy Stanley wrote: On 2013-03-08 14:52:48 +0100 (+0100), Thomas Koch wrote: [...] http://openstack-ci.github.com/publications/ [...] I'm one of the core developers for the team which manages all that tooling and integration for the OpenStack Project, so I'm happy to discuss some of the nitty-gritty details, any gotchas/unpleasantness we experience and how we work around it. A better starting URL is http://ci.openstack.org/ and we're also very active on freenode in #openstack-infra for those who desire more synchronous conversation. I've started copying others, and I now have a a KGB bot, and a Jenkins VM. Now, the only thing I have to do is git push, and here's the result on the #debian-openstack channel: PKG-Openstack python-json-patch thomas debian/experimental * ffa137a debian/ changelog rules PKG-Openstack python-json-patch Now running the unit tests, thanks to Michael Terry mte...@ubuntu.com for the patch (Closes: #702443). [Openstack-Cowbuild] Starting build #2 for job python-json-patch (previous build: SUCCESS) [Openstack-Cowbuild] Project python-json-patch build #2:SUCCESS in 46 sec: https://117.121.243.213/job/python-json-patch/2/ I start to really love the CI thing. I first invested a bit of time in setting-up everything, then it's crazy how much work that saves me, especially with a lot of packages (Openstack and its Python module (build-)dependencies represents nearly 50 source packages now). Once the package is finished building (in a cowbuilder, using git-buildpackage), my script puts it automatically in my private repository, and runs dpkg-scanpackages / dpkg-scansources to keep up-to-date my package repository. I think I'll add piuparts tests as well, and will also run lintian, so it appears in the build log. Jenkins helps being lazy (in the good way). Do a commit, then wait for the result. That's quite cool! Though it took me few days to have this setup. It would be nice to spare all this to other DDs, and have the infrastructure already setup for everyone. Apart from the fact that this kind of tools helps saving a lot of maintainer's time, the Gerrit thing would help giving some more restrictive access. Because for the moment, it's either we give all access, or nothing. Many times, I've granted access to others who, at the end, didn't commit anything. For these, if I had something like Gerrit, I would first ask them to send patches, which wouldn't require a full unix right into /git/openstack, which makes me nervous. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513a1079.8030...@debian.org
RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
I start to really love the CI thing. I first invested a bit of time in setting-up everything, do you have a step by step cookbook for your setup. Maybe on the debian wiki ? Cheers Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a2a20ec3b8560d408356cac2fc148e5358e63...@sun-dag1.synchrotron-soleil.fr
Re: RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 08/03/2013 17:36, PICCA Frédéric-Emmanuel wrote: I start to really love the CI thing. I first invested a bit of time in setting-up everything, do you have a step by step cookbook for your setup. Maybe on the debian wiki ? I love what Michael Prokop did and documented here: http://jenkins-debian-glue.org/ Jenkins + Debian packaging using cowbuilder The code is very clean and easy to hack. Sylvestre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513a186b.5000...@debian.org
RE : RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
I love what Michael Prokop did and documented here: http://jenkins-debian-glue.org/ Jenkins + Debian packaging using cowbuilder The code is very clean and easy to hack. Thanks, yes it looks great. Cheers Fred -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a2a20ec3b8560d408356cac2fc148e5358e63...@sun-dag1.synchrotron-soleil.fr
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
Thomas Koch tho...@koch.ro writes: I'm also thinking a lot about how to improve Debian by improving our Git tooling. Therefor I'm packaging Gerrit (#589436). But gerrit and its dependencies is a big project... Thank you very much for working on this! We use Gerrit extensively but so far just haven't packaged it because it was too intimidating. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obetliyz@windlord.stanford.edu
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-08 12:44:36 -0800 (-0800), Russ Allbery wrote:
Thank you very much for working on this! We use Gerrit extensively but so
far just haven't packaged it because it was too intimidating.
Agreed, if Gerrit gets packaged in Debian/Ubuntu I'll likely push
OpenStack to start using DEBs of it on our CI infrastructure (though
chances are we'll still rebuild from the source package because we
carry patches for features in which Google has thus far been wholly
disinterested).
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130308215201.gb29...@yuggoth.org
Re: git dangerous operations on alioth
On Mon, Mar 04, 2013 at 12:45:14AM +0800, Paul Wise wrote:
On Sun, Mar 3, 2013 at 11:21 PM, Thomas Goirand wrote:
So yes, I would think having a safe, backup of Alioth is important.
Now, what worries me is that I didn't read any of the Alioth admins
explaining what is currently in production. I've searched, and the
only info I found was hosted projects on alioth.d.o (like pkg-bacula,
slbackup, etc.), but so far, no info on how Alioth is backed-up. Did
I miss the obvious?
Take a look at /etc/da-backup*, alioth is backed up to backup.d.o like
all debian.org hosts.
public_{git,bzr} etc. are not backed up, though, as the references from
/git are not resolved to their content. (I.e. rsync's -L is not used
on the repository directories.)
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Re: git dangerous operations on alioth
On 03/03/2013 12:51 AM, Wouter Verhelst wrote: On Thu, Feb 28, 2013 at 11:07:22AM +0100, Stefano Zacchiroli wrote: On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) real men don't take backups. They just put their stuff on a public FTP server and let the world mirror. Every user who has a checkout of a git repository is making backups... If Alioth was to fail and loose all repository data, I would have a real hard time to collect all local copies, with the latest version given a specific branch, being stored in one of the 3 machines I do Debian packaging on. It would take me literally days to find out on which of these computers I made the latest commit (I generally don't care, Git always yell^Wtell if I don't have a fast-forward copy anyway). I also read that others have the habit to *not* store a local copy of the packages they work on. Once the commit is done, they just delete the local copy. That's not my workflow, but I can understand why doing that. So yes, I would think having a safe, backup of Alioth is important. Now, what worries me is that I didn't read any of the Alioth admins explaining what is currently in production. I've searched, and the only info I found was hosted projects on alioth.d.o (like pkg-bacula, slbackup, etc.), but so far, no info on how Alioth is backed-up. Did I miss the obvious? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51336a5c.9090...@debian.org
Re: git dangerous operations on alioth
On 03/01/2013 02:20 AM, Daniel Pocock wrote: 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. As already stated by someone else, something like Gerrit would do what you ask for above. If anyone from the fusionforge project feels like integrating with Gerrit (or anything of the same kind which can have some kind of review- before-merge feature) that'd be really nice. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51336b5e.7050...@debian.org
Re: git dangerous operations on alioth
On Sun, Mar 3, 2013 at 11:21 PM, Thomas Goirand wrote: So yes, I would think having a safe, backup of Alioth is important. Now, what worries me is that I didn't read any of the Alioth admins explaining what is currently in production. I've searched, and the only info I found was hosted projects on alioth.d.o (like pkg-bacula, slbackup, etc.), but so far, no info on how Alioth is backed-up. Did I miss the obvious? Take a look at /etc/da-backup*, alioth is backed up to backup.d.o like all debian.org hosts. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6HhDOGZhqDYY3hE7Ehdrtjhe_5G0=2ww_rwt-wh6lg...@mail.gmail.com
Re: git dangerous operations on alioth
On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote: There was recently some discussion in pkg-javascript about how to give more people access to the VCS (e.g. keeping the git repositories logically organised under the pkg-javascript tree, but making write access available to all DDs + alioth guest users and not just those in the pkg-javascript UNIX group) I generally agree with the principle of giving more people access, but git access is `all or nothing'. This is not just true for alioth, it is much the same with github hosting and many others. Has anybody had experience controlling access to git repositories, for example, to give users access but prevent some of the following dangerous operations? - prevent users pushing with the `--force' option (from the man page for git-push: This can cause the remote repository to lose commits; use it with care.) --force is a unshoot your foot option. It's meant for situations where you have a set of commits pushed to a repository where you go oops, those shouldn't have been published, let's fix that. If you force a commit, they're not actually lost (you can find them with git fsck), but they'll no longer be part of your git history. It can be switched off by enabling the receive.denyNonFastForwards option on the server; but usually you don't want it disabled, unless you have a repository that's read by a *lot* of people whom you may not be able to reach. - ensure that users only push commits authored by themselves (email address white list) Why oh why would you want to do that? Git is a distributed version control system; that means pushing commits which originate from someone else than yourself should be the rule, not the exception. - prevent some users pushing tags (or only allow tags matching a pattern) You'll need to use a hook script for that, I suppose. Github partially works around this issue by providing a convenient web UI for managing pull requests: so you simply don't give people access to do any commits at all, and you manually review each of their changes, although it only requires a couple of mouse clicks to accept each patch. All github does is provide a web UI around what really already exists in git itself. I personally don't actually like github's patch merge infrastructure, to be honest. It sounds to me like you're approaching git like it's a centralized version control system. It isn't. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302164951.gm5...@grep.be
Re: git dangerous operations on alioth
On Thu, Feb 28, 2013 at 11:07:22AM +0100, Stefano Zacchiroli wrote: On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) real men don't take backups. They just put their stuff on a public FTP server and let the world mirror. Every user who has a checkout of a git repository is making backups... -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302165130.gn5...@grep.be
Re: git dangerous operations on alioth
On Donnerstag, 28. Februar 2013, Holger Levsen wrote: signed commits, so you can identify unwanted bits and clean up in the very care case that's actually needed? ^^ rare case -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130308.35957.hol...@layer-acht.org
Re: git dangerous operations on alioth
On 02/28/2013 08:33 PM, Andrew Shadura wrote: we'd have both hg and git in one unified interface. That is a very nice feature. I saw few sites having that, for example bitbucket, unfortunatley, bitbucket doesn't allow git anonymous checkout over http (it's only available with hg, if I understood well). Or is there a hidden URL that I didn't find? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51308793.4080...@debian.org
Re: git dangerous operations on alioth
On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote: On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) Do we have a backup at all? If so, how often is the backup made, and how much days of history do we have? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513088de.5070...@debian.org
Re: git dangerous operations on alioth
On 1 March 2013 10:54, Thomas Goirand z...@debian.org wrote: On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote: On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) Do we have a backup at all? If so, how often is the backup made, and how much days of history do we have? A backup of a git repository is a mirror that constantly does fetch and never performs garbage collection. In addition copying across push reflog and even keeping it committed into git as welll makes sense, this way one can establish when / what / how the repository got updated with broken changes. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUiRM1B9fji2=gqk8fhfvrzrk8wbryqvv4outwgkpby...@mail.gmail.com
Re: git dangerous operations on alioth
On 03/01/2013 07:21 PM, Dmitrijs Ledkovs wrote: On 1 March 2013 10:54, Thomas Goirand z...@debian.org wrote: On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote: On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) Do we have a backup at all? If so, how often is the backup made, and how much days of history do we have? A backup of a git repository is a mirror that constantly does fetch and never performs garbage collection. I wasn't discussing what can be done for backing up a Git repository, I was asking what is *currently installed* in production as a backup for Alioth. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5130ab96.7080...@debian.org
Re: git dangerous operations on alioth
Thomas Goirand z...@debian.org (01/03/2013): I wasn't discussing what can be done for backing up a Git repository, I was asking what is *currently installed* in production as a backup for Alioth. Why are you asking debian-devel@ instead of asking the actual admins? (http://wiki.debian.org/Alioth#Maintenance) Mraw, KiBi. signature.asc Description: Digital signature
Re: git dangerous operations on alioth
On 03/01/2013 09:34 PM, Cyril Brulebois wrote: Thomas Goirand z...@debian.org (01/03/2013): I wasn't discussing what can be done for backing up a Git repository, I was asking what is *currently installed* in production as a backup for Alioth. Why are you asking debian-devel@ instead of asking the actual admins? Because I'm quite sure I wont be the only one interested by the answer. Though, if you think I should have Cc: ad...@alioth.debian.org, well, here you are... Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5130c163.7040...@debian.org
Re: git dangerous operations on alioth
Hello, On Fri, 01 Mar 2013 18:48:51 +0800 Thomas Goirand z...@debian.org wrote: On 02/28/2013 08:33 PM, Andrew Shadura wrote: we'd have both hg and git in one unified interface. That is a very nice feature. I saw few sites having that, for example bitbucket, unfortunatley, bitbucket doesn't allow git anonymous checkout over http (it's only available with hg, if I understood well). Or is there a hidden URL that I didn't find? Seriously, I've never tried bitbucket with git. Actually, what I usually do is exactly other way around: I use github with hg. -- WBR, Andrew signature.asc Description: PGP signature
git dangerous operations on alioth
There was recently some discussion in pkg-javascript about how to give more people access to the VCS (e.g. keeping the git repositories logically organised under the pkg-javascript tree, but making write access available to all DDs + alioth guest users and not just those in the pkg-javascript UNIX group) I generally agree with the principle of giving more people access, but git access is `all or nothing'. This is not just true for alioth, it is much the same with github hosting and many others. Has anybody had experience controlling access to git repositories, for example, to give users access but prevent some of the following dangerous operations? - prevent users pushing with the `--force' option (from the man page for git-push: This can cause the remote repository to lose commits; use it with care.) - ensure that users only push commits authored by themselves (email address white list) - prevent some users pushing tags (or only allow tags matching a pattern) Github partially works around this issue by providing a convenient web UI for managing pull requests: so you simply don't give people access to do any commits at all, and you manually review each of their changes, although it only requires a couple of mouse clicks to accept each patch. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512f25ce.6060...@pocock.com.au
Re: git dangerous operations on alioth
]] Daniel Pocock Has anybody had experience controlling access to git repositories, for example, to give users access but prevent some of the following dangerous operations? - prevent users pushing with the `--force' option (from the man page for git-push: This can cause the remote repository to lose commits; use it with care.) You can enable denyFastForward in the config and enable reflogs, that should help with this. - ensure that users only push commits authored by themselves (email address white list) A hook should be able to do this. - prevent some users pushing tags (or only allow tags matching a pattern) You can do this with a hook as well. I'm using gitano (not packaged) for this on my own setup, it has a set of ACLs that gets run. I think gitolite is able to do it as well, so maybe take a look at whether that does what you want? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ngw7ow0@qurzaw.varnish-software.com
Re: git dangerous operations on alioth
On 28 February 2013 09:39, Daniel Pocock dan...@pocock.com.au wrote: There was recently some discussion in pkg-javascript about how to give more people access to the VCS (e.g. keeping the git repositories logically organised under the pkg-javascript tree, but making write access available to all DDs + alioth guest users and not just those in the pkg-javascript UNIX group) I generally agree with the principle of giving more people access, but git access is `all or nothing'. This is not just true for alioth, it is much the same with github hosting and many others. Has anybody had experience controlling access to git repositories, for example, to give users access but prevent some of the following dangerous operations? - prevent users pushing with the `--force' option (from the man page for git-push: This can cause the remote repository to lose commits; use it with care.) Alternatively gerrit and gitolite can limit that. - ensure that users only push commits authored by themselves (email address white list) gerrit does this out of the box as well. But I do limit use in this. If i merge a patch from my friend, why can't I push it into the repository? I'd rather also look for Sign-off-by lines as well. - prevent some users pushing tags (or only allow tags matching a pattern) gitolite / gerrit can do that. Github partially works around this issue by providing a convenient web UI for managing pull requests: so you simply don't give people access to do any commits at all, and you manually review each of their changes, although it only requires a couple of mouse clicks to accept each patch. Gerrit can provide both web email interface to merge / review patches. It is used by projects like android and libreoffice to process a high velocity stream of incoming patches. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUg2PwR9HWZsBuUrcjTae+p7_Vh6vF=bKiDR070B1y=d...@mail.gmail.com
Re: git dangerous operations on alioth
On Thu, Feb 28, 2013 at 10:45:35AM +0100, Tollef Fog Heen wrote: Has anybody had experience controlling access to git repositories, for example, to give users access but prevent some of the following dangerous operations? - prevent users pushing with the `--force' option (from the man page for git-push: This can cause the remote repository to lose commits; use it with care.) You can enable denyFastForward in the config and enable reflogs, that should help with this. What about `push :branch` ? -- WBR, wRAR signature.asc Description: Digital signature
Re: git dangerous operations on alioth
On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) FWIW, I'm a happy gitolite user on my own sever and it can be used to do rather fine grained access control. But integrating it with alioth is not necessarily trivial, considered that we will have to have per-project gitolite configurations. If someone ends up doing that, please take the time to write down some tutorial/best-practice for alioth integration. It would be *much* appreciated. ... and thanks for raising the topic, Daniel! Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: git dangerous operations on alioth
Hi, On 28.02.2013 11:07, Stefano Zacchiroli wrote: On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) The obvious solution would be to deny people accessing your repository in unwanted ways. The current Alioth ACLs do not really allow this so we have to trust people. Personally I do host almost all my packages in collab-maint and contrary to common belief, I only made good experiences with it. This is more of a hypothetical discussion therefore. Having that said the risk is real and it may be time to reconsider some choices including the use of Alioth itself for those who do not believe in openness. Chances are #700630 is going to rescue us all on that. Maybe we could set-up our own gitorious instance once the stuff is packaged. I at least am very interested in such a Debian service and might even set one up. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: git dangerous operations on alioth
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? Do you consider this to be a strong security measure against malicious changes, or a weak safety measure against accidents? As a security measure, it's basically not going to work as long as users have unrestricted Unix write access to the git repository: anything you set up can be circumvented (at worst, by rm -rf all subdirectories and replace them). I suspect that only a system like Gitorious or Gerrit, where the repository is owned by a dedicated uid and individual users don't have +w, can give you that. As a safety measure against accidents, how far do you need/want to go? As Tollef and Andrey mentioned, denying non-fast-forward pushes protects you from most accidents; it can be circumvented by a sufficiently determined committer, but perhaps don't do that, then. 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. See also http://joeyh.name/blog/entry/ending_the_tyranny_of_unix_permissions/ for an interesting viewpoint on this. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512f4a5b.7060...@debian.org
Re: git dangerous operations on alioth
Hello. On 28 February 2013 12:51, Arno Töll a...@debian.org wrote: Having that said the risk is real and it may be time to reconsider some choices including the use of Alioth itself for those who do not believe in openness. Chances are #700630 is going to rescue us all on that. Maybe we could set-up our own gitorious instance once the stuff is packaged. I at least am very interested in such a Debian service and might even set one up. On this regard, I propose to wait till I finish packaging Rhodecode, and install it, as then we'd have both hg and git in one unified interface. -- WBR, Andrew -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/camb-mazovq1vgal1zpcujg4zsb_cvsmauaz-+u+sf7-xzf9...@mail.gmail.com
Re: git dangerous operations on alioth
On Thu, 28 Feb 2013 12:51:33 +0100, Arno Töll wrote: On 28.02.2013 11:07, Stefano Zacchiroli wrote: On Thu, Feb 28, 2013 at 10:39:26AM +0100, 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? I think the interesting (non-technical) first question is why this would be needed. Related to this, there is also the risk that a user will ssh on alioth and rm the repository (accidentally or not). Do we have any kind of protection against that? (e.g. backups we can access to without bothering the alioth admins, or a way to give git access but not ssh access, or...) At least for pkg-perl I'm quite confident that someone would just push their locally cloned repo back to Alioth in case it was deleted there accidentally. Personally I do host almost all my packages in collab-maint and contrary to common belief, I only made good experiences with it. This is more of a hypothetical discussion therefore. Ack. Again from my pkg-perl experience: Since before I joined all DDs have commit access and we hand out group membership/commit bits quite liberally to non-DDs. I don't remember any malicious action and the few accidents are just minor annoyances that are quickly fixed after the fact. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Kurt Ostbahn Die Kombo: (Heit loss i) Anschreibm signature.asc Description: Digital signature
Re: git dangerous operations on alioth
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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512f9fd9.5080...@pocock.com.au
Re: git dangerous operations on alioth
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. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
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- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512fc0c6.50...@pocock.com.au
Re: git dangerous operations on alioth
On Thu, Feb 28, 2013 at 04:01:34PM +0600, Andrey Rahmatullin wrote: On Thu, Feb 28, 2013 at 10:45:35AM +0100, Tollef Fog Heen wrote: Has anybody had experience controlling access to git repositories, for example, to give users access but prevent some of the following dangerous operations? - prevent users pushing with the `--force' option (from the man page for git-push: This can cause the remote repository to lose commits; use it with care.) You can enable denyFastForward in the config and enable reflogs, that should help with this. What about `push :branch` ? »man git-config« isn't that hard: receive.denyDeletes If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to prevent such a ref deletion via a push. Also I think Tollef meant receive.denyNonFastForwards. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: git dangerous operations on alioth
Hi, signed commits, so you can identify unwanted bits and clean up in the very care case that's actually needed? cheer,s Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201302282241.50840.hol...@layer-acht.org
Re: git dangerous operations on alioth
On Thu, 28 Feb 2013, Holger Levsen wrote: signed commits, so you can identify unwanted bits and clean up in the very care case that's actually needed? Indeed. Secure git workflows are possible, although it is a relatively new development. Signed commits and pull requests are a very big part of such workflows... http://mikegerwitz.com/docs/git-horror-story.html -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301004920.ga7...@khazad-dum.debian.net
