Hi!
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?
Thank you,
Maciej
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
How should I go about this?
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?
Private repos on Github, still just password authentication for now.
Create a personal access token, as described on the GitHub documentation. Add that token before the github.com in the url field, like so:
{
packages = {
scripts = (
{
descriptions = {
de = "Florian Pirchers Sammlung von Glyphs Skripten.";
en = "Florian Pircher’s collection of Glyphs scripts.";
};
installName = "Florian Pircher";
titles = {
de = "Florian Pirchers Skripte";
en = "Florian Pircher’s Scripts";
};
url = "https://PERSONALACCESSTOKEN@github.com/florianpircher/Glyphs-Scripts";
},
);
};
}
If you use an SSH key to access the repository, then that might work, but I have not tested that yet.
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.
Yes, Glyphs recognizes local package indices (and also local url fields). In preferences, specify the file path (no file://…):
/Users/Florian/packages.plist
The value of the url fields must be prefixed by file://, but local package indices can also point to non-local repositories.
Silly me, that works. The repositories are hosted on GitLab, so I used access token instead of username/password and it seems to work.
Good to know that the plist can be local, that will do. Thanks!
Thanks for the explaination. I was curious about the optimal procedure, too.
That is in the plist, right? Which means that the access token is public, if that plist is public, right? Is that a good thing?
Yes.
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.
Why do you like to make the private package file pubic?
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.
I’ve set up a demo at https://florianpircher.com/glyphs/private/packages.plist
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:
https://someuser:somepassword@florianpircher.com/glyphs/private/packages.plist
This is what it would looks like in Glyphs’ preferences:
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.
Wow, this is incredible. Thank you so much! Exactly what I was looking for 
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:
url = "https://USERNAME:PERSONALACCESSTOKEN@github.com/florianpircher/Glyphs-Scripts";
But now it works, thank you @FlorianPircher!
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.
Those options sound plausible. Thank you so much!
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.