Background
GitHub allows you to store Encrypted Secrets (Settings > Codespaces > Codespaces secrets), which is an amazing feature. For security, secrets stored this way are never visible to you once they are stored.
However, while hacking on something new, I find that it’s useful to be able to see my secrets and other environment variables occasionally. Typically, when hacking on a local project, I’ll store my secrets in a .env file, which is kept out of source control by listing it in my .gitignore file.
Issue
I’d like to do the same with GitHub Codespaces: store a gitignore’d .env file in my Codespace that is visible only to me.
However, with GitHub Codespaces living in the cloud, it is unclear whether this .env file would be somehow visible to others.
Question
If I gitignore a .env (or any other) file in my GitHub Codespace, is that file going to be somehow visible via the Codespace to others?
I received this answer on Twitter from GitHub employee Jonathan Carter (#LostInTangent) yesterday:
The Codespaces file system isn’t visible to anyone else, including org admins for the repo the Codespace is associated with. So as long as you gitignore the .env file, you’re totally fine to use that, in addition to managed secrets.
This is the answer I was looking for.
As a helpful aside, he additionally notes in-thread:
That said, you can also use the “Codespaces: Manage User Secrets” command, to view/add/edit/delete secrets directly from VS Code. So that might provide another option for easily managing secrets from the editor?
Related
So….if you want to have environmental variables, you’ll create the .env file right? Well…what if you want to share a repo with team members? Do they have to each manually create a .env file when working on the repository locally or is there a better solution than that? I’m just trying to think of the security behind not allowing everyone to have access to the private strings in a .env file but be able to use the repo as if there was a .env file.
I’m hosting my code in GitHub for reference. Is this a GitHub actions thing or is there another solution? Any help would earn my eternal gratitude in this dire time, lol
There is this Stack Overflow thread that is similar, but I don't want the environmental variables for deployment, just for team-members to do a git-pull and get the repository to work locally without needing to custom-create the .env file and add in the environmental variable strings: React app build/deploy using github actions with secrets
I have been working for some time on a project with a microservices architecture where each service has its own environment variables which are handled with a .env file for each service/repository.
A great part of these variables are related to other services IPs and external resources keys which are different in each environment: Development, Staging, and Production so the .env is not a simple one.
Our development pace is fast and most of the time these variables change with new features and or changes implemented by teammates working on issues related to that service. This causes that almost every time others want to work with a service they get blocked and have to update the .env file before. Therefore we end up requesting and sharing .env files with each other all the time and there is a lack of a "Source of truth" for all the .env files.
I was wondering if someone else has had this problem or a similar one before and what approaches has followed to solve it or improve it.
Is there any application or framework for sharing and managing .env files in a team in an automated way?
Thanks in advance!
EDIT
Just to be clear, these are not being added to source control and they are properly handled on CI/CD.
I was talking more about local development, setting up services locally, and keeping the .env local files up to date in an easy way.
As a summary of all the feedback provided by some coworkers and the community in both: r/SoftwareEngineering and r/softwaredevelopment (Thank you all for it) some of the most useful resources are:
This post about Common Anti-Patterns when Managing Passwords and Application Secrets: https://blog.envkey.com/managing-passwords-and-secrets-common-anti-patterns-2d5d2ab8e8ca
This one with Secure Strategies For Managing Passwords, API Keys, and Other Secrets. https://blog.envkey.com/secure-strategies-for-managing-passwords-api-keys-and-other-secrets-4cc3b2758c02
This application to share API keys with your team self-hosting and managing them. https://envault.dev/
And I want to quote what u/nickthemagicman commented which I think is an important point to take in mind:
But due to the fact that ya'll are still using .env files for this long and it's been this chaotic and no one has fixed this by now, it sounds like your biggest hurdle is going to be to get the team buy in, since it sounds like there's no centralized management either.
Not sure what stack you're using but we're solving this with Infisical.
It provides a source of truth for your environment variables and supports different environments (development, staging, and production). Your team can either automatically inject those variables into your local process or manually pull back environment variables to update your .env file — whichever you're comfortable with most; it's end-to-end encrypted.
We ran into the same issues you're outlining and are finally solving them.
I am using Github as the repository for a package I am building. At the moment I have a .travis.yml file setup that helps with automatically testing the code as it is pushed in. Eventually I'd like to deploy the package to a service like PyPI) but the language and package manager a re unimportant to the question).
Reading the documentation shows that its relatively easy to do this automatically:
For a minimal configuration, all you need to do is add the following
to your .travis.yml:
deploy:
provider: pypi
user: "Your username"
password: "Your password"
Except for the relatively small hitch that I'd need to put the username and password for PyPI into a publically visible yaml file.
Obviously this is bad practice, and I'm sure there are ways around this via tokens or something, but googling shows lots of suggestions along the same lines of "put your password here".
Am I missing something here? Or are people just putting their authentication keys into publicly visible files?
If you search GitHub for password .pypirc or .travis.yml, you would find actually many scripts for generating the .pypirc (for example) file.
The main idea is to version a .travis.yml template and use the deploy process to replace the placeholder values (like password: #password#) with the actual password which should not be stored in a git repo.
Does anyone know of a solution (web hosted or otherwise) for a source code control system that would work well in a university environment where information technology is the focus? We'd like to offer it as a campus-wide "version-control service", much like universities do with an email service. Specifically, I'm talking about the following peculiarities:
There are a large number of new repositories created/managed each semester. Any programming course or research project could require students to use source code control, in various source code environments (including .NET, Java, C++, LaTeX).
Students should be able to create and manage themselves the repositories. Involving an administrator/instructor/etc. is not scalable otherwise.
Repository storage should be secure (private), and archivable for respecting intellectual property (preventing plagiarism, protecting research IP).
Any or all of the flavors of source code control (e.g., CVS/SVN/GIT) would be acceptable.
Remote access to repositories is essential. Student/researchers have freedom to work either in designated lab spaces or remotely. Marking of assignments can be done by instructors who've "checked out" the code anywhere.
If an academic license exists, it must scale for >500 students.
Many commercial/free products (web-based or otherwise) don't satisfy conditions #1 and #2, as they require superusers to administer accounts/repositories/accesses. Solutions such as Google Code, sourceforge.net, GitHub, etc. don't satisfy condition #3, as the repositories are always public.
Here's free one: http://gitlabhq.com/
You can add repositories over this tool.
For security you use RSA Keys.
And I would suggest to use Git. SVN and CVS are outdated.
GitHub would appear to satisfy your requirements. You can set up your own instance in your intranet; https://enterprise.github.com/
You could use git in the students private file storage if they have such a thing, git doesn't require hosting other than a place to store files.
Redmine (SVN, CVS, Git, Mercurial, Bazaar and Darcs)
UberSVN (SVN)
Private Assembla (?) (SVN, Git, Mercurial)
One solution I use is to create a master GIT repository in a Truecrypt variable size encrypted container. The container is placed in a Dropbox folder. The repository is cloned to the local hard drive which becomes the working directory. All the work is done and checked in on the local repository. I wrote scripts that mount the encrypted container, pushes/pulls the local repo to the master repo and dismounts the encrypted container. Dropbox detects the changes in the encrypted container and syncs it to the Dropbox server. Security is maintained as an encrypted file is the only thing sent to the server. Only real way to ensure security is doing the encryption yourself.
All you need to set this up is a few scripts, truecrypt installed and a Dropbox account. Could probably write some basic software to automate some of the steps. To make it scaleable and low cost, the basic steps are still valid. Create a master and local repository, encrypt the master repo, work on the local repo and sync changes to the master, back up the encrypted master repo online or on a server.
I am using mercurial for website development. I "think" I'm using it correctly.
I develop on my development machine, commit fairly regularly. I will somewhat regularly push my commits to my hosted site-dev repository.
If things are set up how I want them for the live site, I push from my dev machine to the hosted site-live repository. Then I pull down from that repository onto the live server.
However, there are some changes that need to be made (changing directories from localhost to www.example.com, changing the DB connection stuff, etc.).
What I did was made these changes on my live machine, then pushed them back up to the site-live repository. I don't know why I did that, really, but at least there's a changeset sitting there with the necessary config changes.
What I don't know how to do is manage this process. I'm a little lost beyond committing, pushing and pulling with hg. I'm a single developer and haven't even done a merge yet.
Is there some way to keep that particular changeset identified, and just apply it, hopefully even BEFORE I pull from the repo down to the live server?
I think you can tell from my question that I'm in a little over my head with hg and workflow at the moment ;)
This is my understanding:
What essentially you are trying to do is have a development, staging and deployment environment. You do your development using 'development' repository, test it on a staging environment and then once satisfied, pull those changes into deployment repository.
And when you pull from staging to deployment, you need to change your environment / configuration data.
My take is you should not be changing the configuration at all.
You should have configuration files such that you have a
basic configuration file
basic.conf
Environment specific overrides
basic.dev.conf, basic.staging.conf and basic. deployment.conf
Use environment variable:
The overrides to the basic configuration data should be defined via an environment
specific variable : APP_ENV : dev or staging or deploy
This way you should be able to override the configuration based on the environment without changing the configuration information.
It is not a good idea to rely on making changes to config files each time you pull your code from development to staging to deployment.
I would keep the live server outside the version control. Meaning that I would have a small "install" script that pulls updates from the repository, removes any unnecessary development files, and applies the correct configuration files. Both development and production configuration files should be in version control.