Le Vendredi 1 Décembre 2006 01:33, negrinv a écrit :
Thank you Robert for your commnets. I am inclined to agree with you, but I
would like to establish first of all if simplicity of implementation is the
overriding consideration. But before I dwell on that let me say that i have
discovered
Sloppy Phrase Scoring Misbehavior
-
Key: LUCENE-736
URL: http://issues.apache.org/jira/browse/LUCENE-736
Project: Lucene - Java
Issue Type: Bug
Components: Search
Reporter: Doron Cohen
[ http://issues.apache.org/jira/browse/LUCENE-736?page=all ]
Doron Cohen updated LUCENE-736:
---
Attachment: sloppy_phrase_tests.patch.txt
sloppy_phrase_tests.patch.txt contains:
- two test cases added in TestPhraseQuery.
These new tests currently fail.
Nicolas Lalevée-2 wrote:
Le Vendredi 1 Décembre 2006 01:33, negrinv a écrit :
Thank you Robert for your commnets. I am inclined to agree with you, but
I
would like to establish first of all if simplicity of implementation is
the
overriding consideration. But before I dwell on that let me
[ http://issues.apache.org/jira/browse/LUCENE-736?page=all ]
Doron Cohen updated LUCENE-736:
---
Attachment: sloppy_phrase_java.patch.txt
perf-search-new.log
perf-search-orig.log
Attached sloppy_phrase_java.patch.txt is fixing
Le Vendredi 1 Décembre 2006 11:10, negrinv a écrit :
Nicolas Lalevée-2 wrote:
Le Vendredi 1 Décembre 2006 01:33, negrinv a écrit :
Thank you Robert for your commnets. I am inclined to agree with you, but
I
would like to establish first of all if simplicity of implementation is
the
[
http://issues.apache.org/jira/browse/LUCENE-736?page=comments#action_12454955 ]
Yonik Seeley commented on LUCENE-736:
-
Great investigations Doron!
Personally I'm more concerned with (1) than (2). Was the fix for one issue
more
I agree with Nicolas.
I think the overhead of decrypting such small payloads (I think it is also
subject to an easy attack, and/or will increase index size dramtically in order
to prevent such small encryption blocks) will have a serious impact on
performance.
We use Lucene for indexing only
Not if running under OSX with encrypted swap turned on ! :)
-Original Message-
From: Nicolas Lalev�e [EMAIL PROTECTED]
Sent: Dec 1, 2006 4:49 AM
To: java-dev@lucene.apache.org
Subject: Re: Attached proposed modifications to Lucene 2.0 to support
Field.Store.Encrypted
Le Vendredi 1
Robert Engels [EMAIL PROTECTED] wrote on 01/12/2006 09:34:12:
... decrypting such small payloads .. I think it is also subject to an
easy attack,
In addition, index statistics are still available, right? So one can know
how many docs, which (encrypted) words appear in which docs and exactly
[
http://issues.apache.org/jira/browse/LUCENE-736?page=comments#action_12454971 ]
Paul Elschot commented on LUCENE-736:
-
I have had similar concerns when I implemented NearSpansOrdered.java and
NearSpansUnordered.java,
which are in the
I think we should not make too many assumptions about performance until we
can test alternative solutions.
The small payload overhead will be amply offset in my opinion by the ability
to be very selective about what is being encrypted, as opposed to wholesale
encryption and decryption. Also we
Victor,
I haven't looked at your patch/ZIP. It would be best to attach to a new JIRA
issue. That will be easier for others to look at (I already don't have the
email with your ZIP, for example). Also, a patch is strngly preferred if
you've made changes to existing code. If you can't do
That is a valid consideration Doron, which brings the discussion back to the
difference between encrypton and security. I believe that security is an end
application responsability, not Lucene's. For instance, is it possible to
write the end application so that those stats are hidden from or
Security should be responsibility of the application. However let's make it
clear that field level encryption is more a means of implementing security
and herefore an infrastructure functionality that in my opinion Lucene should
optionally provide. In the same way relational databases provide
Provision of encryption/decryption services API to support Field.Store.Encrypted
Key: LUCENE-737
URL: http://issues.apache.org/jira/browse/LUCENE-737
Project: Lucene -
Otis, I have raised JIRA Lucene-737. Please note a couple of points. The text
of the issue is a cut and paste of my original posting, which did not
include the encryption provider software, and attached the Lucene
modifications in diff form. The modifications attached to the JIRA are not
in diff
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12455020 ]
Doug Cutting commented on LUCENE-707:
-
Lucene Java, Hadoop Nutch all pointed to the image:
http://lucene.apache.org/java/docs/images/lucene_green_150.gif
I am delighted I am no longer a voice in the wilderness. I couldn't agree
more with you Joaquin!
Victor
Joaquin Delgado-2 wrote:
Security should be responsibility of the application. However let's make
it clear that field level encryption is more a means of implementing
security and
Does forrest not copy unused images? All the images live under the
xdocs/images directory properly in the source tree and I did a
recursive copy from the build.
-Grant
On Dec 1, 2006, at 5:18 PM, Doug Cutting (JIRA) wrote:
[ http://issues.apache.org/jira/browse/LUCENE-707?
Grant Ingersoll wrote:
Does forrest not copy unused images? All the images live under the
xdocs/images directory properly in the source tree and I did a recursive
copy from the build.
No, it seems that Forrest does not copy unused images into the build.
But projects probably shouldn't rely
: That is a valid consideration Doron, which brings the discussion back to the
: difference between encrypton and security. I believe that security is an end
: application responsability, not Lucene's. For instance, is it possible to
: write the end application so that those stats are hidden from
[ http://issues.apache.org/jira/browse/LUCENE-737?page=all ]
Hoss Man updated LUCENE-737:
Attachment: (was: bcprov-jdk14-133.jar)
Provision of encryption/decryption services API to support
Field.Store.Encrypted
: dismay I noticed that JIRA assigned licence to the ASF for the provider
: software. something which I did not intend and which cannot be valid. Can it
: be reversed please?)
the flag can't be modified, but attachments can be deleted, which i have
done for the jar in question.
feel free to
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12455076 ]
Marvin Humphrey commented on LUCENE-707:
One thing you might want to fix is the breadcrumb trail. The javascript that
generates it automatically inserts
[ http://issues.apache.org/jira/browse/LUCENE-737?page=all ]
victor negrin updated LUCENE-737:
-
Attachment: BouncyCastle Licence disclaimer
BouncyCastle Licence, to be read before using the BouncyCastle .jar file
Provision of encryption/decryption
I think you misunderstood. If you do not have encrypted swap (like
OSX provides for) then you encryption is pointless as anyone can
inspect the data as it it loaded into the heap by lucene - bypassing
the encryption.
I also think you underestimated the impact on the size of the
indexes,
27 matches
Mail list logo
