.env file not being ignored

[FionaDL]

Hello,

I noticed that the .env file is not being ignored, and therefor there are secret keys showing. I imagine that this is not being shown on purpose, and that it would be best to change the keys and ignore the file from now on.

[pghdeveloper]

@DeeDeeG Would it be okay to remove the keys and ignore the file moving forward? This is my first time looking through this project. Is there a secure place somewhere where we can access those keys?

[DeeDeeG]

Hi, @pghdeveloper. (EDIT: And hello @FionaDL as well. Sorry I did not respond to this issue before now.)

I had discussed this with the other maintainers a while ago. As I recall, they let me know the keys you see in this file are placeholder development-only credentials that are not used in production. So there is no security concern for our production app -- these credentials would not be useful against the production instance, which must be using different values for these secrets.

I vaguely recall someone set up these keys for development purposes only, and it may indeed have been committed by accident at that time, but again, since those were not credentials for a real production instance, just some developer's instance presumably limited only to their localhost/LAN, there was no security leak that would be of any use to anyone at that time either.

I don't think there would be a downside to removing those. But I am came to this project as a volunteer with not much experience running web apps, truth be told, and I'm still only self-taught, so I lean toward leaving things as-is if they're not causing issues right now. I admit it looks a little alarming, though, given the (misleading) appearance of a genuine/relevant credential leak. And just in general it's weird for there to be effectively useless credential checked in. I just don't know 100% for sure they don't have some obscure impact on the tests, for instance. Might be worth looking into, but the time I dedicate to this project goes pretty much 100% toward dependency updates at the moment.

As has been mentioned in some other issues, the project is in a sort of "maintenance mode", with very little maintainer hours available to do much more with the project right now. I don't know where the other maintainers stand on this, but if a dedicated team of new folks asked to pitch in, with experience of running a web app like this (with a DB and API as the backend), basically picking up where the other folks left off and not doing anything too radically different (not something different than what users expect/want/need), then perhaps it would be good to get some new people on board.

Is there a secure place somewhere where we can access those keys?

As I understand it, these "secrets"/"credentials" are really meant to be set as true environment variables on the server where you host your copy of the webapp. Pretty standard Rails app deployment, I presume. Again, I think someone may have committed their development-only keys at one point in this .env file without it really making sense to commit them, or at least not making sense to keep them long term.

Probably the best thing to do would be to delete these on some branch, and confirm that hopefully it doesn't interfere with the CI tests, and that the local Dockerized/development version of the app still works fine. At which point one could permanently delete them with some confidence.

But without running CI first, if it's not established we don't need them for CI/testing purposes, I'm inclined to leave them. I won't guarantee setting aside some time to do this, but it's something that wouldn't take long, admittedly. Just low stakes and a limited budget of time to set aside for this project, is all.

[DeeDeeG]

See this issue #193 for some of the historical context. The intent is: these credentials are only ever loaded during development and testing.

The intent is: the .env file is ignored completely in production, and we have the production credentials set via other means on our actual production server.

Other maintainers (who are more versed in these things than I am) were confident this is the case last I talked with them about it.

I hope that clears up the concerns, at least.

(If comments are allowed in the .env file, then maybe it'd be best to add one explaining these are development/test only, but I think maybe Docker/docker-compose don't like comments in the file?? Again, I'm hesitant to change anything, since any time spent troubleshooting this is time I don't really have to dedicate to this topic, personally speaking. It is working as-is, that's why I lean toward leaving it as-is.)

[pghdeveloper]

@DeeDeeG Even if they are local secret keys, having any keys in the repository regardless for which environment its used for is not the ideal practice. I can create a branch to remove these keys, make the .env file ignored, and go from there.

[JosefButts]

@DeeDeeG Even if they are local secret keys, having any keys in the repository regardless for which environment its used for is not the ideal practice. I can create a branch to remove these keys, make the .env file ignored, and go from there.

Even if the keys are deleted on a branch and committed, these keys will be present on the git history and also could still be tracked unless they are removed from the cache. This blog outline how to remove them form the history though they should still be rotated if feasible.