The majority of our C# projects configuration is kept in *.ini files. Mainly these files hold
many sections affecting all aspects of programs behaviour. But besides of regular configuration data some of sections are vulnerable like db connection string or server password. We try to keep this sections in following forms:
[Database]
user=testuser
database=testdb
password=
But when developer is testing application he must fill the config in order to start application. It is quite common that some of the passwords are commited into version control.
Because these files are indispensable for application they cannot be included in .svnignore.
Probably what I'm looking for is some kind of script (maybe in powershell). That would scan all *.ini files and erase all passwords. The most interesting solution would be adding some external password storage that can be used both to encode and decode passwords in *.ini files.
I always push to store configuration template files in subversion, but not actual configuration files. So if the configuration file is "config.ini" then I'll check in a "config.ini.template" populated with non-working sample data.
Then to prevent multiple developers from checking in their individual "config.ini" files, I'll add the actual configation file name to the svn:ignore properties list.
This forces the developer to copy the file and modify it appropriately for their environment, but eases the work of that task by not forcing them to find out which fields need to be present. If you have the time, you can even embed comments into the template file to simplify the meanings of some of the configuration options.
At the top of the file, include the directions of how to configure the system using the template, which should read something like:
# *** CONFIGURATION TEMPLATE --- DO NOT MODIFY THIS FILE ***
# 1. Make a copy of this file in the same directory with the command "copy config.ini.template config.ini"
# 2. Edit the new copy and follow the rest of the instructions
#
# Change "this.system.hostname" to the hostname of this system
Hostname = this.system.hostname
# Set the answer "23" to "42"
Answer = 23
You get the idea....
If you have problems (or think you might have problems) with people checking in their configuration options over the config.ini.template file, then I'd recommend using "svn lock" on the template file. However, with the appropriate warning, I've never found it necessary.
I'll not answer your question and instead recommend a different approach, assuming it's not too late to change the relevant design.
You should not store passwords in the same files as the rest. Have the application read a dedicated password file (or retrieve the password from a password storage service) in addition to the regular configuration file. This is not just about not storing passwords in svn, but also about not having passwords exposed to shoulder surfing, accidentally mailed or posted when someone asks for help with a non-working configuration, etc.
Related
I've started working on an Azure project. In terms of config, I currently have three files: ServiceConfiguration.Cloud.cscfg, ServiceConfiguration.Local.cscfg and ServiceDefinition.csdef.
ServiceDefinition.csdef is the template file for the csfg files. ServiceConfiguration.Cloud.cscfg contains all the actual Azure configuration, including DB passwords, SAS keys etc.
Should ServiceConfiguration.Cloud.cscfg be checked into source control? I wouldn't have thought so but a quick search on github for the file shows that it is.
If it should be checked in, how should the sensitive password data be managed?
I typically check in the configurations. The reason is that the behavior of your application will change dramatically depending on these configurations. For example -> number of roles for a distributed application directly affects how you process incoming messages and the vmsize directly affects how much memory you have. You may encounter issues debugging problems if each developer is using a different configuration. This standardizes your deployment.
Anything with plain-text password information shouldn't be checked into a public repo unless you want people to have access to that information.
You can add this file to the .gitignore file and prevent it from being checked in.
Provide a different ServiceConfiguration.Cloud.cscfg named something like ServiceConfiguration.Cloud.cscfg.template with all the config info of your cloud service minus the password values. If someone forks your project they need to use that and fill in the appropriate values and rename the file.
Do this and change all your passwords to something else. Even if you delete this file from the repo, it still exists in the history and anyone can view it.
I'm trying out a yesod applications which I will eventually put up on github or similar.
I will use oauth2 with google which means I have to provide an email and secret token. Which I obviously do not want up on github.
What is a good place to store these in a yesod scaffolded application? I'm hoping to store it in a seperate, config/secret.yml for example, so I can put that into the ignore file of git/mercurial and never commit it.
But i can't find out how to include such a file. Or if such a file already is provided by yesod. config/settings.yml seemed possible, but there's entries there which I would like in github.
So my question is, in a yesod scaffolded application. Where can I store secret keys in a way I can easily exclude it from version control systems?
There are many approaches to this, mostly depending on what flavor of devops/hosting your prefer. One option is to put a dummy value in the config file and override it with an environment variable at runtime (see: https://github.com/yesodweb/yesod/wiki/Configuration#overriding-configuration-values-with-environment-variables). You can also having an extra settings file for production that overrides the values in the default config file, which is how the test suite works. A completely different approach would be to use a system like vault in production and query it for your secure credentials.
EDIT To spell out one of the approaches:
Create a new YAML file with the settings you won't to override, e.g. in config/production.yml:
copyright: This is a copyright notice for production
When you run the application, pass in a command line argument giving the location of the config file
My Google App Engine application includes privileged credentials (like OAuth and cookie signing keys) that I don't want to check in to source control (i.e. Git).
I've considered storing these as system properties or environment variables in the appengine-web.xml file, however this file includes a number of other things that I do want to version. Where would be a good place to store "secret" application data so that I can easily exclude it from source control?
What I usually do it store the credentials in a secure repository (a file that is only accessibly by a superuser that I can trust) and then have a post-build script. Within source control, I have a dummy password in a properties file and then then post-build script runs after a build and replaces the dummy passwords with the real ones. That way the passwords are not in source control, but show up upon every build. This does depend on an automated build/deployment process, but it is very effective.
Put those things into another file/directory and exclude them with .gitignore.
For Java, I recommend the strategy of spring-boot's externalized configuration. The idea is a stack of configuration sources with the ones toward top override the ones below.
Command-line arguments
System properties
Environment variables
Local configuration files (application.yml or application.properties)
Configuration files at the classpath
No. 4 is usually in a hidden folder in the user's home directory, e.g ~/.myapp/application.yml. Only the user can read that file.
For your question, the non-secret, version-controlled properties are put directly in the source code (No. 5 above). Secrets can be also put in 5 but with dummy values. Real secrets overwrite the dummy values at runtime from 1, 2, 3, or 4.
You can either use spring-boot or write your own code following that same strategy.
I would like to start checking that the open source projects that I am using in my apps are what the developers released. I noticed that many projects have a SHA1 and MD5 digests presumably these can be easily tampered with for example if a hacker replaces the orginial zip file on a mirror they can also replace the .md5 and .sha1.
How can I check the integrity of third party open source libraries that I depend on?
I think , there is No trusted way for this, since the hacker may change the source files and its (md5 or sh1) files. He simply may replace the whole project with another one.
so , download the source from trusted sites such as sourceforg and code.google.com and codeproject and mirrors recommended by these sites.
typically an open source project, although open to all to download and modify themselves, the ability to actually change the uploaded files is restricted to certain individuals governed by the project owner.
A good example is https://github.com/thecodemine/formwizard, where you can see a read-only link, but cannot modify directly unless authorised.
However you can fork the project to your own account and modify as you wish, for example https://github.com/AlexKey/formwizard
I'm also guessig on large open source projects like linux distributions for example, even code / files uploaded by authorised individuals will also go through stringent reviews before official release.
A hacker of course on comprosising a system could change files at will, but this isn't a weakness of an opensource model but instead could be a problem for any project.
Also things like Code signing help detect unauthorised modification.
http://en.wikipedia.org/wiki/Code_signing
Code signing is the process of digitally signing executables and
scripts to confirm the software author and guarantee that the code has
not been altered or corrupted since it was signed by use of a
cryptographic hash.
You have not Googled your question. If you do so you'll get a lot of content about it. The link below will teach you how to check the integrity of a downloaded file.
https://help.ubuntu.com/community/HowToMD5SUM
You may also check the following link, which shows that it is very difficult to modify or replace the .md5 and .sh1 files.
Here's the link.
I have an installed and configured squirrelmail in my linux server which i used to send and receive emails.
Now i have to format the linux server... then before formatting how can i backup my emails and configuration so that they can be used again ?
Backing up your email messages is not a SquirrelMail issue. SquirrelMail is an IMAP client and does not store email itself. You need to determine what kind of storage is used for your particular email system. If it's a very simple/default *nix email setup, you might start by looking in /home/ for a directory with a name indicative of the purpose, such as "Mail", "Maildir" or similar. You might also look in /var/mail or /var/spool/mail
There is some starter information on some ways to migrate email between servers here: http://squirrelmail.org/docs/admin/admin-11.html#ss11.2
Also, you might want to re-think why you need to format the whole system. *nix systems don't need to be treated like Windows systems do. They can usually be rearranged, expanded, tweaked and otherwise changed without the need for reformatting.
As for SquirrelMail itself, there are a couple things you may want to back up, which would be any configuration files for SquirrelMail itself (in its "config" directory) and any plugins you'd installed (you can usually just copy the entire plugin directory for most typical plugins and transport them to the new system with minimal hassle), any custom themes you may have had in the "themes" directory, and finally, all user preferences. The location of your user preferences depends on your configuration - might be in a database or might be wherever the "$data_dir" setting points to (find this by looking in "config/config.php" or by using SquirrelMail's configuration tool ("config/conf.pl"). If you have user preferences stored in a directory, you can normally just copy the whole directory. Note that even if you have SquirrelMail configured to keep user preferences in a database, some plugins will still use the data directory setting for some purposes, so it's advisable to back up that directory no matter what.
The wiki page at SquirrelMail detailing upgrades is the same thing you need: http://squirrelmail.org/docs/admin/admin-4.html
When backing up and migrating things like this between servers, you need to be very careful about file/directory ownership/permissions on both your email data and your application configuration and preferences data. If user and system account names and UIDs are not the same between the servers, you'll want to be very careful that you adjust the ownership of the files to suit the destination server.