 |
|
|
|
I'd prefer to focus on a solution instead of discussing different audiences.
If there is a security issue with modules, it needs to be fixed - if necessary, the vendor should be assisted, and existing users should be provided with directions.
Once the product is fixed, I don't see a reason, why it should not be listed in the store again.
The new Developers Advisory Group might develop guidelines, tests and other necessary tools for developers to create DNN extensions, which fit the security requirements.
|
| |
|
|
 | |
|
|
 |
 |
www.40fingers.net
Joined: 2/9/2006
Posts: 4430
|
|
|
Tony Henrich wrote:
How did dnnsoftware become aware of DNNGo's modules security vulnerabilities? I am just curious.
I read the whole thread. Looks like DNNGo fixed the issues but dnnsoftware refused to put them back pr some of them in the store because of code quality. Is dnnsoftware in a position to evaluate and determine the code quality of modules or just that modules meet security guidelines and checks? Module developers code in different styles. What is good quality for someone might be bad for another developer. Also if a module works reliably, safely and performant and does what it claims it does, do module clients care how it is written under the hood?
So the next question is did dnnsoftware notify DNNGo on HOW and WHY their code quality needs rework?
This what happens when a business model is dependent on another company's business. They are at the mercy of the host company. Just like when Facebook changes its API or programming structure, suddenly companies are out in the naked cold.
So a message to module would-be developers, this can happen to you. Unless you're OK to be dependent on selling on your own site only.
**: I am not affiliated with DNNGo in any shape or form.
I guess there's an information issue here :-).
It might be that some in here have more info than others, although I thought this was all public info.
Mid June 2017 several websites were hacked using DNNGo product vulnerabilities.
From the email sent out to DNNgo buyers:
"During the past week, a number of highly visible DNN websites
were hacked. The hackers exploited vulnerabilities in modules sold by DNN Go.
We’re getting in touch because you may have purchased DNN Go modules from the
DNN Store."
|
| |
|
|
| |
|
|
 |
www.berrydigital.com.au
Joined: 1/23/2004
Posts: 1961
|
|
|
Timo Breumelhof wrote:
Tony Henrich wrote:
How did dnnsoftware become aware of DNNGo's modules security vulnerabilities? I am just curious.
I read the whole thread. Looks like DNNGo fixed the issues but dnnsoftware refused to put them back pr some of them in the store because of code quality. Is dnnsoftware in a position to evaluate and determine the code quality of modules or just that modules meet security guidelines and checks? Module developers code in different styles. What is good quality for someone might be bad for another developer. Also if a module works reliably, safely and performant and does what it claims it does, do module clients care how it is written under the hood?
So the next question is did dnnsoftware notify DNNGo on HOW and WHY their code quality needs rework?
This what happens when a business model is dependent on another company's business. They are at the mercy of the host company. Just like when Facebook changes its API or programming structure, suddenly companies are out in the naked cold.
So a message to module would-be developers, this can happen to you. Unless you're OK to be dependent on selling on your own site only.
**: I am not affiliated with DNNGo in any shape or form.
I guess there's an information issue here :-).
It might be that some in here have more info than others, although I thought this was all public info.
Mid June 2017 several websites were hacked using DNNGo product vulnerabilities.
From the email sent out to DNNgo buyers:
"During the past week, a number of highly visible DNN websites
were hacked. The hackers exploited vulnerabilities in modules sold by DNN Go.
We’re getting in touch because you may have purchased DNN Go modules from the
DNN Store."
I received several emails like this as well. It was not just DNNGo affected.
>>>
Recently, I sent you an email indicating that hackers exploited
vulnerabilities in modules sold by Mandeeps. I’d like to provide the following
update:
The updated modules that Mandeeps released on June 9th properly
corrected some of the vulnerabilities. A few more vulnerabilities were also
resolved more recently. The updated products are now available for download
from the DNN Store and the product listings have been reinstated. Please make
sure you are running these versions of Mandeeps’ modules:
Live Campaign 3.9.7
Live Content 6.1.0
Live Forms 4.3.2
Live Helpdesk 1.3.5
Live Utilities 1.1.2
Common Library 2.1.8
Porto 3.3.1
Mandeep was
cooperative and responsive while working with us on these issues. We appreciate
his effort and cooperation.
>>
They were not the only ones with issues, and I would as a guess believe they were as highly visible with modules and themes as Mandeeps.
I would think that DNNGo was one of the top sellers on the DNN store.
Nina Meiers My Little Website
If it's on DNN, I fix, build, deploy, support,skin, host, design, consult, implement, integrate and done since 2003.
Who am I? Just a city chic, having a crack at organic berry farming.. and creating awesome websites.
|
| |
|
|
| |
|
|
|
www.berrydigital.com.au
Joined: 1/23/2004
Posts: 1961
|
|
|
Timo Breumelhof wrote:
Tony Henrich wrote:
How did dnnsoftware become aware of DNNGo's modules security vulnerabilities? I am just curious.
I read the whole thread. Looks like DNNGo fixed the issues but dnnsoftware refused to put them back pr some of them in the store because of code quality. Is dnnsoftware in a position to evaluate and determine the code quality of modules or just that modules meet security guidelines and checks? Module developers code in different styles. What is good quality for someone might be bad for another developer. Also if a module works reliably, safely and performant and does what it claims it does, do module clients care how it is written under the hood?
So the next question is did dnnsoftware notify DNNGo on HOW and WHY their code quality needs rework?
This what happens when a business model is dependent on another company's business. They are at the mercy of the host company. Just like when Facebook changes its API or programming structure, suddenly companies are out in the naked cold.
So a message to module would-be developers, this can happen to you. Unless you're OK to be dependent on selling on your own site only.
**: I am not affiliated with DNNGo in any shape or form.
I guess there's an information issue here :-).
It might be that some in here have more info than others, although I thought this was all public info.
Mid June 2017 several websites were hacked using DNNGo product vulnerabilities.
From the email sent out to DNNgo buyers:
"During the past week, a number of highly visible DNN websites
were hacked. The hackers exploited vulnerabilities in modules sold by DNN Go.
We’re getting in touch because you may have purchased DNN Go modules from the
DNN Store."
I received several emails like this as well. It was not just DNNGo affected.
>>>
Recently, I sent you an email indicating that hackers exploited
vulnerabilities in modules sold by Mandeeps. I’d like to provide the following
update:
The updated modules that Mandeeps released on June 9th properly
corrected some of the vulnerabilities. A few more vulnerabilities were also
resolved more recently. The updated products are now available for download
from the DNN Store and the product listings have been reinstated. Please make
sure you are running these versions of Mandeeps’ modules:
Live Campaign 3.9.7
Live Content 6.1.0
Live Forms 4.3.2
Live Helpdesk 1.3.5
Live Utilities 1.1.2
Common Library 2.1.8
Porto 3.3.1
Mandeep was
cooperative and responsive while working with us on these issues. We appreciate
his effort and cooperation.
>>
They were not the only ones with issues, and I would as a guess believe they were as highly visible with modules and themes as Mandeeps.
I would think that DNNGo was one of the top sellers on the DNN store.
Nina Meiers My Little Website
If it's on DNN, I fix, build, deploy, support,skin, host, design, consult, implement, integrate and done since 2003.
Who am I? Just a city chic, having a crack at organic berry farming.. and creating awesome websites.
|
| |
|
|
| |
|
|
|
Tony Henrich wrote:
How did dnnsoftware become aware of DNNGo's modules security vulnerabilities? I am just curious.
I read the whole thread. Looks like DNNGo fixed the issues but dnnsoftware refused to put them back pr some of them in the store because of code quality. Is dnnsoftware in a position to evaluate and determine the code quality of modules or just that modules meet security guidelines and checks? Module developers code in different styles. What is good quality for someone might be bad for another developer. Also if a module works reliably, safely and performant and does what it claims it does, do module clients care how it is written under the hood?
So the next question is did dnnsoftware notify DNNGo on HOW and WHY their code quality needs rework?
This what happens when a business model is dependent on another company's business. They are at the mercy of the host company. Just like when Facebook changes its API or programming structure, suddenly companies are out in the naked cold.
So a message to module would-be developers, this can happen to you. Unless you're OK to be dependent on selling on your own site only.
**: I am not affiliated with DNNGo in any shape or form.
My guess (I really don't work for Corp nor am I an insider to the degree that I know these things) is that after a number of reports of hacked sites they reached out to DNN Go and asked for source code. And it would be unethical for Corp to share this code with the rest of us. Which leaves just the accusation but no objective way to determine who's right. I don't think that is very satisfying to say the least.
Obviously I'm thinking about how it'd be if it were my own module caught out like this. It must be frustrating for sure. It's startling that they are not getting a response by DNN Corp. I guess at some point I'd pick up a phone and start calling everyone involved. Have they tried that yet?
To the wider issue of "should DNN Corp" be policing the code quality, this is indeed a slippery slope as Tony points out. I can't see (1) everyone just handing over their source code, (2) DNN Corp having the manpower to go through all this code and (3) having concrete rules that determine if a module passes or fails. Maybe a couple of rules in #3, but overal quality? No. E.g. I can imagine failing a module if it fails to set security on a WebAPI method that accesses other users' data for instance. I think we can all agree on that. But what if you spot a potential endless loop in code? This has the potential of freezing up the worker process and recycling your site. But is it really something we should be into policing?
Alternatively you could have a voluntary system whereby a module developer tells DNN Corp: here's my code, feel free to check it and give me critique. Then if it passes we add a badge in the store. Wouldn't that be a better solution?
|
| |
|
|
| |