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
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
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
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
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.
>&
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-
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
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
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
-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,
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
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
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
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 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
15 matches
Mail list logo