- 26 5月, 2023 1 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com> Change-Id: I5269be7d8e6c8ac399d86d9b48bfbd5cfabe0d19
-
- 12 4月, 2023 2 次提交
-
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
由 code4lala 提交于
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
-
- 10 8月, 2021 1 次提交
-
-
由 HJ 提交于
Signed-off-by: NHJ <huangjun42@huawei.com>
-
- 27 2月, 2020 1 次提交
-
-
由 h00416433 提交于
Description:openssl 1.1.1d used bu libhapverify Team:OTHERS Feature or Bugfix:Feature Binary Source:Yes, it is PrivateCode(Yes/No):No Change-Id: I8968f9c0f146b587da17a3e603bd04fb7b4c505b Reviewed-on: http://mgit-tm.rnd.huawei.com/7842784Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com> Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com> Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com> Reviewed-by: Nweiping 00548480 <ping.wei@huawei.com>
-
- 28 9月, 2019 2 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Apart from public and internal header files, there is a third type called local header files, which are located next to source files in the source directory. Currently, they have different suffixes like '*_lcl.h', '*_local.h', or '*_int.h' This commit changes the different suffixes to '*_local.h' uniformly. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
由 Dr. Matthias St. Pierre 提交于
Currently, there are two different directories which contain internal header files of libcrypto which are meant to be shared internally: While header files in 'include/internal' are intended to be shared between libcrypto and libssl, the files in 'crypto/include/internal' are intended to be shared inside libcrypto only. To make things complicated, the include search path is set up in such a way that the directive #include "internal/file.h" could refer to a file in either of these two directoroes. This makes it necessary in some cases to add a '_int.h' suffix to some files to resolve this ambiguity: #include "internal/file.h" # located in 'include/internal' #include "internal/file_int.h" # located in 'crypto/include/internal' This commit moves the private crypto headers from 'crypto/include/internal' to 'include/crypto' As a result, the include directives become unambiguous #include "internal/file.h" # located in 'include/internal' #include "crypto/file.h" # located in 'include/crypto' hence the superfluous '_int.h' suffixes can be stripped. The files 'store_int.h' and 'store.h' need to be treated specially; they are joined into a single file. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
- 17 4月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5990)
-
- 13 4月, 2018 2 次提交
-
-
由 Matt Caswell 提交于
Historically we used to implement standalone base64 code for SRP. This was replaced by commit 3d3f21aa with the standard base64 processing code. However, the SRP base64 code was designed to be compatible with other SRP libraries (notably libsrp, but also others) that use a variant of standard base64. Specifically a different alphabet is used and no padding '=' characters are used. Instead 0 padding is added to the front of the string. By changing to standard base64 we change the behaviour of the API which may impact interoperability. It also means that SRP verifier files created prior to 1.1.1 would not be readable in 1.1.1 and vice versa. Instead we expand our standard base64 processing with the capability to be able to read and generate the SRP base64 variant. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5925)
-
由 Matt Caswell 提交于
Previously they were using EVP_EncodeBlock/EVP_DecodeBlock. These are low level functions that do not handle padding characters. This was causing the SRP code to fail. One side effect of using EVP_EncodeUpdate is that it inserts newlines which is not what we need in SRP so we add a flag to avoid that. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5925)
-
- 18 10月, 2017 1 次提交
-
-
由 KaoruToda 提交于
Since return is inconsistent, I removed unnecessary parentheses and unified them. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4541)
-
- 09 10月, 2017 1 次提交
-
-
由 KaoruToda 提交于
unified them. - return (0); -> return 0; - return (1); -> return 1; - return (-1); -> return -1; Reviewed-by: NStephen Henson <steve@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4500)
-
- 25 7月, 2016 1 次提交
-
-
由 Jakub Zelenka 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1344)
-
- 28 6月, 2016 1 次提交
-
-
由 Emilia Kasper 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 16 6月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
Previously EVP_EncodeUpdate returned a void. However there are a couple of error conditions that can occur. Therefore the return type has been changed to an int, with 0 indicating error and 1 indicating success. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 18 5月, 2016 1 次提交
-
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 03 5月, 2016 2 次提交
-
-
由 Matt Caswell 提交于
With the EVP_EncodeUpdate function it is the caller's responsibility to determine how big the output buffer should be. The function writes the amount actually used to |*outl|. However this could go negative with a sufficiently large value for |inl|. We add a check for this error condition. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Matt Caswell 提交于
An overflow can occur in the EVP_EncodeUpdate function which is used for Base64 encoding of binary data. If an attacker is able to supply very large amounts of input data then a length check can overflow resulting in a heap corruption. Due to the very large amounts of data involved this will most likely result in a crash. Internally to OpenSSL the EVP_EncodeUpdate function is primarly used by the PEM_write_bio* family of functions. These are mainly used within the OpenSSL command line applications, so any application which processes data from an untrusted source and outputs it as a PEM file should be considered vulnerable to this issue. User applications that call these APIs directly with large amounts of untrusted data may also be vulnerable. Issue reported by Guido Vranken. CVE-2016-2105 Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 09 2月, 2016 1 次提交
-
-
由 Rich Salz 提交于
Don't cast malloc-family return values. Also found some places where (a) blank line was missing; and (b) the *wrong* return value was checked. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 27 1月, 2016 1 次提交
-
-
由 Rich Salz 提交于
This was done by the following find . -name '*.[ch]' | /tmp/pl where /tmp/pl is the following three-line script: print unless $. == 1 && m@/\* .*\.[ch] \*/@; close ARGV if eof; # Close file to reset $. And then some hand-editing of other files. Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
-
- 11 12月, 2015 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 19 9月, 2015 1 次提交
-
-
由 Viktor Dukhovni 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 18 9月, 2015 2 次提交
-
-
由 Emilia Kasper 提交于
Previously, the conversion would silently coerce to ASCII. Now, we error out. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Emilia Kasper 提交于
Rewrite EVP_DecodeUpdate. In particular: reject extra trailing padding, and padding in the middle of the content. Don't limit line length. Add tests. Previously, the behaviour was ill-defined, and depended on the position of the padding within the input. In addition, this appears to fix a possible two-byte oob read. Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NDr Stephen Henson <steve@openssl.org>
-
- 14 5月, 2015 1 次提交
-
-
由 Richard Levitte 提交于
There are header files in crypto/ that are used by a number of crypto/ submodules. Move those to crypto/include/internal and adapt the affected source code and Makefiles. The header files that got moved are: crypto/cryptolib.h crypto/md32_common.h Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 01 5月, 2015 1 次提交
-
-
由 Matt Caswell 提交于
There was already a sanity check to ensure the passed buffer length is not zero. Extend this to ensure that it also not negative. Thanks to Kevin Wojtysiak (Int3 Solutions) and Paramjot Oberoi (Int3 Solutions) for reporting this issue. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
- 24 1月, 2015 1 次提交
-
-
由 Rich Salz 提交于
This removes all code surrounded by '#ifdef undef' One case is left: memmove() replaced by open-coded for loop, in crypto/stack/stack.c That needs further review. Also removed a couple of instances of /* dead code */ if I saw them while doing the main removal. Reviewed-by: NMatt Caswell <matt@openssl.org>
-
- 22 1月, 2015 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org>
-
- 31 12月, 2014 1 次提交
-
-
由 Tim Hudson 提交于
indent will not alter them when reformatting comments Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org>
-
- 07 5月, 2014 1 次提交
-
-
由 Geoff Thorpe 提交于
This patch resolves RT ticket #2608. Thanks to Robert Dugal for originally spotting this, and to David Ramos for noticing that the ball had been dropped. Signed-off-by: NGeoff Thorpe <geoff@openssl.org>
-
- 06 9月, 2013 1 次提交
-
-
- 12 6月, 2010 1 次提交
-
-
由 Ben Laurie 提交于
-
- 12 11月, 2008 1 次提交
-
-
由 Geoff Thorpe 提交于
knock-on work than expected - they've been extracted into a patch series that can be completed elsewhere, or in a different branch, before merging back to HEAD.
-
- 02 11月, 2008 1 次提交
-
-
由 Ben Laurie 提交于
-
- 13 10月, 2007 1 次提交
-
-
由 Andy Polyakov 提交于
-
- 21 6月, 2005 1 次提交
-
-
由 Richard Levitte 提交于
of a 4-character block.
-
- 04 4月, 2005 1 次提交
-
-
由 Ben Laurie 提交于
-
- 16 3月, 2004 1 次提交
-
-
由 Richard Levitte 提交于
functions and macros. This change has associated tags: LEVITTE_before_const and LEVITTE_after_const. Those will be removed when this change has been properly reviewed.
-
- 30 10月, 2003 1 次提交
-
-
由 Geoff Thorpe 提交于
I have tried to convert 'len' type variable declarations to unsigned as a means to address these warnings when appropriate, but when in doubt I have used casts in the comparisons instead. The better solution (that would get us all lynched by API users) would be to go through and convert all the function prototypes and structure definitions to use unsigned variables except when signed is necessary. The proliferation of (signed) "int" for strictly non-negative uses is unfortunate.
-
- 13 11月, 2002 1 次提交
-
-
由 Ben Laurie 提交于
-