Recently I tried adding our nonpublic company GitHub repository to G3 Plugin Manager by adding a custom plist. The Plug-ins do appear in Plugin Manager, however I can’t install them. I receive this error: Failed to clone repository from [repo URL] to [local path].
Knowing that items from public repos install without an issue I assume this is because our repo requires authentication (passing an access token?). Can you please help me troubleshoot this?
I have the same issue. I can see my private repos (to which I have full access to) in the plugin manager after adding my publicly available packages.plist url to Addons>Alternate Plugin Repo, but cant actually get to clone them: Failed to clone repository etc
What repository software do you use? Self hosted, or a private repository on a shared host like GitHub or Bitbucket? And what security do you use to access the repository? Password protection, or SSH-key, or something else like a per-app token?
Can packages.plist be a local file? I tried file:///path/to/packages.plist, but the plugin manager does not show the plugin and Glyphs did not show any error messages.
Generally, I would advice against publishing a personal access token as part of your plist. Keep the plist and the token local on your Mac.
There might be a way to only allow a narrow set of permissions for a personal access token (such as only read and no write permissions) in which case it would be OK to publish it. Continue on this path cautious. Here be dragons.
If you want to share a plugin with someone, it (the plist) needs to be public, right? And in return, if you keep the plist file local, you cannot share the plugin. Or am I twisting things again?
In that case, you can place the packages.plist behind an authentication layer. For example, if you serve the public packages.plist over HTTPS, you can use HTTP Basic Auth, requiring a username and password to access the file.
If you follow the link, you first need to authenticate with a username and password. Use the username someuser and password somepassword to load the protected file.
In Glyphs, you would need to prefix username and password joined by a colon (:) and separated by an at sign (@) after the https://, like so:
In HTTP Basic Auth, you can have multiple users with their own passwords. So, when working in a team, create a user for each member. If a team member leaves, you can remove that one user from the list of allowed users while all other users can still access the private packages.plist.
Setting up HTTP Basic Auth differs depending on the hosting provider, so I can not give you much help with that, but you’ll find good tutorials for most server setups online.
Hi all, I only got to trying this out now. I could not get rid of the Failed to clone repository […] message until I put my username in the url field of the .plist in addition to the access token, like this:
Sorry for stirring this up again, but now that I finally had some spare minutes to try to set it up as you described, @FlorianPircher , I still wonder:
I want to share a plugin with a small team. The plugin is in a private repository. Even if the few users will have to access the plist HTTP basic auth, there still needs to be some credential in the plist in order for the access to the repo. There is no way to generate a PAT in github just for a single (that one private) repository. And I don’t want to add a general PAT into that plist, as that one is still clear text and shared around.
So the question still flies around my head: how can these few users get access to the private repo?
A — Don’t use GitHub and serve the Git repository from your own server so that you can use the HTTP Basic Auth mechanism for both the plist and the Git repo. I never did that, but the search term you want to look up is Git Smart HTTP (note that there is also ‘Git Dumb HTTP’ – don’t use that, it’s not supported by Glyphs).
B — Create a new GitHub account specific for that small group and invite that user to the private repos. Create a personal access token for that user with read access on the repo level and put that PAT into the plist.
A word of caution: I have tried the new tokens described below and they caused some vague issues (for example, plugins would sometimes no longer update). I will update this once I know more.
The fine-grained personal access tokens (currently in beta) from GitHub appear to solve the access control issues of the current system. The new tokens can be scoped to only a subset of repositories and be limited to read-only access of the Git repository and none of the other GitHub extras.