#metabrainz

/

      • mara42 joined the channel
      • 2024-05-31 15251, 2024

      • lucifer[m]
        Yes.
      • 2024-05-31 15211, 2024

      • bitmap[m]
        it seems likely that we'll remove it for applications other than Picard, at least
      • 2024-05-31 15220, 2024

      • lucifer[m]
        Yup right.
      • 2024-05-31 15231, 2024

      • lucifer[m]
        If it continues to be supported it will be restricted to Picard.
      • 2024-05-31 15213, 2024

      • bitmap[m]
        older versions will need it to work correctly
      • 2024-05-31 15217, 2024

      • yvanzo
        If Picard can’t do without it, why would other apps be able to?
      • 2024-05-31 15255, 2024

      • lucifer[m]
        right, but those are hardcoded to query MB so shouldn't be an issue (re: bitmap )
      • 2024-05-31 15239, 2024

      • lucifer[m]
        yvanzo (IRC): yes but it is considered to be insecure and most providers have phased it out entirely.
      • 2024-05-31 15243, 2024

      • mara42 has quit
      • 2024-05-31 15243, 2024

      • bitmap[m] nods
      • 2024-05-31 15207, 2024

      • lucifer[m]
        we create and maintain Picard, and that's why the special casing.
      • 2024-05-31 15226, 2024

      • lucifer[m]
        for instance, google disabled OOB grant in late 2023 entirely.
      • 2024-05-31 15231, 2024

      • bitmap[m]
        did you discuss what flow Picard could use?
      • 2024-05-31 15247, 2024

      • lucifer[m]
        authorization code flow.
      • 2024-05-31 15247, 2024

      • yvanzo
        So we should be able to make Picard rid of it.
      • 2024-05-31 15203, 2024

      • lucifer[m]
        spin up a webserver, and listen to a port on localhost for the redirect.
      • 2024-05-31 15205, 2024

      • yvanzo
        (re: we maintain it)
      • 2024-05-31 15227, 2024

      • yvanzo
        Anyway, getting lost into details, is there a PICARD ticket for it?
      • 2024-05-31 15244, 2024

      • bitmap[m]
        hmm, ok. so the port # would need to be hard-coded in the redirect URI
      • 2024-05-31 15231, 2024

      • lucifer[m]
        right. MeB provider supports multiple redirect URIs (unlike MB which requires one).
      • 2024-05-31 15241, 2024

      • mara42 joined the channel
      • 2024-05-31 15204, 2024

      • lucifer[m]
        so you can have a range of ports to try from. unless you are incredibly unlucky and all of them are occupied.
      • 2024-05-31 15220, 2024

      • bitmap[m]
        and if none work fall back to legacy oob flow?
      • 2024-05-31 15224, 2024

      • lucifer[m]
        for which case, outsidecontext mentioned he would like OOB as a final fallback.
      • 2024-05-31 15225, 2024

      • lucifer[m]
        yeah.
      • 2024-05-31 15230, 2024

      • bitmap[m]
        makes sense
      • 2024-05-31 15259, 2024

      • lucifer[m]
        i personally would get rid of OOB and specify 25 or so very uncommon ports to try from.
      • 2024-05-31 15217, 2024

      • lucifer[m]
        which should reduce the chances of failure to almost none.
      • 2024-05-31 15231, 2024

      • lucifer[m]
        yvanzo (IRC): probably yes, i can look it up later.
      • 2024-05-31 15258, 2024

      • lucifer[m]
        moving back to 4?
      • 2024-05-31 15203, 2024

      • yvanzo
        Didn’t find any, just adding a note to create a ticket for3.
      • 2024-05-31 15214, 2024

      • lucifer[m]
        sounds good to me.
      • 2024-05-31 15234, 2024

      • Sophist-UK joined the channel
      • 2024-05-31 15250, 2024

      • bitmap[m]
        onto 4
      • 2024-05-31 15213, 2024

      • lucifer[m]
        4. Reauthorizing with the provider does not revoke previously issued tokens automatically (they do have an expiry time though and will expire eventually).
      • 2024-05-31 15226, 2024

      • lucifer[m]
        As an implementation detail in MB, if you request a new refresh or access token. the old ones get overwritten and are no longer usable. In MeB.org this is not the case.
      • 2024-05-31 15239, 2024

      • lucifer[m]
        so clients can have multiple active access tokens.
      • 2024-05-31 15243, 2024

      • lucifer[m]
        at the same time.
      • 2024-05-31 15211, 2024

      • lucifer[m]
        the older access tokens will expire eventually on their own but are not immediately revoked when a new one is issued.
      • 2024-05-31 15223, 2024

      • zerodogg has quit
      • 2024-05-31 15228, 2024

      • lucifer[m]
        nothing should break from this.
      • 2024-05-31 15248, 2024

      • reosarevok
        > i personally would get rid of OOB and specify 25 or so very uncommon ports to try from.
      • 2024-05-31 15251, 2024

      • lucifer[m]
        and it is fine security wise afaik.
      • 2024-05-31 15259, 2024

      • reosarevok
        Is there a way for the user to change ports further if needed?
      • 2024-05-31 15221, 2024

      • reosarevok
        (sorry, I was busy for a moment)
      • 2024-05-31 15223, 2024

      • bitmap[m]
        don't see any issue with #4
      • 2024-05-31 15233, 2024

      • lucifer[m]
        reosarevok (IRC): yes but it would need them to register their own OAuth application
      • 2024-05-31 15256, 2024

      • reosarevok
        I think documenting that for the crazy case where all the ports are in use might be fine?
      • 2024-05-31 15201, 2024

      • reosarevok
        And drop the fallback
      • 2024-05-31 15222, 2024

      • lucifer[m]
        fine by me, i'll discuss with Picard team once.
      • 2024-05-31 15230, 2024

      • bitmap[m]
        ignoring that MB doesn't currently expire refresh tokens (?)
      • 2024-05-31 15235, 2024

      • yvanzo
        onto 5?
      • 2024-05-31 15239, 2024

      • lucifer[m]
        sure
      • 2024-05-31 15250, 2024

      • lucifer[m]
        bitmap: i think it does.
      • 2024-05-31 15258, 2024

      • lucifer[m]
        well not expire. but overwrites.
      • 2024-05-31 15212, 2024

      • bitmap[m]
        right
      • 2024-05-31 15216, 2024

      • lucifer[m]
        MeB also doesn't expire refresh tokens.
      • 2024-05-31 15241, 2024

      • lucifer[m]
        that is the 5th point
      • 2024-05-31 15245, 2024

      • lucifer[m]
        5. Should refresh tokens that have not been used for a while be expired. Recommended by OAuth security specs.
      • 2024-05-31 15257, 2024

      • reosarevok
        How long is a while?
      • 2024-05-31 15200, 2024

      • lucifer[m]
        currently not implemented in MeB.org and MB doesn't do it
      • 2024-05-31 15203, 2024

      • lucifer[m]
        configurable by us
      • 2024-05-31 15222, 2024

      • yvanzo
        pls remind us how those tokens are used?
      • 2024-05-31 15232, 2024

      • lucifer[m]
        these are used to retrieve new access tokens.
      • 2024-05-31 15243, 2024

      • yvanzo
        yeah, sorry
      • 2024-05-31 15200, 2024

      • lucifer[m]
        So access tokens are short lived and used to perform actions on user's behalf.
      • 2024-05-31 15209, 2024

      • yvanzo
        is there a recommended expiration period?
      • 2024-05-31 15218, 2024

      • lucifer[m]
        and refresh tokens are used to obtain new access tokens. they are usually non expiring or long lived.
      • 2024-05-31 15235, 2024

      • mara42 has quit
      • 2024-05-31 15256, 2024

      • bitmap[m]
        so this suggestion would refresh the expiration period whenever the token is used again, not have a fixed one
      • 2024-05-31 15259, 2024

      • lucifer[m]
        not that i know of, yvanzo (IRC)
      • 2024-05-31 15212, 2024

      • yvanzo
        👍
      • 2024-05-31 15216, 2024

      • lucifer[m]
        bitmap: yes, basically revoke after a period of inactivity.
      • 2024-05-31 15234, 2024

      • bitmap[m]
        sounds reasonable
      • 2024-05-31 15256, 2024

      • bitmap[m]
        TBD what a reasonable period of inactivity is
      • 2024-05-31 15227, 2024

      • yvanzo
        “The expiration time of the refresh token is intentionally never communicated to the client.” https://www.oauth.com/oauth2-servers/making-authe…
      • 2024-05-31 15228, 2024

      • lucifer[m]
        sounds good, somewhere around 3 months is what i had in mind.
      • 2024-05-31 15237, 2024

      • yvanzo
        And more interesting: “When the refresh token changes after each use, if the authorization server ever detects a refresh token was used twice, it means it has likely been copied and is being used by an attacker, and the authorization server can revoke all access tokens and refresh tokens associated with it immediately.”
      • 2024-05-31 15251, 2024

      • lucifer[m]
        right, MeB.org implements this.
      • 2024-05-31 15258, 2024

      • lucifer[m]
        MB doesn't.
      • 2024-05-31 15259, 2024

      • yvanzo
        👍
      • 2024-05-31 15243, 2024

      • lucifer[m]
        I didn't include it in the list of differences because I didn't think it would affect anyone. but can add to the future blog post.
      • 2024-05-31 15249, 2024

      • BrainzGit
        [listenbrainz-server] 14MonkeyDo opened pull request #2894 (03master…manually-submit-album): LB-1401: Manually submit album https://github.com/metabrainz/listenbrainz-server…
      • 2024-05-31 15205, 2024

      • yvanzo
        Thanks for this meeting and all the work behind it lucifer[m]!
      • 2024-05-31 15232, 2024

      • bitmap[m]
        is there anything else on the agenda?
      • 2024-05-31 15247, 2024

      • lucifer[m]
        yes we can discuss two more points if we have time.
      • 2024-05-31 15207, 2024

      • yvanzo
        PKCE probably, but I got to go, will read backlogs.
      • 2024-05-31 15227, 2024

      • bitmap[m]
        just me then ☺️
      • 2024-05-31 15228, 2024

      • lucifer[m]
        mandating PKCE, only supporting SHA256 PKCE, implicit grant support.
      • 2024-05-31 15235, 2024

      • lucifer[m]
        well 3 actually :p
      • 2024-05-31 15214, 2024

      • lucifer[m]
        yvanzo (IRC): sounds great. also thanks for the notes! :D
      • 2024-05-31 15225, 2024

      • lucifer[m]
        1. should we mandate PKCE?
      • 2024-05-31 15246, 2024

      • bitmap[m]
        should we discuss these later when others are around?
      • 2024-05-31 15252, 2024

      • lucifer[m]
        sure
      • 2024-05-31 15201, 2024

      • reosarevok
        I'm more or less around
      • 2024-05-31 15212, 2024

      • reosarevok
        But discussing with yvanzo here makes sense if not super urgent
      • 2024-05-31 15221, 2024

      • atj[m] joined the channel
      • 2024-05-31 15221, 2024

      • atj[m]
        yes, next question 😁
      • 2024-05-31 15251, 2024

      • lucifer[m]
        i am fine with having another meeting next week.
      • 2024-05-31 15206, 2024

      • lucifer[m]
        maybe one hour prior to regular meeting time?
      • 2024-05-31 15229, 2024

      • lucifer[m]
        atj: allow plain PKCE or disallow it?
      • 2024-05-31 15257, 2024

      • atj[m]
        disallow it
      • 2024-05-31 15238, 2024

      • lucifer[m]
        bitmap, reosarevok (IRC) thanks for the meet today. let me know when we can meet next week to finalize the remaining stuff.
      • 2024-05-31 15201, 2024

      • atj[m]
        as I said when this was discussed before, now is the time to enforce secure defaults, because if you say we'll do it in X amount of time you never will
      • 2024-05-31 15211, 2024

      • bitmap[m]
        thanks lucifer !
      • 2024-05-31 15213, 2024

      • lucifer[m]
        bitmap: can you please work on implementing a prototype of accepting MeB.org issued tokens in MB?
      • 2024-05-31 15230, 2024

      • bitmap[m]
        will look into it
      • 2024-05-31 15245, 2024

      • bitmap[m]
        can you open a ticket pretty please?
      • 2024-05-31 15249, 2024

      • lucifer[m]
        i'll open a LB PR to show what all is needed.
      • 2024-05-31 15250, 2024

      • lucifer[m]
        sure
      • 2024-05-31 15205, 2024

      • atj[m]
        [@lucifer](https://matrix.to/#/@lucifer:chatbrainz.org): I accidentally pushed to master on the matrix ansible repo 😬
      • 2024-05-31 15207, 2024

      • reosarevok
        I generally agree with that atj[m] suggestion of breaking stuff all in one go to make stuff safer
      • 2024-05-31 15212, 2024

      • lucifer[m]
        atj: yes, sounds good to me.
      • 2024-05-31 15230, 2024

      • lucifer[m]
        atj: should be fine,
      • 2024-05-31 15240, 2024

      • lucifer[m]
        (pushing to master)
      • 2024-05-31 15252, 2024

      • atj[m]
        i thought i was in a branch
      • 2024-05-31 15221, 2024

      • atj[m]
      • 2024-05-31 15246, 2024

      • lucifer[m]
        thanks! reading it
      • 2024-05-31 15228, 2024

      • lucifer[m]
        the docs make sense to me atj ! thanks a lot for setting it up :D
      • 2024-05-31 15208, 2024

      • atj[m]
        possibly a little confusing as there is a fair amount of switching between the container and the host
      • 2024-05-31 15215, 2024

      • atj[m]
        i tried to make it reasonably clear
      • 2024-05-31 15238, 2024

      • lucifer[m]
        yup, thankfully that was one time thing. and updating configuration is much simpler.
      • 2024-05-31 15244, 2024

      • lucifer[m]
        which is the more recurrent part.
      • 2024-05-31 15251, 2024

      • atj[m]
        i enabled the bridge info setting but haven't actually seen anything in my clients
      • 2024-05-31 15220, 2024

      • lucifer[m]
        did you restart the bridge?
      • 2024-05-31 15223, 2024

      • atj[m]
        yep
      • 2024-05-31 15241, 2024

      • lucifer[m]
        ah okay. yeah dunno what it is does.
      • 2024-05-31 15247, 2024

      • lucifer[m]
        *it does
      • 2024-05-31 15250, 2024

      • lucifer[m]
        mayhem: reosarevok you should have admin privileges for all rooms on matrix. if any one else should have or wants it, let me know.
      • 2024-05-31 15208, 2024

      • atj[m]
      • 2024-05-31 15224, 2024

      • atj[m]
        thanks
      • 2024-05-31 15253, 2024

      • atj[m]
        is that error on bridge startup about power levels worth fixing
      • 2024-05-31 15256, 2024

      • atj[m]
        or is it not a real issue?
      • 2024-05-31 15232, 2024

      • lucifer[m]
        i don't know enough about it. probably can be ignored since we aren't really using any matrix specifc bots etc.
      • 2024-05-31 15255, 2024

      • lucifer[m]
        atj: you also have server admin privileges fwiw.
      • 2024-05-31 15229, 2024

      • lucifer[m]
        to create new user accounts, reset passwords etc etc.
      • 2024-05-31 15231, 2024

      • atj[m]
        i thought so - i was a bit confused why i didn't have admin on the channels but it's obviously separate
      • 2024-05-31 15239, 2024

      • atj[m]
        👍️
      • 2024-05-31 15240, 2024

      • lucifer[m]
      • 2024-05-31 15224, 2024

      • atj[m]
        lucifer: have you looked at supporting OpenID connect?
      • 2024-05-31 15247, 2024

      • lucifer[m]
        for MeB.org provider or chatbrainz?
      • 2024-05-31 15248, 2024

      • atj[m]
        it's generally what you need for SSO IME
      • 2024-05-31 15200, 2024

      • atj[m]
      • 2024-05-31 15232, 2024

      • lucifer[m]
        yes i have looked into it. and techinically that would be the correct way to implement SSO.
      • 2024-05-31 15252, 2024

      • atj[m]
        I looked at implementing MeB SSO on a-tisket at one point but it wouldn't work without OpenID Connect support
      • 2024-05-31 15214, 2024

      • lucifer[m]
        but we have been using just OAuth so plan to migrate first. then look into additional features.
      • 2024-05-31 15222, 2024

      • lucifer[m]
        oh why? what's missing?
      • 2024-05-31 15246, 2024

      • atj[m]
        the webserver add on I was using only supported OpenID connect
      • 2024-05-31 15203, 2024

      • lucifer[m]
        ah okay