I would be surprised if taint is the cause of your pain. From what I know: * you are the sole responsible for activating taint mode. It has to be set in the hash-bang and possibly provided on the command line; * when taint kicks in something like "die()" happens, so you should be pretty aware of it (unless you wrap it all with eval() and throw away any error). You can try your command-line script with taint mode turned on by means of the "-T" command-line switch (see perldoc perlrun for details). If you want to try and untaint the input string for the password, you have to use a regular expression: my ($untainted_password) = $tainted_password =~ /(.*)/; Note that the "blind untaint" method above is frowned upon, tainting is all about forcing you (the programmer) to carefully check your inputs so you should try to figure out the correct way to validate the input. In this case I think that we can assume that any character is valid for a password, so the whole string is good. One thing I'd look at is encoding. I'd try to see whether, in the two different contexts, the two password: 1. have the same encoding status (use utf8::is_utf8() for this, see perldoc utf8) 2. are exactly the same (in this case I'd use something like warning unpack 'H*', $password; in order to see the raw bytes in hex). Good luck, Flavio. On Wed, Apr 20, 2011 at 8:20 PM, Gurunandan Bhat <gbhat@pobox.com> wrote:
Hi,
I am in the process of writing a Dancer application that does (in part) some heavy lifting of PKI (RSA) [en|de]cryption using Crypt::OpenSSL::RSA and a few other Crypt::* modules and have been hit with an issue that I do not fully understand. Here is a rough sequence of what happens:
1. I have written a Moose based class that does PKI stuff. One of the the methods in this class is encrypting binary strings using a Public Key. The Public Key is read from a file on disk. 2. When I run a test script with this class, the encryption works fine. 3. When I run the same script as a route handler in Dancer the encryption silently produces the wrong result - decrypting it does not give me the original string. 4. Testing is a bit hard and complicated due to the fact that RSA encryption is not deterministic and encrypting the same string twice will give wildly different strings but decrypting both should correctly give the original string. However after a few days of trying out multiple test code - I am reasonably certain that *encryption with Crypt::OpenSSL::RSA gives the correct result from the command line but gives the wrong result when run as a Dance route handler*.I am currently working around this by doing the encryption through a script on disk which the route handler runs - but this is obviously too silly for words.
The only thing I can attribute this to is that my input string collected from a form and/or my public key object which I read from file are marked as tainted in Dancer but not in a command line script and that Crypt::OpenSSL::RSA has a bug when used with tainted variables. This is a conjecture but the only one that seems likely given the large amount of testing that I have done.
With this background here are a couple of questions that I have:
1. Does Dancer taint input variables received from the user(-form)? 2. If yes, how do I untaint it. 3. How can I conclusively confirm that taintedness is causing the difference in output between the command line script and the route handler. With identical inputs to my command line script and to my route handler I am certain that there is a difference in output. I am wondering if taintedness is the cause.
Thank you for your patience in reading this rather long message
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users