lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claudio Valente (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-1603) Perl Response Writer
Date Thu, 28 Jan 2010 18:31:34 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805977#action_12805977
] 

Claudio Valente edited comment on SOLR-1603 at 1/28/10 6:31 PM:
----------------------------------------------------------------

Evaluating code from a foreign string is always a security risk and as far as I know is certainly
discouraged in python, perl and php (I suppose ruby too but I don't have enough info).

That's why in python 2.6 the ast.literal_eval was added http://docs.python.org/library/ast.html#ast.literal_eval

Up until that version there was no "safe" way to recover the structures returned from solr's
python response writer apart from using eval or parsing the string yourself. In fact, even
the python bindings to solr I know of use the XML writer.

php and ruby writers suffer from the same problems and I'm not aware of any mitigating approach
such as ast.literal_eval for python.

Even phps (built with the purpose to share data in this way) can crash php, cause massive
memory allocations and even result in code injection.

Following your reasoning (and I'm not questioning its validity) the python, ruby, php and
even phps response writers should be removed or at the very least shouldn't have been added
to the tree.

As for tests, I tried to make some but found none except for JSON and phps  writers. These
are seriously lacking (only test minimal serialization without taking into account indentation
and no unicode for example). Since there were no tests for python, ruby nor php (only phps)
writers I thought these weren't mandatory. If these tests exist, please show me where so that
I can get a feel on what I'm supposed to do here.

If the JSON test is the usual example for this kind of test then I can write an analogous
one for the perl writer but given its naiveté I don't think it will add much.

      was (Author: cvalente):
    Evaluating code from a foreign string is always a security risk and as far as I know is
certainly discouraged in python, perl and php (I suppose ruby too but I don;t have enough
info).

That's why in python 2.6 the ast.literal_eval was added http://docs.python.org/library/ast.html#ast.literal_eval

Up until that version there was no "safe" way to recover the structures returned from solr's
python response writer apart from using eval or parsing the string yourself. In fact, even
the python bindings to solr I know of use the XML writer.

php and ruby writers suffer from the same problems and I'm not aware of any mitigating approach
such as ast.literal_eval for python.

Even phps (built with the purpose to share data in this way) can crash php, cause massive
memory allocations and even result in code injection.

Following your reasoning (and I'm not questioning its validity) the python, ruby, php and
even phps response writers should be removed or at the very least shouldn't have been added
to the tree.

As for tests, I tried to make some but found none except for JSON and phps  writers. These
are seriously lacking (only test minimal serialization without taking into account indentation
and no unicode for exeample). Since there were no tests for python, ruby nor php (only phps)
writers I thought these weren't mandatory. If these tests exist, please show me where so that
I can get a feel on what I'm supposed to do here.

If the JSON test is the usual example for this kind of test then I can write an analogous
one for the perl writer but given its naiveté I don't think it will add much.
  
> Perl Response Writer
> --------------------
>
>                 Key: SOLR-1603
>                 URL: https://issues.apache.org/jira/browse/SOLR-1603
>             Project: Solr
>          Issue Type: New Feature
>          Components: Response Writers
>            Reporter: Claudio Valente
>            Priority: Minor
>         Attachments: SOLR-1603.patch
>
>
> I've made a patch that implements a Perl response writer for Solr.
> It's nan/inf and unicode aware.
> I don't know whether some fields can be binary but if so I can probably extend it to
support that.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message