Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-05 Thread negrinv
there is a third way Doug, and it's for me to stop trying to be polite by answering all the questions that I am being asked, then nobody will get upset by my replies. If the decision is for no encryption at field level, I accept it, but I don't believe it should be externalised. Perhaps someone e

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-05 Thread negrinv
there is absolutely no suggestion to make any changes to the index format. the index format would not change, whether you use encryption or not. Chuck Williams-2 wrote: > > > > Mike Klaas wrote on 12/05/2006 11:38 AM: >> On 12/5/06, negrinv <[EMAIL PROTECTED]> wrote

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-05 Thread negrinv
Doug Cutting wrote: > > > Some utilities for encrypting and decrypting binary fields might make a > useful contrib module, but I see no compelling reason to add this to the > core at this point. If such a contrib module becomes widely used, and > it becomes clear that it would work better i

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-05 Thread negrinv
Chris Hostetter wrote: > > > Compression of stored fields is a feature that the Lucene "core" currently > supports out of the box -- but it does so in a very limited maner that > doesn't allow for much configuration. There is no advantage for users in > using compressed fields over compressing

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-02 Thread negrinv
ke a HUGE difference in the size of the index. > > On Dec 1, 2006, at 2:00 PM, negrinv wrote: > >> >> Good news for OSX users! but what about all the others, should I >> say the >> majority?? >> One more reason for encrypting at field level. >&

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-01 Thread negrinv
if the data fell in obscure hands and they know how to read > the lucene index, they would not be able to see the values stored with it. > > Think about credit card numbers for example ;-) > > That's my two cents. > > -- Joaquin > > > -Original Message-

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-01 Thread negrinv
n't do it > from Eclipse, do it from the command-line: svn diff src, or some such. > > Otis > > - Original Message > From: negrinv <[EMAIL PROTECTED]> > To: java-dev@lucene.apache.org > Sent: Friday, December 1, 2006 5:10:47 AM > Subject: Re: Attach

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-01 Thread negrinv
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 inacc

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-01 Thread negrinv
as 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 D�cembre 2006 11:10, negrinv a �crit�: >>> Nicolas Lale

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-01 Thread negrinv
-Original Message- >>From: Nicolas Lalev�e <[EMAIL PROTECTED]> >>Sent: Dec 1, 2006 2:20 AM >>To: java-dev@lucene.apache.org >>Subject: Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted >> >>Le Vendredi 1 D�cembre 2006 01:33,

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-12-01 Thread negrinv
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

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-11-30 Thread negrinv
ble to me that if > encryption support were added, eventually, application developers will try > to sell Lucene developers on adding features to it in addition to > supporting > and maintaining it (ala configurable compression quality factor). A > configurable, encrypting Base64

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-11-30 Thread negrinv
eate a EncryptedDirectory > implementation of Directory, which requires a password to open/modify the > directory. > > Far simpler, and if yuou are using encryption to begin with, you are > probably encrypting most of the data anyway. > > -Original Message- >>From: n

Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-11-29 Thread negrinv
with utility > methods would be a compromise to preserve this work and make it accessible > to others, or alternatively just a faq entry with the sample code or > references to it. > Luke > > On 11/29/06, negrinv <[EMAIL PROTECTED]> wrote: >> >>

Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted

2006-11-29 Thread negrinv
Attached are proposed modifications to Lucene 2.0 to support Field.Store.Encrypted. The rational behind this proposal is simple. Since Lucene can store data in the index, it effectively makes the data portable. It is conceivable that some of the data may be sensitive in nature, hence the option to