@lunch How does that even hide the token.
Pretty sure that's a bullshit excuse and that using strings(1) or similar on the binary will spit it out.
@owl reading the source, it looks like they made it at least slightly more difficult than that, but definitely doable just using a debugger
@owl also interesting: looks like they implemented their own OAuth2 library for Qt specifically for MS/Azure services named "Katabasis"...
I wonder what they do if/when they find their credentials out in the wild.
I remember Twitter were doing this for a while, refusing to accept that people will extract it if they put it in their app.
@lunch I think its a normal behavior to use a token to connect to an external service (here microsoft).
And it's normal to not distribute it with the source, someone could reuse it to do bad things (bruteforce microsoft account).
Many opensource software do the same. If you want to build it yourself you can get a token from Microsoft.
@lunch It depends, here it uses oauth2, so you don't have to trust the launcher a lot (ok it's kind of stupid because you build it yourself).
That one of the modern way to do clean authentication without giving your Microsoft password to the launcher.
@lunch It adds also the advantage that a Microsoft user can untrust the launcher from his Microsoft account, and it will invalidate the login from Microsoft.
Plus a system of permissions, so the launcher does not have access to your full Microsoft account.
@Tjiho if you can *reproducibly* build it from source then this is a nonissue, but that's not even possible now at least with the way it is right now
@lunch you're right, this is the limit of the thing but it remains complicated.
I'm not an expert with oauth but here it uses the `public client flows` which is a flow intended for such cases.