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
7 years, 4 months
spare cycles
by Ion Savin
Hi all,
I have some spare cycles over the course of the year which I'm going to
use to contribute to open source projects.
If you can think of anything specific that you could use some help with
please let me know.
Thanks,
Ion Savin
7 years, 8 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
7 years, 8 months
Ordering of includeCurrentState events
by Radim Vansa
Currently remote events caused by includeCurrentState=true are not
guaranteed to be delivered before the operation completes; these are
only queued on the server to be sent but not actually sent over wire.
Do we want any such guarantee? Do we want to add to make events from
current state somehow distinguishable from the 'online' ones?
Given all the non-reliability with listeners failover I don't think this
is needed, but I'll rather check in the crowd.
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
7 years, 8 months
Testsuite: memory usage?
by Sanne Grinovero
Hey all,
I'm having OOMs running the tests of infinispan-core.
Initially I thought it was related to limits and security as that's
the usual suspect, but no it's really just not enough memory :)
Found that the root pom.xml sets a <forkJvmArgs> property to Xmx1G for
surefire; I've been observing the growth of heap usage in JConsole and
it's clearly not enough.
What surprises me is that - as an occasional tester - I shouldn't be
the one to notice such a new requirement first. A leak which only
manifests in certain conditions?
What do others observe?
FWIW, I'm running it with 8G heap now and it's working much better;
still a couple of failures but at least they're not OOM related.
Thanks,
Sanne
7 years, 8 months
