#musicbrainz-devel

oops, my misunderstanding

Okay, I see no good reason to restrict to one date per country at the database level

I'll give a weak +.5. It's not something I deal with, but I feel like people would misuse it.

Or maybe I misunderstood.

Burrito time

hello!

ahoi warp

bitbucket shippits are pretty.

Did search just die?

reosarevok: hm, nothing obvious in nagios.

Speaking of nagios, any object to me copying over the check_last_replication_date update to freedb?

what is "copying over" ?

scp

and with freedb you mean freedb.musicbrainz.org?

Yes.

ok, I don't object to you copying that file to that server. but it is a strange question to ask :)

do you want to get that check in nagios?

Well, it will mean git will need a bit more prodding the next time freedb needs an update to musicbrainz-server.

Leftmost: sorry, I just don't have enough context to know what you're talking about.

Oh, sorry.

So there's a check_last_replication_date script in bin/ in the musicbrainz-server repo. It's not working in its current state, but I updated it and it's got a couple approves in review. However, rather than merging it and pulling master on freedb.musicbrainz.org immediately, I was just going to copy the updated script to the appropriate place and get the check running.

I'm not really sure of the procedure for updating freedb's MBS instance, though, so I'm not sure what's best.

oh in that case I would just checkout the branch with that script on freedb.musicbrainz.org

then someone doing "git status" knows immediatly what's going on.

I've never logged into freedb.musicbrainz.org, and my usual passwords don't work. so I don't anything about that server either.

Well, I imagine it will get merged into master any time now. Two approvals means it's ready to ship, right? I could even do it myself. I'm just a little afraid of pulling MBS on a production server with no real clue of what will happen. Especially since it looks like it hasn't been pulled since October.

I guess I should wait for ianmcorvidae to wake up and poke him.

Leftmost: shipits should normally go in beta, not master.

(and it's not a freeze week, so you can do that now if you want)

Yeah. I'm also not sure of the procedure there. There should be absolutely nothing using it, especially since it's in an utterly unusable state, but I also don't want to subvert process without knowing what I'm doing.

sure, probably nothing will break if you merge it into master now. but _I_ don't know that.

but it a hot sunny merge everything with shippits into beta week. if you have shippits, the process is to merge those into beta this week :)

+is

Okay. Well, I don't have access to push to github, so I'll probably just let others do that.

ok, which branch is this? then I'll merge it into beta.

mbs-6009

Thanks.

warp: it looks like scrypt can be used for encryption, not just one way hashing

so it would appear that we could actually store encrypted passwords and still use digest

ocharles: for what purpose?

what for what purpose?

what are you trying to accomplish by storing encrypted passwords instead of plaintext passwords?

you know what we're trying to accomplish, not having plain text passwords leaked if the database is compromised

hashes are good because you cannot get the password back

i know

encrypted passwords are equivalent to plaintext because you can get the password back.

not equivilent, because you need the key

encrypted means we don't have to have plain text or a weak md5 in the db.

but it does mean that yes, there is a key security issue

sure, and the servers need the key.

bcrypt is probably the way to go then, because the scrypt on CPAN is for encryption and decryption

if our security is compromised enough for an attacker to grab the user table it is likely compromised enough to grab the key as well. especially because reading the key is done by open source code, so following the trail to where the key is stored should be easy.

right

encrypted passwords are better than plaintext in terms of "we don't have to be that careful about the DB, only about the key"

that and not accidently dumping passwords in the website too

Not really against an attacking situation, but in terms of "I don't want others to see my password by chance"

Dumper.dump(edit.editor) in /edits is all it takes to leak a lot of passwords

yes

if edit.editor has a password in it that already seems dodgy :)

yes, I think all that auth stuff should be very separate

but that's another story

I don't think it is another story

bcrypt needs a salt - are you meant to use a constant salt?

buenos dias señor ruaok

ocharles: salt should be random per-user, and is stored with the password hash

oh wait, bcrypt stores the salt

kepstin-work: thanks

buenos tardes, warp!

purpose of salt is to make it so rainbow tables are less feasible

I know what salts are for :)

so constant would be bad, since then you can just generate a rainbow table with constant salt :)

generally you don't generate rainbow tables though, you download them

but yes, point taken

bbaib

Project musicbrainz-server_beta build #373: SUCCESS in 29 min: http://ci.musicbrainz.org/job/musicbrainz-serve...

* leftmostcat: Use correct lib location

I was briefly confused why my name was coming up...

I need sleep.

"See Crypt::Eksblowfish::Bcrypt for a detailed description of cost in the context of the bcrypt algorithm." *goes to that module "Non-negative integer controlling the cost of the hash function"

ಠ_ಠ

CPAN, we have different definitions of 'detailed'

What, you wanted the detailed description to include details?

ocharles: can you clarify for navap how he should rewrite the entity_exists() macro? https://bitbucket.org/metabrainz/musicbrainz-se...

themineo: Fix a typo: debuging -> debugging

I should start using "The_Freso" the few times Freso is taken...

The Fresta

El Fresio

Hmm, is it intentional that musicbrainz.org SSL certificates don't provide ownership information?

Bous Fresanoumenos

We have a tweet saying "@MusicBrainz Why you keep giving 502 and 500 errors?"

(from 10 min ago...)

ocharles: I guess cost is the only reason

Was it Mineo talking about Shiva yesterday?

luks: ah, they are more expensive then?

Looking at it a bit more, I think it's *definitely* something that could use some MusicBrainz juice.

ocharles: the CA needs to verify way more information that way, so yes, they are more expensive

ah

makes sense

Project musicbrainz-server_beta build #375: SUCCESS in 29 min: http://ci.musicbrainz.org/job/musicbrainz-serve...

alastair.porter: fix browsing works by artist if artist id doesn't exist

alastairp, sometime in the next couple months I'd like to talk with you about community-managed collections for October, as it seems you have a stake in that.

hmm, sure. we could probably come up with some ideas about that

Might be worth creating a wiki page to hack on some ideas about what it should look like.

I'll create one and ping you.

For now, I really ought to try to get some sleep.

ocharles, warp: 500 and 502 again...

ocharles - warp? Or can anyone else look into it? Having people in twitter telling us about 500 errors in the homepage doesn't look very good :p

I have to leave in a few minutes to drop something off at the post office but I can look after... warp is a better person to prod

reosarevok: did it resolve itself?

reosarevok: the home page loads fine for me now

warp, probbaly

But we can't really keep having several periods of 500/502 per day, whether they solve themselves or don't

:(

*probably even

I agree.

ocharles: what did I screw up, heh?

Leftmost: what did you need?

ianmcorvidae: apparently the upgrade.sh isn't the same in github and bitbucket

(for the schema change stuff)

goodmorning mr McEwen!

that is odd, I should have pushed it both places :/ unless I pushed the wrong branch to one or the other at some point

Yeah, we know you should have :)

:P

oh, it's your fault, that's right

hahaha

Ok

Can we fix it? :)

yes, it is now

ianmcorvidae: hmm. Should I merge the branch agan then?

I'd recommend it

That commit history will look very silly :)

But ok