[openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

2015-12-22 Thread Dave Baggett via RT 
Openssl Version 1.1.0 (master as of 22-DEC-15)
Mac OS X 10.11.2

Connection to my SMTP server, which has a 4096-bit RSA key, fails with:

Traceback (most recent call last):
  File "tls/_openssl.py", line 359, in handshake
error: [Errno 5] 1: TLS handshake with server peer failed: error:14160098:SSL 
routines:READ_STATE_MACHINE:excessive message size

Note that this is via my own Python C extension. However, this connection 
succeeds with openssl 1.0.2.

This appears to be a reappearance of this bug:

https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=319

Dave

Sent with inky

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

2015-12-22 Thread Short, Todd via RT 
Hello OpenSSL org:

I found the following issue via code inspection. In 
tls_process_client_key_exchange(), when EC is disabled, and an error occurs in 
ssl_generate_master_secret() or RAND_bytes(), the error path does not free 
rsa_decrypt.

Note that rsa_decrypt is not conditionally defined by OPENSSL_NO_RSA, so I did 
not wrap the free with that conditional.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."



0001-Memory-leak-in-state-machine-in-error-path.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Richard Levitte 
In message 
 on Tue, 
22 Dec 2015 14:41:16 +, "Salz, Rich"  said:

rsalz> Consistency is more important than support for old platforms :)

Side note: I'd like it if we skipped the age slurs, especially since
we're commonly working on operating systems that come from a decade
more history than VMS. ;-)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Richard Levitte 
In message <20151222153437.192023un5jh69...@www.polarhome.com> on Tue, 22 Dec 
2015 15:34:37 +0100, Zoltan Arpadffy  said:

zoli> Hi,
zoli> 
zoli> > zoli> May I ask you, if the new build will cover the long names issue
zoli> > (
zoli> > zoli> symhacks.h ) too?
zoli> >
zoli> > It's been pointed out to me by the vms-ports folks that it should be
zoli> > possible to solve using the compiler's "#pragma names shortened"
zoli> > rather than maintaining symhacks...  Then, it's just a matter of doing
zoli> > the same thing manually when producing the SYMBOL_VECTOR for a
zoli> > shareable image.  I'm also thinking that "#pragma names as_is" should
zoli> > be norm and that we could produce upper case aliases in SYMBOL_VECTOR
zoli> > (you know how that's done, right?).  Does that sound like a way
zoli> > forward to you?
zoli> 
zoli> It is not my decision, but I don't like either of these approaches.
zoli> 
zoli> The code itself needs to be written that it is as much as possible
zoli> portable.

In the end, this is a LINKER vs rest of the world issue.  In this day
and age, the 31 char limitation is a bit aged, and LINKER should
really be updated to allow longer symbol names.  If nothing else, C++
symbol munging would require it.  I certainly hope VSI receives the
messages and starts dealing with it.

Either way, we're dealing with C, with case sensitive symbols and
symbols longer than 31 chars.  The names pragmas are helpful
portability tools, the smoothest at this point is to put them to good
use.

zoli> It is not impossible to maintain a code base that uses up to 32 char
zoli> long function names - without losing the readability of the code.
zoli> I agree that it requires some extra focus from the developers side -
zoli> but coding a security software needs that (and even more) focus
zoli> anyway.

That can certainly be argued...  Again, that's more of a LINKER issue
than anything else.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Salz, Rich 
> It is not impossible to maintain a code base that uses up to 32 char long
> function names - without losing the readability of the code.
> I agree that it requires some extra focus from the developers side - but
> coding a security software needs that (and even more) focus anyway.

Yes, but symbol names are a distraction from the main focus of security.

Many of the >32 char names are auto-generated via #define's an ASN1 parsing.  
Most of the others follow common convention used elsewhere in the code. 
Consistency is more important than support for old platforms :)
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Zoltan Arpadffy 

Hi,


zoli> May I ask you, if the new build will cover the long names issue (
zoli> symhacks.h ) too?

It's been pointed out to me by the vms-ports folks that it should be
possible to solve using the compiler's "#pragma names shortened"
rather than maintaining symhacks...  Then, it's just a matter of doing
the same thing manually when producing the SYMBOL_VECTOR for a
shareable image.  I'm also thinking that "#pragma names as_is" should
be norm and that we could produce upper case aliases in SYMBOL_VECTOR
(you know how that's done, right?).  Does that sound like a way
forward to you?


It is not my decision, but I don't like either of these approaches.

The code itself needs to be written that it is as much as possible portable.

It is not impossible to maintain a code base that uses up to 32 char  
long function names - without losing the readability of the code.
I agree that it requires some extra focus from the developers side -  
but coding a security software needs that (and even more) focus anyway.


Thanks,
Z

---
WebMail, polarhome.com

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Richard Levitte 
In message <20151222134741.72034a0b79m0z...@www.polarhome.com> on Tue, 22 Dec 
2015 13:47:41 +0100, Zoltan Arpadffy  said:

zoli> Hi,
zoli> 
zoli> > zoli> > (unfortunately, "cpan install Text::Template" doesn't work
zoli> > because
zoli> > zoli> > there's a lack of action lines in the test: target it its
zoli> > Makefile,
zoli> > zoli> > and mms isn't too happy about that...)
zoli> 
zoli> > That's tough, unfortunately...  I've only access to a V8.4 cluster
zoli> > (Alpha and IA64), so I don't know how to help you further.  Of course,
zoli> > there's the option to build perl from source, which isn't very hard at
zoli> > all (I've done so a few times).
zoli> 
zoli> I do have access to VAX, Alpha and IA64 architectures... on range of
zoli> 7.3 to 8.3 OpenVMS versions.
zoli> Also I do have functional perl installed on them.
zoli> I am not the problem here, but ordinary developers that work on an old
zoli> system developing for a legacy program and do not have SYSTEM rights -
zoli> what is the common case.
zoli> The build solution should be designed to be usable by those developers
zoli> too.

Is perl still that uncommon on VMS?  I'm sorry to say that's gonna be
tough, then.  Just as an example, the old test scripts are gone, and
have been replaced with Test::More / Test::Harness recipes, and I'm
pretty sure VMS devs who're building OpenSSL are just as eager to run
the test scripts as anyone.

I could argue that for a developer to work, he/she needs a functional
development environment.  In this day and age, that should include
perl.  Pressure on the sysadmin!  (having been a VMS sysadmin, I'm
saying that very much toungue in cheak ;-))

zoli> > Well, the aim is to have a common structure to build from on all
zoli> > architectures we claim to support.  You've seen for yourself how the
zoli> > scripts for VMS builds were lagging behind, and quite frankly, it's
zoli> > hellish to keep them up to date (I've completely dropped the ball for
zoli> > 1.1).  That's not something I'm willing to have us do all over again.
zoli> 
zoli> Absolutely agree with you. This is the way forward.

Good :-)

zoli> May I ask you, if the new build will cover the long names issue (
zoli> symhacks.h ) too?

It's been pointed out to me by the vms-ports folks that it should be
possible to solve using the compiler's "#pragma names shortened"
rather than maintaining symhacks...  Then, it's just a matter of doing
the same thing manually when producing the SYMBOL_VECTOR for a
shareable image.  I'm also thinking that "#pragma names as_is" should
be norm and that we could produce upper case aliases in SYMBOL_VECTOR
(you know how that's done, right?).  Does that sound like a way
forward to you?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4194] engine command regression in 1.1

2015-12-22 Thread Salz, Rich via RT 
I don't know that I would call it a regression, but rather a difference. :)
I'll fix the summary but not the old uncommon behavior.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4196] BeagleBone Black detected as ARMv4

2015-12-22 Thread noloa...@gmail.com via RT 
This seems like an odd result considering the BeagleBone Black
processor is closer to a NEON. This particular BBB is running a Debian
8.2 based image.

I also believe CFLAGS should include hard-floats (i.e.,
-mfloat-abi=hard). Without it, entropy estimates for some of the RAND_
functions could produce incorrect results.

**

$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-12-20

$ uname -a
Linux beaglebone 4.1.13-ti-r36 #1 SMP PREEMPT Fri Dec 11 00:44:56 UTC
2015 armv7l GNU/Linux

$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

**

$ cpp -dM < /dev/null | grep __ARM | sort
#define __ARMEL__ 1
#define __ARM_32BIT_STATE 1
#define __ARM_ARCH 7
#define __ARM_ARCH_7A__ 1
#define __ARM_ARCH_ISA_ARM 1
#define __ARM_ARCH_ISA_THUMB 2
#define __ARM_ARCH_PROFILE 65
#define __ARM_EABI__ 1
#define __ARM_FEATURE_CLZ 1
#define __ARM_FEATURE_DSP 1
#define __ARM_FEATURE_LDREX 15
#define __ARM_FEATURE_QBIT 1
#define __ARM_FEATURE_SAT 1
#define __ARM_FEATURE_SIMD32 1
#define __ARM_FEATURE_UNALIGNED 1
#define __ARM_FP 12
#define __ARM_NEON_FP 4
#define __ARM_PCS_VFP 1
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __ARM_SIZEOF_WCHAR_T 32

**

$ cat /proc/cpuinfo
processor: 0
model name: ARMv7 Processor rev 2 (v7l)
BogoMIPS: 996.14
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer: 0x41
CPU architecture: 7
CPU variant: 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: Generic AM33XX (Flattened Device Tree)
Revision: 
Serial: ...

**

beaglebone:~/openssl-1.0.2e$ ./config
Operating system: armv7l-whatever-linux2
Configuring for linux-armv4
Configuring for linux-armv4
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-shared   [default]
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-store[experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
IsMK1MF=0
CC=gcc
CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -march=armv7-a -Wa,--noexecstack -O3 -Wall
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
EX_LIBS   =-ldl
CPUID_OBJ =armcap.o armv4cpuid.o
BN_ASM=bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM=
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o rc4_skey.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =ghash-armv4.o ghashv8-armx.o
ENGINES_OBJ   =
PROCESSOR =
RANLIB=/usr/bin/ranlib
ARFLAGS   =
PERL  =/usr/bin/perl
THIRTY_TWO_BIT mode
DES_UNROLL used
DES_INT used
BN_LLONG mode
RC4 uses uchar
RC4_CHUNK is unsigned long
BF_PTR used
created directory `include/openssl'
e_os2.h => include/openssl/e_os2.h
making links in crypto...
make[1]: Entering directory '/.../openssl-1.0.2e/crypto'
crypto.h => ../include/openssl/crypto.h
opensslv.h => ../include/openssl/opensslv.h
opensslconf.h => ../include/openssl/opensslconf.h
ebcdic.h => ../include/openssl/ebcdic.h
symhacks.h => ../include/openssl/symhacks.h
ossl_typ.h => ../include/openssl/ossl_typ.h
constant_time_test.c => ../test/constant_time_test.c
making links in crypto/objects...
make[2]: Entering directory '/.../openssl-1.0.2e/crypto/objects'
objects.h => ../../include/openssl/objects.h
obj_mac.h => ../../include/openssl/obj_mac.h
make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/objects'
making links in crypto/md4...
make[2]: Entering directory '/.../openssl-1.0.2e/crypto/md4'
md4.h => ../../include/openssl/md4.h
md4test.c => ../../test/md4test.c
md4.c => ../../apps/md4.c
make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/md4'
making links in crypto/md5...
make[2]: Entering directory '/.../openssl-1.0.2e/crypto/md5'
md5.h => ../../include/openssl/md5.h
md5test.c => ../../test/md5test.c
make[2]: Leaving directory '/.../openssl-1.0.2e/crypto/md5'
making links in crypto/sha...
make[2]: Entering directory '/.../openssl-1.0.2e/crypto/sha'
sha.h => ../../include/openssl/sha.h
shatest.c => ../../test/shatest.c
sha1test.c => ../../test/sha1test.c
sha256t.c => ../../test/

Re: [openssl-dev] extra data for ec keys

2015-12-22 Thread Salz, Rich 

> External cryptographic modules may store addition information to key.
> What about to define CRYPTO_EX_DATA for ec keys?

That is the plan -- we will remove EX_EX_DATA and the internal API and just use 
the standard crypto_ex_data stuff.  Want to make a more complete patch as a 
github pull request? :)  Otherwise I'll get to it soon.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Zoltan Arpadffy 

Hi,


zoli> > (unfortunately, "cpan install Text::Template" doesn't work because
zoli> > there's a lack of action lines in the test: target it its Makefile,
zoli> > and mms isn't too happy about that...)



That's tough, unfortunately...  I've only access to a V8.4 cluster
(Alpha and IA64), so I don't know how to help you further.  Of course,
there's the option to build perl from source, which isn't very hard at
all (I've done so a few times).


I do have access to VAX, Alpha and IA64 architectures... on range of  
7.3 to 8.3 OpenVMS versions.

Also I do have functional perl installed on them.
I am not the problem here, but ordinary developers that work on an old  
system developing for a legacy program and do not have SYSTEM rights -  
what is the common case.

The build solution should be designed to be usable by those developers too.


Well, the aim is to have a common structure to build from on all
architectures we claim to support.  You've seen for yourself how the
scripts for VMS builds were lagging behind, and quite frankly, it's
hellish to keep them up to date (I've completely dropped the ball for
1.1).  That's not something I'm willing to have us do all over again.


Absolutely agree with you. This is the way forward.

May I ask you, if the new build will cover the long names issue (  
symhacks.h ) too?


Thanks,
Z

---
WebMail, polarhome.com

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Richard Levitte 
In message <20151222122349.916552ojkzhe5...@www.polarhome.com> on Tue, 22 Dec 
2015 12:23:49 +0100, Zoltan Arpadffy  said:

zoli> Hi,
zoli> 
zoli> > zoli> I am aware that having perl installed on a modern operating
zoli> > system is
zoli> > zoli> not a very tough requirement - but experience shows that
zoli> > external
zoli> > zoli> dependencies often cause problems on OpenVMS.
zoli> >
zoli> > For perl, it's not that hard:
zoli> > http://sourceforge.net/projects/vmsperlkit/files/
zoli> 
zoli> > (unfortunately, "cpan install Text::Template" doesn't work because
zoli> > there's a lack of action lines in the test: target it its Makefile,
zoli> > and mms isn't too happy about that...)
zoli> 
zoli> > So, uhmm, nah.  Frankly, it's time (it's been time for long) for the
zoli> > OpenVMS community to catch up with the rest of the world re open
zoli> > source building...
zoli> 
zoli> Please, do not misunderstand me - I am on your side and I would be the
zoli> most happy if that would work.
zoli> 
zoli> But there is a problem:
zoli> The files currently featured are kits for installing
zoli> Perl 5.22.1 on OpenVMS Alpha or Itanium v8.3 and later. (from the home
zoli> page)... but many OpenVMS systems are not on v8.3 yet.

There are older kits in the Archive folder.  I don't know for the
moment what VMS version they're built for.

zoli> This is not good - I know. But this is a fact we need to face when we
zoli> develop for this system.

That's tough, unfortunately...  I've only access to a V8.4 cluster
(Alpha and IA64), so I don't know how to help you further.  Of course,
there's the option to build perl from source, which isn't very hard at
all (I've done so a few times).

zoli> One descript.mms file would be enough. Thank you for asking :)
zoli> MMS/MMK accepts parameters that could be used within the descript file
zoli> making possible the different choices - if it is written on that way,
zoli> especially that architecture and some other parameters can be
zoli> successfully guessed within the MMS file.

Well, the aim is to have a common structure to build from on all
architectures we claim to support.  You've seen for yourself how the
scripts for VMS builds were lagging behind, and quite frankly, it's
hellish to keep them up to date (I've completely dropped the ball for
1.1).  That's not something I'm willing to have us do all over again.

zoli> > zoli> > zoli> Do you need some help with coding, testing?
zoli> >
zoli> > I'll have a branch in g...@github.com:levitte/openssl.git
zoli> > I'll get back when it starts going live.
zoli> 
zoli> Thank you, Richard.
zoli> I am looking forward to help you.

Thanks :-)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Zoltan Arpadffy 

Hi,


zoli> I am aware that having perl installed on a modern operating system is
zoli> not a very tough requirement - but experience shows that external
zoli> dependencies often cause problems on OpenVMS.

For perl, it's not that hard:  
http://sourceforge.net/projects/vmsperlkit/files/



(unfortunately, "cpan install Text::Template" doesn't work because
there's a lack of action lines in the test: target it its Makefile,
and mms isn't too happy about that...)



So, uhmm, nah.  Frankly, it's time (it's been time for long) for the
OpenVMS community to catch up with the rest of the world re open
source building...


Please, do not misunderstand me - I am on your side and I would be the  
most happy if that would work.


But there is a problem:
The files currently featured are kits for installing
Perl 5.22.1 on OpenVMS Alpha or Itanium v8.3 and later. (from the home  
page)... but many OpenVMS systems are not on v8.3 yet.


Here is an unofficial usage statistics for OpenSSL and Vim users

VAX - 7.1 or older  29.82 % (167)
VAX - 7.2 or newer  6.96 % (39)
Alpha - 7.2 or older5.54 % (31)
Alpha - 7.3 or newer29.64 % (166)
Itanium - 8.0 or newer  23.39 % (131)
I do not use OpenVMS3.57 % (20)
I do not know   1.07 % (6)
Total votes: 560

The most probable reason for keeping OpenVMS systems not updated is  
the HP's ECO packages availability as well the OpenVMS excellent  
backwards compatibility that allows old builds to run in new systems.


This is not good - I know. But this is a fact we need to face when we  
develop for this system.



Considering there's Alpha, IA64 and VSI is building VMS for x86_64,
and let's not forget pointer size options, the different possible
configurations is already not a small number, and will only increase.
How many variants of descrip.mms did you want?


One descript.mms file would be enough. Thank you for asking :)
MMS/MMK accepts parameters that could be used within the descript file  
making possible the different choices - if it is written on that way,  
especially that architecture and some other parameters can be  
successfully guessed within the MMS file.



zoli> > zoli> Do you need some help with coding, testing?

I'll have a branch in g...@github.com:levitte/openssl.git
I'll get back when it starts going live.


Thank you, Richard.
I am looking forward to help you.

Regards,
Z

---
WebMail, polarhome.com

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4184] Memory leak in DSA redo case

2015-12-22 Thread Kurt Roeckx via RT 
Fixed.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Richard Levitte 
In message <20151222111022.44086nc6688vq...@www.polarhome.com> on Tue, 22 Dec 
2015 11:10:22 +0100, Zoltan Arpadffy  said:

zoli> Richard,
zoli> 
zoli> > My plan for "new and shiny" is based on perl, running Configure and
zoli> > have it generate a top level descrip.mms.  Requirements will be a perl
zoli> > installation (minimum version 5.12) plus Text::Template.
zoli> 
zoli> Thank you for the information.
zoli> 
zoli> I am aware that having perl installed on a modern operating system is
zoli> not a very tough requirement - but experience shows that external
zoli> dependencies often cause problems on OpenVMS.

For perl, it's not that hard: http://sourceforge.net/projects/vmsperlkit/files/

zoli> I would suggest to include/commit the perl scripts into the OpenSSL
zoli> source code (for developers convenience only), but they should be ran
zoli> and commit the OpenVMS descrip.mms build files matching the current
zoli> code base - as a step in the OpenSSL source code release process.

I was thinking that it might be a good idea to bundle Text::Template,
if that's what you meant.  We try to make sure to only use core perl
modules, but considering there's no template module among the core
ones and I hardly want to reinvent the wheel, I might make an
exception there.  I haven't decided, though, it's not like it's very
hard to do a "cpan download Text::Template" and then install it
(unfortunately, "cpan install Text::Template" doesn't work because
there's a lack of action lines in the test: target it its Makefile,
and mms isn't too happy about that...)

zoli> Unix make files are also made in forehand. Right?

Nope.

zoli> What is your opinion about this?

Considering there's Alpha, IA64 and VSI is building VMS for x86_64,
and let's not forget pointer size options, the different possible
configurations is already not a small number, and will only increase.
How many variants of descrip.mms did you want?

So, uhmm, nah.  Frankly, it's time (it's been time for long) for the
OpenVMS community to catch up with the rest of the world re open
source building...  or for someone to produce OpenSSL install kits
(it's possible that the vms-ports effort will do so, possibly by yours
truly... no promises, though).

zoli> > zoli> Do you need some help with coding, testing?
zoli> >
zoli> > Yes please.
zoli> 
zoli> Please, let me know how... or should I just wait for the make files
zoli> release?

I'll have a branch in g...@github.com:levitte/openssl.git
I'll get back when it starts going live.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Zoltan Arpadffy 

Richard,


My plan for "new and shiny" is based on perl, running Configure and
have it generate a top level descrip.mms.  Requirements will be a perl
installation (minimum version 5.12) plus Text::Template.


Thank you for the information.

I am aware that having perl installed on a modern operating system is  
not a very tough requirement - but experience shows that external  
dependencies often cause problems on OpenVMS.


I would suggest to include/commit the perl scripts into the OpenSSL  
source code (for developers convenience only), but they should be ran  
and commit the OpenVMS descrip.mms build files matching the current  
code base - as a step in the OpenSSL source code release process.


Unix make files are also made in forehand. Right?

What is your opinion about this?



zoli> Do you need some help with coding, testing?

Yes please.


Please, let me know how... or should I just wait for the make files release?

Thank you.
Z

---
WebMail, polarhome.com

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Richard Levitte 
In message <20151222101434.116043c95betf...@www.polarhome.com> on Tue, 22 Dec 
2015 10:14:34 +0100, Zoltan Arpadffy  said:

zoli> Thank you Richard.
zoli> 
zoli> What "slowly" means? Will you be able to commit the OpenVMS build
zoli> scripts before the 1.1.0's release?

Yes.  At the latest, it should be fully present in alpha3.  See the
end of https://openssl.org/policies/releasestrat.html for planned
release dates.

zoli> Do you need some help with coding, testing?

Yes please.

zoli> Should I try to repair the old build scripts?

No.  Thanks for the reminder, they should all go.

My plan for "new and shiny" is based on perl, running Configure and
have it generate a top level descrip.mms.  Requirements will be a perl
installation (minimum version 5.12) plus Text::Template.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

2015-12-22 Thread Zoltan Arpadffy 

Thank you Richard.

What "slowly" means? Will you be able to commit the OpenVMS build  
scripts before the 1.1.0's release?


Do you need some help with coding, testing?
Should I try to repair the old build scripts?

Thanks,
Z



Quoting Richard Levitte :

The building scripts are not at all updated, it's beyond repair. I'm  
(slowly) working on a new solution that doesn't require the separate  
update hell...


Cheers
Richard

Zoltan Arpadffy  skrev: (21 december 2015 20:36:13 CET)

Hi,

I am sorry, but because of the relocation of the header files the 1.1.0
does
not build on OpenVMS.
Please, allow some time to fix the OpenVMS build scripts.

Thank you.
Regards,
Z

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of
OpenSSL
Sent: den 10 december 2015 16:02
To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML
Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 1 published

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  OpenSSL version 1.1.0 pre release 1 (alpha)
  ===

  OpenSSL - The Open Source toolkit for SSL/TLS
  http://www.openssl.org/

OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 1 has
now
  been made available. For details of changes and known issues see the
  release notes at:

   http://www.openssl.org/news/openssl-1.1.0-notes.html

  Note: This OpenSSL pre-release has been provided for testing ONLY.
  It should NOT be used for security critical purposes.

 The alpha release is available for download via HTTP and FTP from the
following master locations (you can find the various FTP mirrors under
  http://www.openssl.org/source/mirror.html):

* http://www.openssl.org/source/
* ftp://ftp.openssl.org/source/

  The distribution file name is:

   o openssl-1.1.0-pre1.tar.gz
 Size: 4990889
 SHA1 checksum: a058b999e17e0c40988bd7b9b280c9876f62684e
 SHA256 checksum:
79da49c38464a19d1b328c2f4a3661849bd2eb3d54a37fdb6a56d9b8a18e87bd

  The checksums were calculated using the following commands:

   openssl sha1 openssl-1.1.0-pre1.tar.gz
   openssl sha256 openssl-1.1.0-pre1.tar.gz

 Please download and check this alpha release as soon as possible. Bug
reports
  should go to r...@openssl.org. Please check the release notes
  and mailing lists to avoid duplicate reports of known issues.

  Yours,

  The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWaYrRAAoJENnE0m0OYESRh5gIAJ8WrkPPV8CW2xWmtyIjAxpz
7FvvpxBWHaBgJcCrvNomh2JJupXa+enWCTsskIyH0+FtS85VeOKNvQg68xbCOvLl
I0dWxMNb8SCxuagvEje8xGEnf8by8pZdYaK8ERASlNoGVIgN8CwppiKnY8c1yRYn
Ti0dUZLyVZvT5Qm2Q3k4pOvfS/+rvFjHiuUllFzfHlp6mdk4573w5eneoTINQvRK
OC8iAnSiINQWQvuiavLVIgw7VFBD1WC2iKWuSA3+31YuM8CUpvbbnJHh2QUfGkIw
oNTkflxgQJhk/txwqvCSzZsVddhvQLZtiRZYQcG4WUuskygCENeieJGPOXN6ioI=
=LY4X
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev





---
WebMail, polarhome.com

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4195] remove duplicates in util/libeay.num

2015-12-22 Thread Roumen Petrov via RT 
Hello,

After remove of some global variables in export file left double 
information for non existent functions.

For instance before:
X509_CERT_PAIR_it   3534 
EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
X509_CERT_PAIR_it   3534 
EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:

current:
X509_CERT_PAIR_it   35341_1_0 NOEXIST::FUNCTION:
X509_CERT_PAIR_it   35341_1_0 NOEXIST::FUNCTION:

Proposed patch removes duplicates.


Regards,
Roumen Petrov




>From 992be79410a3c909f4b1d2f492423aaf2c8a8454 Mon Sep 17 00:00:00 2001
From: Roumen Petrov 
Date: Sat, 21 Mar 2015 15:29:25 +0200
Subject: [PATCH 2/2] remove duplicates in util/libeay.num

---
 util/libeay.num | 13 -
 1 file changed, 13 deletions(-)

diff --git a/util/libeay.num b/util/libeay.num
index e9a678b..bce6ca0 100755
--- a/util/libeay.num
+++ b/util/libeay.num
@@ -1951,7 +1951,6 @@ ENGINE_unregister_ciphers   2528	1_1_0	EXIST::FUNCTION:ENGINE
 ENGINE_get_ciphers  2529	1_1_0	EXIST::FUNCTION:ENGINE
 d2i_OCSP_BASICRESP  2530	1_1_0	EXIST::FUNCTION:
 KRB5_CHECKSUM_it2531	1_1_0	NOEXIST::FUNCTION:
-KRB5_CHECKSUM_it2531	1_1_0	NOEXIST::FUNCTION:
 EC_POINT_add2532	1_1_0	EXIST::FUNCTION:EC
 ASN1_item_ex_i2d2533	1_1_0	EXIST::FUNCTION:
 OCSP_CERTID_it  2534	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
@@ -1983,7 +1982,6 @@ X509_CRL_it 2555	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION
 X509_CRL_it 2555	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
 OCSP_BASICRESP_add_ext  2556	1_1_0	EXIST::FUNCTION:
 KRB5_ENCKEY_it  2557	1_1_0	NOEXIST::FUNCTION:
-KRB5_ENCKEY_it  2557	1_1_0	NOEXIST::FUNCTION:
 UI_method_set_closer2558	1_1_0	EXIST::FUNCTION:
 X509_STORE_set_purpose  2559	1_1_0	EXIST::FUNCTION:
 i2d_ASN1_GENERALSTRING  2560	1_1_0	EXIST::FUNCTION:
@@ -2193,7 +2191,6 @@ X509_ATTRIBUTE_it   2732	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:
 OCSP_ONEREQ_get_ext_by_NID  2733	1_1_0	EXIST::FUNCTION:
 PKCS12_decrypt_skey 2734	1_1_0	EXIST::FUNCTION:
 KRB5_AUTHENT_it 2735	1_1_0	NOEXIST::FUNCTION:
-KRB5_AUTHENT_it 2735	1_1_0	NOEXIST::FUNCTION:
 UI_dup_error_string 2736	1_1_0	EXIST::FUNCTION:
 RSAPublicKey_it 2737	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:RSA
 RSAPublicKey_it 2737	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:RSA
@@ -2211,7 +2208,6 @@ HMAC_CTX_reset  2747	1_1_0	EXIST::FUNCTION:
 ENGINE_get_digest   2748	1_1_0	EXIST::FUNCTION:ENGINE
 OCSP_RESPONSE_print 2749	1_1_0	EXIST::FUNCTION:
 KRB5_TKTBODY_it 2750	1_1_0	NOEXIST::FUNCTION:
-KRB5_TKTBODY_it 2750	1_1_0	NOEXIST::FUNCTION:
 ACCESS_DESCRIPTION_it   2751	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
 ACCESS_DESCRIPTION_it   2751	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
 PKCS7_ISSUER_AND_SERIAL_it  2752	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
@@ -2266,7 +2262,6 @@ ASN1_tag2bit2788	1_1_0	EXIST::FUNCTION:
 UI_method_set_flusher   2789	1_1_0	EXIST::FUNCTION:
 X509_ocspid_print   2790	1_1_0	EXIST::FUNCTION:
 KRB5_ENCDATA_it 2791	1_1_0	NOEXIST::FUNCTION:
-KRB5_ENCDATA_it 2791	1_1_0	NOEXIST::FUNCTION:
 ENGINE_get_load_pubkey_function 2792	1_1_0	EXIST::FUNCTION:ENGINE
 UI_add_user_data2793	1_1_0	EXIST::FUNCTION:
 OCSP_REQUEST_delete_ext 2794	1_1_0	EXIST::FUNCTION:
@@ -2485,7 +2480,6 @@ OCSP_url_svcloc_new 2973	1_1_0	EXIST::FUNCTION:
 ASN1_template_free  2974	1_1_0	NOEXIST::FUNCTION:
 OCSP_SINGLERESP_add_ext 2975	1_1_0	EXIST::FUNCTION:
 KRB5_AUTHENTBODY_it 2976	1_1_0	NOEXIST::FUNCTION:
-KRB5_AUTHENTBODY_it 2976	1_1_0	NOEXIST::FUNCTION:
 X509_supported_extension2977	1_1_0	EXIST::FUNCTION:
 i2d_KRB5_AUTHDATA   2978	1_1_0	NOEXIST::FUNCTION:
 UI_method_get_opener2979	1_1_0	EXIST::FUNCTION:
@@ -2587,13 +2581,11 @@ asn1_do_lock3059	1_1_0	NOEXIST::FUNCTION:
 PKCS7_ATTR_VERIFY_it3060	1_1_0	EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
 PKCS7_ATTR_VERIFY_it3060	1_1_0	EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:
 KRB5_APREQBODY_it   3061	1_1_0	NOEXIST::FUNCTION:
-KRB5_APREQBODY_it   3061	1_1_0	NOEX

[openssl-dev] __STDC_VERSION__ is not defined

2015-12-22 Thread Roumen Petrov 

Hello,

Compilation of an application with current master branch and c89 
compiler produce a lot of warnings.
Proposed patch 
"0001-__STDC_VERSION__-is-not-defined-for-c89-compilers.patch" fix them.


Regards,
Roumen

>From 7d430516d69e6161eee447833518914e6b473dbd Mon Sep 17 00:00:00 2001
From: Roumen Petrov 
Date: Thu, 3 Dec 2015 23:43:24 +0200
Subject: [PATCH 01/15] __STDC_VERSION__ is not defined for c89 compilers

---
 include/openssl/e_os2.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index 23602a5..7ab4788 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -321,8 +321,10 @@ typedef unsigned __int64 uint64_t;
  * some systems (e.g. Mac OS X).
  */
 # ifndef PRIu64
-#  if (__STDC_VERSION__ >= 199901L)
-#   include 
+#  ifdef __STDC_VERSION__
+#   if (__STDC_VERSION__ >= 199901L)
+#include 
+#   endif
 #  endif
 #  ifndef PRIu64
 #   define PRIu64 "lu"
-- 
1.8.4

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] extra data for ec keys

2015-12-22 Thread Roumen Petrov 

Hello,

After merge of ECDH and ECDSA and associating method to EC_KEY I would 
like to request some additional functionality.


External cryptographic modules may store addition information to key.
What about to define CRYPTO_EX_DATA for ec keys?
Proposed patch "0008-extra-data-for-EC_KEY.patch" - note that index 
CRYPTO_EX_INDEX is with gap in numbering but I would like patch to be 
minimal.



I would like to request external applications to be able to change 
method - see attached patch "0009-access-EC_KEY-method-property.patch".


Regards,
Roumen Petrov

>From 36e048c3bbd1c416194a20e8f0c1a84467bf2765 Mon Sep 17 00:00:00 2001
From: Roumen Petrov 
Date: Mon, 21 Dec 2015 17:56:34 +0200
Subject: [PATCH 08/15] extra data for EC_KEY

---
 crypto/ec/ec_lcl.h   |  1 +
 crypto/ec/ec_lib.c   | 10 ++
 include/openssl/crypto.h |  3 +--
 include/openssl/ec.h |  6 ++
 util/libeay.num  |  2 ++
 5 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/crypto/ec/ec_lcl.h b/crypto/ec/ec_lcl.h
index ebfaae3..912aa8e 100644
--- a/crypto/ec/ec_lcl.h
+++ b/crypto/ec/ec_lcl.h
@@ -267,6 +267,7 @@ struct ec_key_st {
 point_conversion_form_t conv_form;
 int references;
 int flags;
+CRYPTO_EX_DATA ex_data;
 EC_EXTRA_DATA *method_data;
 } /* EC_KEY */ ;
 
diff --git a/crypto/ec/ec_lib.c b/crypto/ec/ec_lib.c
index 7cb4759..e9e5832 100644
--- a/crypto/ec/ec_lib.c
+++ b/crypto/ec/ec_lib.c
@@ -1091,3 +1091,13 @@ int ec_precompute_mont_data(EC_GROUP *group)
 BN_CTX_free(ctx);
 return ret;
 }
+
+int EC_KEY_set_ex_data(EC_KEY *key, int idx, void *arg)
+{
+return (CRYPTO_set_ex_data(&key->ex_data, idx, arg));
+}
+
+void *EC_KEY_get_ex_data(const EC_KEY *key, int idx)
+{
+return (CRYPTO_get_ex_data(&key->ex_data, idx));
+}
diff --git a/include/openssl/crypto.h b/include/openssl/crypto.h
index 81e944d..bd8f07d 100644
--- a/include/openssl/crypto.h
+++ b/include/openssl/crypto.h
@@ -270,8 +270,7 @@ DECLARE_STACK_OF(void)
 # define CRYPTO_EX_INDEX_X509_STORE_CTX   5
 # define CRYPTO_EX_INDEX_DH   6
 # define CRYPTO_EX_INDEX_DSA  7
-# define CRYPTO_EX_INDEX_ECDH 8
-# define CRYPTO_EX_INDEX_ECDSA9
+# define CRYPTO_EX_INDEX_EC_KEY   8
 # define CRYPTO_EX_INDEX_RSA 10
 # define CRYPTO_EX_INDEX_ENGINE  11
 # define CRYPTO_EX_INDEX_UI  12
diff --git a/include/openssl/ec.h b/include/openssl/ec.h
index 1dc2db1..923844c 100644
--- a/include/openssl/ec.h
+++ b/include/openssl/ec.h
@@ -868,6 +868,12 @@ void *EC_KEY_insert_key_method_data(EC_KEY *key, void *data,
 void *(*dup_func) (void *),
 void (*free_func) (void *),
 void (*clear_free_func) (void *));
+
+#define EC_KEY_get_ex_new_index(l, p, newf, dupf, freef) \
+CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_EC_KEY, l, p, newf, dupf, freef)
+int EC_KEY_set_ex_data(EC_KEY *key, int idx, void *arg);
+void *EC_KEY_get_ex_data(const EC_KEY *key, int idx);
+
 /* wrapper functions for the underlying EC_GROUP object */
 void EC_KEY_set_asn1_flag(EC_KEY *eckey, int asn1_flag);
 
diff --git a/util/libeay.num b/util/libeay.num
index bce6ca0..a3766ec 100755
--- a/util/libeay.num
+++ b/util/libeay.num
@@ -4735,3 +4735,5 @@ OPENSSL_strlcat 5110	1_1_0	EXIST::FUNCTION:
 OPENSSL_memdup  5111	1_1_0	NOEXIST::FUNCTION:
 CRYPTO_memdup   5112	1_1_0	EXIST::FUNCTION:
 CRYPTO_strndup  5113	1_1_0	EXIST::FUNCTION:
+EC_KEY_get_ex_data  5114	1_1_0	EXIST::FUNCTION:EC
+EC_KEY_set_ex_data  5115	1_1_0	EXIST::FUNCTION:EC
-- 
1.8.4

>From a347853193f419f21e4757abf0a8b1b8d523066b Mon Sep 17 00:00:00 2001
From: Roumen Petrov 
Date: Mon, 21 Dec 2015 19:41:42 +0200
Subject: [PATCH 09/15] access EC_KEY method property

---
 crypto/ec/ec_kmeth.c | 27 +++
 include/openssl/ec.h |  2 ++
 util/libeay.num  |  2 ++
 3 files changed, 31 insertions(+)

diff --git a/crypto/ec/ec_kmeth.c b/crypto/ec/ec_kmeth.c
index d6c2811..9b6f4d9 100644
--- a/crypto/ec/ec_kmeth.c
+++ b/crypto/ec/ec_kmeth.c
@@ -93,6 +93,33 @@ void EC_KEY_set_default_method(const EC_KEY_METHOD *meth)
 default_ec_key_meth = meth;
 }
 
+const EC_KEY_METHOD *EC_KEY_get_method(const EC_KEY *key)
+{
+return key->meth;
+}
+
+int EC_KEY_set_method(EC_KEY *key, const EC_KEY_METHOD *meth)
+{
+{
+/* method is set always, see ... _new_...  */
+void (*finish)(EC_KEY *key) = key->meth->finish;
+if (finish)
+finish(key);
+}
+
+#ifndef OPENSSL_NO_ENGINE
+if (key->engine) {
+ENGINE_finish(key->engine);
+key->engine = NULL;
+}
+#endif
+
+key->meth = meth;
+if (meth->init)
+meth->init(key);
+return 1;
+}
+
 EC_KEY *EC_KEY_new_method(ENGINE *engine)
 {
 EC_KEY *ret = OPE