laserlight;11045865 wrote:

A straightforward way to compare two strings for equality is to compare the characters pairwise. The moment a character pair fails to match, you can return false. This is efficient, but the problem is that it leaks information: if an attacker supplies a string that happens to start with a long common prefix as the other string (the "known string"), it will take longer to compare than if the attacker supplies a string that starts with a different character, even though the strings are of the same length, hence based on timing the attacker can guess that he/she is coming closer to success. hash_equals confounds such a timing attack by ensuring that the comparison of strings of equal length take the same amount of time regardless of their contents.

This is a great explanation laserlight!

    Derokorian;11045867 wrote:

    This is a great explanation laserlight!

    I second that.

      I am having a different problem now. For some reason, actual push payloads from the github webhook seem to lack the X-Hub-Signature that it's supposed send so that you can verify the veracity of the post before attempting to act on it. Am I missing something? This seems to have worked just fine when I was just specifying HTTP urls to github for the webhook.

      The contents of $_SERVER var in PHP (with some values redacted)

          [REDIRECT_UNIQUE_ID] => VQDg-8d0nQsCl2os4xeJVwAAAAY
          [REDIRECT_HTTPS] => on
          [REDIRECT_SSL_TLS_SNI] => example.com
          [REDIRECT_STATUS] => 200
          [UNIQUE_ID] => VQDg-8d0nQsCl2os4xeJVwAAAAY
          [HTTPS] => on
          [SSL_TLS_SNI] => example.com
          [SSL_SERVER_S_DN_C] => --
          [SSL_SERVER_S_DN_ST] => SomeState
          [SSL_SERVER_S_DN_L] => SomeCity
          [SSL_SERVER_S_DN_O] => SomeOrganization
          [SSL_SERVER_S_DN_OU] => SomeOrganizationalUnit
          [SSL_SERVER_S_DN_CN] => example-dev
          [SSL_SERVER_S_DN_Email] => root@example-dev
          [SSL_SERVER_I_DN_C] => --
          [SSL_SERVER_I_DN_ST] => SomeState
          [SSL_SERVER_I_DN_L] => SomeCity
          [SSL_SERVER_I_DN_O] => SomeOrganization
          [SSL_SERVER_I_DN_OU] => SomeOrganizationalUnit
          [SSL_SERVER_I_DN_CN] => example-dev
          [SSL_SERVER_I_DN_Email] => root@example-dev
          [SSL_VERSION_INTERFACE] => mod_ssl/2.4.6
          [SSL_VERSION_LIBRARY] => OpenSSL/1.0.1e-fips
          [SSL_PROTOCOL] => TLSv1.2
          [SSL_SECURE_RENEG] => true
          [SSL_COMPRESS_METHOD] => NULL
          [SSL_CIPHER] => ECDHE-RSA-AES128-GCM-SHA256
          [SSL_CIPHER_EXPORT] => false
          [SSL_CIPHER_USEKEYSIZE] => 128
          [SSL_CIPHER_ALGKEYSIZE] => 128
          [SSL_CLIENT_VERIFY] => NONE
          [SSL_SERVER_M_VERSION] => 3
          [SSL_SERVER_M_SERIAL] => 26F3
          [SSL_SERVER_V_START] => Mar  2 22:09:15 2015 GMT
          [SSL_SERVER_V_END] => Mar  1 22:09:15 2016 GMT
          [SSL_SERVER_S_DN] => emailAddress=root@example-dev,CN=example-dev,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--
          [SSL_SERVER_I_DN] => emailAddress=root@example-dev,CN=example-dev,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--
          [SSL_SERVER_A_KEY] => rsaEncryption
          [SSL_SERVER_A_SIG] => sha256WithRSAEncryption
          [SSL_SESSION_ID] => fb9920c7005b2dacd421b2a9b4383ad2228087762734af2a2941b4334e74674e
          [SSL_SESSION_RESUMED] => Initial
          [HTTP_HOST] => example.com
          [HTTP_ACCEPT] => */*
          [HTTP_USER_AGENT] => GitHub-Hookshot/d5562c3
          [HTTP_X_GITHUB_EVENT] => push
          [HTTP_X_GITHUB_DELIVERY] => af2f2980-c850-11e4-8d23-c8ffead6c718
          [CONTENT_TYPE] => application/json
          [CONTENT_LENGTH] => 16698
          [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
          [SERVER_SIGNATURE] => 
          [SERVER_SOFTWARE] => Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
          [SERVER_NAME] => example.com
          [SERVER_ADDR] => 11.22.33.44
          [SERVER_PORT] => 443
          [REMOTE_ADDR] => 192.30.252.46
          [DOCUMENT_ROOT] => /var/www/html
          [REQUEST_SCHEME] => https
          [CONTEXT_PREFIX] => 
          [CONTEXT_DOCUMENT_ROOT] => /var/www/html
          [SERVER_ADMIN] => root@localhost
          [SCRIPT_FILENAME] => /var/www/html/index.php
          [REMOTE_PORT] => 37657
          [REDIRECT_URL] => /git/push_hook
          [GATEWAY_INTERFACE] => CGI/1.1
          [SERVER_PROTOCOL] => HTTP/1.1
          [REQUEST_METHOD] => POST
          [QUERY_STRING] => 
          [REQUEST_URI] => /git/push_hook
          [SCRIPT_NAME] => /index.php
          [PATH_INFO] => /git/push_hook
          [PATH_TRANSLATED] => redirect:/index.php/git/push_hook/push_hook
          [PHP_SELF] => /index.php/git/push_hook
          [REQUEST_TIME_FLOAT] => 1426120959.894
          [REQUEST_TIME] => 1426120959
      
        Derokorian;11045943 wrote:

        Looking at https://developer.github.com/webhooks/#example-delivery I don't see any X-Hub-Signature. I do see where it says "HMAC hex digest of the payload, using the hook’s secret as the key (if configured)." so maybe its not configured?

        Apparently this was the problem. I had asked a collaborator to do it for me and neglected to explain that we need a secret phrase. He added it and the signatures are validating properly.

        Now I have a different problem. For some reason Apache is having trouble executing the git pull command. Here's my function (part of a CodeIgniter method):

        	public function git_pull() {
        		$this->gitlog->write("PREPARING TO RUN GIT PULL");
        
        	// this is a temporary command for testing
        	$cmd = "sudo /usr/bin/git -C /home/sneakyimp/git-test pull";
        	$this->gitlog->write("cmd:\n" . $cmd);
        	$output = NULL;
        	$return_var = NULL;
        	exec($cmd, $output, $return_var);
        	if ($return_var) {
        		// uh oh
        		$this->gitlog->write("ERROR!!!  Git-pull script returned non-empty value: " . $return_var);
        	}
        	$this->gitlog->write("===== GIT PULL OUTPUT =====");
        	$this->gitlog->write(implode(PHP_EOL, $output));
        	$this->gitlog->write("===== END GIT PULL OUTPUT =====");
        }

        Here's the output in the log file:

        [2015-03-12 12:26:12] - PREPARING TO RUN GIT PULL
        [2015-03-12 12:26:12] - cmd:
        sudo /usr/bin/git -C /home/sneakyimp/git-test pull
        [2015-03-12 12:26:12] - ERROR!!!  Git-pull script returned non-empty value: 1
        [2015-03-12 12:26:12] - ===== GIT PULL OUTPUT =====
        [2015-03-12 12:26:12] - 
        [2015-03-12 12:26:12] - ===== END GIT PULL OUTPUT =====
        

        I'm not sure what the problem is. And it's REALLY ANNOYING that I don't get any kind of error message in the output. This is in the sudoers file:

        apache ALL=(ALL) NOPASSWD: /usr/bin/git -C /home/sneakyimp/git-test pull
        

        And this command works absolutely fine when I type it from the command line:

        sudo -Hu apache sudo /usr/bin/git -C /home/sneakyimp/git-test pull

        Any hints would be welcome. I'm not really sure how I'm going to solve this problem 🙁

          OK I'm not certain yet but apparently the problem was requiretty in the sudoers file. This requirement says the sudo privileges granted in sudoers only apply if there is an actual user logged in from an actual terminal. Following the instructions here, I have tried to remove that requirement for this one command:

          Cmnd_Alias GITPULL = /usr/bin/git -C /home/sneakyimp/git-test pull
          apache ALL=(ALL) NOPASSWD: GITPULL
          Defaults!GITPULL !requiretty
          

            OK this is basically working (PHEW!).

            However, I need to make sure the permissions on the server are set a certain way. If my collaborators get sloppy with their permissions (e.g., set a file 644 instead of 664) then it can introduce a situation where the git-pull command does not work because permissions of files in the web root do not match those in the git repo. In this case, git will refuse to pull, complaining about fast forward, etc.

            I was considering calling a git checkout first on the server before doing the git pull -- this would have the effect of temporarily rolling back any changes before performing the git pull. It works pretty well EXCEPT if some file exists on the server and someone has checked in a file with that same name into the repository.

            For example, on the web server:

            # this is my git working directory
            cd /var/www
            # assume this works just fine
            git pull
            # create a file called foo.txt on the server
            touch foo.txt
            

            The problem now is that if someone checks a file called foo.txt into the repo then the git pull won't work next time. Running a git checkout first doesn't help because this doesn't delete foo.txt.

            Can anyone suggest a more thorough/forceful way to make sure the git pull works every time but that isn't too drastic? For example, I don't want to oblierate the entire directory and clone it again. I also don't want to download every single file every time. Just the changed ones, please!

              sneakyimp wrote:

              It works pretty well EXCEPT if some file exists on the server and someone has checked in a file with that same name into the repository.

              This should not be allowed, unless that file has a name with a pattern listed in .gitignore.

              sneakyimp wrote:

              The problem now is that if someone checks a file called foo.txt into the repo then the git pull won't work next time. Running a git checkout first doesn't help because this doesn't delete foo.txt.

              Suppose running git checkout did delete foo.txt, and there was some critical script that depended on foo.txt containing the data that it contained, whereas the new foo.txt has completely different data. BOOM! Rather, foo.txt should have been under version control to begin with, in which case when you wanted to have your own foo.txt, the conflict would have been detected long before the server got involved. The git pull failing to work is the right behaviour here. The wrong behaviour is the creation of foo.txt on the server outside of version control, despite being within the working tree.

              Likewise, git checkout should be unnecessary since developers should not be updating the files in the working tree directly on the server.

                24 days later
                laserlight;11046053 wrote:

                This should not be allowed, unless that file has a name with a pattern listed in .gitignore.

                I've indicated to my collaborator that directly uploading files to the machine generally mustn't be done (except files in the .gitignore as you say...local config files and such), but I expect at some point that someone will break the rule and this will prevent the git pull.

                laserlight;11046053 wrote:

                Suppose running git checkout did delete foo.txt, and there was some critical script that depended on foo.txt containing the data that it contained, whereas the new foo.txt has completely different data. BOOM! Rather, foo.txt should have been under version control to begin with, in which case when you wanted to have your own foo.txt, the conflict would have been detected long before the server got involved. The git pull failing to work is the right behaviour here. The wrong behaviour is the creation of foo.txt on the server outside of version control, despite being within the working tree.

                I'm inclined to agree with you. Things seem to be working at the moment so hopefully everyone will behave.

                laserlight;11046053 wrote:

                Likewise, git checkout should be unnecessary since developers should not be updating the files in the working tree directly on the server.

                The issue here that most concerns me is that I run a script as part of my commit hook that sets permissions on various files. Log files must be writable, for instance, so I run a shell script to make sure that the log file directories are writable by apache. This script also takes care to make sure that the files in my web root are not owned/writable by apache unless they are log files. Remember that the operation to pull from the repo is triggered by github pinging a PHP script hosted by the web server. I consider it a security risk to let apache have write access to all of my source code. The permission-setting script runs as root (it is the ONLY thing apache can do as root thanks to sudoers file).

                #!/bin/bash
                # cd to parent directory of this script
                echo "running permission.sh"
                DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
                echo "script is in $DIR"
                cd "$DIR/.."
                echo "current working directory:"
                pwd
                
                
                # TODO - shouldn't really do this, it changes .htpasswd makes it readable by apache, however briefly :(
                # not a big deal but would be nice to avoid changing perms on .htpasswd
                echo "chowning all files"
                chown -R repository_user:dev_user_group /var/www
                echo "chmodding all directories"
                find . -type d -exec chmod 775 {} \;
                echo "chmodding all files"
                find . -type f -exec chmod 664 {} \;
                
                # set 'sticky' bit on directories so that newly created files inherit group
                echo "setting sticky bit on all directories"
                find . -type d -exec chmod g+xs {} \;
                
                # make sure htpasswd only editable by root
                echo "protecting htpasswd"
                chown root:root ./.htpasswd
                chmod 644 ./.htpasswd
                
                # make sure apache can write our VLNT log directory
                echo "setting write permissions on log dir"
                chown -R apache:dev_user_group ./vlnt_logs
                
                # make sure permissions script is executable
                echo "setting +x on shell scripts"
                chmod -R 774 ./shell-scripts
                
                echo "permission.sh complete"
                

                Also, I ran across this article on setting up a private git repo which looks pretty cool:
                http://joemaller.com/990/a-web-focused-git-workflow/

                  sneakyimp;11046803 wrote:

                  I've indicated to my collaborator that directly uploading files to the machine generally mustn't be done (except files in the .gitignore as you say...local config files and such), but I expect at some point that someone will break the rule and this will prevent the git pull.

                  It will only prevent the pull if the commit(s) being pulled change the same file(s) changed locally. For example, I've changed my .htaccess on my server for an app, because it needs to be different than in the repo. Yet I can continue to pull changes unless I push a change to .htaccess.

                  As for the other things, consider a deploy script, to move the files from where the repo is downloaded to where they are served from. This way, you're not making changes to the files where git cares. That way, changing things for security reasons doesn't prevent using git for updating those files. This is what I use, if it helps (you'd need to add permissions of course):

                  #!/bin/bash
                  DEPLOY_DIR="/path/to/application/apache/root/"
                  
                  #copy files, but preserve local .htacess
                  rsync -rv --exclude-from=server/rsync_exclude.txt . ${DEPLOY_DIR}
                  
                  # build js
                  r.js -o public/scripts/build.js
                  mv public/scripts/main-build.js ${DEPLOY_DIR}public/scripts
                  
                  # build css
                  for file in `find public/styles -type f`
                  do
                      cat ${file} >> ${DEPLOY_DIR}public/styles/main-build.css
                  done
                  
                  # Remove ResourceManage entries for scripts and styles, replay with a tag for our build files from above
                  sed -e 's/.*AddScript.*//g' \
                      -e 's#.*LoadScript.*#<script type="text/javascript" src="{Config>GetValue(website,site_url)}scripts/main-build.js"></script>#' \
                      -e 's/.*AddStyle.*//g' \
                      -e 's#.*LoadStyle.*#<link rel="stylesheet" type="text/css" href="{Config>GetValue(website,site_url)}styles/main-build.css">#' \
                      -e '/^\s*$/d' -i /usr/local/apache2/htdocs/derokorian.com/app/view/main.html
                  
                  service httpd restart
                  
                  echo "Done"
                    Derokorian;11046809 wrote:

                    It will only prevent the pull if the commit(s) being pulled change the same file(s) changed locally. For example, I've changed my .htaccess on my server for an app, because it needs to be different than in the repo. Yet I can continue to pull changes unless I push a change to .htaccess.

                    Yes this is one of those subtleties of git that I sort of take for granted and haven't quite memorized, but of course the problem that arises is that we need to change .htaccess and someone does and commits it and then suddenly the whole auto-publish-from-git concept is completely broken. I think Laserlight spelled things out pretty clearly above. If it is to be changed, it should be changed and committed to the repo and not otherwise. If it's different for different machines, it probably shouldn't be in the repo. Files like this are a constant source of issues I find. Still looking for the Master Solution To All Cases.

                    Derokorian;11046809 wrote:

                    As for the other things, consider a deploy script, to move the files from where the repo is downloaded to where they are served from. This way, you're not making changes to the files where git cares. That way, changing things for security reasons doesn't prevent using git for updating those files. This is what I use, if it helps (you'd need to add permissions of course):

                    I think I like this idea pretty much. Your script, however, is doing quite a bit more than just moving some files and changing permissions. In particular, the "service https restart" would require root permissions. I'm curious how you are running this script? Is it via a hook?

                    Also, I hope you all will forgive me, but I would like to milk this thread a little further. I now need to set up a repo hosted on my own machine (not github) for another project due to privacy concerns. I'm hoping to set up the repo on my server dev.example.com to facilitate development for multiple devs. I'm not especially concerned about auto-deployment in this case, but PERMISSIONS are proving to be quite confusing. Per this article, I have gone to my production web root and created a git repo there and committed all my files. I realize when creating this repo that the article I just linked says nothing at all about file permissions. I am expecting to create a bare repo on dev.example.com and expect that any contributor must have a user account on that machine, but am wondering what permissions to assign to the bare repo.

                    This article has two suggestions and I was wondering what everyone might think. I was prepared to create a new group, developers, add all my devs to this group and set a chmod g+rws on the bare repo's directory, but the article mentions "security issues" which I can quite visualize. Any thoughts would be much appreciated. From the article:

                    Permissions are a pest.

                    Basically, you need to make sure that all of those developers can write to everything in the git repo.

                    Skip down to The New-Wave Solution for the superior method of granting a group of developers write capability.

                    The Standard Solution
                    If you put all the developers in a specially-created group, you can, in principle, just do:

                    chgrp -R <whatever group> gitrepo
                    chmod -R g+swX gitrepo

                    Then change the umask for the users to 002, so that new files get created with group-writable permissions.

                    The problems with this are legion; if you’re on a distro that assumes a umask of 022 (such as having a common users group that includes everyone by default), this can open up security problems elsewhere. And sooner or later, something is going to screw up your carefully crafted permissions scheme, putting the repo out of action until you get root access and fix it up (i.e., re-running the above commands).

                    The New-Wave Solution
                    A superior solution—though less well understood, and which requires a bit more OS/tool support—is to use POSIX extended attributes. I’ve only come to this area fairly recently, so my knowledge here isn’t as hot as it could be. But basically, an extended ACL is the ability to set permissions on more than just the 3 default slots (user/group/other).

                    So once again, create your group, then run:

                    setfacl -R -m g:<whatever group>:rwX gitrepo
                    find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

                    This sets up the extended ACL for the group so that the group members can read/write/access whatever files are already there (the first line); then, also tell all existing directories that new files should have this same ACL applied (the second line).

                      sneakyimp;11046845 wrote:

                      Yes this is one of those subtleties of git that I sort of take for granted and haven't quite memorized, but of course the problem that arises is that we need to change .htaccess and someone does and commits it and then suddenly the whole auto-publish-from-git concept is completely broken. I think Laserlight spelled things out pretty clearly above. If it is to be changed, it should be changed and committed to the repo and not otherwise. If it's different for different machines, it probably shouldn't be in the repo. Files like this are a constant source of issues I find. Still looking for the Master Solution To All Cases.

                      Using packages or deploy scripts would completely alleviate this concern. We build our rpms and our servers don't even have git installed, instead we just run yum update package-name. I've taken this, and changed it to a simple deploy script for my purposes simply because I dev on windows at home and am too lazy to spin up a vm just for building rpms 😛

                      sneakyimp;11046845 wrote:

                      I think I like this idea pretty much. Your script, however, is doing quite a bit more than just moving some files and changing permissions. In particular, the "service https restart" would require root permissions. I'm curious how you are running this script? Is it via a hook?

                      That's actually an old version of the script and it doesn't restart httpd anymore, but the script is run as root so the fact that root is required certainly doesn't matter. Its not run on any hook, I wouldn't want arbitrary pushes to be auto-deployed (in fact, it sounds like a bad idea to me, especially in a group setting). We test everything before its deployed on testing and staging environments, but building means committing and getting more people to test it means pushing. I don't understand why you want to use a hook, but to each his own and I'm happy to try my best to help you make it work 🙂 My script doesn't do that much actually it syncs to the webroot, replaces some tags with a tags for built resource files, and builds resource files. Basically when on the server I serve one css and one js file, instead of the (currently) 27 js files and 8 css files that I serve in testing.

                      sneakyimp;11046845 wrote:

                      Also, I hope you all will forgive me, but I would like to milk this thread a little further. I now need to set up a repo hosted on my own machine (not github) for another project due to privacy concerns. I'm hoping to set up the repo on my server dev.example.com to facilitate development for multiple devs. I'm not especially concerned about auto-deployment in this case, but PERMISSIONS are proving to be quite confusing. Per this article, I have gone to my production web root and created a git repo there and committed all my files. I realize when creating this repo that the article I just linked says nothing at all about file permissions. I am expecting to create a bare repo on dev.example.com and expect that any contributor must have a user account on that machine, but am wondering what permissions to assign to the bare repo.

                      Maybe I missed something about our set-up, but the git server needs write/read access to the repo. For the client, the owner is whoever cloned the project. I've never really had any issues dealing with permissions for multiple users (we have 70+ devs), and we use packages (rpms) or deploy scripts to manage permissions on the servers, those permissions aren't managed in the git repo (well they are, because the rpm spec is in the repo).

                        Derokorian;11046863 wrote:

                        Using packages or deploy scripts would completely alleviate this concern. We build our rpms and our servers don't even have git installed, instead we just run yum update package-name. I've taken this, and changed it to a simple deploy script for my purposes simply because I dev on windows at home and am too lazy to spin up a vm just for building rpms 😛

                        It is certainly on my list to understand how rpms work, but my plate is currently quite full with git, AngularJS, and a couple of task-specific SDKs. I'll probably be asking about rpms in the next few months.

                        Derokorian;11046863 wrote:

                        but the script is run as root so the fact that root is required certainly doesn't matter.

                        I might be paranoid, but feel like running any script as root is a pretty big deal. One must be quite careful developing such scripts as they can have tremendous impact on a system and security considerations. Especially when you want to automate the running of said script -- and automation is often required if you want to alleviate server admin burdens.

                        Derokorian;11046863 wrote:

                        I wouldn't want arbitrary pushes to be auto-deployed (in fact, it sounds like a bad idea to me, especially in a group setting). We test everything before its deployed on testing and staging environments...

                        This was a request from the client and we are only auto-deploying to a development server (not production no no no). It does have a beneficial side effect that one need not copy one's files manually to the server. Note that the changes are pushed to the dev server not on commit (which affects only one's working directory) but on a push to the shared repo. To me, this makes some sense as one should only be pushing changes that are ready for everyone's consumption. Deployment to production is a wholly separate thing -- and I tend to thing git can assist greatly with that too.

                        Derokorian;11046863 wrote:

                        to each his own and I'm happy to try my best to help you make it work

                        Thank you! I have it working nominally in the first case I posted about. I'm now working on a different client's project and am not using github in this case. Auto-deployment is not a requirement and personally I'd rather deploy manually.

                        Derokorian;11046863 wrote:

                        Maybe I missed something about our set-up, but the git server needs write/read access to the repo. For the client, the owner is whoever cloned the project. I've never really had any issues dealing with permissions for multiple users (we have 70+ devs), and we use packages (rpms) or deploy scripts to manage permissions on the servers, those permissions aren't managed in the git repo (well they are, because the rpm spec is in the repo).

                        I think the confusion arises here from the concept of a 'git server.' I am hoping to grant access to my repository via SSH (see SSH Protocol section here). In this case, there is no server. Users who have SSH access to dev.example.com can simply clone/pull/push via SSH. It doesn't require any server to run, it relies on the SSH permissions I've already set up.

                          I might be paranoid, but feel like running any script as root is a pretty big deal. One must be quite careful developing such scripts as they can have tremendous impact on a system and security considerations. Especially when you want to automate the running of said script -- and automation is often required if you want to alleviate server admin burdens.

                          For sure, care should be taken. However we run all environment modifications as root (using sudo, only certain commands are available to the users). If we were to auto mate a script like this, we would use sudo crontab -e again making it run as root without giving out the root password (in fact, root doesn't have a password but a set of authorized-keys).

                          This was a request from the client and we are only auto-deploying to a development server (not production no no no). It does have a beneficial side effect that one need not copy one's files manually to the server. Note that the changes are pushed to the dev server not on commit (which affects only one's working directory) but on a push to the shared repo. To me, this makes some sense as one should only be pushing changes that are ready for everyone's consumption. Deployment to production is a wholly separate thing -- and I tend to thing git can assist greatly with that too.

                          I disagree, people should be pushing daily for continuous code review and security in not losing ones work if the workstation is bricked. Additionally, what if someone force pushes without pulling? Now someone who is in the middle of testing has lost their code on the test environment. Even for a test env, I think manually building is better because you can be absolutely sure you know whats on it at any given time.

                          I think the confusion arises here from the concept of a 'git server.' I am hoping to grant access to my repository via SSH (see SSH Protocol section here). In this case, there is no server. Users who have SSH access to dev.example.com can simply clone/pull/push via SSH. It doesn't require any server to run, it relies on the SSH permissions I've already set up.

                          So you're using ssh for authorization, why not just make the repo read/writable by everyone then? Restrict the ssh access to be through git commands and they won't be able to go on and make manual changes. (I do commands at work through ssh, but I can't ssh into the box).

                            Derokorian;11046875 wrote:

                            I disagree, people should be pushing daily for continuous code review and security in not losing ones work if the workstation is bricked. Additionally, what if someone force pushes without pulling? Now someone who is in the middle of testing has lost their code on the test environment. Even for a test env, I think manually building is better because you can be absolutely sure you know whats on it at any given time.

                            Tomayto/Tomahhto I guess. I don't claim to be git-master, but I wouldn't want anyone pushing anything to the shared repo that wasn't at least locally tested and ready to run. They are more than welcome to commit locally. As for a force-push without pulling, I think I would strangle someone who did that. The default behavior of git is to prevent a push if you haven't pulled the latest changes. This stands to reason: don't go pushing your changes on a repo that has evolved since you last visited. Download the changes first, do whatever merge may be required (which should be minimal in a well-managed project).

                            I see your point about wrecking the test environment. In a project with a lot of devs, there can be a dedicated testing team and the version being tested must often be carefully documented and bugs carefully tracked. My projects are small ones and testing tends to be quite informal.

                            Derokorian;11046875 wrote:

                            So you're using ssh for authorization, why not just make the repo read/writable by everyone then? Restrict the ssh access to be through git commands and they won't be able to go on and make manual changes. (I do commands at work through ssh, but I can't ssh into the box).

                            My head nearly exploded when I read this. I hadn't even considered such an obvious solution. I'm wary though. Seems to me that granting write permission to everyone is a bad solution.

                              Write a Reply...