lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1603) Perl Response Writer
Date Sat, 30 Jan 2010 02:37:34 GMT

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

Hoss Man commented on SOLR-1603:
--------------------------------


{quote}
the output is a complex Perl data structure with search results which would presumably immediately
be assigned to a variable - not eval'd.
Absolutely agree with Erik and Yonik - I can't think of a realistic case in which this would
present a security risk.
{quote}

The only way (i know of) to utilize a string based representation of a data structure like
this in perl is using eval to convert it from a string representation to the intended data
structures...

bq. I'm aware of the risk of eval'ing untrusted strings, but I'm not sure how this could be
a problem with a Solr response.

...The issue is that If you have a network service whose output format is only useful when
"eval"ed by the client, then even if that service only ever produces serialized data (and
not serialized code) it still opens the client up to man in the middle attacks where a malicious
server can generate a response that _does_ include malicious code, and that code is executed
by the client ... man in the middle attacks of something like XML that provide tainted data
are bad enough, but the possibility of tainted code is really sketchy.

As i said before: i'm not making any statements about this patch being more/less safe then
any of the other existing response writers that are only useful when "eval"ed in a particular
language interpreter -- my point was that while I have never had any clear notion about how/when
evaling strings from an external source was considered "acceptable" in those language communities
(the example of python's literal_eval is a good one), I _am_ a heavy perl user, and i do know
that the Perl community as a whole actively discourages using eval to deserialize "perl" from
remote services -- this is precisely why things like YAML and the Storable API were created.
 Both have options to control how they should behave if/when code is encountered in the serialized
data.

I can see value in adding an output format designed to be trivially useful for perl, but i
don't feel comfortable advertising something for Perl users that directly violates Perl best
practices -- Particularly when we already have two writers that are fairly easy to use from
perl anyway (XML and JSON)




> 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.2.patch, 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