Proposal - encrypted cache
by Sebastian Laskawiec
Hey!
A while ago I stumbled upon [1]. The article talks about encrypting data
before they reach the server, so that the server doesn't know how to
decrypt it. This makes the data more secure.
The idea is definitely not new and I have been asked about something
similar several times during local JUGs meetups (in my area there are lots
of payments organizations who might be interested in this).
Of course, this can be easily done inside an app, so that it encrypts the
data and passes a byte array to the Hot Rod Client. I'm just thinking about
making it a bit easier and adding a default encryption/decryption mechanism
to the Hot Rod client.
What do you think? Does it make sense?
Thanks
Sebastian
[1] https://eprint.iacr.org/2016/920.pdf
5 years, 10 months
Hot Rod secured by default
by Tristan Tarrant
Dear all,
after a mini chat on IRC, I wanted to bring this to everybody's attention.
We should make the Hot Rod endpoint require authentication in the
out-of-the-box configuration.
The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
mechanism against the ApplicationRealm and require users to run the
add-user script.
This would achieve two goals:
- secure out-of-the-box configuration, which is always a good idea
- access to the "protected" schema and script caches which is prevented
when not on loopback on non-authenticated endpoints.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
6 years, 2 months
Re: [infinispan-dev] not sure if this is the place to post a question on infinispan
by Wayne Wang
Hi All,
I am not sure if this is the place I could post a question on infinispan.
Basically, I am testing a scenario of invalidation cache in a cluster environment. It looks like the instance that actually modified the object has not problem of re-building the cache after data is updated, but the instances (in the same cluster) receiving the signal to invalidate the cache will indeed invalidate the cache, but can not re-build the cache until cache expiration.
Is this intended design, or there is some wrong in the configuration?
Thanks,
Wayne
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Sanne Grinovero
Sent: Monday, July 31, 2017 12:04 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Conflict Manager and Partition Handling Blog
Great job! I love to see this improved and being described in detail.
+1 to add some practical examples, as I'm afraid we only notice
limitations in features like this when thinking about specific use-cases.
The option `REMOVE_ALL` seems sensible for the disposable Cache use case. One question though: if one partition has a defined value for a key, while the other partition has no value (null) for this same key, is it considered a conflict?
I think you need to clarify if a "null" in a subset of partitions causes the conflict merge to be triggered or not. I think it should:
for example having the cache use case in mind, an explicit invalidation needs to be propagated safely.
Thanks,
Sanne
On 26 July 2017 at 13:41, Ryan Emerson <remerson(a)redhat.com> wrote:
> Hi Galder,
>
> Thanks for the feedback.
>
> Conflicts are detected by applying a predicate to the returned
> Map<Address, CacheEntry> for each cache entry. Currently this
> predicate utilises Stream::distinct (so .equals), to check for
> multiple versions of an entry. So implementing pluggable strategies
> for defining a conflict should be trivial :)
>
> Good idea about a simple tutorial/demo, I'll look into it when I get a chance.
>
> Cheers
> Ryan
>
> ----- Original Message -----
>> Oh, if we can't find a simple tutorial for it, there's always
>> https://github.com/infinispan-demos :)
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>> > On 25 Jul 2017, at 17:11, Galder Zamarreño <galder(a)redhat.com> wrote:
>> >
>> > One more thing: have you thought how we could have a simple
>> > tutorial on this feature?
>> >
>> > It'd be great to find a simple, reduced, example to show it off :)
>> >
>> > Cheers,
>> > --
>> > Galder Zamarreño
>> > Infinispan, Red Hat
>> >
>> >> On 25 Jul 2017, at 16:54, Galder Zamarreño <galder(a)redhat.com> wrote:
>> >>
>> >> Hey Ryan,
>> >>
>> >> Very detailed blog post! Great work on both the post and the
>> >> feature! :D
>> >>
>> >> While reading, the following question came to my mind: how does
>> >> Infinispan determine there's a conflict? Does it rely on .equals() based equality?
>> >>
>> >> A follow up would be: whether in the future this could be pluggable, e.g.
>> >> when comparing a version field is enough to realise there's a conflict.
>> >> As opposed of relying in .equals(), if that's what's being used
>> >> inside :)
>> >>
>> >> Cheers,
>> >> --
>> >> Galder Zamarreño
>> >> Infinispan, Red Hat
>> >>
>> >>> On 17 Jul 2017, at 14:16, Ryan Emerson <remerson(a)redhat.com> wrote:
>> >>>
>> >>> Hi Everyone,
>> >>>
>> >>> Here's a blog post on the introduction of ConflictManager and the
>> >>> recent changes to partition handling.
>> >>>
>> >>> http://blog.infinispan.org/2017/07/conflict-management-and-partit
>> >>> ion.html
>> >>>
>> >>> Cheers
>> >>> Ryan
>> >>> _______________________________________________
>> >>> infinispan-dev mailing list
>> >>> infinispan-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>
>> >
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6 years, 9 months
Transactional consistency of query
by Radim Vansa
Hi,
while working on ISPN-7806 I am wondering how should queries work with
transactions. Right now it seems that updates to index are done during
either regular command execution (on originator [A]) or prepare command
on remote nodes [B]. Both of these cause rolled-back transactions to be
seen, so these must be treated as bugs [C].
If we index the data after committing the transaction, there would be a
time window when we could see the updated entries but the index would
not reflect that. That might be acceptable limitation if a
query-matching misses some entity, but it's also possible that we
retrieve the query result key-set and then (after retrieving full
entities) we return something that does not match the query. One of the
reproducers for ISPN-7806 I've written [1] triggers a situation where
listing all Persons could return Animal (different entity type), so I
think that there's no validity post-check (though these reproducers
don't use transactions).
Therefore, I wonder if the index should contain only the key; maybe we
should store an unique version and invalidate the query if some of the
entries has changed.
If we index the data before committing the transaction, similar
situation could happen: the index will return keys for entities that
will match in the future but the actually returned list will contain
stale entities.
What's the overall plan? Do we just accept inconsistencies? In that
case, please add a verbose statement in docs and point me to that.
And if I've misinterpreted something and raised the red flag in error,
please let me know.
Radim
[A] This seems to be a regression after moving towards async
interceptors - our impl of
org.hibernate.search.backend.TransactionContext is incorrectly bound to
TransactionManager. Then we seem to be running out of transaction and
are happy to index it right away. The thread that executes the
interceptor handler is also dependent on ownership (due to remote
LockCommand execution), so I think that it does not fail the local-mode
tests.
[B] ... and it does so twice as a regression after ISPN-7840 but that's
easy to fix.
[C] Indexing in prepare command was OK before ISPN-7840 with pessimistic
locking which does not send the CommitCommand, but now that the QI has
been moved below EWI it means that we're indexing before storing the
actual values. Optimistic locking was not correct, though.
[1]
https://github.com/rvansa/infinispan/commit/1d62c9b84888c7ac21a9811213b56...
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
6 years, 9 months
Annotated encoded entries
by Radim Vansa
Hi guys,
recently the new encoding stuff has dawned in the codebase, and I must
admit that keeping track what's in storage-format and what's not (and I
think I've spotted some bugs). I think that we could use Java 8's type
annotations that would explicitly mark the contents as encoded or not
encoded:
@Target({ ElementType.FIELD, ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER, ElementType.TYPE_PARAMETER, ElementType.TYPE_USE })
public @interface Storage {
}
@Target({ ElementType.FIELD, ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER, ElementType.TYPE_PARAMETER, ElementType.TYPE_USE })
public @interface External {
}
Then the Encoder would look like:
public interface Encoder {
@Storage Object toStorage(@External Object content);
@External Object fromStorage(@Storage Object content);
}
Eventually we could use tools like the Checker Framework [1] to enforce
explicit casts from non-annotated type to annotated. I am still not
fully decided if we should have separate annotations for keys & values.
While this gives some clarity on use, those annotations would have to be
rather ubiquitous (code bloat?). Nevertheless, what do you think about it?
Radim
[1] https://checkerframework.org/jsr308/
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
6 years, 9 months
Quick fix for ISPN-7710
by Galder Zamarreño
Hi all,
I'm seeing more and more people trying to do stuff like I did in [1] WRT to running server tasks in server.
One of the blockers is [2]. I know we have transcoding coming up but I wondered if we could implement the quick hack of referencing remote-query.server module from root org.infinispan module.
So, in essence, adding the following to org/infinispan/main/module.xml:
<module name="org.infinispan.remote-query.server" optional="true"/>
Once ISPN-7710 is in place, along with ISPN-7814, users can run the demos in [1] without a custom server build.
Cheers,
[1] https://github.com/infinispan-demos/swiss-transport-datagrid
[2] https://issues.jboss.org/browse/ISPN-7710
--
Galder Zamarreño
Infinispan, Red Hat
6 years, 9 months
