is there a way to give a GitHub token only access to pull the latest release from my private GitHub repository. for updating a electron application. I don't want the token to have access to anything else but the latest release only
No, this is not possible. Tokens are generally scoped much more broadly than that (usually to your entire account), and even for ones that are scoped more narrowly, they'd cover at least all of the releases for the repository, if not the rest of the repository contents as well.
If you're trying to distribute software that's in a private repository, you should use some sort of CDN or cloud bucket for doing that (over HTTPS) and implement a suitable digital signature scheme to prevent rogue updates.
Related
I'm trying to figure out, if it is possible on GitHub to give someone read-only access to a specific private repository, allow only to see content, without the possibility of collaboration to contribute with change in the code or readme markup
This is only possible for private repositories managed by organisations.
https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization
If your repository is an organisation one, you can visit:
https://github.com/`OWNER`/`REPO`/settings/access
You can then add a collaborator and set their permission level to:
Read: Recommended for non-code contributors who want to view or discuss your project
Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access
Write: Recommended for contributors who actively push to your project
Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository
Is there any way to restrict the release download only to registered users, for a public repository?
No, there isn't. Access to the releases and release assets are allowed to exactly those people that have access to the repository. For a public repository, that's everyone.
If you want to restrict the set of users who can download release assets, you'll need to either restrict access to the repository or use a different solution. For example, if you want to restrict binaries to paid users, you'll need to build something yourself.
There is a feature named Protected branches API on GitLab API. Basically, you can restrict all the push and merge access by setting their levels to 0.
I have checked Branches section on GitHub REST API document but I couldn't find the equivalent API. How can I restrict merge and push to a branch on GitHub? Also, I want to remove this restriction after some operations.
protect master branch (do not allow any push, merge etc.)
do something
unprotect master branch
Going to the github api documentation, I see they have added protections. This seems pretty clear how to add proctections using API now.
I don't know a way using the API, but in the UI, you can go to settings > branches and then add some protection rules
You can read more about it here
My application calls GitHub API so I have to store GitHub token somewhere. I don't want to publish my token to public repository. I decided to store it in environmental variables. Disadvantage of environmental variables is that I have to set it correctly on all machines (localhost, codenvy, jenkins ...)
Is there better solution?
You can easily move it to Properties file and distribute it on all systems you need. If the security is matter for you, consider encryption of actual values for such file.
Hope it helps!
I am using github to share a set of SPARQL queries:
http://www.boisvert.me.uk/opendata/sparql_aq+.html?file=specific%20sensor.txt
Currently the simple work allows end-users to access queries stored on the github repository, but ultimately I want to allow them to also modify the queries, as with a pastebin, and make use of the repository to better manage the shared system. Ideally I would want end-users who may not be very tech-savvy, to be able to make minor changes to queries to an open, linked data endpoint: so to keep the technology barrier low.
My problem is this: how best to structure the github project and exploit the API to make the most of the available information? I can think of different points:
Currently the project (https://github.com/boisvert/unshaql) holds client code and example queries. Does it make a difference to create an independent project (separate from the web client code) for SPARQL queries?
I would use directories within the project to classify/tag queries, and file names to title them. Are there better alternatives? It strikes me that a hierarchical structure is not a good fit to tags.
When end-users save, a simpler (and cruder) option is to allow them to push their file into just one branch, which holds the examples. A better engineered one would be to allow them to use their github credentials to fork the set of SPARQL queries and edit theirs, but with unaware users, how do I avoid creating a mess?
I think that a rigular Github repository is a rather bad fit for this kind of content. If your users have a GitHub account, you should probably use Gists instead: https://help.github.com/articles/about-gists/ I never used this myself, but it seems perfectly adapted to what you are planning. Your site could become a DB of tags over user-provided gists. That would however lock you into GitHub-specific solutions.
Even if you go for a regular repository, you should not allow the users to commit into the repository hosting your code: that would be a serious security hazard as you won't be able to control the parts of the repository to which they are allowed to commit.
If you setup two repositories, it's rather easy to have the code of a webpage in a repository, and the code automatically commited in another repository (under an anonymous identity so that your users don't have to create a github account).
Also, note that the oauth token should never be stored in a public repository (or the GitHub robots will invalidate it in a matter of hours).
See Hiding GitHub token in .gitconfig for a solution to this sub-problem.