Feature #1707
Git support
100%
Description
First of all thanks to Bertrand Baudinet for his great patch adding Git support to the plugin!
I believe adding other repositories support is a very cool feature! However this changes much and I have some "items" to think:- The plugin name is to be changed perhaps (including, of course, description);
- File
subversion.ymlshould support configuration for different repositories, e.g.:production: svnpath: /var/lib/svn svnadmin: /usr/bin/svnadmin gitpath: /var/lib/git git: /usr/bin/git
This way the plugin will allow to “manage” several repositories on the same installation... - Configuration class
SvnConfigshould be renamed (again)?
History
#1
Updated by Andriy Lesyuk over 13 years ago
Updated by - Target version set to 0.1.0
- % Done changed from 0 to 40
#2
Updated by Andriy Lesyuk over 13 years ago
- File deleted (
add_git_support.diff)
#3
Updated by Andriy Lesyuk over 13 years ago
- Status changed from Open to In Progress
#4
Updated by Andriy Lesyuk over 13 years ago
Maybe even so:
production:
svn:
path: /var/lib/svn
svnadmin: /usr/bin/svnadmin
git:
path: /var/lib/git
git: /usr/bin/git
#5
Updated by Andriy Lesyuk over 13 years ago
- Due date set to 28 May 2011
- % Done changed from 40 to 100
It would be great if someone tested this...
#6
Updated by Jean-Sébastien Bour over 13 years ago
Updated by No real problem here; “destroy” doesn’t destroy the repository but it’s not related to git, it just doesn’t look implemented yet
We have a problem with file permissions on disk, but it’s related to Ruby people who seem to think that it’s cool to put “File.umask 0000 # Insure sensible umask” all around daemonize.rb, because security is for boring people I guess I think I’ll add a “chmod o-a” after the system call to git
#7
Updated by Andriy Lesyuk over 13 years ago
No real problem here; “destroy” doesn’t destroy the repository but it’s not related to git, it just doesn’t look implemented yet
I guess this is going to remain this way... Destroying just a repository in Redmine is one thing and destroying the repo itself... not sure if this is good/wanted. Let it be “backup”...
We have a problem with file permissions on disk, but it’s related to Ruby people who seem to think that it’s cool to put “File.umask 0000 # Insure sensible umask” all around daemonize.rb, because security is for boring people I guess I think I’ll add a “chmod o-a” after the system call to git
This is interesting! Bertrand used chmod (or maybe chown - don’t remembder) also... When I tested I figured out that chmod is not needed. Where did you find this line?
#8
Updated by Jean-Sébastien Bour over 13 years ago
Andriy Lesyuk wrote:
No real problem here; “destroy” doesn’t destroy the repository but it’s not related to git, it just doesn’t look implemented yet
I guess this is going to remain this way... Destroying just a repository in Redmine is one thing and destroying the repo itself... not sure if this is good/wanted. Let it be “backup”...
Indeed. However I thought about this from a “use auto_* features and let the machine handle EVERYTHING” point of view. And remember I speak on git fans behalf, so who really cares about the “server” repository when everyone has a copy?
This is interesting! Bertrand used
chmod(or maybechown- don’t remembder) also... When I tested I figured out that chmod is not needed. Where did you find this line?
~# grep -hn umask /usr/lib/ruby/gems/1.8/gems/daemons-1.0.10/lib/daemons/daemonize.rb 119: File.umask 0000 # Insure sensible umask 176: File.umask 0000 # Insure sensible umask 219: File.umask 0000 # Insure sensible umask
and umask command ran from a shell with our redmine system account outputs 0022, while ran from a system() call I added in a Redmine controller just to see, outputs 0000...
It ends up with a repo full of files with 777 UNIX rights, which is not a real huge security flaw ATM since we use group-shared git repos and everyone is in the dev group (or, just doesn’t have access to the server), but in other situations it might...
#9
Updated by Andriy Lesyuk over 13 years ago
- Status changed from In Progress to Closed
Jean-Sébastien Bour wrote:
Indeed. However I thought about this from a “use
auto_*features and let the machine handle EVERYTHING” point of view. And remember I speak on git fans behalf, so who really cares about the “server” repository when everyone has a copy?
Created issue #1770... This means that perhaps I will implement this in future...
It ends up with a repo full of files with 777 UNIX rights, which is not a real huge security flaw ATM since we use group-shared git repos and everyone is in the dev group (or, just doesn’t have access to the server), but in other situations it might...
This can be (and perhaps should be) solved by setting the correct umask or whatever somewhere else (e.g. in system - I don’t know). I have access to several Redmine installation using different distros and did not see such permission issue... What makes me think this is an issue not related to the plugin but to the system (even if you solve this in plugin you potentially have a security “bug” which can lead to 777 files created by other applications)!
#10
Updated by Jean-Sébastien Bour over 13 years ago
I can confirm this umask problem is not a bug in the system, we have a 0022 umask set at system level, and the Redmine system user creates files with correct permissions from the shell for example. This 0000 umask is clearly set by the ruby daemonize library. Maybe you don’t have a setup with this particular version and they fixed it?
However it is indeed not a problem in your plugin.
#11
Updated by Andriy Lesyuk over 13 years ago
This 0000 umask is clearly set by the ruby daemonize library. Maybe you don’t have a setup with this particular version and they fixed it?
I’m using Redmine from Debian repository... I guess Debian package maintainer fixed it.