Update to 0.6.2.2 for fix CVE-2023-37464

allow-compilation-against-OpenSSL-3.patch

@@ -1,54 +0,0 @@
-From c345a1ae4d41856ee5aa7a93f1cbad838649632c Mon Sep 17 00:00:00 2001
-From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
-Date: Tue, 5 Apr 2022 16:16:14 +0200
-Subject: [PATCH] allow compilation against OpenSSL 3
-
-using "#define OPENSSL_API_COMPAT 0x10000000L"
-closes https://github.com/zmartzone/cjose/pull/13
-
-Signed-off-by: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
----
- src/jwe.c    | 2 ++
- src/jwk.c    | 2 ++
- src/jws.c    | 2 ++
- 4 files changed, 7 insertions(+)
-
-diff --git a/src/jwe.c b/src/jwe.c
-index b20c2c7..4285097 100644
---- a/src/jwe.c
-+++ b/src/jwe.c
-@@ -5,6 +5,8 @@
-  * Copyright (c) 2014-2016 Cisco Systems, Inc.  All Rights Reserved.
-  */
- 
-+#define OPENSSL_API_COMPAT 0x10000000L
-+
- #include <cjose/base64.h>
- #include <cjose/header.h>
- #include <cjose/jwe.h>
-diff --git a/src/jwk.c b/src/jwk.c
-index 860f0e7..2e4b241 100644
---- a/src/jwk.c
-+++ b/src/jwk.c
-@@ -5,6 +5,8 @@
-  * Copyright (c) 2014-2016 Cisco Systems, Inc.  All Rights Reserved.
-  */
- 
-+#define OPENSSL_API_COMPAT 0x10000000L
-+
- #include "include/jwk_int.h"
- #include "include/util_int.h"
- 
-diff --git a/src/jws.c b/src/jws.c
-index 47fb880..d73debb 100644
---- a/src/jws.c
-+++ b/src/jws.c
-@@ -5,6 +5,8 @@
-  * Copyright (c) 2014-2016 Cisco Systems, Inc.  All Rights Reserved.
-  */
- 
-+#define OPENSSL_API_COMPAT 0x10000000L
-+
- #include <cjose/base64.h>
- #include <cjose/header.h>
- #include <cjose/jws.h>

cjose.spec

@@ -1,12 +1,10 @@
 Name:                cjose
-Version:             0.6.1
-Release:             4
+Version:             0.6.2.2
+Release:             1
 Summary:             C library implementing the Javascript Object Signing and Encryption (JOSE)
 License:             MIT
-URL:                 https://github.com/cisco/cjose
-Source0:             https://github.com/cisco/%{name}/archive/%{version}/%{name}-%{version}.tar.gz
-Patch1:              concatkdf.patch
-Patch2:              allow-compilation-against-OpenSSL-3.patch
+URL:                 https://github.com/OpenIDC/cjose
+Source0:             https://github.com/OpenIDC/cjose/releases/download/v%{version}/%{name}-%{version}.tar.gz
 BuildRequires:       gcc doxygen libtcnative-1-0 jansson-devel check-devel openssl-devel
 %description
 Implementation of JOSE for C/C++
@@ -49,6 +47,9 @@ make check || (cat test/test-suite.log; exit 1)
 %{_libdir}/pkgconfig/cjose.pc
 
 %changelog
+* Mon Jul 24 2023 yaoxin <yao_xin001@hoperun.com> - 0.6.2.2-1
+- Update to 0.6.2.2 for fix CVE-2023-37464
+
 * Fri Feb 03 2023 xu_ping <xuping33@h-partners.com> - 0.6.1-4
 - Fix build failure due to openssl upgrade 3.0
 

concatkdf.patch

@@ -1,74 +0,0 @@
-commit 0238eb8f3612515f4374381b593dd79116169330
-Author: John Dennis <jdennis@redhat.com>
-Date:   Thu Aug 2 16:21:33 2018 -0400
-
-    fix concatkdf failures on big endian architectures
-    
-    Several of the elements used to compute the digest in ECDH-ES key
-    agreement computation are represented in binary form as a 32-bit
-    integer length followed by that number of octets.  the length
-    field. The 32-bit length integer is represented in big endian
-    format (the 8 most significant bits are in the first octet.).
-    
-    The conversion to a 4 byte big endian integer was being computed
-    in a manner that only worked on little endian architectures. The
-    function htonl() returns a 32-bit integer whose octet sequence given
-    the address of the integer is big endian. There is no need for any
-    further manipulation.
-    
-    The existing code used bit shifting on a 32-bit value. In C bit
-    shifting is endian agnostic for multi-octet values, a right shift
-    moves most significant bits toward least significant bits. The result
-    of a bit shift of a multi-octet value on either big or little
-    archictures will always be the same provided you "view" it as the same
-    data type (e.g. 32-bit integer). But indexing the octets of that
-    mulit-octet value will be different depending on endianness, hence the
-    assembled octets differed depending on endianness.
-    
-    Issue: #77
-    Signed-off-by: John Dennis <jdennis@redhat.com>
-
-diff --git a/src/concatkdf.c b/src/concatkdf.c
-index ec064ab..59b845a 100644
---- a/src/concatkdf.c
-+++ b/src/concatkdf.c
-@@ -29,15 +29,9 @@
- ////////////////////////////////////////////////////////////////////////////////
- static uint8_t *_apply_uint32(const uint32_t value, uint8_t *buffer)
- {
--    const uint32_t formatted = htonl(value);
--    const uint8_t data[4] = {
--        (formatted >> 0) & 0xff,
--        (formatted >> 8) & 0xff,
--        (formatted >> 16) & 0xff,
--        (formatted >> 24) & 0xff
--    };
--    memcpy(buffer, data, 4);
-+    const uint32_t big_endian_int32 = htonl(value);
- 
-+    memcpy(buffer, &big_endian_int32, 4);
-     return buffer + 4;
- }
- 
-diff --git a/test/check_concatkdf.c b/test/check_concatkdf.c
-index e4325fc..41d0f1c 100644
---- a/test/check_concatkdf.c
-+++ b/test/check_concatkdf.c
-@@ -60,14 +60,9 @@ _create_otherinfo_header_finish:
- 
- static bool _cmp_uint32(uint8_t **actual, uint32_t expected)
- {
--    uint32_t value = htonl(expected);
--    uint8_t expectedData[] = {
--        (value >> 0) & 0xff,
--        (value >> 8) & 0xff,
--        (value >> 16) & 0xff,
--        (value >> 24) & 0xff
--    };
--    bool result = (0 == memcmp(*actual, expectedData, 4));
-+    uint32_t big_endian_int32 = htonl(expected);
-+
-+    bool result = (0 == memcmp(*actual, &big_endian_int32, 4));
-     (*actual) += 4;
-     return result;
- }