- 27 5月, 2023 4 次提交
-
-
由 CheungVane 提交于
Signed-off-by: Nzhangwenzhi <zhangwenzhi3@huawei.com>
-
由 openharmony_ci 提交于
Merge pull request !112 from openharmony_ci/revert-merge-109-master
-
由 openharmony_ci 提交于
-
由 openharmony_ci 提交于
Merge pull request !109 from CheungVane/master
-
- 26 5月, 2023 9 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !110 from code4lala/master
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 CheungVane 提交于
Signed-off-by: Nzhangwenzhi <zhangwenzhi3@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I17f9c6be01e95129a522f2383fbfd10e84f564c4
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I877ef2192fa46fffcfc4326cd85d716c191139f9
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I5269be7d8e6c8ac399d86d9b48bfbd5cfabe0d19
-
由 CheungVane 提交于
Signed-off-by: Nzhangwenzhi <zhangwenzhi3@huawei.com>
-
由 CheungVane 提交于
Signed-off-by: Nzhangwenzhi <zhangwenzhi3@huawei.com>
-
- 25 5月, 2023 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !108 from code4lala/master
-
- 23 5月, 2023 1 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
- 18 5月, 2023 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !106 from code4lala/master
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I96e829f4af516c340556f51c3c531710267e3551
-
- 17 5月, 2023 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !105 from code4lala/make_build_all_generated
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: Ib34b9b5d1bfa9edf4a312988ff9a5c9e1732cde8
-
- 16 5月, 2023 1 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: If0feac1105ed773eb9c56463c4a4281a3437040e
-
- 05 5月, 2023 3 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !104 from code4lala/M1
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I19ba093109979031f24a6beb82f70e1f8cc00142
-
- 04 5月, 2023 3 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !103 from code4lala/darwin
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: Ice9cf979dcd8026815a65158de64c899ab884e12
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: Idb402192f30605ab52dea1a56f1574971ab2f2a8
-
- 28 4月, 2023 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !77 from code4lala/master
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
- 27 4月, 2023 1 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I1be72a32ac34ab145541069582d3e7299a54000b
-
- 26 4月, 2023 11 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I488711240cdb6fcac66e5660a5695513ac47a816
-
由 Tomas Mraz 提交于
The function was incorrectly documented as enabling policy checking. Fixes: CVE-2023-0466 Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NPaul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20563) Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I515b0c03074af5cf5a6f5e72bcec4a2d6642707a
-
由 Pauli 提交于
This reverts commit 9aa4be691f5c73eb3c68606d824c104550c053f7 and removed the redundant flag setting. Fixes #19643 Fixes LOW CVE-2022-3996 Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: NTomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19652) (cherry picked from commit 4d0340a6d2f327700a059f0b8f954d6160f8eef5) Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I1013e00e8fe7c7975cf8e6dd4db380f37179660d
-
由 Pauli 提交于
A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Fixes CVE-2023-0464 Reviewed-by: NTomas Mraz <tomas@openssl.org> Reviewed-by: NShane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/20568) Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: Ia84b5d25d543af1e61661fced02acd92b22afe5a
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 Dmitry Belyavskiy 提交于
A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. Patch written by Dmitry Belyavsky and Hubert Kario CVE-2022-4304 Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NTomas Mraz <tomas@openssl.org> Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: Ib81f15484fa3374bf5f50baece50bb36d105d6d7
-
由 slontis 提交于
Fixes CVE-2023-0217 When attempting to do a BN_Copy of params->p there was no NULL check. Since BN_copy does not check for NULL this is a NULL reference. As an aside BN_cmp() does do a NULL check, so there are other checks that fail because a NULL is passed. A more general check for NULL params has been added for both FFC public and private key validation instead. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NPaul Dale <pauli@openssl.org> Reviewed-by: NTomas Mraz <tomas@openssl.org> Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I7086365d9f51b6f36fcfb79a45d36f8d032e1f22
-
由 Tomas Mraz 提交于
Original author: Nevine Ebeid (Amazon) Fixes: CVE-2023-1255 The buffer overread happens on decrypts of 4 mod 5 sizes. Unless the memory just after the buffer is unmapped this is harmless. Reviewed-by: NPaul Dale <pauli@openssl.org> Reviewed-by: NTom Cosgrove <tom.cosgrove@arm.com> (Merged from https://github.com/openssl/openssl/pull/20759) (cherry picked from commit 72dfe46550ee1f1bbfacd49f071419365bc23304) Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I636543b8cf34e1edaeee4d1c0d5617eb500a24a6
-