I want to know whether the following thing can be achieved by Github Actions or other Github feature:
I have a repository having hundreds of file, I want to share only a few files by my developer/ team. (They can only able to saw those few files, I shared).
The program can only run successfully if a developer has all those files(hidden and unhidden both).
So, is there any way through which I can hide all my code from the team, and whenever they pull the repository, all those hidden files should be downloaded in an encrypted way, and rest unhidden files can be accessed by the developer and they can execute the whole repository successfully.
If it's not possible with Github, is there any alternative tool through which I can achieve this?
Thanks
Git does not provide access control to only parts of repositories, and it's not intended to. From gitnamespaces(7):
The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers.
So if you want to give a user access to only a few files, they need to live in another repository with separate access control (that is not a fork of the original). That will involve a separate history.
If the user needs the other files in order to develop the software, then you'll just have to give them access, or you'll have to provide pre-built binary assets they can download to build against.
In general, it's not practical to not trust your developers with full code access. Usually one protects this access with legal means, like non-disclosure agreements, not technical measures, since technical measures are usually easily bypassed.
Related
for a small startup , I employed some remote developers. However, I only want to reveal the necessary codes to a certain developer, not the entire source code.
is this kind of feature offered by GitHub? If not, please provide a workaround.
Many thanks
With git repositories in GitHub there is no way to prevent a developer from cloning the whole repository and GitHub can't filter the contents of the repository to leave out part of the data. Permissions in GitHub can only prevent access to a repository, make the whole repo read-only or grant write access to the repository.
If you really want to limit access, you'll need to split your solution into multiple pieces, each in their own git repository. You can then set permissions for each repository in GitHub.
As a developer myself I caution you against this. A developer with only part if the sources would have a hard time verifying their changes work in way you intend to and it might make it much harder for them to debug any issues that happen in development.
we have a UI mono repo using NX workspace , we are sharing code with multiple teams.Is there a way
To allow access to Team members only the modules they own?
To create PR which can be viewed and approved by module owners (Team only)?
No, read access = entire repo. If you're using a mono repo, then read access to all or no access. See: Information about Managing Teams
Read access for PRs is same as above, but you can require certain groups of approvers for PRs that include certain paths when merging to particular branches. See Information about Code Owners and Protected Branches
No, there is no way to restrict access to only part of a repository. The Git documentation is very clear that anyone who can read or write to a repository can access all of the contents of that repository. From the gitnamespaces(7) manual page:
The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers.
If you need granular permissions, you need multiple repositories. I generally recommend against monorepos because they usually end up growing very large and then performing poorly (well after it's too late to fix), but this is also another reason why they're a bad idea.
As for PRs which can be approved by module owners, it depends on the platform. GitHub has the CODEOWNERS file, which can be used to mandate that files owned by certain teams require a review from that team.
I have signed up my organization to a GitHub Teams free plan, and we are considering pushing our code to private repositories on GitHub. Our projects consist of decades old legacy code and there are lots of hard-coded credentials (not only in the code, but also in comments) for various servers and databases.
I do not want to make my team change all this code to store credentials in config files, I am not 100% sure our various tech stacks support this. It would also be very time consuming, and there is no guarantee we can find every single reference of credentials. I’m just wondering if it is safe to push the code with all these credentials even if the repositories we create are not public?
Storing your code on GitHub is no less secure than storing it anywhere else. For example, GitHub generally takes significant effort to secure repositories, and staff are not permitted to look at the contents of private repositories without the consent of the repository owner. Pushing this code to GitHub will not intrinsically expose it any more than storing it on any other server.
However, having said that, storing credentials in your repository is a security problem regardless of where you host that code. It is easy for a repository to accidentally leak for many reasons, due to server misconfiguration, laptop theft, or various other situations. You would be well served to put at least a modicum of effort into using a more secure practice for storing credentials, if for no other reason than that you will have them stored in a single, secure place where you can find them all. For example, rotating credentials is much easier when they all live in a tool like Vault and you can easily rotate a compromised credential across all systems.
So, in general, what you are doing is not very secure, but using or not using GitHub will not change that.
I have a project just getting started at http://sourceforge.net/projects/iotabuildit/ (more details at http://sourceforge.net/p/iotabuildit/wiki/Home/) that is currently using Mercurial for revision control. And it seems like Mercurial and SourceForge almost have all the right features or elements to put together the collaboration mechanism I have in mind for this project, but I think I'm not quite there yet. I want people to be able to submit, discuss and vote on individual changes from a large number of individuals (more developers than a project would normally have). And I want it to be as easy as possible for users to participate in this. The thought right now is that people can clone the "free4all" fork, which is a clone of the base "code" repository, or they can create their own fork in their own SourceForge user project (SourceForge now provides a workspace for every user to host miscellaneous project-related content). Then they can clone that to their local repository (after downloading TortoiseHg or their preferred Mercurial client). Then they can make modifications, commit them, push them to the fork, and request a merge into the base "code" repository, at which point we can discuss/review the merge request. This all is still far too many steps, and more formal than I'd like.
I see there is such a thing as "shelving" in Mercurial, but I don't see how/if that is supported in the SourceForge repository. And there probably isn't a way to discuss shelved changes as there is merge requests.
I'm looking for any suggestions that would make this easier. Ideally, I would like users to be able to:
Specify any version that they would like to play, and have that requested version extracted from source control hosted for the user to play at SourceForge (because the game can't be played locally due to security restrictions the Chrome browser properly applies to javascript code accessing image content in independent files)
Allow the user to download the requested version of the project for local editing (a C# version built from the same source is also playable locally, or Internet Explorer apparently ignores the security restriction, allowing local play in a browser)
Accept submitted modifications in a form that can be merged with any other compatible "branch" or version of the game that has been submitted/posted (ideally this would be very simple -- perhaps used just uploads the whole set of files back to the server and the compare and patch/diff extraction is performed there)
Other players can see a list of available submitted patches and choose any set to play/test with, then discuss and vote on changes.
Clearly some of these requirements are very specific, and I will probably need to write some server side code if I want to reach the ideal goal. But I want to take the path of least resistance and use the technologies available if much of the functionality I need is already almost there. Or I'd like to see if I can get any closer than the process I outlined earlier without writing any server code. So what pieces will help me do this? Does Mercurial & SourceForge support storing and sharing shelved code in the way I would want? Is there something to this "Patch Queue" (that I see, but can't understand or get to work yet) that might help? Is there a way to extract a patch file from a given set of files compared to a specific revision in a repository (on the server side), without having the user download any Mercurial components?
It sounds like something you could do with mercurial queue (mq) patch queues. The patch queue can be is own, separate versioned repository, and people can use 'guards' to apply only the patches they want to try.
But really it sounds even easier to use bitbucket or github, both of which have excellent patch-submission, review, and acceptance workflows built into them.
At my work I'm on a separate network to my colleague due to clearance reasons, and we both need to share code. I am wondering what the best versioning system would be? There's got to be something better than having project1.zip, project2.zip , etc - but something not as expansive as git or hg.
I would still recommend Git, as it allows to:
make a bundle (only one file, and it can be an incremental bundle)
mail that bundle to your colleague (meaning it will work even if your separate networks have no other way to communicate)
The idea is to exchange one file (from which you can pull any new history bundled in it).
And Git is very cheap for creating and adding a repo when an existing code base is already there.
That being said, any communication procedure will have to be approved by your employer: don't bypass any security measure ;)