On Mon, May 11, 2009 at 2:06 PM, Babak Farhang wrote:
> I am not familiar with the details of CFS, but I didn't interpret
> Michael's comment to mean that there is actually any rewriting going
> on here. The problem here appears to be one of translating the
> encrypted/compressed file position to
On Mon, May 11, 2009 at 12:19 AM, Andrzej Bialecki wrote:
>
> Unfortunately, current Lucene IndexWriter implementation uses seek /
> overwrite when writing term info dictionary. This is described in more
> detail here:
>
> https://issues.apache.org/jira/browse/LUCENE-532
>
Thanks for the enlight
Babak Farhang wrote:
If "position" is the only thing Lucene needs during writing, then that
is good news: seeking backwards and overwriting what's already
written--that would be difficult to implement. If Lucene employs a
write once strategy for file I/O (w/ no exceptions), then we wont
really
Seems to me this discussion is not necessarily limited to
*encryption*: if you can implement encryption, you can also implement
compression--which is perhaps interesting for archiving purposes (at
access time, faster than unzipping an entire archived Directory and
loading it, for example).
>> Luce
pplications the price of having unsecure data is
>> unacceptable, when secure data is published to a laptop for use
offline.
>> In this case, the additional time needed to access the index would be
>> acceptable.
>>
>> Examples: Military, Medical, and Financial information.
e price of having unsecure data is
>> unacceptable, when secure data is published to a laptop for use offline.
>> In this case, the additional time needed to access the index would be
>> acceptable.
>>
>> Examples: Military, Medical, and Financial information.
>&
he additional time needed to access the index would be
acceptable.
Examples: Military, Medical, and Financial information.
Thanks,
Peter
Subject:
Re: Lucene Index Encryption
<http://markmail.org/message/2munvfksg4gvifek>
Actions...
From:
Michael McCandless (luc...@mikemccandless.com)
Dat
However, in some applications the price of having unsecure data is
unacceptable, when secure data is published to a laptop for use offline.
In this case, the additional time needed to access the index would be
acceptable.
Examples: Military, Medical, and Financial information.
Thanks,
Peter
Sub
However, in some applications the price of having unsecure data is
unacceptable, when secure data is published to a laptop for use offline.
In this case, the additional time needed to access the index would be
acceptable.
Examples: Military, Medical, and Financial information.
Thanks,
Peter
Sub
> Lucene needs to be able to ask a RAF opened for writing what it's
> current "position" is during indexing, which it then stores away, and
> later during searching it needs to ask a RAF opened for reading to
> seek back to that position so it can read bytes from there. Would the
> encryption APIs
Would you encrypt at the file level? Ie, the encryption would live
"under" a RandomAccessFile (RAF) and otherwise feel "normal" to
Lucene?
(I think I remember others exploring encryption at the individual term
level, which is interesting but does leak information in that you can
see individual te
If you store such sensitive data that you think about index encription.
then I may suggest simply isolate the host with lucene index:
- ssh only, VERY limited set of users to login
- provide a solr over https to search the index (avoid in-tranzit interception)
- setup firewall rules
This way Lu
12 matches
Mail list logo
