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, 3 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, 7 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
8 years, 2 months
Feedback for PR 5233 needed
by Adrian Nistor
This pr [1] adds a new approach for defining the compat marshaller class
and the indexed entity classes (in server), and the same approach could
be used in future for deployment of encoders, lucene analyzers and
possilby other code bits that a user would want to add a server in order
to implement an extension point that we support.
Your feedback is wellcome!
[1] https://github.com/infinispan/infinispan/pull/5233
8 years, 3 months
Write-only commands
by Radim Vansa
Hi,
I am working on entry version history (again). In Como we've discussed
that previous values are needed for (continuous) query and reliable
listeners, so I wonder what should we do with functional write-only
commands. These are different to commands with flags, because flags
(other than ignore return value) are expected to break something. I see
the available options as:
1) run write-only commands 'optimized', ignoring any querying and such
(warn user that he will break it)
2) run write-only without any optimization, rendering them useless
3) detect when querying is set up (ignoring listeners and maybe other
stuff that could get broken)
4) remove write-only commands completely (and probably functional
listeners as well because these will lose their purpose)
Right now I am inclined towards 4). There could be some internal use
(e.g. multimaps) that could use 1) which is ran without a fancy setup,
though, but it's asking for trouble.
WDYT?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
8 years, 3 months
9.1.0 endgame
by Tristan Tarrant
Hi all,
I have updated Jira with the next milestones for 9.1.0
9.1.0.CR1 - 30th June
9.1.0.Final - 14th July
This extends the traditional minor-release timebox by two weeks,
essential because the features we wanted for Beta were a bit late.
From now until the end we should only consider features whose PR have
been open for a while (e.g. scattered cache). Bug fixes and minor
enhancements to existing features are obviously allowed.
Anything else will need to be shunted to 9.2.0.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
8 years, 3 months
