This is an automated email from the ASF dual-hosted git repository.

asf-gitbox-commits pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mina-site.git


The following commit(s) were added to refs/heads/master by this push:
     new 405c64d49 Fixed some wrong version in the news. Added info on the SSL 
internal
405c64d49 is described below

commit 405c64d490591f54d560e5b049a432ee05b8769b
Author: emmanuel lecharny <[email protected]>
AuthorDate: Fri Jul 31 17:55:46 2026 +0200

    Fixed some wrong version in the news. Added info on the SSL internal
---
 source/mina-project/news.md                                  | 12 ++++++------
 .../mina-project/technical-documentation/ssl-tls-internal.md | 11 ++++++++---
 2 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/source/mina-project/news.md b/source/mina-project/news.md
index 9c57adc37..d32f4cb6e 100644
--- a/source/mina-project/news.md
+++ b/source/mina-project/news.md
@@ -14,7 +14,7 @@ This is a bug fix release: A fix for CVE-2026-47065 
("Critical Deserialization A
 Many thanks to **tonghuaroot** who have reported this mistake.
 
 
-## Versions affected
+## Affected versions
 
 These issues affects **MINA** core versions prior to 2.1.15 and 2.0.31
 
@@ -22,15 +22,15 @@ These issues affects **MINA** core versions prior to 2.1.15 
and 2.0.31
 
 Those who used the versions 2.2.14, 2.0.30 and prior have to upgrade.
 
-## MINA 2.2.8, 2.1.14, 2.0.30 released _posted on June, 19 2026_
+## MINA 2.2.9, 2.1.14, 2.0.30 released _posted on June, 19 2026_
 
-The MINA project is pleased to announce the MINA 2.2.8, 2.1.14 and 2.0.30 
releases.
+The MINA project is pleased to announce the MINA 2.2.9, 2.1.14 and 2.0.30 
releases.
 
 This is a bug fix release: the last release was supposed to fix the 
Compression Filter, and it does, to some extent, except that a copy/paste made 
it so that the deflater became actually an inflater. The unit test for this 
feature has been... commented (due to a Mock library migration that didn't go 
well, and it was expected to be temporary), so all the tests passed green. 
Wrongly...
 
 Bottom line thanks to Jörg Michelberger who accuratly reviewed the code, we 
were made aware of this mistake, and decided to cut this release ASAP.
 
-## Versions affected
+## Affected versions
 
 These issues affects **MINA** core versions 2.2.8, 2.1.13 and 2.0.29 and none 
of the previous versions
 
@@ -163,7 +163,7 @@ potentially leading to remote code execution (**RCE**) 
attacks.
 A security release has been issued in Decmber 2024, but was incomplete. An 
allow-list of classes was added to tell MINA which classes can be used by the 
deserialization of messages through the *AbstractIoBuffer.getObject()* method, 
but static classes or primitives types are bypassing this check.  
 
 
-## Versions affected
+## Affected versions
 
 These issues affects **MINA** core versions 2.1.X and 2.2.X, and is fixed by 
the releases 2.1.12 and 2.2.7.
 
@@ -252,7 +252,7 @@ potentially leading to remote code execution (**RCE**) 
attacks.
 A security release has been issued in Decmber 2024, but was incomplete. An 
allow-list of classes was added to tell MINA which classes can be used by the 
deserialization of messages through the *AbstractIoBuffer.getObject()* method, 
but static classes or primitives types are bypassing this check.  
 
 
-## Versions affected
+## Affected versions
 
 These issues affects **MINA** core versions 2.0.X, 2.1.X and 2.2.X, and is 
fixed by the releases 2.0.28, 2.1.11 and 2.2.6.
 
diff --git a/source/mina-project/technical-documentation/ssl-tls-internal.md 
b/source/mina-project/technical-documentation/ssl-tls-internal.md
index 478686852..3fac1c4cf 100644
--- a/source/mina-project/technical-documentation/ssl-tls-internal.md
+++ b/source/mina-project/technical-documentation/ssl-tls-internal.md
@@ -407,15 +407,20 @@ The generl algorithm is the following:
 
 ```
 - get the received bytes
-- check that the inbound channel is not closed
+- check that the inbound channel is not closed. If it's closed, throw an 
exception
 - allocate a decoded buffer if needed
 - try to unwrap the received data
 - if we don't have enough data to decode it into an application message
-  - wait for more incomoing data, and restart 
+  - exit the loop. We will go through the process once we have received more 
bytes
+- else 
+  - push the decoded  message to the next filter
+  - if we have some more bytes to deal with, restart to step 2, otherwise exit 
the loop
 
 ```
 
-Here are the calls
+One of the issue here is that we can't know what will be the size of the 
decoded buffer. 
+
+Here are the calls in the current implementation:
 
 ```
 SslFilter.messageReceived()

Reply via email to