First of all Nina, I chose not to be an active member of core team because I felt there was a significant conflict of interest in which I didn't feel comfortable with. Being a core team member has a tactical advantage of seeing API changes before public release and having access to that as a commercial developer, is in my mind, a conflict of interest when those changes are not public. Thus I felt it violated my sense of ethics to be a member of core team and a commercial module developer.
So my comments on your core team member status was not contradictory at all, and had no bearing on me being or not being a member of Core Team. That was my own ethical decision in which I stand by.
Secondly your comment in regards to why I posted here - instead of your site or email, because in essence, this was your reference that I was made aware of – I saw earlier the comment in asp.net forums, but didn’t feel it was appropriate since the thread was very old at the time. However, this was a new posting that I was made aware of today. Did you comment to us, or ask us about your issues on May 2nd? No. I have no issues in regards to your post of the 2nd in your blog, but it was well written and showed what the hacker did to your site without informing really anyone what the issue may have been. Anyone that would have downloaded evals to try and discover the hack post your blog entry wouldn't have had an entry point into it.
But let's take the following scenario, and keep it simple and you tell me what you think would have served the community better.
Nina has a problem with the patch. Nina contacts us, we assist her with her upgrade, in that case if Nina felt uncomfortable with the solution, we would have recommended the 30 second corrective actions to remove the security flaw.
Nina then posts in the forums, "yes, I had a problem applying the patch, however, dnn modules also has a quick remediation available that doesn't require the module updates. By all means do this if you have their modules and don't want to upgrade immediately."
On the other hand we have your post in your blogs in regards to our module and the update and also a similar posting in asp.net forums. Which do you think would have gotten the users to at least contact us and get the darn problem fixed quicker for ones that were on the fence or ignored it?
We know alot did ignore it, or for whatever unknown reason simply decided not to do anything about it. Why? I have no idea.
Your comment in regards to the code being old - Nina - you profess you know little about development, perhaps you should be kindly made aware of that existing code atypically isn't covered in a development plan or phase. Usually developers don't have to re-write their code every six months from scratch - the ones that do, don't do this for a living. Thus code that was written years ago may exhibit uncharacteristic issues. Some of these actual issues were discovered in some very significant large applications including Windows.
Which brings me to your interesting comment on confidence of a vendor - so why are you running on Windows Servers, SQL Server and even ASP.NET of all which have had glaring security holes discovered (especially SQL Server)? We all run updates on our Internet Server software - most of us update immediately any patches or schedule them in ASAP - why? Because problems are found in even the best shops.
We are to blame for this issue ultimately (not the one on the original post mind you), however, what bothers me is that hackers have found a potential series of weaknesses. There is allot of old DNN sites out there, with alot of modules or even core code going back to DNN 1.x days. There were known security flaws to DNN back then (begs the point of why even you're using DNN), and now my concern is that hackers will start targeting DNN a little more seriously or simply exploiting smaller modules or other modules while the dust is still settling from this one. That is actually what's concerning me more about the Microsoft France hack. Heck, I was surfing the web and found a city tourism site still running dnn 1.x, and that was a pretty official government website. As I stressed to Shaun on this matter, the only safety DNN can do in this regard is to educate users of the DNN community.
I know we've corrected our code in a responsible manner. Elements CAN fall through the cracks and be discovered. It's up to the vendor to quickly react to the problem on hand and resolve the issue - which we did (otherwise, using your suggestive practice none of us would be running Windows or using .NET or using SQL Servers). We've also written our own server software that operates on our DNN Server (and soon a distributable client component) insure that we keep track of licenses against valid users - to again, insure that we don't lose touch of our software and where it is running. We've also recommended and have instigated changes to SnowCovered via Brice so that notifications can be broadcasted out in a more efficient manner than they were - as both of us were caught with trying to send / broadcast out emails to email addresses that were no longer used. We've also done both human QA and black box testing of entry points such as the one discovered in BDPDT, and insured they were hardened in several different methods including the base server controls that might have ever been used now and in the future. That has been a rigourous task since we were informed of this law, and covers a breadth of a half a million lines of code or more - and no, that's not a bloated total for each DNN version either.
As far as our ratings, wow - talk about a completely off topic comment Nina. Since you brought it up, I'll respond... The one I find most interesting and that you didn't mention, is our response time, over 900 ticket requests or questions with an average of 6 hours response time. I find that people tend to complain visibly more than compliment, so thus, myself, personally would rather look at our overall response times - given the wide breath of users, dnn versions and modules that we support. I don't feel the need, even though I should do so, in begging a client for a feedback rating when their problem is solved or question answered. If I did that every time, you'd see a far different rating. Even in the aspects of snowcovered and support - we requested and had SnowCovered's HelpDesk enhanced because some tickets were falling through the cracks because of snowcovered.com's email system.
To end this, before we're both told to go sit in the corner and can't play in the sandbox anymore, is this. You can't expect to sit there on your soapbox and state comments being a core team member on a problem on an upgrade especially of one of this magnitude, without having the vendor come back publicly at you. Whether you choose to admit it or not, your actions can have an affect whether it is positive or negative, that is your choice.
Anyways, as much as I enjoyed the banter, I have some code to write in one of those “development phases”, and more stuff that people want added (now that never seems to end *smile*...) – let’s all just hope that the lessons are learnt from all, be it module developers, DNN Core Team and the end clients of the seriousness and due diligence required to develop, run and maintain Internet Applications, none of us can ever relax in this issue, and it's an ongoing element of concern to all. ISP’s got their heads kicked with SQL Server and IIS flaws prior, now it’s time for us to stop pointing fingers and making sure that our overall clientele is properly informed and knowledgeable. Then we all learn, and hopefully never have to go through this again.
Cheers,
Richard