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, 9 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, 1 month
Prepending internal cache names with org.infinispan instead of triple underscore
by Galder Zamarreño
Hi all,
I'm currently going through the JCache 1.1 proposed changes, and one that made me think is [1]. In particular:
> Caches do not use forward slashes (/) or colons (:) as part of their names. Additionally it is
> recommended that cache names starting with java. or javax.should not be used.
I'm wondering whether in the future we should move away from the triple underscore trick we use for internal cache names, and instead just prepend them with `org.infinispan`, which is our group id. I think it'd be cleaner.
Thoughts?
[1] https://github.com/jsr107/jsr107spec/issues/350
--
Galder Zamarreño
Infinispan, Red Hat
6 years, 4 months
JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net
by Rory O'Donnell
Hi Galder,
*JDK 10 Early Access build 33 is available at : - **jdk.java.net/10/*
Notable changes since previous email.
<http://bugs.openjdk.java.net/browse/JDK-8175094>JDK-8180019
<http://bugs.openjdk.java.net/browse/JDK-8180019> - *javadoc treats
failure to access a URL as an error , not a warning.*
If javadoc cannot access the contents of a URL provided with the -link
or -linkoffline options,the tool will now report an error.
Previously, the tool continued with a warning, producing incorrect
documentation output.
JDK-8175094 <http://bugs.openjdk.java.net/browse/JDK-8175094>*- **The
java.security.acl APIs are deprecated, for removal****
* The deprecated java.security.acl APIs are now marked with
forRemoval=true and are subject to removal in a future version of Java SE.
JDK-8175091 <http://bugs.openjdk.java.net/browse/JDK-8175091> *- The
java.security.{Certificate,Identity,IdentityScope,Signer} APIs are
deprecated, for removal*
The deprecated java.security.{Certificate, Identity, IdentityScope,
Signer} classes are now marked with forRemoval=true and are subject to
removal in a future version of Java SE.
JDK 10 Schedule, Status & Features are available [1]
Notes
* OpenJDK EA binaries will be available at a later date.
* Oracle has proposed: Newer version-string scheme for the Java SE
Platform and the JDK
o Please see Mark Reinhold's proposal [2]
*JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/*
<http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
*Feedback* - If you have suggestions or encounter bugs, please submit
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the
|java --version| command.
Regards,
Rory
[1] http://openjdk.java.net/projects/jdk/10/
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
6 years, 4 months
infinispan-bom needs some love
by Galder Zamarreño
Hi all,
Re: https://issues.jboss.org/browse/ISPN-8552
Re: https://issues.jboss.org/browse/ISPN-8408
Just fell of my chair with ^
Did I somehow miss a discussion on ISPN-8408? Anything that changes infinispan-bom needs to be discussed in this list :|
Can someone ellaborate what problem ISPN-8408 is trying to fix in infinispan-bom exactly? I have personally not heard anyone complaining about it.
>From my POV, the easiest way to consume Infinispan is leaving the infinispan-bom as it was. So, the vert.x way.
If we want a different "bom" that doesn't contain Infinispan modules, maybe we can add it separately and don't break existing examples/apps... but it really needs solves a problem :|
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
6 years, 4 months
9.2.0 schedule
by Tristan Tarrant
Dear all,
I've made some changes to the 9.2.0 schedule to adapt them to the delays
introduced during this cycle. Because of the Christmas holidays, I've
moved Final over to January.
2017-11-29 9.2.0.Beta2
2017-12-13 9.2.0.CR1
2018-01-10 9.2.0.Final
Hack on!
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
6 years, 5 months
Weekly Infinispan Meeting IRC Logs 2017-11-20
by Tristan Tarrant
Dear all,
yesterday's meeting logs are here:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/inf...
Since I wasn't present, here is my update:
- ISPN-8543 Pluggable global configuration persistence
I've extracted the persistence logic from the global configuration stuff
introduced in ISPN-7776 so that in the future we can add alternate
providers, such as ones for server standalone and domain mode,
kubernetes configmap, etc.
- ISPN-8529 Implement cache admin ops over the REST protocol
I wrote a quick implementation of this using WebDAV protocol ops, but at
Gustavo's suggestion I'm reworking it to make it more RESTful. I should
have it done this week.
I've also spent a little time looking at some test failures and trying
to iron out the two component upgrade PRs.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
6 years, 5 months
The future of Infinispan Docker image
by Sebastian Laskawiec
Hey!
Together with Ryan we are thinking about the future of Infinispan Docker
image [1].
Currently we use a single Dockerfile and a bootstrap script which is
responsible for setting up memory limits and creating/generating (if
necessary) credentials. Our build pipeline uses Docker HUB integration
hooks, so whenever we push a new commit (or a tag) our images are being
rebuilt. This is very simple to understand and very powerful setup.
However we are thinking about bringing product and project images closer
together and possibly reusing some bits (a common example might be Jolokia
- those bits could be easily reused without touching core server
distribution). This however requires converting our image to a framework
called Concreate [2]. Concreate divides setup scripts into modules which
are later on assembled into a single Dockerfile and built. Modules can also
be pulled from other public git repository and I consider this as the most
powerful option. It is also worth to mention, that Concreate is based on
YAML file - here's an example of JDG image [3].
As you can see, this can be quite a change so I would like to reach out for
some opinions. The biggest issue I can see is that we will lose our Docker
HUB build pipeline and we will need to build and push images on our CI
(which already does this locally for Online Services).
WDYT?
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/infinispan/tree/master/server
[2] http://concreate.readthedocs.io/en/latest/
[3]
https://github.com/jboss-container-images/jboss-datagrid-7-openshift-imag...
6 years, 5 months
