Write access for authentication via GitHub

[AlexWayfer]

Hello.

I'm trying to sign-in at https://web.pulsar-edit.dev/

And this is what I see:

This application will be able to read and write all public repository data.

Do you really need an access to write into my public repositories?

I'm just trying to sign in at site.

[Spiker985]

The token it creates/presents to you can be used for Pulsar Package Manager (PPM) in order to publish packages

[AlexWayfer]

1. There is nothing what presents me a token, as far as I know.
2. I think, there should be different applications for different tasks, as "Sign in to website" and "publish packages".
3. I don't understand why PPM should have write access to my repos, if I publish to Pulsar website.

[confused-Techie]

@AlexWayfer PPR does not need write access to your repositories, and nor is it intended to ask for it.

Your PPR token only needs read access. Which from the source code you can see was the intention. Even looking at the backends documentation about managing your Pulsar account, you can see that when the documentation was written Pulsar was only requesting "Read-only" access. So why this has changed I'm not sure, but I'll look into it.

I almost suspect GitHub's exact definitions of these services has changed, or else there may be something funky going on that we can look into. Can you confirm how you went about creating an account from the Pulsar website?

---

To answer some of your questions you put on @Spiker985 reply.

1. Once you finish getting through this sign on screen you will be given a PPR token.
2. You do have a point there, although at a certain point it becomes problematic, when you consider that already there needs to be a GitHub token to sign PPM into your GitHub account, another token to log the github package into your account, then a Pulsar token, and as suggested then another Pulsar token to publish. Having a Pulsar account is how we authenticate to publish packages to Pulsar as well. The system was designed around using your Pulsar account to do so, and would be rather difficult to change at this point.

But again, this account is supposed to have the least permissions possible.

3. It shouldn't. It doesn't want it, it won't use it. It's an error that it's asking. Although if it's any solace. Even if you do allow this access, Pulsar literally never even stores the token.

[AlexWayfer]

Can you confirm how you went about creating an account from the Pulsar website?

Sorry, I'm not sure that I understood your question.

I was browsing packages at https://web.pulsar-edit.dev/

I saw no button like "mark as outdated", but noticed "Sign in" link at the header and tried it:

I don't know what is "PAT", so I've clicked "GitHub":

That's all. Currently you have to expand "Public repositories" item to see "read and write access" notice, it's hidden by default (what I account as a GitHub's fault and slippery).

[confused-Techie]

No this is exactly what I'm asking. Just confirming that you signed up via OAuth, and ensured we were on the right website. Since this is the first I'm hearing of this issue.

So thanks for that. I'll try to look into what's going on after work today, and see if we can't figure out what's gone wrong.

[DeeDeeG]

So, first off, we may be able to improve this situation by authenticating via a GitHub App, rather than with an OAuth App. More research into this is needed. But there is an explanation why it asks for the permissions it asks for, which is OAuth Apps can't request just read, it's read+write or zero access to repo info. So that is why we needed to do it that way at the time. In the mean-time, PAT's (Personal Authentication Tokens) have a more fine-grained permission model, so you can get a more narrow token that way today while we look into the alternative.

I was honestly surprised to see it too, since when looking back I could recall that where possible, we asked for the least permissions we could. I couldn't recall off the top of my head why we would request such wide permissions.

Upon looking up the docs again (it has been some time since this was set up), It turns out the permissions we can ask for with an OAuth App are very coarse. We can ask for read/write access to the repo scope to get the info we need (especially we need to know whether or not you have write access to your package's repo, before we let you administer that package on our package backend). Or we can not request any access to that information. Which wouldn't enable the Pulsar Package Registry / ppm workflows we are trying to enable.

https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes

So, per some guidance I am seeing on the GitHub documentation now, it'd be good to do something Atom org couldn't do at the time they originally wrote their integration that we mimicked: We should ideally make a "GitHub App" instead of an "OAuth App", if possible.

https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps

As long as ppm can handle that, we should be able to make the switch if/when there is development time to do the research and development to put together the GitHub App as a replacement authentication management approach, vs the current OAuth App approach. As well as implementing the transition in our website's code. (I suppose we would need to gracefully deprecate the "OAuth App" stuff, too, in our own documentation and UI.) And if ppm can't handle it as-is, then we will need to update ppm itself, and make sure that transition is smooth for users, so such a migration could be that bit much harder if ppm needs any changes to handle it.

But potentially there is a better way available, so I think we should try and move to using a GitHub App instead of an OAuth App, if we can, and as dev time allows.

P.S. Yeah, the token is only ever stored on your local machine in a fairly standard, secure manner. So, we hope that somewhat limits the possibility of misuse of the tokens. For now while we are still providing an OAuth App authentication flow option. (And again, if the permissions feel too broad, PATs are an alternative that we support already today, since they have been more flexible all along, and since integrating them as another option was fairly easy.)