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
6 years, 5 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, 9 months
Smoke test suite for hibernate-cache
by Martin Gencur
Hi all,
I'm currently in the process of refreshing the "smoke" test suite for
Infinispan.
There's a relatively new module called hibernate-cache. Could someone
suggest tests that should be part of the smoke test suite?
Ideally just a few tens of test cases (maybe a few hundreds at most but
the test suite execution should finish in a few seconds).
A list of test classes as a reply to this email would be ideal:)
Thanks,
Martin
7 years, 3 months
Current 'master' status
by Tristan Tarrant
Dear all,
it's now been a while since we've embarked on a mission to kill all
those pesky unreliable tests and, while we've achieved quite some
progress, we're still not in an ideal and reliable situation.
I think we are quite close with the latest round of fixes, but there is
still one outstanding offender:
ISPN-6827 ReplTotalOrderVersionedStateTransferTest.testStateTransfer
random failures
Any other failures you wish to single out ?
I propose we move this to the unstable group, merge some of the pending
PRs and release 9.1.1 and branch for 9.2. At this point I'll rework the
9.x roadmap and schedule.
At this point we can reopen all of the PRs that were closed: make sure
you open them before rebasing, otherwise GitHub will complain.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
7 years, 3 months
infinispan cache retrieval - byte[]
by Alessandro Vaccarezza
Hi guys,
we ar facing an issue since quite a long time and can't come up with a solution.
Our simple application is deployed on a wildfly instance and make use of a local infinispan data store (infinispan-9.1.0.Final).
Wildfly resides on a CentOS 6.8 instance, Java version is 1.8.0_112.
We implemented a very basic servlet and registered as a listener. Within this servlet we use an org.infinispan.manager.EmbeddedCacheManager to retrieve an
existing cache and add values to it.
Compatibility mode is on.
The values added to the cache are instance of a simple Java POJO.
When we try to retrieve what we just added, within the same servlet, we get a byte array, no way to retrieve the original POJO.
When we force the cast we get the obvious:
java.lang.ClassCastException: [B cannot be cast to com.my.pojo.SamplePOJO
Servlet: https://gist.github.com/anonymous/e8752cc8457301c2c70b3255e5c3bbc5
POJO: https://gist.github.com/anonymous/f35900875500a4bd6b4bb3b0cf73a363
Infinispan config file: https://gist.github.com/anonymous/b8482595f6b86ecc5642cceb6a99ad5e
Retrieving the cache via Hot Rod client works fine; also, if compatibility mode is turned off everything works fine as well.
7 years, 3 months
A tool for adjusting configuration
by Sebastian Laskawiec
Hey,
Our cloud integration bits require a tool for adjusting the configuration
for certain use cases. A common example would be - take this `cloud.xml`
file, remove all caches, add a new, replicated cache as default one.
The tool should take either configuration or a file name as input (e.g.
`config-tool --add-default-cache -f cloud.xml` or `cat cloud.xml |
config-tool --add-default-cache > cloud-new.xml`) and print out
configuration either to System Out or to a file.
Do you have any ideas what could I use to write such a tool? Those
technologies come into my mind:
- Perl
- Python
- Java (probably with some XPath library)
Thoughts? Ideas? Recommendations?
Thanks,
Sebastian
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
7 years, 3 months
