[1/2] I think the entire scheme using github-only, is flawed. You probably want to set up your own server, which would accept end-user HTTP requests (with proper authentication), and will communicate with github - in this way your github repo will be insulated from any prying eyes. If you don't expect too much traffic, you might even be able to use Wolfram Cloud for that, deploying a custom APIFunction and setting up proper permissions. In this way, your secret token will only unlock execution of that API function in the cloud, ...

[2/2] ... and that APIFunction will be responsible for actually checking out the new version of your package from your github repo, encoding it, and returning the response to the WL client, which would decode it and run / install updates. You can set cloud permissions so that the users will have a permission to execute the cloud object / APIFunction (provided that they have a secret token), but not read that CloudObject or modify it - so the code you put there, that will actually communicate with github (using this time a real github token - which of course you don't share), should be safe.

But even with all that, I would still follow the suggestion to have a separate github private account with just that repo. Github's story for read-only access to repo seems to not be particularly promising, despite the huge demand expressed in that thread. But there seem to be some workarounds and ways out (even with the setup I described above, it is better to not give your cloud API a write permission)

One last thought: you will obviously have to think also about protecting your code from being read. You may find this Q/A helpful, although you probably are already aware of most of the suggestions discussed there.

Hi @LeonidShifrin, and thanks for your feedback. Is it possible to use Wolfram Cloud with free account? I only have <5 collaborators, so not much traffic definitely. Yes I am aware of code protections against being read. I have implemented a few of them for some pieces of codes I wanted to protect, but don't need them so much, as most of the code is better be readable. I only want to implement a secure way to grant access to github but still avoid troubles on my git repositories :)

If you can make me an xample, that would be great. What I need is to be able to get the tag list (with download links) and the list of commits since last tag.

Well I guess I misinterpreted your request. If your audience are your collaborators, then I don't understand your collaboration model - i.e. why not give them full access to that repository? You can set things up so that changes are only possible via pull requests. Or do you want them to only have access to part of your codebase? This all sounds more a workflow / github / permissions issue to me. Also, what does this have to do with running your app in Mathematica and (auto) updating it? Your collaborators can presumably check out proper branch, as long as they have access to the repo.

Our collaboration model is...kinda strange. I can just say that they currently have access to the new code but they forget to update it, or update only part of it. This in turn means the claim bugs that are not there. I prefer to avoid discussions, so I wrote an easy autoupdate script :) in any case, it might be enough something even less secure than what you proposed (even though your proposal sounds interesting for some future plans I have...).

At the moment I have hidden the token of a second account in an encoded file that hides it together with tons of similar ones in an array, then the update script, also encoded, choses the right one to query github. The token is not loaded in memory until the update script starts running, and after the query, the array of tokens is removed from memory. So loading and deleting happens all with the single update command. I don't know if it is possible to "pause" execution during a command... Of course all critical functions are protected, reaprotected and locked. What do you think?

It's hard for me to assess how well your current scheme fits your needs, but it all boils down to the level of security you need. From what you have described so far, your scheme seems fine. The critical part of course is the manipulations with array of tokens. You may protect your own functions, but built-ins like Part and other list-manipulation functions can be easily overloaded in such a way that they will log their input and output, in addition to their normal actions. And as soon as someone gets an array of tokens, it is just a technical matter to try them all and find the working one.

But pretty much any single machine - based security scheme will have vulnerabilities. The scheme with Wolfram Cloud is better because your end users don't need the token at all, they simply send a request to the cloud, and it is the cloud code that has that github token and actually sends the request to github. But the cloud code is not accessible for the users and is not executing on their machines. You should be able to use the free account for the cloud, as long as the number of users is not too large and updates are not too frequent, which seems to be the case for you.

Hi! Thanks for support! Yes I agree it-s better if the token is not distributed at all! I was also thinking about locking decode using machineID but maybe there are ways to change it... Yes this is the case. DO you have an example of implementation?

I don't have anything ready. I might look into it (this topic is of interest for me as well), but I can't promise when, since time is scarce at the moment, so you will be better off not depending on this. Or, we can do it this way: if I don't come up with something by Monday, don't wait for me and try on your own. You can always post specific questions on the site, and if they are short and self-contained, you have good chances for getting help.

I have no hurry. I am going on leave tomorrow, coming back in 2 weeks :)

Ok, sounds good. If I have something, I will reply back either here or below the original question, or simply post an answer there. Have a good time on your leave :)