From 35140f335461c6d03d08247e29a93794e4f96f86 Mon Sep 17 00:00:00 2001 From: Richard Levitte Date: Fri, 11 Aug 2000 08:36:25 +0000 Subject: [PATCH] Abdelilah Essiari reports that for very small records, EVP_EncodeUpdate() may misbehave. This happens when there's a record boundary between the two ending b64 equal signs, which makes EVP_EncodeUpdate think there has been more than one EOF, and therefore add an extra NUL at the end of the output buffer. This fix corrects that problem. --- crypto/evp/encode.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/crypto/evp/encode.c b/crypto/evp/encode.c index 14a4cb11f6..6ff9c1783c 100644 --- a/crypto/evp/encode.c +++ b/crypto/evp/encode.c @@ -292,7 +292,17 @@ int EVP_DecodeUpdate(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl, /* If we are at the end of input and it looks like a * line, process it. */ if (((i+1) == inl) && (((n&3) == 0) || eof)) + { v=B64_EOF; + /* In case things were given us in really small + records (so two '=' were given in separate + updates), eof may contain the incorrect number + of ending bytes to skip, so let's redo the count */ + eof = 0; + if (d[n-1] == '=') eof++; + if (d[n-2] == '=') eof++; + /* There will never be more than two '=' */ + } if ((v == B64_EOF) || (n >= 64)) {