Warning email from GitGuardian about SECRET_KEY

[jwhitlock]

In the "Deploy!" section, when the project is pushed to GitHub, an email "[username/my-first-blog] Django Secret Key exposed on GitHub" is sent to the repo owner from [email protected]. It does not seem that this is an official GitHub feature, but a unsolicited email from a hungry startup.

Here's my version of the email:

GitGuardian has detected the following Django Secret Key exposed within your GitHub account.

Details

• Secret type: Django Secret Key
• Repository: jwhitlock/djangofest-2020
• Pushed date: 2020-11-14T18:50:11+0000

[[ Protect Your GitHub Repos]]

GitGuardian is an automated secrets detection service trusted by 150,000 developers worldwide.

The phrase "Protect Your GitHub Repos" is a call-to-action button that takes you to a GitHub authorization screen to add the GitGuardian service to your account. I signed up, and there was no useful advice about how to solve the issue easily available. They have some blog articles:

• https://blog.gitguardian.com/secrets-api-management/ - generic "best practices" advise, including to sign up for their service, but not specific to SECRET_KEY.

If this company continues doing this, it would affect any student regardless of language or operating systems.

This caused some distress for the students and a lot of discussion among the coaches.

I'm not sure what the solution should be. It may be enough to say "you may get this email, and should ignore it for now". Another possible solution is to use python-dotenv as suggested by pythonanywhere, and walk students through those changes in the tutorial. Or, it may be enough to mention the Django deployment checklist, linked in the generated settings.py.

[nandish1199]

i have got the same message but from weather api secret

[waseyhasankhan]

I got the same and you helped us

[ghost]

got same message when I pushed changed to remote github repo. help ?

[das-g]

You can just ignore that message. (I'd write "You can safely ignore that message", but that wouldn't be quite true, as the message is indeed right that publishing the SECRET_KEY on GitHub is unsafe. However it's what the tutorial currently instructs you to do for simplicity, so just be aware that you should not do it that way for production deployments.)

[mariesises]

Thank you very much. I had a similar message and I clicked on fix the secret leak, but before authorizing it it seemed strange to me and when looking for information it came out your warning :) . Anyway if you look at the github icon the link is different too.


or in dark mode

[jayumaks]

I got the same message, is there a way of fixing this...???

[mnemonico]

the most strange thing is that I got this message concerning a leak directly to my professional email, which I really don't recall using it ever for the gitguardian solution or something related.

[das-g]

Probably most who receive(d) these warning e-mails don't have any relation to GitGuardian at all.

For how they got that e-mail address, @mnemonico: Did you maybe use it as the Git user e-mail address on a computer, on which you make commits that you pushed to your Django Girls blog repository on GitHub? If so, the e-mail address can simply be read out of these (public) commits. (It isn't shown on the GitHub web interface, but anyone can clone the repo and get it that way. And this can of course be automated, which GitGuardian probably has done, if they get the addresses that way.)

[mcdwayne]

Hello there,

Dwayne from GitGuardian here.

You received that message as part of our Good Samaritan project. We monitor all new public GitHub commits, and we alert GitHub users who push anything that looks like sensitive credentials into repos.
This is a free service we do for the public good. We don't ask for anything in return.
If you ever want to opt-out, reply to one of those emails and let us know.

das-g is correct; we pull the emails from the commits themselves. We want to give the devs a heads-up ASAP.

((Full disclosure, I just joined a few months ago and just found this thread researching who has mentioned us on GitHub))

[das-g]

Hi @mcdwayne

Thanks for replying here and for confirming some of our assumptions.

Is there a way to opt out on a per-line basis (e.g. by a special code comment, as is the case with many linters)? As the tutorial is intended to be followed by many (and pushing the resulting code is part of it), a per-user opt-out isn't really practical for this case, as the affected users aren't known in advance.

Alternatively (and maybe preferably), do you have any suggestions on how to make the code produced in this tutorial secure regarding this aspect (so that it would not trigger GitGuardian's warning in the first place), without complicating the instructions too much?

[mcdwayne]

Hi @das-g

I am asking the detections team about ways to opt out 'per line' or how we have dealt with similar issues with tutorial repos in the past.

As far as best practices here:
The original suggestion of leveraging python-dotenv to programmatically call for the needed credential instead of hardcoding them is a very good path and one we strongly recommend folks start with.

My feeling here is While it might be 'easier' to just hardcode things, it is a bad habit ever to pick up. Using a .env file adds a little complexity, but in the long run, all the folks using this tutorial will be set up for long-term success if they adopt this philosophy of 'never hardcode secrets' earlier.

Alternatively, but much heavier, is setting up and using Hashicorp Vault. That might be too overwhelming for new folks, though.

I will reply further when I get an answer from my team.

[mcdwayne]

Hi @das-g
I was able to chat with the secrets team on this. That is the internal team that oversees our secrets detection engine.
They first suggested the same as I did, leverage .env consistently, and it will set folks up for better long-term success.

But to fix the immediate issue at hand, it is possible to ignore a secret by adding a # ggignore comment on the same line as the secret (it has to be on the same line because otherwise, the engine could miss the comment when scanning a diff).

I hope that helps.

[amastaneh]

I still can't believe it. A very unprofessional approach by GitGuardian. Without my consent, without my membership on their site, they checked my personal GitHub account and sent this email to my business email address.
I would not share this information with my company. Really! Why do they do this?

@er-vin, @ericfourrier, @eugenenelou, @julienc91, @KNedelec

[mcdwayne]

Hi @amastaneh
I got an alert on this thread, so I thought I would reply on behalf of GitGuardian.

Sorry that you are not a fan of our public alerting. I am a Developer Advocate at GitGuardian.

It seems you did publish an .env file in public containing something that looks like a valid key, with a commit signed with your a...@s.....a.com account, which I assume is the work account you mentioned. This is not private information, as it is in a public repo and we sent the alert to the person who signed the commit. We are not trying to send it to your company and would never send the alert to anyone except the commit signer.

We at GitGuardian are really trying to do a public service here, helping folks discover they might not have pushed what they thought they were pushing into places they might not have meant to. The feed for new commits is publicly available and we want to give you a heads-up. There are automated bots put out there by bad actors that are constantly looking at new commits to extract keys they might exploit.

We did not mean to annoy you and if you don't ever want to hear from us again, we understand.
Feel free to reach out to me directly at [email protected]

I would welcome your feedback on how we could better handle the situation.

[amastaneh]

@mcdwayne I appreciate your quick and comprehensive explanation. That was my mistake to unwittingly and unknowingly sign this public repository with my professional email address.

Thanks for providing the public with such a valuable service.

As recommended, it would be helpful to include the source of the email (with a link to the commit.patch) at least in the initial email like this:

+@er-vin, @ericfourrier, @eugenenelou, @julienc91, @KNedelec

[mcdwayne]

Thank you @amastaneh
That is good feedback. I am working with the team to improve the messaging and this is a good idea.

[fragmuffin]

I just got one too... similar experience as @mnemonico comment; it was sent to my work email, even though it's a private repo, but that's because I'd globally configured git to use my work email (oops).

$ git config --global user.email
<my work email>

I started panicking because the email appears to come from a separate domain: [email protected]

• getgitguardian.com ⛔ , instead of
• gitguardian.com, or a subdomain (if they really wanted to put "get" in there)
• get.gitguardian.com ... very uncool 😠

Which was scary because getgitguardian.com appears to be registered by a completely different party (when queried through who.is)

However the good news is the button to authorise them (as a 3rd party to github on your behalf) does link to the (slightly) more legitimate gitguardian.com domain.

In Summary:

• Completely unrelated to django (sorry 🤷 , but big-love for django tho ❤️ )
• Contact from gitguardian was unsolicited, but does not appear to be malicious.
• If you granted 3rd party access, you can remove them from: https://github.com/settings/applications

[das-g]

related: #1192

[thibaudcolas]

@mcdwayne aside from ggignore, does your service have any specific logic to trigger an alert or not based on how/where the SECRET_KEY is defined? Or possibly to skip the alert for the Good Samaritans program specifically?

Part of the problem here is that the SECRET_KEY is defined as part Django’s built-in project scaffolding / project template. I would expect it’s pretty common for people to push the output of project scaffolding tools to GitHub, so this must be creating a lot of false-positives.

For reference, this is the kind of format that’s generated by django-admin startproject, in a mysite/settings.py:

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'django-insecure-07eo4&4fy=1csgz@tj%!^buz&09nn&ej@=4t)%6^nx6eyntq&a'

I tried to go through the tutorial with a "fresh" GitHub account and didn’t receive an email, so I imagine at least lines with this django-insecure- prefix might be ignored?

The project template’s security key generation from Django happens in startproject.py, and here is the settings.py’s file template.

[thibaudcolas]

@mcdwayne 👋 could you take a look at the above when you have the chance?

Also FYI Fly.io also generates SECRET_KEY in their Django project scaffolding.

[mcdwayne]

Hi @thibaudcolas
Sorry for the lag, I somehow missed the first message from October; I was not ignoring you on purpose. Sorry about that.
I need to go ask internally about this and likely get someone from our engineering involved directly. I just sent that request internally now and will report back asap.
Sorry again for the lag.

[mcdwayne]

@thibaudcolas
I got a product update today. It is on the to-do list for an upcoming sprint to address the django-insecure prefix globally. Can't commit to a timeline for this, but yes, we are on it. The team appreciates the feedback.
I will let you know the development status as they share it with me.

[Dilrushan]

the most strange thing is that I got this message concerning a leak directly to my professional email, which I really don't recall using it ever for the gitguardian solution or something related.

I got an email from GitGuardian as you mentioned and clicked the link and proceeded, now what to do?
Now I have removed this app from GitHub, but I have still doubt about the security

[amastaneh]

The story is that I accidentally made a Git commit using my work email, and when I saw the email notification in my work mailbox, I nearly had a heart attack. It took me a while to calm down and realize that it was actually a good thing I found out that day instead of much later. So, I decided to roll up my sleeves and build this Google Chrome Extension to easily spot commit info and avoid this kind of mistake in the future.

https://chromewebstore.google.com/detail/github-prime/aimhjdfkkcffllnacnjefnjgodfafjbj?hl=en
https://github.com/amastaneh/github-prime
https://githubprime.com/

Thank you @mcdwayne

[C76GN]

I have absolutely no idea what to do.I'm just a student, there are a lot of things I don't understand yet

[fltfx]

@das-g Can we close this as it doesn't seem like this is now relevant to Django Girls?

[das-g]

@das-g Can we close this as it doesn't seem like this is now relevant to Django Girls?

Well, as we see from #1687 (comment), this is still an issue.

The problem is that (for simplicity / brevity) the Django Girls tutorial instructs the participants to do things (well, at least one thing) in a way in which they shouldn't be done in production and that GitGuardian scans all of GitHub and warns all that push code with such a "mistake", which understandably confuses participants or even puts them into panic.

I'm still not sure how to best resolve the problem, though.

[das-g]

Well, as we see from #1687 (comment), this is still an issue.

Though, looking at the e-mail in the screenshot in #1687 (comment), this doesn't seem to be about a repo that participants create during the Django Girls tutorial, but about some other project. For other recent-ish comments (#1687 (comment) & #1687 (comment)) it's unclear whether the warning is for a repo from following the Django Girls tutorial.

@Dilrushan, @amastaneh, did you get these warnings for a repo you created while following the Django Girls tutorial?

[fltfx]

I also agree that #1687 (comment) is not related to the Django Girls tutorial repo.

Also, I didn't get the warning when I went through the tutorial in Sept (2024), so I don't think it's an issue anymore. Let's see what @Dilrushan and @amastaneh say.