"Warning: this is a potentially destructive action" when trying to make a repository private

What will happen if I make a Github repository private ?

I have deployed the app on AWS, but I think I haven’t deployed from it, I just have API Calls in the code to aws services.

The main reason I wanted to make it private is due to FEAR. Constantly I am getting security alerts from Github, which I don’t know how to fix or what do they even mean. And why I care about this security faults? Well because in this app I have in AWS, there are services which cost money, like S3 Image. Right now the app is not being used by nobody (I built it for my portfolio) so it costs me 0.01$ each month. BUT, I fear if some day a hacker or something will be able to hack the app try to make 1 million request or who knows and I will be charged hundreds or thousands of dollars on my credit card.

I TRIED To put a Billing Limit on AWS but it doesn’t exist. There are only billing alerts! And they are monthly, so it doesn’t serve me at all.

Another option would be to just close the AWS account but then I would miss a good quality app for my portfolio.

Thank you for your help!

It’s fairly self-explanatory: nobody will be able to see it unless they are you or you have granted them access.

If you have included API tokens/private config keys/etc in the repo code (regardless of if it is private or not), remove them and use environment variables (which are local to your machine). Then it shouldn’t matter if it’s private or not, because no-one can use the code without setting up their own AWS instances.

You should not have a situation where someone else can use your AWS account. If you have included keys/tokens etc in a public repo, this is similar to (for example) you posting your email passwords up on the internet, or your bank account login, or whatever. If this is the case this is not a smart thing to do.

What are they? It would be a very good idea to investigate what they are and why you’re getting them.

Mhhh, here’s one of them

Remediation

Upgrade set-value to version 4.0.1 or later. For example:

set-value@^4.0.1: version “4.0.1”

Always verify the validity and compatibility of suggestions with your codebase.

Details

CVE-2021-23440

high severity

Vulnerable versions: < 4.0.1

Patched version: 4.0.1

This affects the package set-value before 4.0.1. A type confusion vulnerability can lead to a bypass of CVE-2019-10747when the user-provided keys used in the path parameter are arrays.

So what do you think the warning is advising you to do here? And do you think that making the repo private will change the warning in any way?

No idea, thats why i asked :sweat_smile:. You can stop the “education” attitude here with me trying to “sort It out for yourself”. I’m a busy person, I’m just trying to solve a problem here brother.

Is there any of the words in here you do not understand? The instructions seem very clear to me.


It looks like you are running dangerously out of date package versions and you are receiving warnings that tell you what versions you need to upgrade to.

Emm, this is a critical part of building software. If there are errors, YOLOing it and just not bothering to read the error message is going to bite you. As @JeremyLT says, the warning is really clear, particularly as it’s telling you exactly what it recommends to mitigate the problem. Again, what do you not understand about this warning message?

It’s a warning about a package you have installed in your project, so the error isn’t from GitHub itself, which means that you have turned on the bot (dependabot) that notifies you of outdated dependencies.

And the warning may be about a dependency (or a dependency of a dependency) for some package you only use in development – in that case you may be able to ignore the warning. But you need to investigate it, and you need to check each warning to see if it’s valid or not.

Edit: you want instructions on this?

  • you have turned on a feature of GitHub that notifies you of outdated dependencies.
  • some or these may be potential security threats
  • these outdated dependencies may be dependencies of dependencies – ie you have installed some package which depends on other things and one of those other things is outdated.
  • by outdated dependencies, I mean that there is a newer version available.
  • GH is opening issues automatically that say “you may need to update these dependencies”. It’s not being cryptic about it, it’s literally telling you in plain language.
  • I’m asking you questions because I don’t understand how you cannot see that:
    1. it’s telling you that you might need to update dependencies, and
    2. making the repo private has absolutely zero effect on whether a dependency is up to date or not
  • so you check what the dependency is, and you check if it’s a dependency of something else
  • you go to the repo of the dependency
  • you look at the issues there, you look at the release notes if there are any, you assess whether it needs upgrading
  • if you’re unsure or there isn’t any info, you Google for the issue, you look on Stack Overflow
  • then you do that for every dependency listed in every issue that GH has raised
  • then after a while of doing this you can generally assess quickly which issues can be ignored and which need attention :man_shrugging:t3: if you are too busy to do all of this, then just ignore the warnings and errors
4 Likes

Static references to vulnerable code aren’t the problem, code running with vulnerabilities is. Hiding the references to the dependencies is not going to make your deployed code any more secure.

Sure having the repo visible will make it searchable (you can search GitHub for vulnerable codebases), but any attack will be on the deployed code, not the repo.

Bad actors do not need access to your repo code in order to find and attack the deployed vulnerable app. So that is what needs to be secured.


This is just an opinion, but I find it more likely that you as a developer will make some mistake that exposes sensitive information than some vulnerable dependencies giving access to your AWS account. I’m not suggesting you shouldn’t want to update your dependencies, just trying to put it into some perspective.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.