There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Deleted GitHub data is forever accessible to anyone, researchers claim | Cybernews

“The implication here is that any code committed to a public repository may be accessible forever as long as there is at least one fork of that repository,” the report’s authors claim.

Am I dumb or is this exactly the purpose of forks? I feel like I’m missing something.

hexagonwin ,

if it was never public/forked i guess it’s alright…?

Aatube ,

*if it was forked or is a fork of something public. Only commits made while public can be read.

I feel like I’m missing something

You should read the original research article, which has its own thread someone else linked below. Basically, people often delete a fork after testing the public repo by committing an API key, which can be read using the method mentioned, which GitHub claimed was an intentional design feature.

Boozilla ,
@Boozilla@lemmy.world avatar

I find the language of the article a little confusing, too. But I’m a noob when it comes to GitHub. I have a couple of private projects that I’ve never shared, so not sure if this applies to me or not. We also plan on transitioning to GitHub at work. It’s always smart to assume nothing ever gets truly deleted from an internet service.

Dave ,
@Dave@lemmy.nz avatar

The article is really not clear. Is it saying if a project is forked, then the original is made private, the fork can access data from the private fork?

potentially enabling malicious actors to access sensitive information such as API keys and secrets even after users think they’ve deleted it.

Is this saying people misunderstand git and think committing a deletion makes people unable to access the previous version? Or is it saying the sharing between public and private repos can expose keys in private repos?

If you accidentally commit an API key into a public repository… you need to roll that key. Even if it was deleted completely, someone still could have accessed it while it was there.

eager_eagle ,
@eager_eagle@lemmy.world avatar

from their actual report


<span style="color:#323232;">As long as one fork exists, any commit to that repository network (ie: commits on the “upstream” repo or “downstream” forks) will exist forever.
</span>

<span style="color:#323232;">   This further cements our view that the only way to securely remediate a leaked key on a public GitHub repository is through key rotation. We’ve spent a lot of time documenting how to rotate keys for the most popularly leaked secret types - check our work out here: howtorotate.com.
</span>
Dave ,
@Dave@lemmy.nz avatar

I’m still not sure that answers it. If I fork a project, and the upstream project commits an API key (after I’ve forked it), then they delete the commit, does this commit stay available to me (unexpected behaviour)? Or is it only if I sync that commit into my repo while it’s in the upstream repo (expected behaviour)?

Or is it talking about this from a comment here:

Word of caution 2: The commit can still be accessible directly via SHA1. Force push does not delete the commit, it creates a new one and moves the file pointer to it. To truly delete a commit you must delete the whole repo.

Someone replies and said by having garbage collection kick in it removes this unconnected commit, but it’s not clear to me whether this works for github or just the local git repo.

Perhaps the issue is that these commits are synced into upstream/downstream repos when synced when they should not be?

Like I said, I’m really confused about the specifics of this.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines