Re: [openssl.org #3451] patch for x509.c
On Út, 2014-07-15 at 20:08 +0200, Jan Just Keijser via RT wrote: On 15/07/14 15:20, Daniel Kahn Gillmor wrote: On 07/15/2014 07:58 AM, Salz, Rich via RT wrote: The Globus syntax is strange. :) We should support the ISO date/time standard, and use that throughout and not invent yet another syntax, or yet another flag. It's fairly simple to parse, and handles timezones, relative times, date/time mixing, and so on. The XML XSD spec, for example, has a reasonable explanation. Agreed here. also, the presence of a hyphen in a time marker is too easily misunderstood as a minus sign. If we're talking about the duration of a certificate, we could use something like the ISO-8601 duration syntax: https://en.wikipedia.org/wiki/ISO-8601#Durations e.g. PT1800S is 1800 seconds I like the idea, but I won't have time to rewrite the patch right now. Implementing full ISO8061 timestamps will take some effort. I'd also propose to rename '-valid' to '-duration' . I'll get back on this in mid August. What about just supporting float number argument for -days (0.5 for 12 hours certificate validity)? That should be fairly simple. In the first step. And add something like -notafter argument that would specify the exact end datetime in the ISO format (not duration) as a second step. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3457] AutoReply: Possible Bugs in EVP_KeyToBytes?
Please cancel the first issue of not adding previous hash when
looping. I mis-read it (twice!).
I believe the return value issue is still valid.
On Tue, Jul 15, 2014 at 1:31 PM, The default queue via RT
r...@openssl.org wrote:
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
Possible Bugs in EVP_KeyToBytes?,
a summary of which appears below.
There is no need to reply to this message right now. Your ticket has been
assigned an ID of [openssl.org #3457].
Please include the string:
[openssl.org #3457]
in the subject line of all future correspondence about this issue. To do so,
you may reply to this message.
Thank you,
r...@openssl.org
-
Below is from crypto/evp/evp_key.c.
Notice that `addmd` is never set to 1. *If* the routine needs to loop
back to the top to finish fulfilling a derivation request, then the
previous hash is *not* added back into the computation. That is, this
is never executed:
if (addmd++)
if (!EVP_DigestUpdate(c,(md_buf[0]),mds))
I believe that means the same bit pattern repeats. If MD5 is the
underlying hash (which appears to be used fairly regularly), then the
bits repeat after 16 bytes.
Also, the early out from `if (data == NULL) return(nkey);` should
probably return something other than a successful result. Since
nothing was derived, the function should return 0; and not nkey.
*
int EVP_BytesToKey(const EVP_CIPHER *type, const EVP_MD *md,
const unsigned char *salt, const unsigned char
*data, int datal,
int count, unsigned char *key, unsigned char *iv)
{
EVP_MD_CTX c;
unsigned char md_buf[EVP_MAX_MD_SIZE];
int niv,nkey,addmd=0;
unsigned int mds=0,i;
int rv = 0;
nkey=type-key_len;
niv=type-iv_len;
OPENSSL_assert(nkey = EVP_MAX_KEY_LENGTH);
OPENSSL_assert(niv = EVP_MAX_IV_LENGTH);
if (data == NULL) return(nkey);
EVP_MD_CTX_init(c);
for (;;)
{
if (!EVP_DigestInit_ex(c,md, NULL))
return 0;
if (addmd++)
if (!EVP_DigestUpdate(c,(md_buf[0]),mds))
goto err;
if (!EVP_DigestUpdate(c,data,datal))
goto err;
if (salt != NULL)
if (!EVP_DigestUpdate(c,salt,PKCS5_SALT_LEN))
goto err;
if (!EVP_DigestFinal_ex(c,(md_buf[0]),mds))
goto err;
for (i=1; i(unsigned int)count; i++)
{
if (!EVP_DigestInit_ex(c,md, NULL))
goto err;
if (!EVP_DigestUpdate(c,(md_buf[0]),mds))
goto err;
if (!EVP_DigestFinal_ex(c,(md_buf[0]),mds))
goto err;
}
i=0;
if (nkey)
{
for (;;)
{
if (nkey == 0) break;
if (i == mds) break;
if (key != NULL)
*(key++)=md_buf[i];
nkey--;
i++;
}
}
if (niv (i != mds))
{
for (;;)
{
if (niv == 0) break;
if (i == mds) break;
if (iv != NULL)
*(iv++)=md_buf[i];
niv--;
i++;
}
}
if ((nkey == 0) (niv == 0)) break;
}
rv = type-key_len;
err:
EVP_MD_CTX_cleanup(c);
OPENSSL_cleanse((md_buf[0]),EVP_MAX_MD_SIZE);
return rv;
}
*
$ git pull
...
$ git log
commit 199772e53427ca921c289471c1344d454781fcc0
...
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3458] PATCH: ensure debug builds with GCC include -g3 -ggdb
PATCH: ensure generic debug builds with GCC include `-g3 -ggdb`.
Developer configurations, such as `debug-ben-*`, were not modified.
Unfamiliar platforms, such as HP-UX, were not modified.
`-g3` provides the highest level of debug information, including
symbolic names for constants.
`-ggdb` adds GDB extensions. According to Jan Kratochvil, `-ggdb`
currently has no effect
(http://www.sourceware.org/ml/gdb/2011-08/msg00109.html). That might
change in the future, so I usually include it. It was also present in
some of the other debug configurations.
Optimization were *not* modified for debug builds.
**
Here's an example from `git diff`:
-debug-darwin-i386-cc,cc:-arch i386 -g3
-DL_ENDIAN::-D_REENTRANT:MACOSX:-Wl,-search_paths_first%:BN_LLONG
RC4_INT RC4_CHUNK DES_UNROLL
BF_PTR:${x86_asm}:macosx:dlfcn:darwin-shared:-fPIC -fno-common:-arch
i386 -dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib,
-debug-darwin64-x86_64-cc,cc:-arch x86_64 -ggdb -g2 -O0 -DL_ENDIAN
-Wall::-D_REENTRANT:MACOSX:-Wl,-search_paths_first%:SIXTY_FOUR_BIT_LONG
RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:macosx:dlfcn:darwin-shared:-fPIC
-fno-common:-arch x86_64
-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib,
+debug-darwin-i386-cc,cc:-arch i386 -g3 -ggdb
-DL_ENDIAN::-D_REENTRANT:MACOSX:-Wl,-search_paths_first%:BN_LLONG
RC4_INT RC4_CHUNK DES_UNROLL
BF_PTR:${x86_asm}:macosx:dlfcn:darwin-shared:-fPIC -fno-common:-arch
i386 -dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib,
+debug-darwin64-x86_64-cc,cc:-arch x86_64 -ggdb -g3 -O0 -DL_ENDIAN
-Wall::-D_REENTRANT:MACOSX:-Wl,-search_paths_first%:SIXTY_FOUR_BIT_LONG
RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:macosx:dlfcn:darwin-shared:-fPIC
-fno-common:-arch x86_64
-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib,
diff --git a/Configure b/Configure
index 429eaed..451b8ba 100755
--- a/Configure
+++ b/Configure
@@ -192,14 +192,14 @@ my %table=(
debug-levitte-linux-noasm-extreme,gcc:-DLEVITTE_DEBUG -DREF_CHECK
-DCONF_DEBUG -DBN_DEBUG -DBN_DEBUG_RAND -DCRYPTO_MDEBUG -DENGINE_CONF_DEBUG
-DOPENSSL_NO_ASM -DL_ENDIAN -DTERMIO -DPEDANTIC -ggdb -g3 -pedantic -ansi -Wall
-W -Wundef -Wshadow -Wcast-align -Wstrict-prototypes -Wmissing-prototypes
-Wno-long-long -Wundef -Wconversion -pipe::-D_REENTRANT::-ldl:BN_LLONG
${x86_gcc_des}
${x86_gcc_opts}:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
debug-geoff32,gcc:-DBN_DEBUG -DBN_DEBUG_RAND -DBN_STRICT -DPURIFY
-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_ASM -DOPENSSL_NO_INLINE_ASM -DL_ENDIAN
-DTERMIO -DPEDANTIC -O1 -ggdb2 -Wall -Werror -Wundef -pedantic -Wshadow
-Wpointer-arith -Wbad-function-cast -Wcast-align -Wsign-compare
-Wmissing-prototypes -Wmissing-declarations
-Wno-long-long::-D_REENTRANT::-ldl:BN_LLONG:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
debug-geoff64,gcc:-DBN_DEBUG -DBN_DEBUG_RAND -DBN_STRICT -DPURIFY
-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_ASM -DOPENSSL_NO_INLINE_ASM -DL_ENDIAN
-DTERMIO -DPEDANTIC -O1 -ggdb2 -Wall -Werror -Wundef -pedantic -Wshadow
-Wpointer-arith -Wbad-function-cast -Wcast-align -Wsign-compare
-Wmissing-prototypes -Wmissing-declarations
-Wno-long-long::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
DES_INT DES_UNROLL
BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
-debug-linux-pentium,gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG
-DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -mcpu=pentium
-Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn,
-debug-linux-ppro,gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG
-DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -mcpu=pentiumpro
-Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn,
-debug-linux-elf,gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG
-DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -march=i486
-Wall::-D_REENTRANT::-lefence -ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
-debug-linux-elf-noefence,gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG
-DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -march=i486
-Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+debug-linux-pentium,gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG
-DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -ggdb -g3 -mcpu=pentium
-Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn,
+debug-linux-ppro,gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG
-DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -ggdb -g3 -mcpu=pentiumpro
-Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn,
+debug-linux-elf,gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG
-DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g3 -ggdb -march=i486
-Wall::-D_REENTRANT::-lefence -ldl:BN_LLONG ${x86_gcc_des}
EC_METHOD struct
Hello In the EC_METHOD structure, the pointers to methods for converting between affine and projective coordinates are named: `point_set_Jprojective_coordinates_GFp` and `point_get_Jprojective_coordinates_GFp` Does that mean any implementation of EC_METHOD (for prime curves) can only use Jacobian coordinates? Is it not possible to use some other coordinate system (may be homogeneous)? -- :-)balaji __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EC_METHOD struct
balaji marisetti balajimarise...@gmail.com: In the EC_METHOD structure, the pointers to methods for converting between affine and projective coordinates are named: `point_set_Jprojective_coordinates_GFp` and `point_get_Jprojective_coordinates_GFp` Does that mean any implementation of EC_METHOD (for prime curves) can only use Jacobian coordinates? Is it not possible to use some other coordinate system (may be homogeneous)? This method name just means that the EC_METHOD implementation should support setting points based on Jacobian coordinates. Internally, it might convert them to something else. (Or, the EC_METHOD could entirely omit support for this method. Typical usage of the ECC library won't depend on this.) Bodo
Re: EC_METHOD struct
Wouldn't it have been simpler to name these function pointers just projective instead of Jprojective? This way, EC methods that use different projective system than jacobian could have their own implementation to set/get projective co-ordinates and use these function pointers without confusion. Another reason for this is, new EC methods that get implemented would take existing simple EC method as reference and steal as much code (as many functions) as possible from it. In simple EC method, set_affine_coordinates would internally call set_projective_coordinates with Z as 1. One cannot stick to this code, and leave set_projective function unset at the same time. Here, change is necessary to call the internal function instead of the function pointer that sets x, y, 1 to X, Y, Z. On Wed, Jul 16, 2014 at 4:48 PM, Bodo Moeller bmoel...@acm.org wrote: balaji marisetti balajimarise...@gmail.com: In the EC_METHOD structure, the pointers to methods for converting between affine and projective coordinates are named: `point_set_Jprojective_coordinates_GFp` and `point_get_Jprojective_coordinates_GFp` Does that mean any implementation of EC_METHOD (for prime curves) can only use Jacobian coordinates? Is it not possible to use some other coordinate system (may be homogeneous)? This method name just means that the EC_METHOD implementation should support setting points based on Jacobian coordinates. Internally, it might convert them to something else. (Or, the EC_METHOD could entirely omit support for this method. Typical usage of the ECC library won't depend on this.) Bodo
Re: [openssl.org #3451] patch for x509.c
On 07/16/2014 03:39 AM, Tomas Mraz via RT wrote: What about just supporting float number argument for -days (0.5 for 12 hours certificate validity)? That should be fairly simple. In the first step. And add something like -notafter argument that would specify the exact end datetime in the ISO format (not duration) as a second step. This also seems like a reasonable proposal to me. --dkg signature.asc Description: PGP signature
RE: [openssl.org #3451] patch for x509.c
But then it has to be supported for, like ever. :) If the right thing to do is the ISO format, and I strongly believe it is, then we should just work toward that and not add variants to solve a short-term need that will require long-term care and confusion. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��jם.+-1�ځ��j:+v���h�
RE: argv/Argv hacks in openssl.c
Would it work to *always* copy argv on VMS? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EC_METHOD struct
Thulasi Goriparthi thulasi.goripar...@gmail.com: Wouldn't it have been simpler to name these function pointers just projective instead of Jprojective? This way, EC methods that use different projective system than jacobian could have their own implementation to set/get projective co-ordinates and use these function pointers without confusion. Well, I don't necessarily agree with the without confusion part ... The behavior that you get with these methods would then depend on the internals of that implementation, which isn't necessarily what users might expect from the library. If someone uses (the hypothetical) EC_POINT_set_projective_coordinates_GFp with Jacobian coordinates but these are interpreted as something else, that could be a problem. Another reason for this is, new EC methods that get implemented would take existing simple EC method as reference and steal as much code (as many functions) as possible from it. In simple EC method, set_affine_coordinates would internally call set_projective_coordinates with Z as 1. One cannot stick to this code, and leave set_projective function unset at the same time. Here, change is necessary to call the internal function instead of the function pointer that sets x, y, 1 to X, Y, Z. I know -- if you don't implement point_set_Jprojective_coordinates_GFp, you'll have to provide your own point_set_affine_coordinates_GFp (etc.). That should be straightforward in any case, though. You'll necessarily have to implement point_get_affine_coordinates_GFp, which will be more involved. I think at least for the get functions, it should be pretty clear why I prefer to have an explicit Jprojective in the function numbers, rather than merely projective: if ec_GFp_simple_point_get_affine_coordinates were to use a generically named EC_POINT_get_projective_coordinates_GFp instead of the actual EC_POINT_get_Jprojective_coordinates_GFp, you'd have to pay more attention to notice that it's not actually appropriate for the coordinates that your implementation is using. Bodo
Re: argv/Argv hacks in openssl.c
From: Salz, Rich rs...@akamai.com Would it work to *always* copy argv on VMS? Sure. It would also work always to copy argv[] _everywhere_. The comments explain where/when it's necessary. It made more sense to me to do the extra work where/when it's needed, rather than impose the (small?) performance penalty where/when it's not needed, but what do I know? Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3451] patch for x509.c
On 07/16/2014 09:40 AM, Salz, Rich wrote: But then it has to be supported for, like ever. :) do you realistically think we'll ever drop support for the -days argument though? Dropping -days would break a million scripts. Extending it to support a non-integer number of days seems like a straightforward win. While we're at it, we could extend the -days argument to accept the ISO-8601 duration format, distinguishing it by whether the first character is a 'P' or not -- i don't know whether that itself is too many variants to handle. If the right thing to do is the ISO format, and I strongly believe it is, then we should just work toward that and not add variants to solve a short-term need that will require long-term care and confusion. Tomas' proposal was to use the ISO-8601 date format (which is much better known than ISO-8601 duration) for a new -notafter argument that would allow people to specify concrete end times in a standard and well-understood fashion. I think this is in line with the goals you describe here, no? --dkg signature.asc Description: PGP signature
RE: argv/Argv hacks in openssl.c
The amount of time it took me to read the comment and figure out what is going
on, and your time to write email explaining it, and Ted's time to chime in
about the necessity of doing all this far outweighs the new code which is
#ifdef VMS'd Because now main() looks really simple and bog-standard with
argc,argv. The maintenance cost for *everyone* is reduced, at the expense of a
few extra bytes on some platforms.
The only reason why I'm making a big deal of this (well any deal at all) is
that I think this an important trend for OpenSSL moving forward. We try to
support as many platforms as we can, but this has a cost in making the code
more complex and a sometimes-gnarly set of #ifdef's. That imposes a burden on
everyone who has to read and maintain the code. If instead we can make things
slightly less optimal in some cases while simplifying things, that's the kind
of trade-off we want to make. At the risk of being small-minded, I'll point
out there's a big difference between suboptimal and broken :)
(http://arstechnica.com/security/2014/07/only-a-few-days-old-openssl-fork-libressl-is-declared-unsafe-for-linux/
)
char ** copy_argv(int *argc, char **argv) {
int i;
char **newargv = (char **)OPENSSL_malloc((*argc+1) * sizeof *newargv);
for (i = 0; argv[i]; i++)
newargv[i] = argv[i];
newargv[i] = NULL;
*argc = i;
return newargv;
}
--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rs...@jabber.me; Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3451] patch for x509.c
- Original Message - From: Rich Salz rs...@akamai.com To: openssl-dev@openssl.org, janj...@nikhef.nl Sent: Wednesday, 16 July, 2014 3:40:03 PM Subject: RE: [openssl.org #3451] patch for x509.c But then it has to be supported for, like ever. :) If the right thing to do is the ISO format, and I strongly believe it is, then we should just work toward that and not add variants to solve a short-term need that will require long-term care and confusion. The third alternative is just add -startdate and -enddate from ca util and direct people to the `date` application if they want relative dates, e.g.: date '+%Y%m%d%H%M%SZ' -d '2 hours ago' date '+%Y%m%d%H%M%SZ' -d '1 month 12 hours' Not applicable to all platforms, but (I'd guess) easiest to implement and providing most freedom. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3451] patch for x509.c
do you realistically think we'll ever drop support for the -days argument though? Dropping -days would break a million scripts. No, we'll never drop support for -days. But whether the code is atoi() or atof() is a big difference and might cause important silent failures for new scripts running on anything other than the most recent openssl. On most systems atoi(0.5) returns 0 and no error indicator so -days 0.5 would silently do the wrong thing on anything other than openssl 1.0.whatever Which seems much worse. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��jם.+-1�ځ��j:+v���h�
RE: [openssl.org #3451] patch for x509.c
date '+%Y%m%d%H%M%SZ' -d '1 month 12 hours' Wow. Old code never dies; that's my get_date code from August 1990 :) /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3451] patch for x509.c
On 07/16/2014 11:24 AM, Salz, Rich wrote: do you realistically think we'll ever drop support for the -days argument though? Dropping -days would break a million scripts. No, we'll never drop support for -days. But whether the code is atoi() or atof() is a big difference and might cause important silent failures for new scripts running on anything other than the most recent openssl. On most systems atoi(0.5) returns 0 and no error indicator so -days 0.5 would silently do the wrong thing on anything other than openssl 1.0.whatever Which seems much worse. ugh, you're quite right. Sorry, i wasn't thinking about the support hassle in that direction. And to make matters worse, openssl req -x509 currently interprets -days 0 or -days 0.5 or -days PT1800S as use the default number of days, which is 30. :/ From experimentation, i just discovered that -days is also happy to accept and interpret negative integer arguments as well, resulting in a key with ValidNotBefore later than ValidNotAfter :( not even an error message to let you know that you've just created a certificate that no validation stack in its right mind should ever accept. I withdraw my support for making -days take a fractional argument, given the behavior of the existing deployed base. --dkg signature.asc Description: PGP signature
Re: [openssl.org #3451] patch for x509.c
On St, 2014-07-16 at 17:46 +0200, Daniel Kahn Gillmor via RT wrote: On 07/16/2014 11:24 AM, Salz, Rich wrote: do you realistically think we'll ever drop support for the -days argument though? Dropping -days would break a million scripts. No, we'll never drop support for -days. But whether the code is atoi() or atof() is a big difference and might cause important silent failures for new scripts running on anything other than the most recent openssl. On most systems atoi(0.5) returns 0 and no error indicator so -days 0.5 would silently do the wrong thing on anything other than openssl 1.0.whatever Which seems much worse. ugh, you're quite right. Sorry, i wasn't thinking about the support hassle in that direction. And to make matters worse, openssl req -x509 currently interprets -days 0 or -days 0.5 or -days PT1800S as use the default number of days, which is 30. :/ From experimentation, i just discovered that -days is also happy to accept and interpret negative integer arguments as well, resulting in a key with ValidNotBefore later than ValidNotAfter :( not even an error message to let you know that you've just created a certificate that no validation stack in its right mind should ever accept. I withdraw my support for making -days take a fractional argument, given the behavior of the existing deployed base. I agree with that as well. I did not look at the actual code in openssl so I did not know that the fractional argument with the current version does not error out. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Sync Configure with config on -Wa,--noexecstack
Is it necessaryto sync Configure with config on -Wa,--noexecstack?
+diff --git a/Configure b/Configure
+index 3232cfe..df84922 100644
+===
+--- a/Configure
b/Configure
+@@ -1256,6 +1256,30 @@ $libdir=lib$multilib if $libdir eq ;
+
+ $cflags = $cflags$exp_cflags;
+
++if ($no_asm)
++{
++}
++else
++{
++my $retvalue;
++if ($cross_compile_prefix)
++{
++$retvalue =system($cross_compile_prefix -Wa,--help -c -o /tmp/null.o
-x assembler /dev/null | grep noexecstack /dev/null );
++}
++else
++{
++$retvalue =system($cc -Wa,--help -c -o /tmp/null.o -x assembler
/dev/null | grep noexecstack /dev/null );
++}
++if ($retvalue)
++{
++#noting to add
++}
++else
++{
++$cflags = -Wa,--noexecstack $cflags;
++}
++}
[openssl.org #3459] HeartBleed for HP SMH on Windows 2003
We are facing Heartbleed vulnerability on Win 2003 servers. We have upgraded the HP SMH version 7.2.3 . Removed Certs and reimported the new cert but the vulnerability still exist for OPENSSL . Kindly suggest what steps should we take to remediate this vulnerability. Regards, Abhishek The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3459] HeartBleed for HP SMH on Windows 2003
I don't know what HP SMH is. But that doesn't matter. If you download and compile openssl yourselves, then make sure you are using the latest version. Or add the -DOPENSSL_NO_HEARTBEATS flag to your compiler flags (such as in util/pl/VC-vars32) There is nothing for openssl project to do here. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3459] HeartBleed for HP SMH on Windows 2003
It is HP systems management home page.i am infrastructure guy and not sure what to do though i upgraded smh as recommended by HP. Sent from my Windows Phone From: Rich Salz via RTmailto:r...@openssl.org Sent: 17-07-2014 01:42 To: Pandey, Abhishekmailto:abhishek.pan...@ironmountain.com Cc: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Subject: [openssl.org #3459] HeartBleed for HP SMH on Windows 2003 I don't know what HP SMH is. But that doesn't matter. If you download and compile openssl yourselves, then make sure you are using the latest version. Or add the -DOPENSSL_NO_HEARTBEATS flag to your compiler flags (such as in util/pl/VC-vars32) There is nothing for openssl project to do here. The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command
Fixed (with dkg's suggested wording change): https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=2097a17c576f2395a10b05f14490688bc5f45a07 Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3451] patch for x509.c
On Wed, Jul 16, 2014 at 05:46:42PM +0200, Daniel Kahn Gillmor via RT wrote: From experimentation, i just discovered that -days is also happy to accept and interpret negative integer arguments as well, resulting in a key with ValidNotBefore later than ValidNotAfter That's a useful feature, at least for testing, certificate verification engines, you get what you ask for. Tools that prevent you from asking for the wrong thing without recourse are worse. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
openssl apps; flags, parsing dates, etc.
I agree with that as well. I did not look at the actual code in openssl so I did not know that the fractional argument with the current version does not error out. I have a branch that adds pretty comprehensive option-checking to all the openssl commands: ; ./openssl x509 --CA /no/such/file x509: Cannot open input file /no/such/file, No such file or directory x509: Use -help for summary. ; ./openssl x509 -days 1.2 x509: Invalid number 1.2 for -days x509: Use -help for summary. ; ./openssl rsa -out /vmlinuz rsa: Cannot open output file /vmlinuz, Permission denied rsa: Use -help for summary. I know I broke some things; please try things out. The branch is here: https://github.com/akamai/openssl/tree/rsalz-monolith This is NOT planned for 1.0.2, but hopefully the very next one after that. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: openssl apps; flags, parsing dates, etc.
On Wed, Jul 16, 2014 at 10:56:03PM -0400, Salz, Rich wrote: I have a branch that adds pretty comprehensive option-checking to all the openssl commands: ; ./openssl x509 --CA /no/such/file x509: Cannot open input file /no/such/file, No such file or directory x509: Use -help for summary. ; ./openssl x509 -days 1.2 x509: Invalid number 1.2 for -days x509: Use -help for summary. ; ./openssl rsa -out /vmlinuz rsa: Cannot open output file /vmlinuz, Permission denied rsa: Use -help for summary. I know I broke some things; please try things out. The branch is here: https://github.com/akamai/openssl/tree/rsalz-monolith You've declared -days to take only positive numbers, it should allow negative numbers. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: openssl apps; flags, parsing dates, etc.
You've declared -days to take only positive numbers, it should allow negative numbers. Pushed, thanks. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl apps; flags, parsing dates, etc.
On Thu, Jul 17, 2014 at 12:09:29AM -0400, Salz, Rich wrote: You've declared -days to take only positive numbers, it should allow negative numbers. Pushed, thanks. Also the keyform option definition string looks wrong: keyform, OPT_KEYFORM, 'f', Private key file format (PEM or ENGINE) while the valid choices seem to be PEM or DER, not PEM or ENGINE: doc/apps/ca.pod:[B-keyform PEM|DER] doc/apps/ca.pod:=item B-keyform PEM|DER doc/apps/dgst.pod:[B-keyform arg] doc/apps/dgst.pod:=item B-keyform arg doc/apps/pkeyutl.pod:[B-keyform PEM|DER] doc/apps/pkeyutl.pod:=item B-keyform PEM|DER doc/apps/req.pod:[B-keyform PEM|DER] doc/apps/req.pod:=item B-keyform PEM|DER doc/apps/s_client.pod:[B-keyform DER|PEM] doc/apps/s_client.pod:=item B-keyform format doc/apps/s_server.pod:[B-keyform DER|PEM] doc/apps/s_server.pod:[B-dkeyform DER|PEM] doc/apps/s_server.pod:=item B-keyform format doc/apps/s_server.pod:=item B-dcertform format, B-dkeyform format, B-dpass arg doc/apps/x509.pod:[B-keyform DER|PEM] doc/apps/x509.pod:[B-CAkeyform DER|PEM] doc/apps/x509.pod:=item B-keyform PEM|DER doc/apps/x509.pod:The format or Bkey can be specified using the B-keyform option. In any case avoid magic constants in function call arguments: opt_format(..., 1, ...) instead: #define ANY_FORMAT 0 #define PEMDER_FORMAT 1 and use these only, or use an enum instead of defines if you prefer. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: openssl apps; flags, parsing dates, etc.
keyform, OPT_KEYFORM, 'f', Private key file format (PEM or ENGINE) while the valid choices seem to be PEM or DER, not PEM or ENGINE: No, it depends on the command. Some, for example, expect keys to be stored in the ENGINE (presumably an HSM). The docs are often outdated. But pem/der is the majority of choices. The right thing to do is change opt_format to be generic, and specify exactly which types of formats are supported. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl apps; flags, parsing dates, etc.
On 07/17/2014 12:03 AM, Viktor Dukhovni wrote: You've declared -days to take only positive numbers, it should allow negative numbers. why? Or at least: why accept these generally unacceptable options by default? I can understand wanting to be able to create perverse certificates to test validation stacks, but i don't think that the command line tool used by many people to create certs should be willing to create known bad certs without explicitly overriding a warning or something. --dkg signature.asc Description: OpenPGP digital signature
Re: openssl apps; flags, parsing dates, etc.
On Thu, Jul 17, 2014 at 12:56:40AM -0400, Daniel Kahn Gillmor wrote: You've declared -days to take only positive numbers, it should allow negative numbers. why? Or at least: why accept these generally unacceptable options by default? I can understand wanting to be able to create perverse certificates to test validation stacks, but i don't think that the command line tool used by many people to create certs should be willing to create known bad certs without explicitly overriding a warning or something. Command-line tools on unix systems do what they're told. The resulting certificate is well-formed, and never valid. However in some applications expiration checks are irrelevant (fingerprint checks and the like), and a deliberately pre-expired certificate may be a reasonable choice. Higher-level tools can check the days argument before invoking the openssl apps layer. It should not be necessary to write C code to generate well-formed if corner-case certificates. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl apps; flags, parsing dates, etc.
On Thu, Jul 17, 2014 at 05:06:07AM +, Viktor Dukhovni wrote: Higher-level tools can check the days argument before invoking the openssl apps layer. It should not be necessary to write C code to generate well-formed if corner-case certificates. Also there is far more risk in generating a certificate that lasts too long, than one that is never valid. Should there also be warnings for 100-year certificates? 1 day certificates? The CLI is not an interface for naive users. It is a toolkit for shell scripts. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
