2

I'm lost as to how to handle secret keys.

I've published a repo on GitHub with a secret key (I know now, big no no), then found out about the GitHub Secret Key in the settings and stored the key there.

So, two questions:

  • what's the best way to clean the commit history so that the secret key isn't available anymore?
  • how do I actually access this secret key? In my settings.py, I now had SECRET_KEY = 'name_of_key_on_github' but that throws NameError: not defined.

Any help is appreciated, thank you.

Update

Ok, so according to the link provided by @VonC, I need to create a .yml file in .github/workflows directory.

general.yml

name: key #needed but name can be arbitrary

on: [push, pull_request, deployment]

env:
    runs-on: ubuntu-latest
      - uses: actions/labeler@v2
        with:
          repo-token: ${{ secrets.name_of_my_key }}
      credentials: #these don't work yet, if anyone can tell me why?
        username: ${{ github.actor }}
        password: ${{ secrets.ghcr_token }}

settings.py

SECRET_KEY = "../.github/general.yml"

Project structure if you want / need to reproduce:

myrepo
├── app_name
│   ├── settings.py
├── .github
│   ├── workflows
│   │   ├── general.yml

I can run python manage.py runserver, but on pushing to remote I get the following error:

! [remote rejected] master -> master (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/general.yml` without `workflow` scope)

Update 2

Hadn't enabled the workflow scope (github.com > profile > settings > developer settings > personal access tokens):

You need to make sure box is checked.

workflow box needs to be checked

Suki
  • 177
  • 3
  • 12

1 Answers1

1

Use the new git filter-repo, which does replace the old git filter-branch or BFG.

It has many usage examples, including content-based filtering, in order for you to remote the path/to/secret file in past commits:

To keep all files except these paths, just add --invert-paths:

git filter-repo --path path/to/secret --invert-paths

You can add --dry-run to test it before actually changing your repository.

Then git push --force (that does rewrite the history of your repository, so make sure to notify any other collaborator)

Since it must be done on a fresh clone:

  1. Don't touch anything to your current clone folder
  2. Create a separate clone of the repository, where you do the filter repo
  3. In that second clone, now cleaned (no more big file in its history), import your work from your first repo

That is, for point 3:

cd /path/to/second/clone
git --work-tree=/path/to/first/original/clone add .
git commit -m "Import work from first clone"
git push --force

Regarding git gilter-repo, see a complete example in "Removing sensitive files from git from Boopathi Rajaa.


You can store encrypted keys, but available for GitHub Actions only.

Outside of GitHub Actions, see Github, secret keys and other local settings from Paul Smits.

For that you need a credential (PAT) with workflow scope.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Hi @VonC, thank you for your help. Let me double check and see if I got that all. 1. I clone my repo from github to a second location. 2. Change the worktree to original location 3. Use ```filter-repo``` 4. force push to original repo Do I understand correctly that both locations point to the same repo on Github? Do I get rid of the original repo afterwards? – Suki Jan 28 '21 at 09:00
  • Ok, so I followed the article you linked by Boopathi Rajaa. I did ```git filter-repo --invert-paths``` and I can see the new files in .git. But when I ```git push --force```, my remote is disconnected: ```fatal: No configured push destination.``` I've tried ```git add remote repo_name repo_link``` and get nothing back. What do you suggest? – Suki Jan 28 '21 at 16:01
  • 1
    @LisaLaw If your local repository is correct (meaning it has its full history, and the sensitive information is gone), you need to add the remote back (which you did), and then `git push -u origin master` (assuming the default branch is `master`, and not `main`, like it is the case for new repositories these days) – VonC Jan 28 '21 at 16:22
  • Great, this seems to have worked. Do I have to do all my pushes like this now or can I go back to ```git push``` on its own? – Suki Jan 28 '21 at 16:30
  • @LisaLaw No, the next push (from the default `master` branch) will be a simple `git push` – VonC Jan 28 '21 at 16:31
  • Fantastic, thank you so much for all your help. :) I think I've got all my doubts cleared now, hehe. At least for this question ;) – Suki Jan 28 '21 at 16:37
  • @LisaLaw Great! Well done. Until your next question, then. – VonC Jan 28 '21 at 16:37