Delete Capfile & deploy.rb after deployment #127

Closed
iGEL opened this Issue Nov 14, 2011 · 1 comment

Comments

Projects
None yet
2 participants
@iGEL
Contributor

iGEL commented Nov 14, 2011

The deploy.rb usually contains private informations like passwords to the server and scm, scm addresses and server adresses. If you deploy other projects than Rails, these files may be published into the DOC_ROOT. There is no reason to keep the Capfile and config/deploy.rb on the live server, so it'll be the best solution to remove these files after the deployment.

Here a basic version (I don't know all the details of Capistrano):

namespace :deploy do
  task :remove_deployment_files do
    run "rm #{latest_release}/Capfile #{latest_release}/config/deploy.rb"
  end
end

after 'deploy:update_code', 'deploy:remove_deployment_files'
@leehambley

This comment has been minimized.

Show comment
Hide comment
@leehambley

leehambley Nov 14, 2011

Member

The deploy.rb and Capfile are part of your source repository, deleting them from the server leaves your <scm> status unclean.

The thin veil of security as an excuse for deleting them doesn't actually solve any security issues (if someone is reading code on your app server, they're already too far penetrated into your codebase. If you're speaking about security within your own team, it's not an open source Gem's responsibility to facilitate that.

I recommend not putting any passwords into the Capfile, if you're using Subversion, I know that can be tricky; but using a decent, modern SCM which has SSH as a transport, you can use SSH (with agent forwarding, or deploy keys) to make sure you don't need any deploy-time passwords to get at the code.

And regarding database passwords, or otherwise which can be in those files, they should be deployed to the server by a trusted member of staff, and symlinked from the deployment each time through.

Thanks for opening the issue, but it's not really a security improvement.

Member

leehambley commented Nov 14, 2011

The deploy.rb and Capfile are part of your source repository, deleting them from the server leaves your <scm> status unclean.

The thin veil of security as an excuse for deleting them doesn't actually solve any security issues (if someone is reading code on your app server, they're already too far penetrated into your codebase. If you're speaking about security within your own team, it's not an open source Gem's responsibility to facilitate that.

I recommend not putting any passwords into the Capfile, if you're using Subversion, I know that can be tricky; but using a decent, modern SCM which has SSH as a transport, you can use SSH (with agent forwarding, or deploy keys) to make sure you don't need any deploy-time passwords to get at the code.

And regarding database passwords, or otherwise which can be in those files, they should be deployed to the server by a trusted member of staff, and symlinked from the deployment each time through.

Thanks for opening the issue, but it's not really a security improvement.

@leehambley leehambley closed this Nov 14, 2011

mattbrictson pushed a commit to mattbrictson/capistrano that referenced this issue Aug 24, 2016

Merge pull request #127 from mattbrictson/patch-1
Add airbrussh to third party plugins list
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment