xeiaso
eyedeekay: did you see the message i sent yesterday
eyedeekay
Yes I did, did you not get my private message?
xeiaso
No I don't see it
dr|z3d
xeiaso: what are you a trying to achieve by releasing proof of concepts for potentially serious issues on pastebins and in this channel?
dr|z3d
responsible disclosure usually involves some private channel.
xeiaso
dr|z3d: My goal is to get the bugs fixed. Security through obscurity is not the way to go.
dr|z3d
We're not talking about security through obscurity, that's a straw man argument, we're talking about responsible disclosure.
xeiaso
> potentially serious issues < see this is the problematic issue, fixes won't happen until discussion happens.
xeiaso
Text that's too much to just copy-paste on IRC goes into a pastebin. It's just common courtesy.
dr|z3d
There's not a huge amount of courtesy involved in dumping your findings wherever is most convenient to you, in full public view, for issues that may not have a simple fix.
dr|z3d
Responsible disclosure involves coordination with the developer(s) in question, and private disclosure. That's courtesy.
xeiaso
I write here because it's where people who can fix it are. Private backrooms discussions are where issues go to die.
xeiaso
To put it simply: the developers are the public
dr|z3d
So, you think it's fine to dump potentially serious issues into public channels without forewarning, you're not prepared to coordinate with the developers privately, and you're not providing any patches or other mitigations. And you think that's courteous? I've got a different take; I think you're actively hostile.
xeiaso
Bringing up the issues here is the forewarning. The code is public and anyone skilled enough to exploit these issues would have not problem finding them.
xeiaso
Recognizing flaws in a codebase is the first step toward fixing them.
xeiaso
Take the message id problem for example. When I saw "_context.inNetMessagePool().add(msg, null, null);" it immediately struck me as serious. And a few lines into add() confirmed my suspicions.
dr|z3d
Identifying potential issues is all well and good, but when those issues relate to the security of the software, responsible disclosure is how people with benevolent intent operate. Or better still, they provide patches.
xeiaso
If it gets into the June 12th release then it's fine. It's best left up to the people that are familiar with the codebase to choose the solution they like the most.
dr|z3d
If what gets into the release? Some patch you're providing?
xeiaso
If the fixes to the issues get into the release.
dr|z3d
No, it's not fine. You're not providing any code, you're just dumping potential avenues for exploit in public channels without talking to the devs privately. Your motives are suspect at best.
xeiaso
I don't agree with your characterization of the situation.
dr|z3d
There's no characterization going on. Just the facts. Those are not in dispute.
xeiaso
Terms like "dumping" or "suspect motivations" have a certain viewpoint to them. "potential" is in dispute.
xeiaso
"messaging" or "minimal" are more neutral.
dr|z3d
I'm not expressing an opinion, I'm stating facts. That you don't like being confronted with those facts is neither here nor there. Your behavior is suspect at best, outright hostile at worst. Fact.
eyedeekay
What if it doesn't get into the release? A potentially substantial refactor of the netDB is unlikely to be complete by then especially if we have to prove the issue, develop the solution, then prove the solution fixes the issue before like... Tuesday at the latest for the current schedule.
xeiaso
Tuesday? I though the release would be on the 12th?
xeiaso
And it doesn't need to be a complete fix on the netdb, just enough of a band-aid.
eyedeekay
We have to do it before tag freeze and we have to have time to test
eyedeekay
I'm not rolling with release-day last minute fixes
eyedeekay
I don't understand how to band-aid it, I have an idea of a big-picture approach I like but it will take time
xeiaso
Adding more context parameters like the xor id one.
xeiaso
also why is the 3 arg add() back, anyway?
eyedeekay
Because embedders might be using it and I'd rather help them migrate than break their builds unannounced
xeiaso
What is and isn't considered an API for embedders? I would have expected that InNetMessagePool is an internal implementation detail.
eyedeekay
Maybe. Probably. There aren't very many good reasons to use things that deep, but some might exist so for now it stays, even though it's unused in our code now
xeiaso
eyedeekay: enable speaking in ls2 please