tracker issue : CF-3818547

+1. In CFML code, we're more likely to find problems than your lot are.

Vote by External U.

+1 "I'm a leaf on the wind. Watch how I soar." - Wash, Serenity

Vote by External U.

+1 Please make this possible.

Comment by External U.

+1 - Couldn't agree more with Adam and Adam that the CF Administrator code should not be encrypted and that the community is more likely to find issues and fixes than Adobe are. Closing it without comments and a reason of "As Designed" is complete BS. The whole point of the report was challenging the way it is been designed, so in my mind that is not a valid reason for closing the ticket. Please either re-open and make the change as requested or provide a reason as to why it shouldn't be done.

Vote by External U.

Shame and embarrassment at the state of the code are the only reasons I can see to not do this. Adobe CF is not that special, and can not continue to treat its users poorly. Let's see what's in there, and get it fixed.

Vote by External U.

+1 Seems like a reasonable request. I won't impugn your integrity or your skills or your goals. If you ignore the tone of the comments here and just evaluate it with respect to the merits, seems like you should reverse your decision. Adam C makes a great point when he says the community is capable of helping here. And Adam T has done plenty to help the language and community int he past. Opening up the access shouldn't hurt your business model while at the same time getting the possibility of better tools for your customers. That can only help.

Vote by External U.

Make the code visible so we can help debug it.

Vote by External U.

+1 "As designed"? Is that even a reason in this case? When the community that sails your ship presents a issue or resolution, doesn't it make sense to at least respond? There are great points being brought to the table in regards to why this request would be positive. In the back of my mind I read this action as "we're not confident in this being un-encrypted and we don't want a potential security hole to come to light (if there are any. (ya, there probably are.)); and we're so arrogant that we know best for our community. Who needs explanations." Which is of course bitterly absurd. We test, beat, batter and help fix every other end of the language over time to help you guys. Might as well make it the whole lot right? Because if the admin is pieced together in any related way like some other bits of CF, it'd do everyone a favor to be able to analyze and fix any issues. We wouldn't have to wait 8 months for a patch either. But that's none of my business. Wait. ;)

Vote by External U.

25 characters or more 25 characters or more Take one down Pass it around Encrypted code makes me frown I agree the source should be available somewhere to view and audit.

Vote by External U.

"Withdrawn" "As designed" Seriously wtf? It has been proven time and again that not only are you guys not good cfml developers, you are not good web developers period. This really sounds to me like you are afraid that if you unencrypt it then the world will see how true this statement is. Well guess what, the bad guys have probably already got the unencrypted version of this, so why not give the good guys a chance to look over the code and fix the problems before we have yet another embarrassing breach. The sheer arrogance of closing this ticket like that without even offering a reason is beyond the pale.

Vote by External U.

AsDesigned? The BUG here is in that design. In this day and age - with increased security exploits and the benefits of more eyes on the source code - you really need to CHANGE that design to fix this "BUG".

Vote by External U.

Makes perfect sense to me...

Vote by External U.

AsDesigned and Withdrawn both seem like invalid for closing this. Of course it works as designed, but thats why it is a enhancement request and shouldn't withdrawn be something the reporter does. There should be some reasoning explaining why this doesn't deserve to be implemented.

Vote by External U.

Thank for all the attention and feedback on this issue. This is issue will be reopened and evaluated internally. Any further update on the issue will be communicated through the comments here.

Comment by Rakshith N.

It would certainly be nice to know the code powering the admin. Even though we follow the lock down guide, everyone should be able to review all the code that runs on their servers.

Vote by External U.

I could not agree more with this statement from Adam. "If you decrypt them, then the community can provide feedback and patches to make them even more secure." Please decrypt.

Vote by External U.

+1 for decrypt. Better to fix the bugs/security issues then to locked down access to it

Vote by External U.

It would allow a good community review to find any security holes.

Vote by External U.

I wrote about this in the beta forums before. As the source code was stolen from Adobe anyway, it does not make sense to hide the source from your supporters in the CF community and leave it only available to those who are trying to exploit it.

Vote by External U.

+1 - It should use the Admin API.

Vote by External U.

Agree totally. There is no advantage to doing this any more, if there ever was.

Vote by External U.

I believe the community could improve the admin, as well as extend it. Encrypting the admin makes no sense any more.

Vote by External U.

So anyway Rupesh... you've had the best part of a year to mull this over, and here we are in the CF12 pre-release phase. "Any further update on the issue"...?

Comment by External U.

Oops... "Rakshith", rather than "Rupesh". I picked the wrong procrastinator ;-)

Comment by External U.

I would welcome an opportunity to help Adobe improve admin security by having the ability to access unencrypted code.

Vote by External U.

+1 - I'll add my vote to this list. Please decrypt the Admin.

Vote by External U.

I've been asking for this for years. Considering there is an Admin API, and the Admin API should have 100% parity with the Admin, there is no need to encrypt the admin.

Vote by External U.

+1 ... More eyes can only be a good thing.

Vote by External U.

+1 to Adam's question. "Any further update on the issue"? +1 to Ray's comment: "Considering there is an Admin API, and the Admin API should have 100% parity with the Admin, there is no need to encrypt the admin." Thanks!, -Aaron

Comment by External U.

Two months later now. Adobe?

Comment by External U.

While we appreciate the request for decrypting the administrator cfm files from a security review perspective, the recommendation from the security group at Adobe is to not ship decrypted administrator cfm files. The reason for this that we (Adobe) would like to be full control of the changes that are made to these cfm files. Decrypting the source files will potentially lead to cfml developers at our customer locations make changes to the code without understanding the security impact of the changes that are made. At Adobe we take security very seriously. To address the potential security issues with the administrator code, we will be arranging for a private security audit of the entire source code and any other measures as required.

Comment by Rakshith N.

OK, in that case how about you open source CFAdmin as a project. That way the community can help with bug fixing and security concerns, and when you come to build CF for release, you can encrypt the files you ship. Deals with both requirements.

Comment by External U.

Sorry Rakshith, I find that response unacceptable. There are a million and one ways I can make my server insecure. I could drop a vulnerable unencrypted file into the CFIDE folder. I could modify query.cfc (currently provided unencrypted) to not use query params, making all of my script queries that use it vulnerable to SQL Injection. Encryption is not the solution to this problem. Education is. And OF COURSE if someone modifies the code in their CFIDE folder they are liable for any vulnerabilities they introduce. Granted, Adam Cameron's proposal for an alternate path is... reasonably acceptable. If you were to publish the unencrypted code, say, on GitHub; and accept pull requests that improve it in meaningful ways (security, performance, usability, etc)... and then encrypt that to be included in the installer... I guess I will grudgingly accept that as a (poor) solution to this request.

Comment by External U.

Hi Rakshith, The private security audit should be of the Admin API code, not the CF Admin code. First, the CF Admin should use -only- the Admin API. Then have private security audit of the Admin API. This would allow 2 things: 1) Admin API would have 100% parity w/ CF Admin (ex: DSN creation via Admin API would have the same defaults as DSN creation via CF Admin) 2) A security audit of Admin API would implicitly cover CF Admin. (no need for 2 separate audits) Currently, a private security audit of only the CF Admin would not be sufficient. B/c the non-parity of non-audited Admin API could still potentially allow a breach. And, again, there's no need for 2 separate audits. And there's no need for the confusion caused by Admin API having separate defaults from CF Admin. The solution to both can be fixed simultaneously: have CF Admin -only- use Admin API. My primary issue w/ CF Admin and Admin API is: they're not in-sync. Then, once they're in-sync, this ticket could be re-visited since there would be less reason to encrypt the CF Admin code. Thanks!, -Aaron

Comment by External U.

Thanks for all the inputs and the feedback. The Security team does not want to go with the approach of open-sourcing the Administrator. @Aaron, we will evaluate the suggestion of bringing Admin API and Admin code in sync.

Comment by Vamseekrishna N.

Is this the same security team that facilitated the h.cfm hack? Are you sure you should be listening to them? (in case you hadn't worked it out, that was not a serious question, but was a serious observation that your "security team" isn't really up to much, and never has been. Which is why we started this discussion in the first place)

Comment by External U.