public inbox for ipfire-scm@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <git@ipfire.org>
To: ipfire-scm@lists.ipfire.org
Subject: [git.ipfire.org] IPFire 2.x development tree branch, master, updated. a80d817716406d88b8c7e82397f4618d64e499a9
Date: Tue, 03 Sep 2024 18:02:50 +0000	[thread overview]
Message-ID: <4Wytky3H0Sz2xSd@people01.haj.ipfire.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 4240 bytes --]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "IPFire 2.x development tree".

The branch, master has been updated
       via  a80d817716406d88b8c7e82397f4618d64e499a9 (commit)
       via  74a02d3372fe99bfa5dee8bfed6b64670d99775f (commit)
      from  3ce4d238d255477a240c3b1479cb34828c87fb59 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit a80d817716406d88b8c7e82397f4618d64e499a9
Author: Michael Tremer <michael.tremer(a)ipfire.org>
Date:   Tue Sep 3 18:02:34 2024 +0000

    core188: Ship OpenSSL
    
    Signed-off-by: Michael Tremer <michael.tremer(a)ipfire.org>

commit 74a02d3372fe99bfa5dee8bfed6b64670d99775f
Author: Michael Tremer <michael.tremer(a)ipfire.org>
Date:   Tue Sep 3 18:00:17 2024 +0000

    openssl: Update to 3.3.2
    
    Possible denial of service in X.509 name checks (CVE-2024-6119)
    ===============================================================
    
    Severity: Moderate
    
    Issue summary: Applications performing certificate name checks (e.g., TLS
    clients checking server certificates) may attempt to read an invalid memory
    address resulting in abnormal termination of the application process.
    
    Impact summary: Abnormal termination of an application can a cause a denial of
    service.
    
    Applications performing certificate name checks (e.g., TLS clients checking
    server certificates) may attempt to read an invalid memory address when
    comparing the expected name with an `otherName` subject alternative name of an
    X.509 certificate. This may result in an exception that terminates the
    application program.
    
    Note that basic certificate chain validation (signatures, dates, ...) is not
    affected, the denial of service can occur only when the application also
    specifies an expected DNS name, Email address or IP address.
    
    TLS servers rarely solicit client certificates, and even when they do, they
    generally don't perform a name check against a "reference identifier" (expected
    identity), but rather extract the presented identity after checking the
    certificate chain.  So TLS servers are generally not affected and the severity
    of the issue is Moderate.
    
    The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
    OpenSSL 1.1.1 and 1.0.2 are also not affected by this issue.
    
    OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.
    
    Signed-off-by: Michael Tremer <michael.tremer(a)ipfire.org>

-----------------------------------------------------------------------

Summary of changes:
 config/rootfiles/{oldcore/100 => core/188}/filelists/openssl | 0
 lfs/openssl                                                  | 4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 copy config/rootfiles/{oldcore/100 => core/188}/filelists/openssl (100%)

Difference in files:
diff --git a/config/rootfiles/core/188/filelists/openssl b/config/rootfiles/core/188/filelists/openssl
new file mode 120000
index 000000000..e011a9266
--- /dev/null
+++ b/config/rootfiles/core/188/filelists/openssl
@@ -0,0 +1 @@
+../../../common/openssl
\ No newline at end of file
diff --git a/lfs/openssl b/lfs/openssl
index d6333f7a4..22a670118 100644
--- a/lfs/openssl
+++ b/lfs/openssl
@@ -24,7 +24,7 @@
 
 include Config
 
-VER        = 3.3.1
+VER        = 3.3.2
 
 THISAPP    = openssl-$(VER)
 DL_FILE    = $(THISAPP).tar.gz
@@ -72,7 +72,7 @@ objects = $(DL_FILE)
 
 $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
 
-$(DL_FILE)_BLAKE2 = b09bbe94f49c33015fbcee5f578a20c0da33c289791bf33292170d5d3de44ea2e22144ee11067947aef2733e979c0fded875a4ec92d81468285837053447e68e
+$(DL_FILE)_BLAKE2 = cc53d45418673bc2a406d6697b8bd17ff6c726463c4ccc87bb2fa5a6592d0d178dc8cfeb2fbb980ea354a5dc2c86f31c48453427c6937896c7221273e623c9b5
 
 install : $(TARGET)
 


hooks/post-receive
--
IPFire 2.x development tree

                 reply	other threads:[~2024-09-03 18:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4Wytky3H0Sz2xSd@people01.haj.ipfire.org \
    --to=git@ipfire.org \
    --cc=ipfire-scm@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox