manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: Release?
Date Thu, 16 Dec 2010 09:22:16 GMT
Tests are now complete for the framework changes.
Robert, Grant, please comment on CONNECTORS-128 about the future of
the FileNet and Documentum connectors.  If those connectors are deemed
acceptable, I can generate a new release candidate.

Karl

On Sun, Dec 12, 2010 at 6:48 PM, Karl Wright <daddywri@gmail.com> wrote:
> The preliminary change has been done, and I was able to hand-test a
> good chunk of the modified queries by hand, so I checked it in.  I
> still need to test document expiration, however, and I'd like the
> automated tests to cover the modified functionality.  I won't be able
> to get to it this until next weekend at the earliest,
>
> During the process of removing string constants from all queries, I
> also noticed that string constants are used by the FileNet and
> Documentum connectors.  These connectors have a proprietary, SQL-like
> language (I don't know what the FileNet language is called, but the
> Documentum one is called DQL.)  There does not appear to be any way to
> use the equivalent of query parameters for either sql-like language.
> If quoting is always unsafe, that would imply that neither the FileNet
> connector nor the Documentum connector could be made secure, by
> Robert's standards.  Of course, the same is going to be true of any
> FileNet or Documentum client code.
>
> Robert, Grant, do you believe I should delete these connectors?
>
> Karl
>
>
> On Fri, Dec 10, 2010 at 10:00 AM, Karl Wright <daddywri@gmail.com> wrote:
>> The only vulnerability occurs if:
>> (a) People use PostgreSQL configured incorrectly, AND
>> (b) Coders change ManifoldCF after the release to use the
>> quoteSQLString method for non-constant values.
>> OR
>> (a) People use PostgreSQL configured incorrectly, AND
>> (b) Our audit procedures have overlooked a non-constant usage of
>> quoteSQLString somehow.
>>
>> But, clearly, any whiff of a potential security issue, no matter how
>> remote the chances of one actually existing in real life, are clearly
>> enough to require some weeks of work before a release can be made.
>> Personally, I'd be concerned about places where just plain quotes
>> appeared in a string rather than finger quoteSQLString as a bad actor,
>> but so be it.
>>
>> I therefore withdraw the release plan and will delete the release
>> branch.  We can discuss strategy for release again when the code has
>> been reworked and all the tests exist to confirm to my satisfaction
>> that we've broken nothing.
>>
>> Karl
>>
>>
>>
>> On Fri, Dec 10, 2010 at 9:50 AM, Jack Krupansky
>> <jack.krupansky@lucidimagination.com> wrote:
>>> At this point in the discussion maybe what we need is a clearly stated Jira
>>> on the issue and what specifically is needed. Whether it is needed for 0.1
>>> is another matter. It sounds like (potentially) a definite 1.0 issue, but
>>> could we get by with a clear "statement of vulnerability" for a 0.x release
>>> (if in fact there is an actual vulnerability)?
>>>
>>> It sounds like there may be a distinction between "actual" vulnerability and
>>> "potential" vulnerability. Whether such a distinction really matters is
>>> another matter.
>>>
>>> -- Jack Krupansky
>>>
>>> -----Original Message----- From: Grant Ingersoll
>>> Sent: Friday, December 10, 2010 9:36 AM
>>> To: connectors-dev@incubator.apache.org
>>> Subject: Re: Release?
>>>
>>> I think if there are known vulnerabilities, we need to fix them.
>>>
>>> On Dec 10, 2010, at 6:01 AM, Karl Wright wrote:
>>>
>>>> You can be serious about security without agreeing on the remediation.
>>>> This software certainly adhered to MetaCarta standards and was
>>>> audited by government agencies as well.  I understand your position,
>>>> but I don't know if everyone will see it in a similar way, since a
>>>> code audit highlights no problems at this time, because quoteSQLString
>>>> is used only on constant values.  What do others think?  If the
>>>> incubator would prohibit release on this basis, how in the heck did
>>>> solr ever get released?
>>>>
>>>> Karl
>>>>
>>>> On Fri, Dec 10, 2010 at 8:50 AM, Robert Muir <rcmuir@gmail.com> wrote:
>>>>>
>>>>> On Fri, Dec 10, 2010 at 8:42 AM, Karl Wright <daddywri@gmail.com>
wrote:
>>>>>>
>>>>>>  Do you believe that this is a
>>>>>> requirement for an initial release?  If so, I believe we should
>>>>>> suspend plans for that release and revisit it in February or March.
>>>>>>
>>>>>
>>>>> I'll certainly go along with whatever everyone feels on this one... it
>>>>> was just always my impression that Apache was pretty serious about
>>>>> security, but I'm not really sure how this applies to incubating
>>>>> projects etc.
>>>>>
>>>>> I thought it was relevant especially since the Solr Wiki says: The
>>>>> recommended way to add document level security to your search is
>>>>> through Apache Lucene Connector Framework (LCF).
>>>>>
>>>>> http://wiki.apache.org/solr/SolrSecurity
>>>>>
>>>
>>>
>>
>

Mime
View raw message