Pretty much as the title says. Can Codestriker be run on either of the above two database systems?
I've had a stab at getting it up and running on Sybase, but everytime you create something it seems to choke due to using TEXT fields.
DBD::Sybase::db prepare_cached failed: Server message number=2782 severity=16 state=1 line=1 server=ABCD procedure=DBD2 text=An untyped variable in the PREPARE statement 'DBD2' is being resolved to a TEXT or IMAGE type. This is illegal in a dynamic PREPARE statement.
I believe this is the explanation for the above error:
> I presume this relates to the statement in the DBD::Sybase man page:
> ?-style placeholders can NOT be used to pass TEXT or IMAGE data items to
> the server. This is a limitation of the TDS protocol, not of
Which doesn't bode well for Sybase. :-(
Wow - I have seen some database limitations before, but that one takes the cake!
I suspect you'll have a lot more luck with a real database system, such as DB2. Have you had any luck with DB2?
Well I tried a little perl test harness that does
a prepare_cached() and execute() on
"INSERT INTO ABCD (A, B) VALUES (?, ?)";
Against a DB2 table:
CREATE TABLE ABCD (A VARCHAR(10),B CLOB)
And that seems to work, which bodes well. Using Sybase (with IMAGE in place of CLOB) fails the above.
I imagine DB2 should be pretty easy to get working. Just follow the examples of one of the other database drivers in the Codestriker source code.
If you need any help - you can email me at:
sits AT users DOT sourceforge DOT net.
Once we get it working, we can commit it, so that it can be used in the next release.
Sure thanks. I have it sort of working against DB2 now but need to do a bit more testing first before I'm happy.
One caveat is that it doesn't work in 'tainted mode' (i.e. perl -T) as there is (initially anyway) a problem with "lib/Codestriker/Model/Project.pm" at line 50 - the $name variable is not passed into the database layer.
Can't bind unknown parameter marker '1' at ./codestriker-1.9.2/bin/../lib/Codestriker/Model/Project.pm line 50.
Is this type of thing a known bug? I'm using Perl 5.8.0 on RHEL3 (Linux 2.4.21)
I'm sure there may be a few more of these to flush out before I can turn tainted mode back on. Having said that I'll continue testing the DB2 integration without the tainted checks on for now and see how that shapes up.
Project.pm on line 50 is just:
my $success = defined $select;
I suspect that this is an issue with the DB2 DBD driver. I've never seen these messages before. Perhaps you can try updating your DBD::DB2 (or whatever it is) driver to see if it goes away.
But your approach is right - lets get it working for non-taint mode first.
Hi, firstly DB2 now works 100% in non-taint mode. (There is a new database layer file a bit like the Oracle one, and there are a few small fixes made to call finish() on a few of the prepared statements after use, which cause warnings to be raised in the logs.)
Secondly about the taint problems. I'm working off the 1.9.2 release so the Project.pm I'm using is:
At line 50 it is doing an execute() using $name as an argument, which is (according to Perl 5.8.2) tainted at that point in time and thus appears null. It could be that the DBD::DB2 code will only accept untainted input, whereas other DBD drivers are not that fussy.
The input appears to come from here:
And I cant find where 'project_name' is run past a regex to untaint it.
My question is am I understanding the processing flow within Codestriker right here?
This is interesting... I think you are correct, the DB2 driver must be a lot more strict at enforcing taintness.
The missing bit is in lib/Codestriker/Http/Input.pm. In here, you will see all HTTP variables are untainted, however project_name clearly hasn't been done. You could add the appropriate code in here, and that should fix the problem.
Once you have finish - yes a unidiff against 1.9.2 would be perfect, many thanks.
Actually, I'm replying to myself here.
Seems there is a particular problem with the DBI:DB2 logic where parameters passed to execute() cannot be tainted - unlike as for other database flavours.
So the upshot is it to either run codestriker in non-taint mode for DB2 or to untaint all cgi-input throughout the code. I'm tempted by the former, as it is an internal app, and the extra precautions are not required (for me).
As regards to submitting the DB2 patches written, I need approval from my firm first, so that may take a week or so first. How would you like them - a set of diffs against the 1.9.2 release?
In case its not clear, in Input.pm, we'd need to add code to all the remaining HTTP parameters which get used by the DB code, as something like:
This is safe, since all of the parameters are passed as proper database parameters.