When you start Liferay 7 up, you'll probably notice it stopping for a
"quick" integrity check for its LPKGs.
This was supposed to be security measure which was used to verify
that the LPKG files have not been compromised, maliciously or not.
This is just too painful, specially, during development phases.
In production, this becomes an issue for availability when servers
need to be restarted and new servers created. Liferay is probably one
of the slowest to start up in your service stack, and the benefits of
this feature do not seem to be advantageous in any tradeoff scenario.
*please note that I will expose some arguments that are only valid
for containers and not for traditional servers.
In the past, when a lot of software was available through HTTP/FTP
that was not deployed with TLS, we were always advised to check hashes
and go through several procedures that became part of what today is
just common sense or automated for us via the network stack and other
parts of the system. (if you are not using current protocols well, you
probably have other issues).
One could argue that the source of the packages could be compromised,
but them, hashes would probably also be. And we should not mix the
subjects when looking into this feature, as it is not a security
measure, as it is just an integrity feature. So, keeping it alive just
by keeping it under the umbrella called "security" is not
Putting security considerations apart, and focusing on integrity, in
our current containerized world, there are so many extra layers
checking for integrity that this feature comes to a point were it is
The key here is that you already get this check when you deploy a container.
During its life, the container can be tempered with too, but one
could also think about read only containers and the fact that
containers can be replaced all the time. Leading to scenarios where if
the container by any chance had its files tempered with it will be
after stating up the service and before the next container replacement
what makes this check pointless in this description.
Fortunately it can be disabled by adding the following line to portal-ext.properties:
if you are using one of our images you can use this environment variable:
That's all you need. You should probably keep it in traditional
server deployments though to help you keeping the integrity of you