This is an automated email from the ASF dual-hosted git repository.
engelen pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/pekko.git
The following commit(s) were added to refs/heads/main by this push:
new 7cd4d5fb00 docs: use different reference for deserialization security
(#2661)
7cd4d5fb00 is described below
commit 7cd4d5fb008922152e04ac69050f0e9932f8f9a6
Author: Arnout Engelen <[email protected]>
AuthorDate: Mon Feb 9 10:28:19 2026 +0100
docs: use different reference for deserialization security (#2661)
Since our previous link has a certificate configuration error now,
and did not respond when we notified them of that.
Fixes https://github.com/apache/pekko/issues/2651.
This seems like a more 'authorative' reference anyway.
---
docs/src/main/paradox/remoting-artery.md | 2 +-
docs/src/main/paradox/remoting.md | 2 +-
docs/src/main/paradox/serialization.md | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/src/main/paradox/remoting-artery.md
b/docs/src/main/paradox/remoting-artery.md
index 25495a9d59..39b22b07eb 100644
--- a/docs/src/main/paradox/remoting-artery.md
+++ b/docs/src/main/paradox/remoting-artery.md
@@ -270,7 +270,7 @@ compromising any node with certificates issued by the same
internal PKI tree.
By default, @ref[Java serialization](serialization.md#java-serialization) is
disabled in Pekko.
That is also security best-practice because of its multiple
-[known attack
surfaces](https://community.microfocus.com/cyberres/fortify/f/fortify-discussions/317555/the-perils-of-java-deserialization).
+[known attack
surfaces](https://docs.oracle.com/en/java/javase/25/core/addressing-serialization-vulnerabilities.html).
<a id="remote-tls"></a>
### Configuring SSL/TLS for Pekko Remoting
diff --git a/docs/src/main/paradox/remoting.md
b/docs/src/main/paradox/remoting.md
index 44eea89249..09f5c95c3c 100644
--- a/docs/src/main/paradox/remoting.md
+++ b/docs/src/main/paradox/remoting.md
@@ -434,7 +434,7 @@ compromising any node with certificates issued by the same
internal PKI tree.
By default, @ref[Java serialization](serialization.md#java-serialization) is
disabled in Pekko.
That is also security best-practice because of its multiple
-[known attack
surfaces](https://community.microfocus.com/cyberres/fortify/f/fortify-discussions/317555/the-perils-of-java-deserialization).
+[known attack
surfaces](https://docs.oracle.com/en/java/javase/25/core/addressing-serialization-vulnerabilities.html).
<a id="remote-tls"></a>
### Configuring SSL/TLS for Pekko Remoting
diff --git a/docs/src/main/paradox/serialization.md
b/docs/src/main/paradox/serialization.md
index 23ba295936..31000e306d 100644
--- a/docs/src/main/paradox/serialization.md
+++ b/docs/src/main/paradox/serialization.md
@@ -218,7 +218,7 @@ Applications should use standard Protobuf dependency and
not `pekko-protobuf-v3`
## Java serialization
-Java serialization is known to be slow and [prone to
attacks](https://community.microfocus.com/cyberres/fortify/f/fortify-discussions/317555/the-perils-of-java-deserialization)
+Java serialization is known to be slow and [prone to
attacks](https://docs.oracle.com/en/java/javase/25/core/addressing-serialization-vulnerabilities.html";)
of various kinds - it never was designed for high throughput messaging after
all.
One may think that network bandwidth and latency limit the performance of
remote messaging, but serialization is a more typical bottleneck.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
