#musicbrainz-devel

http://chatlogs.metabrainz.org/admin/accounts/u... ?

Freso: did you check to see if your admin privs on jira work?

ah, found a working one

Leo_Verto, LordSputnik: Freso and I also discussed that we should probably rejigger the IRC channels we have.

ruaok: yeah, we've mentioned that idea a couple of times in #bb-devel too

Mhm, I mentioned an idea I had for that during the last meeting

What have you been thinking?

one suggestion was to have: #musicbrainz and #metabrainz-devel

and #bookbrainz

That sounds good to me

even then I wonder if bookbrainz makes a lot of sense.

my idea was to keep one channel per major project for internal discussions and direct general help to #metabrainz

the idea is to concentrate the devlopment in one place.

I thought to keep the -devel channels though it might be cleaner without that

ah

ruaok: It doesn't right now, but it probably will eventually

LordSputnik: exactly.

the opposite of my idea then :P

as we get too much noise in one channel, we create a separate channel.

#musicbrainz is clearly needed

but #critiquebrainz would be dead and empty. clearly something we need to change, but in the short term another solution might be good.

Mhmm, I think the more people looking at development talk, the better

#metabrainz -- discussion on general metabrainz projects except musicbrainz, #musicbrainz for musicbrainz and #metabrainz-devel for metabrainz development.

LordSputnik: exactly. hence only one devel channel for all things.

besides Freso pointed out that we have a lot of shared things in common.

hmm, a single devel channel would be a lot of noise though

perhaps not code, but hosting, community, concepts, etc.

Leo_Verto: we're already all in #mb-devel though :P

Leo_Verto: it has the potential to become noisy, yes.

but even if combine bookbrainz-devel and muscbrainz-devel, its still not too noisy.

Leo_Verto: and I don't think it'd hinder us talking about BB development

and once it does become too noisy, you break our a new channel.

yeah, it will make it more difficult to filter relevant backlog though

the main idea behind this is not have 6 dead -devel channels were people are constantly popping asking if the project is dead.

heh

Leo_Verto: perhaps that just means we should focus more on posting important stuff on the mailing list to save the need to search IRC backlog?

yeah, that might work

I'll mention this in the mailing list progress update this week, so we can all agree on something

we could also get the bot to parse our already used <BANG> </BANG> tags and link meeting chatlogs on the mailing list :P

>.<

Leo_Verto: doing that in here resets the topic :)

oh nice :D

That's where it came from - to clear the agenda items from the topic after the MB-devel meeting

I'm sure that's a feature we don't want to port, isn't it? :P

ruaok: then I guess the next step would be to blog about it, and then make the change - maybe some time in the next week?

I think we ought to review this proposal in the meeting on monday.

and on the SSO front, we really need to determine if jira and discuss can be used with oauth2.

if so, then we have a clear plan.

(at least a clear plan is forming in my mind)

though that relies on the REST API

unless our version supports Application Links

ruaok: are we still being blocked on updating JIRA by bugs/broken import?

no, they were apparently paying attention and fixed the issue.

so, as far as I am concerned we need to solve the oauth issue to our satisfaction and then we can proceed.

the first listed AppLinks version is for JIRA 4.3

Leo_Verto: We have an OAuth2 server, no?

and OAuth and OAuth2 don't play well together?

me too :P

if you could dig more into this, that would really help move this issue along.

legoktm has agreed to look after the wiki and it does OAuth2, so that is easy.

leaves only discuss

and that we will probably want to move OAuth stuff to metabrainz, not musicbrainz.

LordSputnik, mind confirming that BB-122 is fixed now?

Leo_Verto: afaik there's still a problem for small resolutions above the mobile cut-off

oh, I haven't deployed the fix to bb.org yet

ruaok: https://jira.atlassian.com/browse/JRA-43171

ruaok: So our options for now are to leave JIRA out of SSO until that's implemented, or additionally provide OAuth 1.0 for MetaBrainz

nice, unassigned

do we have to use OAuth 2?

apparently there are some reasons against using it http://hueniverse.com/2012/07/26/oauth-2-0-and-... http://hueniverse.com/2010/09/29/oauth-bearer-t...

Well, it works OK, it's used by lots of people

I don't think it'd be a huge problem to also allow OAuth 1.0

The major differences I've gathered so far are that it relies on HTTPS for security but works better for non-browser clients due to that

OpenID might actually be a better fit for this

and OAuth 2 can be misconfigured very easily (though that wouldn't be a problem here)

yep, there's a plugin for that

non-free though

and not available for JIRA cloud

"Add-ons are always free for community and open-source licenses." :D

supports JIRA server 6.0+

mind you, the latest iteration of OpenID appears to be built on top of OAuth 2.0

yeah, saw that

though I don't think it'd work with just an OAuth2 provider, would it?

I think we need to carefully examine our security needs and possible motivations for someone to attack us or our users.

do we have needs that go beyond,

we use oauth2 and it works fine as far as I can see

not exposing passwords in out net communications?

*our

and why would someone attack us? or try to take over someone's jira account?

to steal their bugs so they can fix them before someone else?

ruaok: so you think we could use HTTPS encrypted basic auth?

plenty of other services do too: google, facebook, microsoft. you name it

so, the oauth bearer token thing doesn't seem like a big problem for us.

LordSputnik: I would rather use what we have and know works.

and oauth2 seems to fit the bill and work "well enough".

as long as we keep our HTTPS setup up to date and don't make any gross configuration mistakes, we should be fine :P

and maybe we just keep our own install of jira.

hmm, I kinda agree with Ben though, what we primarily need is authentication, not authorisation, and while OAuth 2 can apparently handle both in recent versions, OpenID might be easier for us to work with

that may just be the right thing to do. esp if we have a dedicated sysadmin

ruaok: what's preventing us allowing basic authentication to MeB over HTTPS?

because that would also work with JIRA

Leo_Verto: another issue is that we'll need to support two systems instead of one

heh https://www.ssllabs.com/ssltest/analyze.html?d=...

ruaok: Or #musicbrainz , #metabrainz , and #bookbrainz

Leo_Verto: yeah, once I get the gateways deployed properly, I want to remove the diffie helllman bit.

okay, I'll have to leave now but from what I've read so far, OpenID would probably suit us best, if it can be set up in all relevant systems

see ya

Leo_Verto: I really don't want to setup yet another piece of technology. the idea to remove things.

Leo_Verto | I'm sure that's a feature we don't want to port, isn't it? :P -- I didn't make a ticket for it anyway. :)

ruaok: yeah, actually, thinking about this, it's probably best to keep hosting JIRA as you suggested. I don't think there's a way that we can hook up MB accounts with Atlassian Cloud

Leo_Verto | do we have to use OAuth 2? -- Maybe not, but we already have an OAuth2 endpoint on mb.o which is used by AcousticBrainz, AcoustID, MB Picard, CritiqueBrainz, ..., replacing it would be a *lot* of work and break backwards compatibility with software relying on it, and adding an alternative is one more thing that needs to be kept maintained.

ruaok: so do you have a plan for SSO with MB-hosted JIRA?

LordSputnik: Not if it can be helped.

As ruaok said, we really, really want to host/support fewer things. Which likely means that if hosted JIRA won't work with OAuth2 SSO, we're probably more likely to look for another ticket tracker that we won't have to host and which will support it.

Nowhere in those cards do we have SSO on the MB-hosted JIRA instance.

Freso: But then we lose all of the existing tickets

LordSputnik: Yes.

Unless we import them to the new system.

This would not be the first time we've changed ticket tracking software.

So we'd be looking for a cloud hosted ticket tracker with OAuth2 support *and* allowing import from JIRA

I don't suppose there are too many solutions for that

Most systems have some kind of importing, JIRA allows to export. If need be, some kind of translation can go on between Jira's export and the expected format for import.

Freso: Do we really need SSO for the ticketing system, if it's something we previously haven't had

LordSputnik: Yes.

We also haven't previously had SSO for wiki or forums, but that doesn't mean it hasn't been needed.

We really, really want "One Account to Rule Them All" so people don't have to juggle multiple accounts to contribute meaningfully to M(e)B.

I don't think you'll find a ticket tracker with all those criteria. Especially one free for open source

It doesn't necessarily have to be free.

Also, "all those criteria"? Primary criteria are "supports SSO with OAuth2" and "not hosted by MeB". The rest can be taken from there.

I still think it'll be difficult to find an issue tracker that allows OAuth2.0. In fact, after reading more about JIRA, it doesn't support any form of external account sign in - those REST API articles Leo posted earlier are for logging into JIRA via the API with JIRA credentials. So it doesn't even support OAuth 1

FUD: https://marketplace.atlassian.com/search?q=oauth

I didn't realize that plugin supported OAuth2 previously...

Even if it didn't, supporting OpenID != "doesn't support any form of external account sign in"

Freso: well, that is a plugin, and it doesn't work with the cloud

Jira also supports at least LDAP, which is what was previously the plan for SSO, prior to luks' OAuth2 implementation.

So, perhaps a viable plan would be to upgrade our own JIRA to the latest version, then trial that plugin and see if it'll work for us

ruaok: I think no matter what we eventually decide to do with SSO, if nothing is blocking the JIRA upgrade, perhaps we could proceed with that? I'd be happy to help if I can :)

LordSputnik: the issue with the jira update is a privacy concern that we haven't settled.

there are email addresses and thus only an contractor can really work on that.