Thoughts, ideas, tips, musings, and pontifications (not necessarily in that order) by Ben Forta ...
NOTE: This is my personal blog, and the opinions and statements voiced here are my own.
As blogged back in June, we announced at CFUNITED that the ColdFusion team would be working with and supporting the CFEclipse project. As noted in that keynote, RDS support is the most requested CFEclipse enhancement, and today Damon Cooper blogged that this feature is indeed in the works, one way that we are contributing to this community effort.
Since I couldn't find a way to post a comment on Damon's site I'm asking here.
Will the RDS code be part of CFEclipse codebase? Or will Macromedia only contribute closed source RDS library? Will MM go open source or protect it's proprietary protocol?
Erki, we'll know as we work that one through. But, my gut feel is that it would not be a good idea to fully expose the source for RDS as that may create potential security problems. But that is just my opinion. We'll know for sure once we're done.
Hasn't "security by obscurity" been debunked? Isn't the idea that open source--Linux, Firefox, etc.--is more secure because more people can examine the code for security flaws? Macromedia may have valid business reasons for keeping the RDS protocol proprietary (which may make some open source people unhappy), but don't use security as an excuse.
While it is good to see that Macromedia is taking first steps with CFEclipse, I was hoping for something more impactful.
It's my opinion that RDS is inherently insecure and unless there are changes to CFMX 7+ (signficant ones), there's really no point in using it.
How about we instead incorparate the database features and the component features that RDS provides in CFEclipse without relying on RDS and just forget the thing exists...
Resource access through a single password = very bad in my opinion.
Whoa, slow down. I did not suggest that obscurity would secure anything. Nor did I say that fully exposing RDS would expose security vulnerabilities. Nor did I say that we'd not do so, and that if not that that would be the reason we'd not.
What I did say was that my gut feel on this one tells me that RDS has always served a very limited and restricted role, and one that we've controlled both ends of the pipe of. And when you do control both ends of the pipe the connection is easier to secure. That is not suggest that if we did not control both ends that it would not be secure, but I am suggesting that before we did open it up we'd need to really think through what the potential security implications may be, if there are any. It's not that I think there will be issues, it's that I don't know that we know there won't be any.
As I said in the opening words of my comment, we'll know as we work it through.
It seems to me that there are at least two meanings associated with RDS. One is the ability to browse the file system or a remote database, and add/edit files. The other has to do with the ability to deploy files to remote servers. For example, in Homesite+ selecting a file and right clicking on it allows you to access a deployment option. That option brings up a dialog box that allows you select any RDS or FTP server one has defined and deploy the file. This is very powerful for those of us that deploy code to dev, qa, and integration environments during the development life cycle. I appreciate the concern about security above, but what I would like to know is this, does RDS support include the remote deployment functionality we know in Homesite+?
Will the RDS code be part of CFEclipse codebase? Or will Macromedia only contribute closed source RDS library? Will MM go open source or protect it's proprietary protocol?
Your surly familiar with the saying security by obscurity is not security at all.
I can understand why MM might not want to release the source code for business reasons - but I'm quite surprised you cite security reasons.
I think it would be in the benefit of the community to further explain that statement.
It's my opinion that RDS is inherently insecure and unless there are changes to CFMX 7+ (signficant ones), there's really no point in using it.
How about we instead incorparate the database features and the component features that RDS provides in CFEclipse without relying on RDS and just forget the thing exists...
Resource access through a single password = very bad in my opinion.
What I did say was that my gut feel on this one tells me that RDS has always served a very limited and restricted role, and one that we've controlled both ends of the pipe of. And when you do control both ends of the pipe the connection is easier to secure. That is not suggest that if we did not control both ends that it would not be secure, but I am suggesting that before we did open it up we'd need to really think through what the potential security implications may be, if there are any. It's not that I think there will be issues, it's that I don't know that we know there won't be any.
As I said in the opening words of my comment, we'll know as we work it through.
It seems to me that there are at least two meanings associated with RDS. One is the ability to browse the file system or a remote database, and add/edit files. The other has to do with the ability to deploy files to remote servers. For example, in Homesite+ selecting a file and right clicking on it allows you to access a deployment option. That option brings up a dialog box that allows you select any RDS or FTP server one has defined and deploy the file. This is very powerful for those of us that deploy code to dev, qa, and integration environments during the development life cycle. I appreciate the concern about security above, but what I would like to know is this, does RDS support include the remote deployment functionality we know in Homesite+?