I have a device driver that uses telnet. In order to parse the telnet response I make use of the "Scanner" class. This code was working perfectly fine up until Hub Update 2.0.7, and then it stopped working. Here's the snippet of code:
Scanner scanner = new Scanner(msg);
scanner.next()
iptext = scanner.next()
ip = iptext.substring(1, iptext.length()-1)
scanner.next()
mac = scanner.next()
//log.debug("IP: " + ip + ", MAC: " + mac)
state.lastContact = now()
state.ip = ip
sendEvent(name: "presence", value: "present", descriptionText: "Discovered in ARP table")
sendEvent(name: "switch", value: "on")
After updating to 2.0.7, this code no longer works, it now complains about a "SecurityException":
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during canonicalization: Expression [DeclarationExpression] is not allowed: (scanner = new java.util.Scanner(msg)) at line number: 87
java.lang.SecurityException: Expression [DeclarationExpression] is not allowed: (scanner = new java.util.Scanner(msg)) at line number: 87
Line 87 is the very first line of code in the code snippet above, specifically this line:
Scanner scanner = new Scanner(msg);
Was the Scanner class disabled for a reason? The removal of this class makes it a lot harder to parse responses from things like telnet in device drivers...
Yes, Scanner was not on our whitelist.. is is possible to just use the .split() or tokenize() methods there instead? I don't see anything in that code that would require the use of Scanner.
Yeah, I can certainly re-write it. It's just a bit frustrating that perfectly good code was disabled in an upgrade...
Scanner must have been on the whitelist in 2.0.6, since it was working in versions prior to 2.0.7?
Scanner seems like a pretty innocent class to have it Blacklisted. May I ask what the reason was for removing it from the whitelist in 2.0.7? It's sole purpose is to simply parse strings of text.
We have a limited whitelist now and we went through and looked at as much user code as we could, and with our beta testers to make sure nothing broke. Obviously we missed yours. Unless there are some other features of Scanner that are needed it seems like the built in Groovy String methods are fine for what you need Scanner for so we won't be adding it.
Hmmm. I don't like the sound of that at all. I think perhaps I missed a document somewhere which explains the ground rules. I was attracted to Hubitat because it was supposed to be open, local, developer / power-user friendly, etc. Can I ask who exactly is deciding which language features we do or do not need? How is that being communicated? What is the process for making requests or appealing decisions? What exactly is the benefit of locking this down vs. allowing users to do what they want?
FYI that I am a developer by trade and have been doing Java work for a long time. I became a Sun Certified Java Programmer way back in 1999. I have been doing Java / JEE / Groovy / Python / PERL / you-name-it for 20+ years. It rubs me the wrong way to hear that you're going to tell me how I can use the device I bought. It sounds like you're essentially arbitrarily crippling the device, incrementally, and without input or feedback from your customers? Is this whitelist published anywhere?
I started a week or two ago writing my own UDP listener to support a class of devices I have at home, using a number of classes from java.net.* and java.nio.* which I suspect are way off the reservation in terms of whatever whitelist we're discussing here. I've just gone back and tried to re-save that code and am now getting errors, obviously due to this same change. I really do NOT appreciate that at all.
I am not trying to win or lose any points, I was trying to voice what I think is a legitimate concern and one which I suspect will be shared by many more once it becomes clear what a big change was just made. I think I asked a number of legitimate questions about the process, communication, and documentation. I wasn't rude, but I did express that I was and am upset. If that is not appropriate for this community then I think I am very, very confused.
It was done as we had a security audit and found some issues. I'm going to be brutally honest with you, at this point the "process" is arbitrary. You said you have not been here long so I will tell you that we are very open to feedback about how the system works and what we add to it. We are also very active and very responsive in the community. We will post the whitelist in our docs and we are open to suggestions about what is allowed and what is not.
That being said, we are not an open source project and so we do not release our source code and we are also not creating a development environment. We are creating a home automation hub that allows for coding extensibility within our sandbox. That sandbox is there to protect you and to protect us. We had to make some choices on white listing based on existing apps and drivers to allow all existing code to function. For instance if you try to use Scanner on Smarthings you will also get a security error. I did not see a reason to add that class in based on the code listed above.
I understand wanting to do advanced programming but we still have to maintain the security of our system. I myself have been a Java developer since 2002, so I can understand wanting to use various classes and libraries, however there are some great features in Groovy that allow you to do so much more than you can in Java.
There are plenty of people here on the forum to give help and suggestions. If there are classes that you feel you need, please bring them up and we can discuss.
The benefit for the userbase is that everyone enjoys having a reasonable amount of stability in the Hubitat environment. From a support perspective, they are dealing with fewer issues by blocking classes known to have issues or carry risks.
They have already limited your how you use the device by not allowing you root access to it. They provide a sandboxed environment for development, as such, by definition they determine what is allowed in their sandbox.
You have drawn that conclusion from two weeks of using Hubitat?
Thank you for taking the time to provide me a reasonable response. Part of what concerned me with the original response was that it did seem a little abrupt. Perhaps I overreacted to that. I apologize.
A lot of my excitement was about having the opportunity to build some things which would close gaps around some of the current out-of-the-box capabilities or lack thereof. Yes, I am new to this product - but I don't think I am speaking out of turn in saying that the product is still maturing and that a few people (relatively) are working hard to close a lot of gaps in terms of driver stability, features, and device support. There is also the problem of the many vs. the few - clearly, you guys are going to work hardest to address the broadest needs, and niche needs (like less popular devices) will be a lot slower to get attention if at all. Working with a limited set of tools may make it harder for your expert / power users to self-service. My example is my set of Haiku (Big-Ass Fan Company) fans, lights, and controls which use UDP peer-to-peer as well as broadcast for control and event notification. As far as I understand from the documentation I have reviewed, there is no way to listen for UDP broadcast packets on a port currently - though I was building one with non-whitelisted Java classes. Quite possibly this is a very specialized requirement which you'll never decide to support, and that's why I got upset.
