Technology

59569 readers

3825 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

222

Deleted GitHub data is forever accessible to anyone, researchers claim | Cybernews (cybernews.com)

submitted 3 months ago by AnActOfCreation@programming.dev to c/technology@lemmy.world

16 comments fedilink hide all child comments

“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.

you are viewing a single comment's thread
view the rest of the comments

[–] eager_eagle@lemmy.world 14 points 3 months ago (6 children)

from their actual report

As long as one fork exists, any commit to that repository network (ie: commits on the “upstream” repo or “downstream” forks) will exist forever.

   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.

[–] Dave@lemmy.nz 11 points 3 months ago (5 children)

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.

[–] grrgyle@slrpnk.net 5 points 3 months ago (1 children)

In my experience with GitHub, dropped commits remain indefinitely accessible. I use this to my advantage on pull requests with lots of good commit context that I don't want totally lost in a squash: by copying result of git log --oneline main... into the PR body. The SHAs remain accessible even after I force push my branch down to a single commit.

I think there is a theoretical limit to how long these commits remain accessible, but I haven't ever hit it in my daily usage.

[–] Dave@lemmy.nz 2 points 3 months ago

Ah thanks, this explains it a bit more.

load more comments (3 replies)