If we are using GitHub Enterprise inside the company and the Private Mode is enabled, what's different between a public and private repo?
Typically, your Github Enterprise instances are visible to developers within your organization. However, also within your organization, you might want to have a more fine-grained control of who is allowed to see which repository.
Because of that, Github Enterprise knows two visibilities of repositories - private and public.
It's straight forward, as the documentation tells us:
Public repositories are a great choice for getting started! They're visible to any user on your GitHub Enterprise instance, so you can benefit from a collaborative community.
Private repositories require a little more setup. They're only available to you, the repository owner, as well as any collaborators you choose to share with.
Edit for clarification:
The Github Enterprise private mode, does regulate access on a different level: it merely defines that the forge itself cannot be accessed without being logged in.
Since May 23rd, 2019, you also have the internal repository visibility (still in beta)
The internal repository visibility option is available to customers with an Enterprise account.
This new visibility option makes it easier to innersource code and projects to your organization members while restricting access to outside collaborators.
That might be easier to manage than a private repo, where you need to add collaborators: here, every collaborators (to your organization) is already added to an internal repo: the rest of the world is not.
See more at "Creating an internal repository":
You can use internal repositories to practice "innersource" within your enterprise account. Members of organizations in your enterprise account can collaborate using open source methodologies without sharing proprietary information publicly. For more information on innersource, see GitHub's whitepaper "An introduction to innersource."
All members of the enterprise account have read permissions to the internal repository and can create issues in the repository.
Members of the enterprise account can't edit the repository's code directly, but they can fork the repository and create a pull request from their fork.
Internal repositories are not visible to people outside of the enterprise account, including outside collaborators on organization repositories.
Private Mode for the GitHub Enterprise instance is a different concept than Public/Private settings for a Repository.
In private mode, GitHub Enterprise requires every user to sign in to access the installation. Anonymous clones over git:// are disabled and—if built-in authentication is enabled—new users can't sign up and must be invited by an administrator.
So the private mode setting really means that users must log in to access the instance. If your GitHub Enterprise instance is on a public-facing IP, it needs to have private mode enabled.
Public and Private repositories will still affect visibility/access to users that belong to an Organization, Team, or Repository.
Public Repositories : They're visible to any user on your GitHub Enterprise instance.
Private Repositories : They're only available to the repository owner. You can add collaborators of your choise to share with.
You can keep all the repositories in the your organization's GitHub Enterprise to Private by default with exception to a few repositories which contain sensitive information. This is a good way to keep reusing the code in the same organization. If you have a repository you want made Public instead of Private you can request to your GitHub Enterprise to white-list it.
Related
I want to deploy my github project to firebase using github actions and the project id is exposed in the .firebaserc file.
Is it safe for make to commit my code to github with the GCP projectID exposed?
Also, I've tried to search for a work around but it seems not to be a concern.
It depends entirely on what you mean by "safe", and what you are giving up to anyone who knows (or can guess) your project ID.
If your exposed project ID has computing resources allocated to it, and those resources can be discovered by what you provide in source control, and those resources are accessible to the public, then you are on the hook to pay the billing for those resources if they might get used.
If your exposed project ID has any public API endpoints that are not protected by some form of authentication, anyone could possibly discover those endpoints, reverse engineer them, and use them to gain the data that those endpoints could possibly deliver.
Even if you do not expose your project ID, someone could guess it and still do all of the above.
In general, I personally would not put any information related to the identification of my projects in public source control. I would leave that a matter of configuration, to be read from environment variables or git-ignored files that must be provided by the person working on the project. That is the safest and least problematic approach.
However, if you want to sacrifice security for convenience, that's entirely up to you. Just be sure you are comfortable with the ramifications of doing so.
See also: Is it safe to expose Firebase apiKey to the public?
Running Github Enterprise 2.18. Is there any way to determine via the API that a user is dormant? I don't see a specific call for it anywhere...
To answer your question....
Running Github Enterprise 2.18. Is there any way to determine via the
API that a user is dormant?
No, it's not possible using GitHub API (Enterprise or not).
GitHub has a strict privacy agreement for it's users. Since repositories can
be public as well as private, you're out of luck getting dormancy info via their API.
GitHub's own help page mentions it in their "Reports" section:
If you need to get information on the users, organizations, and
repositories in your GitHub Enterprise Server instance, you would
ordinarily fetch JSON data through the GitHub API. Unfortunately, the
API may not provide all of the data that you want and it requires a
bit of technical expertise to use. The site admin dashboard offers a
Reports section as an alternative, making it easy for you to download
CSV reports with most of the information that you are likely to need
for users, organizations, and repositories.
Specifically, you can download CSV reports that list
all users
all users who have been active within the last month
all users who have been inactive for one month or more
all users whohave been suspended
all organizations
all repositories
The help page also goes on to show examples on how to invoke the report data via CURL (you could do this with other methods as well, like in Powershell, which I prefer)
curl -L -u username:password/token http(s)://hostname/stafftools/reports/dormant_users.csv
You could make use of that data, without the API and parse it into your application. The world is your oyster.
We have given anonymous user to upload files to nexus repository manager.But it was not a good practice.We need to limit access to each project.Only relevant users should have read access.How can i fulfill this requirement.
Currently we have created two repos lib-release-local and lib-snapshot-local and inside those repos we are managing our projects.In this design how we can implement permission schema.
NXRM3 has a piece called content selectors, which are pretty much designed for what you're describing. Using a query language you can create a privilege which limits what folks can see or do in a certain repository (or format). Then you can assign that privilege to a role and that role a set of users (also removing the ability for them to view *).
See documentation for more. I also advice if you have questions about content selectors and their implementation asking on community.sonatype.com forums where the development team as well as support monitor.
Are there scripts for exporting and importing all Apigee Edge objects, such as developers, users, apps, caches, key value maps, etc?
To clarify, it would be nice to have non-runtime objects as a priority vs. the runtime data contained within. E.g., the current content of caches are not as critical as just having the cache object available.
I have released a tool that can be used to retrieve Apigee organization settings. This tool has been in use internally at Apigee for some time, but this is the first time it has been released to the public. It uses the Apigee management API to pull configuration data, and that data to be pulled is configurable. The data is stored in a hierarchical directory structure, which can be archived, explored, or used to compare organizations. It can be used with both the Apigee Edge cloud and on-prem offerings.
A few caveats:
This tool does not retrieve all data from an organization. For example, it does not retrieve API proxies. Use the Apigee management UI or management API to retrieve API proxies.
The tool is composed of a few bash scripts. It has been successfully run on Linux and Mac OS X.
The tool does not write data back into the organization, although the files it retrieves can often be POSTed back to the organization using the management API.
This tool is released as-is. It is not officially supported by Apigee.
Find the tool at the api-platform samples site (https://github.com/apigee/api-platform-samples) in the tools/org-snapshot directory.
There is work planned to provide a tool that will export/import provisional data (such as apps, developer, products). Other aspects of an org's configuration require access to the production Cassandra database, which cannot be given out publicly. We have a provisional tool for in-house use that we are currently hardening. If the consumer tool (when it is available) doesn't provide all of the backup support you need, you will need to log a support ticket for them to run the in-house tool.
There are scripts for importing a set of objects (developers, apps, API products) that work with the sample proxies that you can find on GitHub:
https://github.com/apigee/api-platform-samples/tree/master/setup
For Perl programmers: see also Apigee::Edge on CPAN
I have a private project, and i want it hosted on google code. this project is just for project members. How to enable browsing and submitting SVN code only for project members? I don't want other people to be able to do this.
How to disable public access to the source code in Google Code?
There are no read restrictions on Google Code, so there's no way to create a project that's completely private.
If you want a private code repository, I recommend you check this question:
Free version control server provider for non-public projects
You can't...
We only intend to host projects that
are open source software projects,
documentation projects directly
related to open source software
development, and projects for the
development and maintenance of open
standards.
http://code.google.com/p/support/wiki/MakingHostingBetter
I think you can't.
Projects hosted at googleCode must be public!
Check FAQ
You can't, but you can hide some tabs
There are of course alternatives to Google Code. BitBucket has free hosting and allows private repositories for free. There are some limits, but for a reasonably small project with few team members you might be OK.
It's currently not possible.
However, there are currently 1663 stars on this feature request. Since this is a feature that you want, you should go along and star it too.
The more stars the feature request gets, the higher the priority it gets. (Well, at least that's to be expected.)