228 private links
AI is not good now: https://github.com/dotnet/runtime/pull/115733
60req/hour for unauthenticated users, that's not much!
Forks are copy of the original repository. As such, leaked credentials remains in the forks.
A deleted repository still has the commit from the original repository and it can access it. Demo on youtube
Example:
They immediately deleted the repository, but since it had been forked, I could still access the commit containing the sensitive data via a fork
Also related to private repositories:
We demonstrate how organizations open-source new tools while maintaining private internal forks, and then show how someone could access commit data from the private internal version via the public one.
How to access the data? By direct access to the commit.
If you know the commit hash you can directly access data that is not intended for you.
AND
Commit hashes can be brute forced through GitHub’s UI, particularly because the git protocol permits the use of short SHA-1 values when referencing a commit.
because there are 65.536 minimal values, and 16.777.216 is a more realistic approach (6 characters per commit).
Also, "deleting a repository or fork does not mean your commit data is actually deleted."
The flaw also exists in other version control system products.
How to set significant labels on a Kanban?
Cross-posting on multiple platform.
The project is hosted on Github: https://github.com/rknightuk/echo
An argument for GitHub against self-hosted source code forgery.
The main reason is I’m kind of tired of the amount of spam bots that keep signing up to my Gitea.
Creating blog articles from github issues. Not bad as an idea, but it creates a dependency between Github and your personal blog that I dislike.
The blog: https://github.com/Kerollmops/blog
A collection of awesome projects. It is great to find good quality projects in it.
A list of the most-starred projects on Github
Lint Github workflow files
Github Worflow trigger cheatsheet
A map of github projects :)
Argument against Github that are mostly arguments against monopolies.
In order to measure this, the developers had to set up a JS server. Which is a routine... and that's cool Copilot helps with that. What would be a game changing is when specialized dev task can be done by Copilot.
A tool to make better README and the easy way.
It is especially useful for GitHub.
Nobody is entitled to support from volunteer FOSS projects, but they absolutely do deserve not to have the issues they took time to file actively thrown away. If you haven't fixed the bug, it stays open.
And nobody wants to find this issue closed if they found the same problem...
Reminder that this is not about closing bugs/PRs/requests in a NEEDINFO state where the user isn't being responsive. This is about indiscriminately closing "stale" bugs on a timer with no regard to whether they're still valid