[openssl-dev] [openssl.org #4593] [PATCH] pod: fix nits related to spacing around commas and assignments
Also update the nit checker to catch missing spaces in prototypes as that is where the majority of errors were located. --- crypto/bn/README.pod | 10 +- doc/apps/ec.pod | 2 +- doc/apps/ecparam.pod | 2 +- doc/crypto/BF_encrypt.pod| 4 ++-- doc/crypto/BIO_ctrl.pod | 12 ++-- doc/crypto/BIO_f_buffer.pod | 8 doc/crypto/BIO_f_ssl.pod | 24 doc/crypto/BIO_find_type.pod | 2 +- doc/crypto/BIO_new.pod | 2 +- doc/crypto/BIO_push.pod | 2 +- doc/crypto/BIO_s_bio.pod | 12 ++-- doc/crypto/BIO_s_fd.pod | 4 ++-- doc/crypto/BIO_s_file.pod| 4 ++-- doc/crypto/BIO_s_mem.pod | 6 +++--- doc/crypto/BIO_set_callback.pod | 16 doc/crypto/BN_BLINDING_new.pod | 2 +- doc/crypto/BN_generate_prime.pod | 6 +++--- doc/crypto/DH_generate_parameters.pod| 2 +- doc/crypto/DSA_generate_parameters.pod | 2 +- doc/crypto/EVP_BytesToKey.pod| 4 ++-- doc/crypto/EVP_DigestInit.pod| 4 ++-- doc/crypto/EVP_OpenInit.pod | 4 ++-- doc/crypto/EVP_PKEY_encrypt.pod | 2 +- doc/crypto/EVP_PKEY_keygen.pod | 12 ++-- doc/crypto/EVP_PKEY_set1_RSA.pod | 16 doc/crypto/EVP_SignInit.pod | 2 +- doc/crypto/EVP_VerifyInit.pod| 2 +- doc/crypto/OPENSSL_LH_COMPFUNC.pod | 2 +- doc/crypto/RSA_generate_key.pod | 2 +- doc/crypto/RSA_get0_key.pod | 2 +- doc/crypto/X509_NAME_ENTRY_get_object.pod| 2 +- doc/crypto/X509_NAME_add_entry_by_txt.pod| 2 +- doc/crypto/X509_NAME_get_index_by_NID.pod| 8 doc/crypto/X509_NAME_print_ex.pod| 2 +- doc/crypto/X509_STORE_CTX_new.pod| 2 +- doc/crypto/X509_STORE_CTX_set_verify_cb.pod | 22 +++--- doc/ssl/SSL_CTX_set_cert_verify_callback.pod | 2 +- doc/ssl/SSL_CTX_set_client_CA_list.pod | 2 +- doc/ssl/SSL_CTX_set_info_callback.pod| 22 +++--- doc/ssl/SSL_CTX_set_read_ahead.pod | 4 ++-- doc/ssl/SSL_CTX_set_split_send_fragment.pod | 24 doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod | 2 +- doc/ssl/SSL_CTX_set_verify.pod | 2 +- doc/ssl/SSL_CTX_use_certificate.pod | 2 +- doc/ssl/SSL_get_current_cipher.pod | 4 ++-- doc/ssl/ssl.pod | 4 ++-- util/find-doc-nits.pl| 4 47 files changed, 144 insertions(+), 140 deletions(-) diff --git a/crypto/bn/README.pod b/crypto/bn/README.pod index 07e72aa2c5d9..109ab0d91428 100644 --- a/crypto/bn/README.pod +++ b/crypto/bn/README.pod @@ -36,9 +36,9 @@ library internal functions int nb); void bn_mul_low_normal(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n); void bn_mul_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n2, - int dna,int dnb,BN_ULONG *tmp); + int dna, int dnb, BN_ULONG *tmp); void bn_mul_part_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, - int n, int tna,int tnb, BN_ULONG *tmp); + int n, int tna, int tnb, BN_ULONG *tmp); void bn_mul_low_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n2, BN_ULONG *tmp); void bn_mul_high(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, BN_ULONG *l, @@ -96,8 +96,8 @@ bn.top=1. B is 1 if the number is negative. When a B is B<0>, the B field can be B and B == B<0>. B is a bit field of flags which are defined in C. The -flags begin with B. The macros BN_set_flags(b,n) and -BN_get_flags(b,n) exist to enable or fetch flag(s) B from B +flags begin with B. The macros BN_set_flags(b, n) and +BN_get_flags(b, n) exist to enable or fetch flag(s) B from B structure B. Various routines in this library require the use of temporary @@ -124,7 +124,7 @@ bn_sqr_words(B, B, B) operates on the B word array B and the 2*B word array B. It computes B * B word-wise, and places the low and high bytes of the result in B. -bn_div_words(B, B, B) divides the two word number (B,B) +bn_div_words(B, B, B) divides the two word number (B, B) by B and returns the result. bn_add_words(B, B, B, B) operates on the B word diff --git a/doc/apps/ec.pod b/doc/apps/ec.pod index 10c5e859aac9..758709f081dd 100644 --- a/doc/apps/ec.pod +++ b/doc/apps/ec.pod @@ -132,7 +132,7 @@ Possible value are: B, i.e. the ec parameters are specified by an OID, or B where the ec parameters are explicitly given (see RFC 3279 for the definition of the EC parameters structures). The default value is B. -B the B alternative ,as specified in RFC 3279, +B the B alternative, as specified in RFC 3279, is
[openssl-dev] [PATCH] [openssl.org #2558] make windres controllable via build env var settings
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. So add support for the standard $RC
/ $WINDRES env vars as well.
---
Configure | 1 +
Makefile.in | 2 ++
Makefile.shared | 2 +-
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Configure b/Configure
index 080bc06..f5b1257 100755
--- a/Configure
+++ b/Configure
@@ -888,6 +888,7 @@ $target{ranlib} = $ENV{'RANLIB'} || $target{ranlib} ||
$default_ranlib;
$target{ar} = $ENV{'AR'} || "ar";
$target{arflags} = "" if !defined($target{arflags});
$target{nm} = "nm";
+$target{windres} = $ENV{'RC'} || $ENV{'WINDRES'} || "windres";
# Make sure build_scheme is consistent.
$target{build_scheme} = [ $target{build_scheme} ]
if ref($target{build_scheme}) ne "ARRAY";
diff --git a/Makefile.in b/Makefile.in
index 30f44ff..0830b88 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -103,6 +103,7 @@ ARFLAGS= {- $target{arflags} -}
AR=$(CROSS_COMPILE){- $target{ar} -} $(ARFLAGS) r
RANLIB= {- $target{ranlib} -}
NM= $(CROSS_COMPILE){- $target{nm} -}
+WINDRES= $(CROSS_COMPILE){- $target{windres} -}
PERL= {- $config{perl} -}
#RM= echo --
RM= rm -f
@@ -254,6 +255,7 @@ BUILDENV= LC_ALL=C PLATFORM='$(PLATFORM)'
PROCESSOR='$(PROCESSOR)'\
SHARED_CFLAG='$(SHARED_CFLAG)' \
AS='$(CC)' ASFLAG='$(CFLAG) -c' \
AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)'\
+ WINDRES='$(WINDRES)'\
CROSS_COMPILE='$(CROSS_COMPILE)'\
PERL='$(PERL)' DYNAMIC_ENGINES='$(DYNAMIC_ENGINES)' \
SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \
diff --git a/Makefile.shared b/Makefile.shared
index 9028960..adcfe40 100644
--- a/Makefile.shared
+++ b/Makefile.shared
@@ -280,7 +280,7 @@ link_shlib.cygwin:
echo "$(PERL) $(SRCDIR)/util/mkrc.pl $$dll_name |" \
"$(CROSS_COMPILE)windres $(SHARED_RCFLAGS) -o rc.o"; \
$(PERL) $(SRCDIR)/util/mkrc.pl $$dll_name | \
- $(CROSS_COMPILE)windres $(SHARED_RCFLAGS) -o rc.o; \
+ $(WINDRES) $(SHARED_RCFLAGS) -o rc.o; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared
-Wl,--enable-auto-image-base -Wl,-Bsymbolic
-Wl,--out-implib,lib$(LIBNAME).dll.a rc.o"; \
--
2.6.2
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2558
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3738] [PATCH] tell make running subcommands are make based
On 08 Mar 2015 20:26, Salz, Rich wrote: > > Lets add + to the rules we know are make based. > > Isn't that a gnu-make-only thing? looks to me like POSIX specifies it: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_03 -mike ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3934] [PATCH] test: use _DEFAULT_SOURCE with newer glibc versions
The _BSD_SOURCE macro is replaced by the _DEFAULT_SOURCE macro. Using just the former with newer versions leads to a build time warning, so make sure to use the new macro too. --- test/ssltest.c | 1 + 1 file changed, 1 insertion(+) diff --git a/test/ssltest.c b/test/ssltest.c index 26cf96c..b36f667 100644 --- a/test/ssltest.c +++ b/test/ssltest.c @@ -141,6 +141,7 @@ */ /* Or gethostname won't be declared properly on Linux and GNU platforms. */ +#define _DEFAULT_SOURCE 1 #define _BSD_SOURCE 1 #include assert.h -- 2.4.4 ___ 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 #3780] [PATCH] fix race when symlink shareds libs
When the crypto/ssl targets attempt to build their shared libs, they run: cd ..; make libcrypto.so.1.0.0 The top level Makefile in turn runs the build-shared target for that lib. The build-shared target depends on both do_$(SHLIB_TARGET) link-shared. When building in parallel, make is allowed to run both of these. They both run Makefile.shared for their respective targets: do_$(SHLIB_TARGET) - link_a.linux-shared - link_a.gnu - ...; $(LINK_SO_A) - $(LINK_SO) - $(SYMLINK_SO) link-shared - symlink.linux-shared - symlink.gnu - ...; $(SYMLINK_SO) The shell code for SYMLINK_SO attempts to do a [ -e lib ] check, but fails basic TOCTOU semantics. Depending on the load, that means two processes will run the sequence: rm -f libcrypto.so ln -s libcrypto.so.1.0.0 libcrypto.so Which obviously fails: ln: failed to create symbolic link 'libcrypto.so': File exists Since we know do_$(SHLIB_TARGET) will create the symlink for us, don't bother depending on link-shared at all in the top level Makefile when building things. Reported-by: Martin von Gagern martin.vgag...@gmx.net URL: https://bugs.gentoo.org/545028 --- Makefile.org | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile.org b/Makefile.org index 890bfe4..576c60e 100644 --- a/Makefile.org +++ b/Makefile.org @@ -350,7 +350,10 @@ link-shared: libs=$$libs -l$$i; \ done -build-shared: do_$(SHLIB_TARGET) link-shared +# The link target in Makefile.shared will create the symlink for us, so no need +# to call link-shared directly. Doing so will cause races with two processes +# trying to symlink the lib. +build-shared: do_$(SHLIB_TARGET) do_$(SHLIB_TARGET): @ set -e; libs='-L. $(SHLIBDEPS)'; for i in $(SHLIBDIRS); do \ -- 2.3.4 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. So add support for the standard $RC
/ $WINDRES env vars as well.
---
Configure | 3 +++
Makefile.org| 2 ++
Makefile.shared | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Configure b/Configure
index 97c2573..c137a4c 100755
--- a/Configure
+++ b/Configure
@@ -1307,6 +1307,7 @@ my $shared_ldflag = $table{$target}-{shared_ldflag};
my $shared_extension = $table{$target}-{shared_extension};
my $ranlib = $ENV{'RANLIB'} || $table{$target}-{ranlib};
my $ar = $ENV{'AR'} || ar;
+my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || windres;
my $arflags = $table{$target}-{arflags};
my $multilib = $table{$target}-{multilib};
@@ -1774,12 +1775,14 @@ while (IN)
s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/;
s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/;
s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/;
+ s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc
eq gcc;
}
else{
s/^CC=.*$/CC= $cc/;
s/^AR=\s*ar/AR= $ar/;
s/^RANLIB=.*/RANLIB= $ranlib/;
+ s/^WINDRES=.*/WINDRES= $windres/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq gcc || ($cc eq
'cc' $target =~ /darwin/);
}
s/^CFLAG=.*$/CFLAG= $cflags/;
diff --git a/Makefile.org b/Makefile.org
index f254d76..a6d9471 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -66,6 +66,7 @@ EXE_EXT=
ARFLAGS=
AR=ar $(ARFLAGS) r
RANLIB= ranlib
+WINDRES= windres
NM= nm
PERL= perl
#RM= echo --
@@ -216,6 +217,7 @@ BUILDENV= PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)'
\
CC='$(CC)' CFLAG='$(CFLAG)' \
AS='$(CC)' ASFLAG='$(CFLAG) -c' \
AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)'\
+ WINDRES='$(WINDRES)'\
CROSS_COMPILE='$(CROSS_COMPILE)'\
PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' \
SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \
diff --git a/Makefile.shared b/Makefile.shared
index babeb46..e8903ca 100644
--- a/Makefile.shared
+++ b/Makefile.shared
@@ -282,7 +282,7 @@ link_a.cygwin:
fi; \
dll_name=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \
$(PERL) util/mkrc.pl $$dll_name | \
- $(CROSS_COMPILE)windres -o rc.o; \
+ $(WINDRES) -o rc.o; \
extras=$$extras rc.o; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
--
2.3.4
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3758] [PATCH] fix malloc define typo
Reported-by: Conrad Kostecki ck+gentoobugzi...@bl4ckb0x.de
URL: https://bugs.gentoo.org/543828
---
crypto/bio/bss_dgram.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c
index aef8149..ed275d1 100644
--- a/crypto/bio/bss_dgram.c
+++ b/crypto/bio/bss_dgram.c
@@ -1338,7 +1338,7 @@ static int dgram_sctp_read(BIO *b, char *out, int outl)
(socklen_t) (sizeof(sctp_assoc_t) + 256 * sizeof(uint8_t));
authchunks = OPENSSL_malloc(optlen);
if (!authchunks) {
-BIOerr(BIO_F_DGRAM_SCTP_READ, ERR_R_MALLOC_ERROR);
+BIOerr(BIO_F_DGRAM_SCTP_READ, ERR_R_MALLOC_FAILURE);
return -1;
}
memset(authchunks, 0, optlen);
@@ -1410,7 +1410,7 @@ static int dgram_sctp_write(BIO *b, const char *in, int
inl)
char *tmp;
data-saved_message.bio = b;
if(!(tmp = OPENSSL_malloc(inl))) {
-BIOerr(BIO_F_DGRAM_SCTP_WRITE, ERR_R_MALLOC_ERROR);
+BIOerr(BIO_F_DGRAM_SCTP_WRITE, ERR_R_MALLOC_FAILURE);
return -1;
}
if (data-saved_message.data)
--
2.3.3
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3759] [PATCH] crypto: use bigint in x86-64 perl
When building on x32 systems where the default type is 32bit, make sure
we can transparently represent 64bit integers. Otherwise we end up with
build errors like:
/usr/bin/perl asm/ghash-x86_64.pl elf ghash-x86_64.s
Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xlate.pl
line 201, line 890.
...
ghash-x86_64.s: Assembler messages:
ghash-x86_64.s:890: Error: junk '.15473355479995e+19' after expression
We don't enable this globally as there are some cases where we'd get
32bit values interpreted as unsigned when we need them as signed.
Reported-by: Bertrand Jacquin bertr...@jacquin.bzh
URL: https://bugs.gentoo.org/542618
---
crypto/perlasm/x86_64-xlate.pl | 4
1 file changed, 4 insertions(+)
diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl
index aae8288..0bf9774 100755
--- a/crypto/perlasm/x86_64-xlate.pl
+++ b/crypto/perlasm/x86_64-xlate.pl
@@ -195,6 +195,10 @@ my %globals;
sub out {
my $self = shift;
+ # When building on x32 ABIs, the expanded hex value might be too
+ # big to fit into 32bits. Enable transparent 64bit support here
+ # so we can safely print it out.
+ use bigint;
if ($gas) {
# Solaris /usr/ccs/bin/as can't handle multiplications
# in $self-{value}
--
2.3.3
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3736] [PATCH] fix parallel install with dir creation
The mkdir-p.pl does not handle parallel creation of directories. This comes up when the install_sw and install_docs rules run and both call mkdir-p.pl on sibling directory trees. Instead, lets create a single install_dirs rule that makes all of the dirs we need, and have these two install steps depend on that. --- Makefile.org | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Makefile.org b/Makefile.org index 83fa45a..5f8e03d 100644 --- a/Makefile.org +++ b/Makefile.org @@ -193,7 +193,11 @@ INSTALLDIRS= \ $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl \ $(INSTALL_PREFIX)$(OPENSSLDIR)/misc \ $(INSTALL_PREFIX)$(OPENSSLDIR)/certs \ - $(INSTALL_PREFIX)$(OPENSSLDIR)/private + $(INSTALL_PREFIX)$(OPENSSLDIR)/private \ + $(INSTALL_PREFIX)$(MANDIR)/man1 \ + $(INSTALL_PREFIX)$(MANDIR)/man3 \ + $(INSTALL_PREFIX)$(MANDIR)/man5 \ + $(INSTALL_PREFIX)$(MANDIR)/man7 all: Makefile build_all openssl.pc libssl.pc libcrypto.pc @@ -548,8 +552,10 @@ install: all install_docs install_sw uninstall: uninstall_sw uninstall_docs -install_sw: +install_dirs: @$(PERL) $(TOP)/util/mkdir-p.pl $(INSTALLDIRS) + +install_sw: install_dirs @set -e; headerlist=$(EXHEADER); for i in $$headerlist;\ do \ (cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i; \ @@ -694,12 +700,7 @@ uninstall_html_docs: done; \ done -install_docs: - @$(PERL) $(TOP)/util/mkdir-p.pl \ - $(INSTALL_PREFIX)$(MANDIR)/man1 \ - $(INSTALL_PREFIX)$(MANDIR)/man3 \ - $(INSTALL_PREFIX)$(MANDIR)/man5 \ - $(INSTALL_PREFIX)$(MANDIR)/man7 +install_docs: install_dirs here=`pwd`; \ filecase=; \ case $(PLATFORM) in DJGPP|Cygwin*|mingw*|darwin*-*-cc) \ -- 2.3.1 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3737] [PATCH] fix parallel generation of obj headers
The current code has dummy sleep/touch commands to try and work around the parallel issue, but that is obviously racy. Instead lets force one of the files to depend on the other so we know they'll never run in parallel. --- crypto/objects/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/crypto/objects/Makefile b/crypto/objects/Makefile index a8aedbd..aaa8d29 100644 --- a/crypto/objects/Makefile +++ b/crypto/objects/Makefile @@ -44,11 +44,11 @@ obj_dat.h: obj_dat.pl obj_mac.h # objects.pl both reads and writes obj_mac.num obj_mac.h: objects.pl objects.txt obj_mac.num $(PERL) objects.pl objects.txt obj_mac.num obj_mac.h - @sleep 1; touch obj_mac.h; sleep 1 -obj_xref.h: objxref.pl obj_xref.txt obj_mac.num +# This doesn't really need obj_mac.h, but since that rule reads writes +# obj_mac.num, we can't run in parallel with it. +obj_xref.h: objxref.pl obj_xref.txt obj_mac.num obj_mac.h $(PERL) objxref.pl obj_mac.num obj_xref.txt obj_xref.h - @sleep 1; touch obj_xref.h; sleep 1 files: $(PERL) $(TOP)/util/files.pl Makefile $(TOP)/MINFO -- 2.3.1 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
this can be closed now since d475b2a3bfde8d4aceefb41b21acc3711893d2a8 fixed it -mike signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. So add support for the standard $RC
/ $WINDRES env vars as well.
---
Configure | 3 +++
Makefile.org| 2 ++
Makefile.shared | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Configure b/Configure
index 5dbfa6c..080cfe2 100755
--- a/Configure
+++ b/Configure
@@ -744,6 +744,7 @@ my $shared_extension = $fields[$idx_shared_extension];
my $ranlib = $ENV{'RANLIB'} || $fields[$idx_ranlib];
my $ar = $ENV{'AR'} || ar;
my $arflags = $fields[$idx_arflags];
+my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || windres;
my $multilib = $fields[$idx_multilib];
# if $prefix/lib$multilib is not an existing directory, then
@@ -1210,12 +1211,14 @@ while (IN)
s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/;
s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/;
s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/;
+ s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc
eq gcc;
}
else{
s/^CC=.*$/CC= $cc/;
s/^AR=\s*ar/AR= $ar/;
s/^RANLIB=.*/RANLIB= $ranlib/;
+ s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq gcc || ($cc eq
'cc' $target =~ /darwin/);
}
s/^CFLAG=.*$/CFLAG= $cflags/;
diff --git a/Makefile.org b/Makefile.org
index 50f7ae2..83fa45a 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -66,6 +66,7 @@ EXE_EXT=
ARFLAGS=
AR=ar $(ARFLAGS) r
RANLIB= ranlib
+WINDRES= windres
NM= nm
PERL= perl
#RM= echo --
@@ -216,6 +217,7 @@ BUILDENV= PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)'
\
CC='$(CC)' CFLAG='$(CFLAG)' \
AS='$(CC)' ASFLAG='$(CFLAG) -c' \
AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)'\
+ WINDRES='$(WINDRES)'\
CROSS_COMPILE='$(CROSS_COMPILE)'\
PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' \
SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \
diff --git a/Makefile.shared b/Makefile.shared
index babeb46..e8903ca 100644
--- a/Makefile.shared
+++ b/Makefile.shared
@@ -282,7 +282,7 @@ link_a.cygwin:
fi; \
dll_name=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \
$(PERL) util/mkrc.pl $$dll_name | \
- $(CROSS_COMPILE)windres -o rc.o; \
+ $(WINDRES) -o rc.o; \
extras=$$extras rc.o; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
--
2.3.1
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: Inconsistency in ARM support
On 26 Oct 2014 22:58, Andy Polyakov wrote: I would go with option 2. and detect the ARM architecture that we are compiling for in the configure phase and compile for it. As mentioned in another message question was not about removing run-time switch as concept, but about limiting it to ARMv=7 targets. sounds reasonable for =armv7 to do runtime detection, and for =armv6 to be compiled for the specific target. =armv5 is a deadish category (some still exist and see updates, but few), and really armv6 is only viable because of things like the raspberry pi. -mike signature.asc Description: Digital signature
Re: [openssl.org #3505] rewrite c_rehash in C
On 26 Aug 2014 19:44, Timo Teras wrote: On Tue, 26 Aug 2014 10:12:06 -0400 Salz, Rich wrote: Find a C version (which I have written) of the utility at: http://git.alpinelinux.org/cgit/aports/plain/main/openssl/c_rehash.c That's pretty cool. We'd need to modify it to not use the XXXat functions or fnmatch, but definitely something we should consider for a future release. It's fairly simple to get rid of them both. I write it originally for Linux without caring too much for portability. the XXXat functions are in POSIX and are not specific to Linux or glibc, so they are technically portable. but openssl tries to work on older/crappier systems that do not follow or stay up to date with POSIX ... -mike signature.asc Description: Digital signature
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
On Tue 16 Sep 2014 08:15:37 Andy Polyakov via RT wrote: This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s:alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? i don't understand what you mean. the code as written in the tree does not work with gcc. preproc will expand into /tmp/pid.alphacpuid.s, and since gcc will skip .s files with -E, you get no output. But if you name the file /tmp/pid.alphacpuid.s.S, then it should work. Because gcc driver looks at last extension, right? sorry, missed the .S suffix in all the noise :) i'd also highlight that relying on the pid # to give you a global unique tmp file is very very broken. it's easy for malicious people to clobber, and it's not even unique on modern Linux systems with pid namespaces. it should really just write it to $@.tmp instead and then do `mv $@ $@.tmp`. OK, preproc=$@.S then. Can you confirm that it works? that seems to work -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
On Fri 12 Sep 2014 09:44:59 Andy Polyakov via RT wrote: This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s: alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? i don't understand what you mean. the code as written in the tree does not work with gcc. preproc will expand into /tmp/pid.alphacpuid.s, and since gcc will skip .s files with -E, you get no output. i'd also highlight that relying on the pid # to give you a global unique tmp file is very very broken. it's easy for malicious people to clobber, and it's not even unique on modern Linux systems with pid namespaces. it should really just write it to $@.tmp instead and then do `mv $@ $@.tmp`. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
On Fri 12 Sep 2014 09:44:59 Andy Polyakov via RT wrote: This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s: alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? i don't understand what you mean. the code as written in the tree does not work with gcc. preproc will expand into /tmp/pid.alphacpuid.s, and since gcc will skip .s files with -E, you get no output. i'd also highlight that relying on the pid # to give you a global unique tmp file is very very broken. it's easy for malicious people to clobber, and it's not even unique on modern Linux systems with pid namespaces. it should really just write it to $@.tmp instead and then do `mv $@ $@.tmp`. -mike signature.asc Description: PGP signature
Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell
On Tue 26 Aug 2014 04:31:07 Rich Salz via RT wrote: The sad thing is, perl is widely available than posix shell. cool hack tho. i don't think that's really true. else, why is autoconf friends relying on a shell and not perl ? those see way more distribution than openssl. -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell
On Tue 26 Aug 2014 04:31:07 Rich Salz via RT wrote: The sad thing is, perl is widely available than posix shell. cool hack tho. i don't think that's really true. else, why is autoconf friends relying on a shell and not perl ? those see way more distribution than openssl. -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell
On Wed 27 Aug 2014 15:24:45 Salz, Rich via RT wrote: i don't think that's really true. else, why is autoconf friends relying on a shell and not perl ? those see way more distribution than openssl. Last I looked, autoconf doesn't use anything that really wasn't in Version 7 Bourne shell. In my comment, I deliberately used the term posix shell the proposed script uses few features and doesn't really push the limits of POSIX: - variables - if statements - for/while loops - functions - `local` - `export` - `return` - math with $((...)) - printf - $IFS - `[` test - `read` - $#/$*/$1 positionals i don't have a Version 7 shell, but wikipedia indicates those are all available But to my mind, the question is moot, since post-1.0.2 we'll almost definitely have c_rehash builtin to the openssl command. that would also work -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell
On Wed 27 Aug 2014 15:24:45 Salz, Rich via RT wrote: i don't think that's really true. else, why is autoconf friends relying on a shell and not perl ? those see way more distribution than openssl. Last I looked, autoconf doesn't use anything that really wasn't in Version 7 Bourne shell. In my comment, I deliberately used the term posix shell the proposed script uses few features and doesn't really push the limits of POSIX: - variables - if statements - for/while loops - functions - `local` - `export` - `return` - math with $((...)) - printf - $IFS - `[` test - `read` - $#/$*/$1 positionals i don't have a Version 7 shell, but wikipedia indicates those are all available But to my mind, the question is moot, since post-1.0.2 we'll almost definitely have c_rehash builtin to the openssl command. that would also work -mike signature.asc Description: PGP signature
Re: [openssl.org #1979] Add uClibc support
On Tue 01 Jul 2014 08:53:56 Tim Hudson wrote: On 30/06/2014 10:23 PM, Salz, Rich wrote: On Tue, Jul 01, 2014 at 12:25:00AM +0200, Rich Salz via RT wrote: Unsupported platform. Not having read the ticket, uClibc and newlib might be useful to support if possible since they're popular for embedded devices. They are actively used - but with a case that old and known current usage (one of the FIPS140 validated platforms is indeed uClibc based) so closing the ticket in my view is the right approach. If there is a specific issue with current releases those impacted should raise a new issue ... The specific suggested Makefile included in the RT item is also somewhat rather specific to the snapgear distribution layout ... yeah, that patch makes no sense to include. Gentoo actively builds the latest openssl on uClibc, so it's not clear to me if any changes are needed at all. i know hat openssl on nommu/Linux (which uses uClibc) has troubles with some apps because they use fork(), but that patch doesn't help there. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote: While rpaths are not needed in some contexts, they are important in others, please do not remove rpath support. Yes, such as cross-compiling or embedded systems. I think it's reasonable to make it a config option tho. eh ? rpaths are not needed when cross-compiling or for embedded. they're needed only when people are installing into non-standard paths and can't be bothered to update their ld.so.conf mechanisms to include those paths. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu 01 May 2014 13:26:48 Stephen Henson via RT wrote: On Thu May 01 12:29:58 2014, meiss...@suse.de wrote: SUSE has received a bugreport from a user, that the padding extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP- appliances-interop-issue-td66873.html Quoting from our openSUSE bugreport: Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some services, e.g. Cisco Ironport SMTP appliances. 1.0.1g not only fixes the Heartbleed bug but also adds another change by adding: #define TLSEXT_TYPE_padding 21 This in turn breaks SSL connections to e.g. Ironports, probably others: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Workaround: Force protocol to SSLv3 or recompile without the define above. Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( If you use a smaller cipherstring it should also work without having to force SSLv3. The padding extension is only used if the ClientHello would be between 256 and 511 bytes in length so if you reduce the number of ciphersuites it wont be used. maybe a quick system would be useful. the default behavior is to do the right thing, but through a series of env vars, quirks can be injected at the right place ? then there is no wishy/washy behavior where we try to appease every broken system out there simultaneously. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Mon 16 Jun 2014 06:39:40 Viktor Dukhovni wrote: On Mon, Jun 16, 2014 at 02:10:14AM -0400, Mike Frysinger wrote: On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote: While rpaths are not needed in some contexts, they are important in others, please do not remove rpath support. Yes, such as cross-compiling or embedded systems. I think it's reasonable to make it a config option tho. eh ? rpaths are not needed when cross-compiling or for embedded. they're needed only when people are installing into non-standard paths and can't be bothered to update their ld.so.conf mechanisms to include those paths. can't be bothered is a rather loaded term. Sometimes it is a bad idea to force every application on a system to look for libraries in a location needed by just one. We should acknowledge that rpaths are sometimes useful. s/sometimes/rarely/ even then, it's trivial to keep this behavior -- set LDFLAGS yourself to your non-standard paths. i don't think using rpath is a sane default. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Fri 06 Jun 2014 09:15:09 Kurt Roeckx via RT wrote: On Fri, Jun 06, 2014 at 01:27:02AM -0400, Mike Frysinger wrote: On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote: On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote: It's a standard setting that other build systems use. Can you explain why you need this? because people want to set custom linker flags. `man ld` shows quite a large number that can easily be applied such as extra hardening or optimization. I ended up using the cflags in Configure for that. that would workaround the problem, but my goal is to fix things :) -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Fri 06 Jun 2014 09:15:09 Kurt Roeckx via RT wrote: On Fri, Jun 06, 2014 at 01:27:02AM -0400, Mike Frysinger wrote: On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote: On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote: It's a standard setting that other build systems use. Can you explain why you need this? because people want to set custom linker flags. `man ld` shows quite a large number that can easily be applied such as extra hardening or optimization. I ended up using the cflags in Configure for that. that would workaround the problem, but my goal is to fix things :) -mike signature.asc Description: PGP signature
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote:
On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote:
It's a standard setting that other build systems use.
Can you explain why you need this?
because people want to set custom linker flags. `man ld` shows quite a large
number that can easily be applied such as extra hardening or optimization.
@@ -217,6 +217,7 @@ BUILDENV= PLATFORM='$(PLATFORM)'
PROCESSOR='$(PROCESSOR)' \
MAKEDEPEND='{TOP}/util/domd {TOP} -MD $(MAKEDEPPROG)' \
DEPFLAG='-DOPENSSL_NO_DEPRECATED $(DEPFLAG)' \
MAKEDEPPROG='$(MAKEDEPPROG)' \
+ LDFLAGS='${LDFLAGS}' \
I'm wondering whether it would be better to remove LDFLAGS from CLEARENV (a
few lines before the above), rather than add it to BUILDENV? Thoughts? Or
am I missing something?
maybe. i find it really hard to understand what the Makefiles are going for
in general, so i don't try to start at them too hard.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote:
On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote:
It's a standard setting that other build systems use.
Can you explain why you need this?
because people want to set custom linker flags. `man ld` shows quite a large
number that can easily be applied such as extra hardening or optimization.
@@ -217,6 +217,7 @@ BUILDENV= PLATFORM='$(PLATFORM)'
PROCESSOR='$(PROCESSOR)' \
MAKEDEPEND='{TOP}/util/domd {TOP} -MD $(MAKEDEPPROG)' \
DEPFLAG='-DOPENSSL_NO_DEPRECATED $(DEPFLAG)' \
MAKEDEPPROG='$(MAKEDEPPROG)' \
+ LDFLAGS='${LDFLAGS}' \
I'm wondering whether it would be better to remove LDFLAGS from CLEARENV (a
few lines before the above), rather than add it to BUILDENV? Thoughts? Or
am I missing something?
maybe. i find it really hard to understand what the Makefiles are going for
in general, so i don't try to start at them too hard.
-mike
signature.asc
Description: PGP signature
Re: [openssl.org #3332] [PATCH] fix pkg-config generation
On Mon, May 5, 2014 at 9:37 AM, Viktor Dukhovni wrote: On Sun, May 04, 2014 at 11:59:55PM +0100, Matt Caswell wrote: As far as I understand if you want to have both -lssl -lcrypto you should use openssl instead of libssl? Anyway, I think this makes perfect sense and if things break it's easy enough to fix it. I'd be interested to hear what other people think about this. I have to say I was in two minds about it. The OpenSSL documentation does not indicate which -l option provides a particular function. Here are some of the more commonly used whose origin is not necessarily obvious ... I can dig up more reasons why few realistic applications can get by with explicit linkage to libssl alone. Since even those that only directly drag in symbols from libssl still ultimately depend on libcrypto, the cost of explicitly including -lcrypto seems to me to be outweighed by the benefit of making life easier for users by always providing both. What is the motivation to attempt to avoid -lcrypto here? in case people don't actually know what is going on, openssl provides *three* pkg-config files: libssl.pc libcrypto.pc openssl.pc if you want to link against openssl and not worry about which libraries are required, then just use `pkg-config --libs openssl`. i am merely fixing `pkg-config --libs libssl` to not output -lcrypto all the time since people aren't asking for libcrypto here -- they're asking for libssl. my patch also fixes openssl.pc to use proper dependency lines instead of hand duplicating information already found in libssl.pc and libcrypto.pc. even if people want to keep -lcrypto in libssl.pc (even though it makes no sense), that second hunk in my patch changes nothing from the end user's point of view -- it just cleans up the internals of the generated pkg-config files. -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3332] [PATCH] fix pkg-config generation
On Mon 05 May 2014 00:36:57 Matt Caswell via RT wrote: This patch changes the output of pkg-config --libs libssl from: -L/usr/local/ssl/lib -lssl -lcrypto to: -L/usr/local/ssl/lib -lssl Arguably this is the strictly correct approach. However in practice I suspect many build scripts will rely on this behaviour and break as a result of this change. I'm not sure its worth it for slightly cleaner .pc files. For that reason I am rejecting this patch in its current form. i don't understand your logic. first, pkg-config files are a bit new, so the number of packages utilizing them are low at this point. the ones that i have personally converted upstream are doing the right thing. the only way this would break is if you were using pkg-config wrongly and trying to build static programs w/out the --static flag to pkg-config. but then again, you'd break with a lot more things than just openssl. finally, i've been using this patch in Gentoo since openssl first added .pc files. we have yet to see a package fail to build here. so trying to protect unknown broken build systems from being broken to the detriment of correct working build systems makes no sense. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3332] [PATCH] fix pkg-config generation
On Mon 05 May 2014 00:36:57 Matt Caswell via RT wrote: This patch changes the output of pkg-config --libs libssl from: -L/usr/local/ssl/lib -lssl -lcrypto to: -L/usr/local/ssl/lib -lssl Arguably this is the strictly correct approach. However in practice I suspect many build scripts will rely on this behaviour and break as a result of this change. I'm not sure its worth it for slightly cleaner .pc files. For that reason I am rejecting this patch in its current form. i don't understand your logic. first, pkg-config files are a bit new, so the number of packages utilizing them are low at this point. the ones that i have personally converted upstream are doing the right thing. the only way this would break is if you were using pkg-config wrongly and trying to build static programs w/out the --static flag to pkg-config. but then again, you'd break with a lot more things than just openssl. finally, i've been using this patch in Gentoo since openssl first added .pc files. we have yet to see a package fail to build here. so trying to protect unknown broken build systems from being broken to the detriment of correct working build systems makes no sense. -mike signature.asc Description: PGP signature
[openssl.org #3331] [PATCH] respect LDFLAGS during build
It's a standard setting that other build systems use.
---
Makefile.org| 1 +
Makefile.shared | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.org b/Makefile.org
index e7f6e5b..991a439 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -217,6 +217,7 @@ BUILDENV= PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)'
\
MAKEDEPEND='{TOP}/util/domd {TOP} -MD $(MAKEDEPPROG)' \
DEPFLAG='-DOPENSSL_NO_DEPRECATED $(DEPFLAG)'\
MAKEDEPPROG='$(MAKEDEPPROG)'\
+ LDFLAGS='${LDFLAGS}'\
SHARED_LDFLAGS='$(SHARED_LDFLAGS)' \
KRB5_INCLUDES='$(KRB5_INCLUDES)' LIBKRB5='$(LIBKRB5)' \
ZLIB_INCLUDE='$(ZLIB_INCLUDE)' LIBZLIB='$(LIBZLIB)' \
diff --git a/Makefile.shared b/Makefile.shared
index e753f44..53c3a64 100644
--- a/Makefile.shared
+++ b/Makefile.shared
@@ -153,7 +153,7 @@ DO_GNU_SO=$(CALC_VERSIONS); \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
SHAREDFLAGS=$(CFLAGS) $(SHARED_LDFLAGS) -shared -Wl,-Bsymbolic
-Wl,-soname=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX
-DO_GNU_APP=LDFLAGS=$(CFLAGS) -Wl,-rpath,$(LIBRPATH)
+DO_GNU_APP=LDFLAGS=$(LDFLAGS) $(CFLAGS)
#This is rather special. It's a special target with which one can link
#applications without bothering with any features that have anything to
--
1.9.2
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3332] [PATCH] fix pkg-config generation
Have the .pc files depend on each other rather than duplicating the
various link settings.
---
Makefile.org | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/Makefile.org b/Makefile.org
index 991a439..c9a7253 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -468,11 +468,11 @@ libssl.pc: Makefile
echo 'libdir=$${exec_prefix}/$(LIBDIR)'; \
echo 'includedir=$${prefix}/include'; \
echo ''; \
- echo 'Name: OpenSSL'; \
+ echo 'Name: OpenSSL-libssl'; \
echo 'Description: Secure Sockets Layer and cryptography
libraries'; \
echo 'Version: '$(VERSION); \
- echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
+ echo 'Requires.private: libcrypto'; \
+ echo 'Libs: -L$${libdir} -lssl'; \
echo 'Libs.private: $(EX_LIBS)'; \
echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) libssl.pc
@@ -485,10 +485,7 @@ openssl.pc: Makefile
echo 'Name: OpenSSL'; \
echo 'Description: Secure Sockets Layer and cryptography libraries
and tools'; \
echo 'Version: '$(VERSION); \
- echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
- echo 'Libs.private: $(EX_LIBS)'; \
- echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) openssl.pc
+ echo 'Requires: libssl libcrypto' ) openssl.pc
Makefile: Makefile.org Configure config
@echo Makefile is older than Makefile.org, Configure or config.
--
1.9.2
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- crypto/Makefile | 4 +--- crypto/bn/Makefile| 4 +--- crypto/modes/Makefile | 5 + crypto/sha/Makefile | 4 +--- 4 files changed, 4 insertions(+), 13 deletions(-) diff --git a/crypto/Makefile b/crypto/Makefile index 0537913..6faa9c7 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -86,9 +86,7 @@ ia64cpuid.s: ia64cpuid.S;$(CC) $(CFLAGS) -E ia64cpuid.S $@ ppccpuid.s:ppccpuid.pl;$(PERL) ppccpuid.pl $(PERLASM_SCHEME) $@ pariscid.s:pariscid.pl;$(PERL) pariscid.pl $(PERLASM_SCHEME) $@ alphacpuid.s: alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null subdirs: @target=all; $(RECURSIVE_MAKE) diff --git a/crypto/bn/Makefile b/crypto/bn/Makefile index 9eae43f..bb43706 100644 --- a/crypto/bn/Makefile +++ b/crypto/bn/Makefile @@ -136,9 +136,7 @@ ppc-mont.s: asm/ppc-mont.pl;$(PERL) asm/ppc-mont.pl $(PERLASM_SCHEME) $@ ppc64-mont.s: asm/ppc64-mont.pl;$(PERL) asm/ppc64-mont.pl $(PERLASM_SCHEME) $@ alpha-mont.s: asm/alpha-mont.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) asm/alpha-mont.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null # GNU make catch all %-mont.S: asm/%-mont.pl; $(PERL) $ $(PERLASM_SCHEME) $@ diff --git a/crypto/modes/Makefile b/crypto/modes/Makefile index b8cfa71..b0d5b9f 100644 --- a/crypto/modes/Makefile +++ b/crypto/modes/Makefile @@ -55,10 +55,7 @@ aesni-gcm-x86_64.s: asm/aesni-gcm-x86_64.pl ghash-sparcv9.s: asm/ghash-sparcv9.pl $(PERL) asm/ghash-sparcv9.pl $@ $(CFLAGS) ghash-alpha.s: asm/ghash-alpha.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) asm/ghash-alpha.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) - + $(PERL) $ | $(CC) -E - | tee $@ /dev/null ghash-parisc.s:asm/ghash-parisc.pl $(PERL) asm/ghash-parisc.pl $(PERLASM_SCHEME) $@ diff --git a/crypto/sha/Makefile b/crypto/sha/Makefile index 64eab6c..63fba69 100644 --- a/crypto/sha/Makefile +++ b/crypto/sha/Makefile @@ -60,9 +60,7 @@ sha256-armv4.S: asm/sha256-armv4.pl $(PERL) $ $(PERLASM_SCHEME) $@ sha1-alpha.s: asm/sha1-alpha.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) asm/sha1-alpha.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null # Solaris make has to be explicitly told sha1-x86_64.s: asm/sha1-x86_64.pl; $(PERL) asm/sha1-x86_64.pl $(PERLASM_SCHEME) $@ -- 1.9.2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Sun 27 Apr 2014 14:08:12 Kurt Roeckx via RT wrote: -DO_GNU_APP=LDFLAGS=$(CFLAGS) -Wl,-rpath,$(LIBRPATH) +DO_GNU_APP=LDFLAGS=$(LDFLAGS) $(CFLAGS) Shouldn't that be this? +DO_GNU_APP=LDFLAGS=$(LDFLAGS) -Wl,-rpath,$(LIBRPATH) i didn't mean to include dropping of the rpath in this change. it should be: DO_GNU_APP=LDFLAGS=$(LDFLAGS) $(CFLAGS) -Wl,-rpath,$(LIBRPATH) But then I think think that we shouldn't have rpaths in the first place, so I wouldn't have a problem with removing the rpath. yeah, in most systems it's pointless. guess it should be made into a configure flag if people want to continue supporting it. -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Sun 27 Apr 2014 14:08:12 Kurt Roeckx via RT wrote: -DO_GNU_APP=LDFLAGS=$(CFLAGS) -Wl,-rpath,$(LIBRPATH) +DO_GNU_APP=LDFLAGS=$(LDFLAGS) $(CFLAGS) Shouldn't that be this? +DO_GNU_APP=LDFLAGS=$(LDFLAGS) -Wl,-rpath,$(LIBRPATH) i didn't mean to include dropping of the rpath in this change. it should be: DO_GNU_APP=LDFLAGS=$(LDFLAGS) $(CFLAGS) -Wl,-rpath,$(LIBRPATH) But then I think think that we shouldn't have rpaths in the first place, so I wouldn't have a problem with removing the rpath. yeah, in most systems it's pointless. guess it should be made into a configure flag if people want to continue supporting it. -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] libssl: Hide library private symbols
On Thursday 25 July 2013 13:48:20 Kurt Roeckx wrote: I've submitted a patch in 2007 to make as much as possible static, but it never got applied, so I never bothered writing a patch to make the rest hidden. I think making things static is even better than hiding them, and should work on all platforms. It's just that you can't making everything that isn't public static. i think these patches are complementary. mark everything static where possible, and additionally mark everything hidden. but i guess hopes of getting these merged are a pipe dream :/ -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3145] openssl auto install to /usr/local/lib64
On Sunday 20 October 2013 10:40:10 Kx Mp via RT wrote: when install target folder have lib64 folder it will auto install into lib64 rather than lib folder what exactly is the suggestion ? there is a --libdir configure flag to set the path as needed. trying to add logic to guess what the right path is for the active toolchain tends to be fragile and toolchain specific. that's quite a lot of junk code for no real gain. if you want to install into lib64, then pass --libdir=lib64. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] armcap.c: use getauxv on glibc to find caps
On Sunday 15 September 2013 18:30:32 Yuriy Kaminskiy wrote: Cristian Rodríguez wrote: El 12/09/13 14:17, Yuriy Kaminskiy escribió: This will break on glibc-3.0. #if defined(__GLIBC_PREREQ) __GLIBC_PREREQ(2, 16) Yes, that is the correct way, but ensure features.h is being included. (it seems this patch will be rejected for different reasons anyway, but to avoid replicating bad recipes...) ... unfortunately, condition above won't work properly too, sorry :-( When __GLIBC_PREREQ is not defined, preprocessor will error out. So, it should be either #if defined(__GLIBC__) ((__GLIBC__16) | __GLIBC_MINOR__) = ((216) | 16) or nest the ifdefs #ifdef __GLIBC_PREREQ # if __GLIBC_PREREQ(...) -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] armcap.c: use getauxv on glibc to find caps
On Friday 13 September 2013 16:27:03 Green, Paul wrote: Cristian Rodríguez wrote: El 12/09/13 14:17, Yuriy Kaminskiy escribió: This will break on glibc-3.0. #if defined(__GLIBC_PREREQ) __GLIBC_PREREQ(2, 16) Yes, that is the correct way, but ensure features.h is being included. As a compiler implementer, I must object. The universal convention is that symbols starting with a double-underscore are for the implementation's use, not for use by end-user software. Please stop reading the headers and trying to figure out how the implementation-specific macros work. Stay with the documented macros. If you are concerned about compiler or runtime bugs, write a configure test for them, like any other feature. Don't put these hacks into the source code. it isn't a compiler feature, it's a C library feature that said, a simple check for the sys/auxv.h header is sufficient. if openssl even has the build tooling to support headers like that. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] armcap.c: use getauxv on glibc to find caps
On Wednesday 11 September 2013 10:49:36 Kyle McMartin wrote: +#if defined(__GNUC__) __GNUC__=2 +void OPENSSL_cpuid_setup(void) __attribute__((constructor)); +#endif +void OPENSSL_cpuid_setup(void) this can be made simpler: #if defined(__GNUC__) __GNUC__=2 __attribute__((constructor)) #endif void OPENSSL_cpuid_setup(void) -mike signature.asc Description: This is a digitally signed message part.
Re: parallel make broken
On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: While building openssl-1.0.1e I noticed that the parallel build is broken. yes, it's pretty much always been broken I found this patch on the net: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl /fi les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine in parallel. heh, you've found me! the referenced ticket says it's been merged, but it doesn't seem that way (at least for the latest branch). You are right it hasn't been merged. One problem with it is it doesn't work with BSD make (BSD make doesn't understand | in dependencies). true, but the patch posted to RT didn't include that, and that usage shows up only twice in the current Gentoo patch. plenty of the other parts can be merged now so it's not nearly as terrible. i wonder if the | can be written instead like: lib: $(MAKE) subdirs $(MAKE) $(LIB) @touch lib $(LIB): $(LIBOBJ) ... -mike signature.asc Description: This is a digitally signed message part.
Re: parallel make broken
On Saturday 22 June 2013 15:07:49 Ben Laurie wrote: On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: While building openssl-1.0.1e I noticed that the parallel build is broken. yes, it's pretty much always been broken I found this patch on the net: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/open ssl /fi les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine in parallel. heh, you've found me! the referenced ticket says it's been merged, but it doesn't seem that way (at least for the latest branch). You are right it hasn't been merged. One problem with it is it doesn't work with BSD make (BSD make doesn't understand | in dependencies). true, but the patch posted to RT didn't include that, and that usage shows up only twice in the current Gentoo patch. plenty of the other parts can be merged now so it's not nearly as terrible. i wonder if the | can be written instead like: lib: $(MAKE) subdirs $(MAKE) $(LIB) @touch lib $(LIB): $(LIBOBJ) ... I don't know, but FWIW, I've also been working on -j stuff, but using the mk1mf script (see the GitConfigure and GitMake scripts in master and 1.0.2). My version is at least twice as fast as yours - on my machine :-) to be fair, i was just trying to make it work rather than rewrite things unfortunately mk1mf is a perl script, and i've been doing my damnedest to make sure perl isn't a requirement to build a base system. we've been able to avoid this so far w/openssl ... Possibly the right answer is to simply move to a single makefile... that might work -mike signature.asc Description: This is a digitally signed message part.
Re: parallel make broken
On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: While building openssl-1.0.1e I noticed that the parallel build is broken. yes, it's pretty much always been broken I found this patch on the net: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/fi les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine in parallel. heh, you've found me! the referenced ticket says it's been merged, but it doesn't seem that way (at least for the latest branch). the feedback loop w/the rt tracker has been kind of bad, so i lose incentive to fix keep posting patches. the other thing you should do is to run: make -j1 depend make -jN -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3036] openssl-0.9.8y config removes symbolic link /dev/null on Solaris
On Friday 03 May 2013 12:56:41 Mitch Halmu via RT wrote: When running the config script on Solaris 9 (sparc), the symbolic link /dev/null - /devices/pseudo/mm@0:null is destroyed. You will notice it happened by the error messages that start spewing. To repair: # ln -s /devices/pseudo/mm@0:null /dev/null Workaround: comment out the following lines before running config: #($CC -Wa,--help -c -o /dev/null -x assembler /dev/null 21 | \ # grep \\--noexecstack) 21 /dev/null \ # options=$options -Wa,--noexecstack that is a bug in the compiler/assembler. it should only unlink ordinary files. -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: IPv6 in openssl
On Tuesday 09 April 2013 09:56:59 Quanah Gibson-Mount wrote: --On Tuesday, April 09, 2013 4:43 PM +0530 Balakumaran Kannan wrote: I recently joined Openssl mailing list. Currently I'm trying to implement IPv6 support to openssl binary (s_server and s_client) as part of my work. I saw already few threads in the mailing list archives asking about IPv6 support. But still it is not fully implemented. Can I know is there any specific reason not to support IPv6 in openssl and if I send my patch will it be considered? There is already a patch that does this. Why re-invent the wheel? But I agree, it would be nice if it would be added to the product so people don't have to patch it. We require the ability to be able to use s_client to test IPv6, and it's a pain having to manually patch OpenSSL for this every release. it'd be nice if the patch was merged http://rt.openssl.org/Ticket/Display.html?id=2051 -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
i've improved the original patch to make the -4/-6 behavior consistent across
the tools. i also tweaked the behavior slightly to make it run correctly
(imo).
-mike
http://rt.openssl.org/Ticket/Display.html?id=2051
user/pass: guest/guest
Index: apps/s_apps.h
===
RCS file: /v/openssl/cvs/openssl/apps/s_apps.h,v
retrieving revision 1.21.2.1
diff -u -r1.21.2.1 s_apps.h
--- apps/s_apps.h 4 Sep 2009 17:42:04 - 1.21.2.1
+++ apps/s_apps.h 28 Dec 2011 00:28:14 -
@@ -148,7 +148,7 @@
#define PORT_STR4433
#define PROTOCOLtcp
-int do_server(int port, int type, int *ret, int (*cb) (char *hostname, int s, unsigned char *context), unsigned char *context);
+int do_server(int port, int type, int *ret, int (*cb) (char *hostname, int s, unsigned char *context), unsigned char *context, int use_ipv4, int use_ipv6);
#ifdef HEADER_X509_H
int MS_CALLBACK verify_callback(int ok, X509_STORE_CTX *ctx);
#endif
@@ -156,7 +156,7 @@
int set_cert_stuff(SSL_CTX *ctx, char *cert_file, char *key_file);
int set_cert_key_stuff(SSL_CTX *ctx, X509 *cert, EVP_PKEY *key);
#endif
-int init_client(int *sock, char *server, int port, int type);
+int init_client(int *sock, char *server, int port, int type, int use_ipv4, int use_ipv6);
int should_retry(int i);
int extract_port(char *str, short *port_ptr);
int extract_host_port(char *str,char **host_ptr,unsigned char *ip,short *p);
Index: apps/s_client.c
===
RCS file: /v/openssl/cvs/openssl/apps/s_client.c,v
retrieving revision 1.123.2.6.2.10
diff -u -r1.123.2.6.2.10 s_client.c
--- apps/s_client.c 14 Dec 2011 22:18:02 - 1.123.2.6.2.10
+++ apps/s_client.c 28 Dec 2011 00:28:14 -
@@ -285,6 +285,10 @@
{
BIO_printf(bio_err,usage: s_client args\n);
BIO_printf(bio_err,\n);
+ BIO_printf(bio_err, -4 - use IPv4 only\n);
+#if OPENSSL_USE_IPV6
+ BIO_printf(bio_err, -6 - use IPv6 only\n);
+#endif
BIO_printf(bio_err, -host host - use -connect instead\n);
BIO_printf(bio_err, -port port - use -connect instead\n);
BIO_printf(bio_err, -connect host:port - who to connect to (default is %s:%s)\n,SSL_HOST_NAME,PORT_STR);
@@ -564,6 +567,7 @@
int sbuf_len,sbuf_off;
fd_set readfds,writefds;
short port=PORT;
+ int use_ipv4, use_ipv6;
int full_log=1;
char *host=SSL_HOST_NAME;
char *cert_file=NULL,*key_file=NULL;
@@ -609,7 +613,11 @@
#endif
char *sess_in = NULL;
char *sess_out = NULL;
- struct sockaddr peer;
+#if OPENSSL_USE_IPV6
+ struct sockaddr_storage peer;
+#else
+ struct sockaddr_in peer;
+#endif
int peerlen = sizeof(peer);
int enable_timeouts = 0 ;
long socket_mtu = 0;
@@ -630,6 +638,12 @@
meth=SSLv2_client_method();
#endif
+ use_ipv4 = 1;
+#if OPENSSL_USE_IPV6
+ use_ipv6 = 1;
+#else
+ use_ipv6 = 0;
+#endif
apps_startup();
c_Pause=0;
c_quiet=0;
@@ -951,6 +961,18 @@
jpake_secret = *++argv;
}
#endif
+ else if (strcmp(*argv,-4) == 0)
+ {
+ use_ipv4 = 1;
+ use_ipv6 = 0;
+ }
+#if OPENSSL_USE_IPV6
+ else if (strcmp(*argv,-6) == 0)
+ {
+ use_ipv4 = 0;
+ use_ipv6 = 1;
+ }
+#endif
#ifndef OPENSSL_NO_SRTP
else if (strcmp(*argv,-use_srtp) == 0)
{
@@ -1259,7 +1276,7 @@
re_start:
- if (init_client(s,host,port,socket_type) == 0)
+ if (init_client(s,host,port,socket_type,use_ipv4,use_ipv6) == 0)
{
BIO_printf(bio_err,connect:errno=%d\n,get_last_socket_error());
SHUTDOWN(s);
@@ -1285,7 +1302,7 @@
{
sbio=BIO_new_dgram(s,BIO_NOCLOSE);
- if (getsockname(s, peer, (void *)peerlen) 0)
+ if (getsockname(s, (struct sockaddr *)peer, (void *)peerlen) 0)
{
BIO_printf(bio_err, getsockname:errno=%d\n,
get_last_socket_error());
===
RCS file: /v/openssl/cvs/openssl/apps/s_server.c,v
retrieving revision 1.136.2.15.2.13
diff -u -r1.136.2.15.2.13 s_server.c
--- apps/s_server.c 27 Dec 2011 14:23:22 - 1.136.2.15.2.13
+++ apps/s_server.c 28 Dec 2011 00:28:14 -
@@ -558,6 +558,10 @@
# endif
BIO_printf(bio_err, -use_srtp profiles - Offer SRTP key management with a colon-separated profile list);
#endif
+ BIO_printf(bio_err, -4- use IPv4 only\n);
+#if OPENSSL_USE_IPV6
+ BIO_printf(bio_err, -6- use IPv6 only\n);
+#endif
BIO_printf(bio_err, -keymatexport label - Export keying material using label\n);
BIO_printf(bio_err, -keymatexportlen len - Export len bytes of keying material (default 20)\n);
}
@@ -943,6 +947,7 @@
int state=0;
const SSL_METHOD *meth=NULL;
int socket_type=SOCK_STREAM;
+ int use_ipv4, use_ipv6;
ENGINE *e=NULL;
char *inrand=NULL;
int s_cert_format = FORMAT_PEM, s_key_format = FORMAT_PEM;
@@ -981,6 +986,12 @@
/* #error no SSL version enabled */
#endif
+ use_ipv4 = 1;
+#if OPENSSL_USE_IPV6
+ use_ipv6 = 1;
+#else
+ use_ipv6 = 0;
+#endif
local_argc=argc;
local_argv=argv;
@@ -1329,6 +1340,18 @@
Re: OpenSSL 1.0.1 released
On Thursday 15 March 2012 03:19:07 Ludwig Nussel wrote: Dr. Stephen Henson wrote: On Wed, Mar 14, 2012, Mike Frysinger wrote: i'm not looking for downstream workarounds here but rather the right answer. is openssl-1.0.1 expected to be ABI compatible with openssl-1.0.0 ? Yes. In brief the versioning scheme introduced with 1.0.0 is: Changes to last letter: security and bugfix only, no new features. E.g. 1.0.0-1.0.0a Changes to last number: new ABI compatible features. E.g. 1.0.0-1.0.1 Changes to middle number: major release, ABI compatibility not guaranteed. E.g. 1.0.0-1.1.0 btw, are there any plans to use symbol versioning on systems that support it? as long as it's backwards compatible in the minor versions, symbol versioning isn't necessary. if you want to do across 1.x, then you'd prob need symbol versioning, but getting past minor version incompatibles is a huge improvement. -mike signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.1 released
On Wednesday 14 March 2012 11:09:22 OpenSSL wrote: OpenSSL version 1.0.1 released === http://www.openssl.org/source/exp/CHANGES. The most significant changes are: o TLS/DTLS heartbeat support. o SCTP support. o RFC 5705 TLS key material exporter. o RFC 5764 DTLS-SRTP negotiation. o Next Protocol Negotiation. o PSS signatures in certificates, requests and CRLs. o Support for password based recipient info for CMS. o Support TLS v1.2 and TLS v1.1. o Preliminary FIPS capability for unvalidated 2.0 FIPS module. o SRP support. i don't see mention of ABI compat changes, and it seems to not be compatible. did someone forget to update the version string in crypto/opensslv.h ? it still says 1.0.0 ... -mike signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.1 released
On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote: On Wed, Mar 14, 2012, Mike Frysinger wrote: On Wednesday 14 March 2012 11:09:22 OpenSSL wrote: OpenSSL version 1.0.1 released === http://www.openssl.org/source/exp/CHANGES. The most significant changes are: o TLS/DTLS heartbeat support. o SCTP support. o RFC 5705 TLS key material exporter. o RFC 5764 DTLS-SRTP negotiation. o Next Protocol Negotiation. o PSS signatures in certificates, requests and CRLs. o Support for password based recipient info for CMS. o Support TLS v1.2 and TLS v1.1. o Preliminary FIPS capability for unvalidated 2.0 FIPS module. o SRP support. i don't see mention of ABI compat changes, and it seems to not be compatible. did someone forget to update the version string in crypto/opensslv.h ? it still says 1.0.0 ... Can you be more specific about seems to not be compatible. if the versions were compatible, there should be no warning when running apps with openssl-1.0.1 that were built against openssl-1.0.0*. but there is: OpenSSL version mismatch. Built against 105f, you have 1000100f -mike signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.1 released
On Wednesday 14 March 2012 14:36:09 Dr. Stephen Henson wrote: On Wed, Mar 14, 2012, Mike Frysinger wrote: On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote: On Wed, Mar 14, 2012, Mike Frysinger wrote: On Wednesday 14 March 2012 11:09:22 OpenSSL wrote: OpenSSL version 1.0.1 released === http://www.openssl.org/source/exp/CHANGES. The most significant changes are: o TLS/DTLS heartbeat support. o SCTP support. o RFC 5705 TLS key material exporter. o RFC 5764 DTLS-SRTP negotiation. o Next Protocol Negotiation. o PSS signatures in certificates, requests and CRLs. o Support for password based recipient info for CMS. o Support TLS v1.2 and TLS v1.1. o Preliminary FIPS capability for unvalidated 2.0 FIPS module. o SRP support. i don't see mention of ABI compat changes, and it seems to not be compatible. did someone forget to update the version string in crypto/opensslv.h ? it still says 1.0.0 ... Can you be more specific about seems to not be compatible. if the versions were compatible, there should be no warning when running apps with openssl-1.0.1 that were built against openssl-1.0.0*. but there is: OpenSSL version mismatch. Built against 105f, you have 1000100f What is producing that warning? $ ssh-keygen -l OpenSSL version mismatch. Built against 105f, you have 1000100f -mike signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.1 released
On Wednesday 14 March 2012 17:18:19 Kurt Roeckx wrote: On Wed, Mar 14, 2012 at 02:30:29PM -0400, Mike Frysinger wrote: On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote: On Wed, Mar 14, 2012, Mike Frysinger wrote: On Wednesday 14 March 2012 11:09:22 OpenSSL wrote: OpenSSL version 1.0.1 released === http://www.openssl.org/source/exp/CHANGES. The most significant changes are: o TLS/DTLS heartbeat support. o SCTP support. o RFC 5705 TLS key material exporter. o RFC 5764 DTLS-SRTP negotiation. o Next Protocol Negotiation. o PSS signatures in certificates, requests and CRLs. o Support for password based recipient info for CMS. o Support TLS v1.2 and TLS v1.1. o Preliminary FIPS capability for unvalidated 2.0 FIPS module. o SRP support. i don't see mention of ABI compat changes, and it seems to not be compatible. did someone forget to update the version string in crypto/opensslv.h ? it still says 1.0.0 ... Can you be more specific about seems to not be compatible. if the versions were compatible, there should be no warning when running apps with openssl-1.0.1 that were built against openssl-1.0.0*. but there is: OpenSSL version mismatch. Built against 105f, you have 1000100f As far as I know, we disabled most such checks in Debian because they're not really useful. I can change the ABI without changing the version, or have the same ABI with a different version. If it's not compatible the soname should have changed. The appliation shouldn't go and second guess that it's really compatible or not. And if the soname stays the same but the ABI is not compatible, we also have ways to deal with that. i'm not looking for downstream workarounds here but rather the right answer. is openssl-1.0.1 expected to be ABI compatible with openssl-1.0.0 ? there was nothing in the notes that i saw, and this is a significant change in behavior from how openssl has loong operated. and it wouldn't be the first time that a new openssl release had bugs in it including forgetting to update the version number (which i've reported before) or can't even compile for some targets due to files missing from the release tarball. if, indeed, openssl has started down the enlightened ABI compatible path, then i can work on fixing relevant packages that do runtime version sanity checks such as openssh. but i haven't heard an answer in either direction as to the openssl behavior: it's a bug or it's correct behavior. -mike signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.1 released
On Wednesday 14 March 2012 19:23:14 Dr. Stephen Henson wrote: On Wed, Mar 14, 2012, Mike Frysinger wrote: i'm not looking for downstream workarounds here but rather the right answer. is openssl-1.0.1 expected to be ABI compatible with openssl-1.0.0 ? Yes. In brief the versioning scheme introduced with 1.0.0 is: Changes to last letter: security and bugfix only, no new features. E.g. 1.0.0-1.0.0a Changes to last number: new ABI compatible features. E.g. 1.0.0-1.0.1 Changes to middle number: major release, ABI compatibility not guaranteed. E.g. 1.0.0-1.1.0 This is the first feature release that has been done since he versioning scheme changed so there may be some issues to iron out... thanks. i've posted a report for the openssh guys. https://bugzilla.mindrot.org/show_bug.cgi?id=1991 -mike signature.asc Description: This is a digitally signed message part.
[openssl.org #2645] [patch] fix up lib handling in pkg-config files
the current generated .pc files dump all libraries into the Libs: section.
this is incorrect: only the main library should be listed there while all
others should be listed under Libs.private. in other words, if people want
to use libcrypto, they should just link with -lcrypto by default. if they
want to link statically, then they'd have to link all the other libs. this is
what the split between Libs and Libs.private does for you.
also, rather than hardcoding the sublibs in the higher pkg-config files (i.e.
inlining the contents of libcrypto into libssl), use the Requires fields.
attached patch against openssl-1.0.0e (and seems to apply cleanly to current
CVS) should fix all these issues.
now we get the output we want:
$ pkg-config --libs libcrypto
-lcrypto
$ pkg-config --libs libssl
-lssl
$ pkg-config --libs openssl
-lssl -lcrypto
then when linking in statically, we get the extra stuff:
$ pkg-config --libs --static libcrypto
-lcrypto -lgmp -ldl -lz
$ pkg-config --libs --static libssl
-lssl -lcrypto -lgmp -ldl -lz
$ pkg-config --libs --static openssl
-lssl -lcrypto -lgmp -ldl -lz
as compared to the current pkg-config files which has the --libs output look
exactly the same as --libs --static
-mike
move internal libraries to .private fields so that the default
--libs output matches only what we need
--- a/Makefile.org
+++ b/Makefile.org
@@ -325,7 +325,8 @@ libcrypto.pc: Makefile
echo 'Description: OpenSSL cryptography library'; \
echo 'Version: '$(VERSION); \
echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lcrypto $(EX_LIBS)'; \
+ echo 'Libs: -L$${libdir} -lcrypto'; \
+ echo 'Libs.private: $(EX_LIBS)'; \
echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) libcrypto.pc
libssl.pc: Makefile
@@ -334,11 +335,12 @@ libssl.pc: Makefile
echo 'libdir=$${exec_prefix}/$(LIBDIR)'; \
echo 'includedir=$${prefix}/include'; \
echo ''; \
- echo 'Name: OpenSSL'; \
+ echo 'Name: OpenSSL-libssl'; \
echo 'Description: Secure Sockets Layer and cryptography libraries'; \
echo 'Version: '$(VERSION); \
- echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
+ echo 'Requires.private: libcrypto'; \
+ echo 'Libs: -L$${libdir} -lssl'; \
+ echo 'Libs.private: $(EX_LIBS)'; \
echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) libssl.pc
openssl.pc: Makefile
@@ -350,9 +352,7 @@ openssl.pc: Makefile
echo 'Name: OpenSSL'; \
echo 'Description: Secure Sockets Layer and cryptography libraries and tools'; \
echo 'Version: '$(VERSION); \
- echo 'Requires: '; \
- echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
- echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) openssl.pc
+ echo 'Requires: libssl libcrypto' ) openssl.pc
Makefile: Makefile.org Configure config
@echo Makefile is older than Makefile.org, Configure or config.
Re: [openssl.org #2641] Move the libraries needed for static linking to Libs.private
On Tuesday 22 November 2011 17:49:50 Tomas Mraz via RT wrote: The attached patch changes the generated pkgconfig files so the libraries needed for static linking are in Libs.private instead of Libs. ah, this is better than the current state, but i ended up posting a patch earlier today that goes a bit further. see attached. -mike signature.asc Description: This is a digitally signed message part.
[openssl.org #2558] [patch] make windres controllable via build env var settings
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. so add support for the standard $RC
/ $WINDRES env vars as well.
-mike
Index: Configure
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/Configure,v
retrieving revision 1.621.2.40
diff -u -p -r1.621.2.40 Configure
--- Configure 30 Nov 2010 22:19:26 - 1.621.2.40
+++ Configure 4 Jul 2011 23:12:32 -
@@ -1094,6 +1094,7 @@ my $shared_extension = $fields[$idx_shar
my $ranlib = $ENV{'RANLIB'} || $fields[$idx_ranlib];
my $ar = $ENV{'AR'} || ar;
my $arflags = $fields[$idx_arflags];
+my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || windres;
my $multilib = $fields[$idx_multilib];
# if $prefix/lib$multilib is not an existing directory, then
@@ -1511,12 +1512,14 @@ while (IN)
s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/;
s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/;
s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/;
+ s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc eq gcc;
}
else {
s/^CC=.*$/CC= $cc/;
s/^AR=\s*ar/AR= $ar/;
s/^RANLIB=.*/RANLIB= $ranlib/;
+ s/^WINDRES=.*/WINDRES= $windres/;
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq gcc;
}
s/^CFLAG=.*$/CFLAG= $cflags/;
Index: Makefile.org
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/Makefile.org,v
retrieving revision 1.295.2.10
diff -u -p -r1.295.2.10 Makefile.org
--- Makefile.org 27 Jan 2010 16:06:58 - 1.295.2.10
+++ Makefile.org 4 Jul 2011 23:13:08 -
@@ -66,6 +66,7 @@ EXE_EXT=
ARFLAGS=
AR=ar $(ARFLAGS) r
RANLIB= ranlib
+WINDRES= windres
NM= nm
PERL= perl
TAR= tar
@@ -180,6 +181,7 @@ BUILDENV= PLATFORM='$(PLATFORM)' PROCESS
CC='$(CC)' CFLAG='$(CFLAG)' \
AS='$(CC)' ASFLAG='$(CFLAG) -c' \
AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)' \
+ WINDRES='$(WINDRES)'\
CROSS_COMPILE='$(CROSS_COMPILE)' \
PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' \
SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \
Index: Makefile.shared
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/Makefile.shared,v
retrieving revision 1.72.2.4
diff -u -p -r1.72.2.4 Makefile.shared
--- Makefile.shared 21 Aug 2010 11:36:49 - 1.72.2.4
+++ Makefile.shared 4 Jul 2011 23:13:52 -
@@ -293,7 +293,7 @@ link_a.cygwin:
fi; \
dll_name=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \
$(PERL) util/mkrc.pl $$dll_name | \
- $(CROSS_COMPILE)windres -o rc.o; \
+ $(WINDRES) -o rc.o; \
extras=$$extras rc.o; \
ALLSYMSFLAGS='-Wl,--whole-archive'; \
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
[openssl.org #2507] [patch] fix typo in alpha mont asm code
--- crypto/bn/asm/alpha-mont.pl +++ crypto/bn/asm/alpha-mont.pl @@ -41,7 +41,7 @@ $j=s4; $m1=s5; $code=___; -#indef __linux__ +#ifdef __linux__ #include asm/regdef.h #else #include asm.h -mike signature.asc Description: PGP signature
[openssl.org #2508] rt website hits cookie error for me
if i load a fresh browser (i.e. no cookies/etc...), and do:
- goto http://rt.openssl.org/
- login with guest/guest
- enter alpha into search box in upper right
- click the link for the 2nd alpha bug (1597)
http://rt.openssl.org/Ticket/Display.html?id=1597
- see perl error:
Can't call method delete on an undefined value at
/v/openssl/sw/libexec/rt/WebRT/html/Elements/SetupSessionCookie line 90.
Trace begun at /v/openssl/sw/libexec/rt/HTML/Mason/Exceptions.pm line 129
HTML::Mason::Exceptions::rethrow_exception('Can\'t call method delete on an
undefined value at
/v/openssl/sw/libexec/rt/WebRT/html/Elements/SetupSessionCookie line 90.^J')
called at /v/openssl/sw/libexec/rt/WebRT/html/Elements/SetupSessionCookie line
90
HTML::Mason::Commands::__ANON__('id', 1597) called at
/v/openssl/sw/libexec/rt/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run('HTML::Mason::Component::FileBased=HASH(0x809034ee8)',
'id', 1597) called at /v/openssl/sw/libexec/rt/HTML/Mason/Request.pm line 1251
eval {...} at /v/openssl/sw/libexec/rt/HTML/Mason/Request.pm line 1245
HTML::Mason::Request::comp(undef, undef, 'id', 1597) called at
/v/openssl/sw/libexec/rt/WebRT/html/autohandler line 73
HTML::Mason::Commands::__ANON__('id', 1597) called at
/v/openssl/sw/libexec/rt/HTML/Mason/Component.pm line 135
HTML::Mason::Component::run('HTML::Mason::Component::FileBased=HASH(0x809010240)',
'id', 1597) called at /v/openssl/sw/libexec/rt/HTML/Mason/Request.pm line 1246
eval {...} at /v/openssl/sw/libexec/rt/HTML/Mason/Request.pm line 1245
HTML::Mason::Request::comp(undef, undef, undef, 'id', 1597) called at
/v/openssl/sw/libexec/rt/HTML/Mason/Request.pm line 459
eval {...} at /v/openssl/sw/libexec/rt/HTML/Mason/Request.pm line 459
eval {...} at /v/openssl/sw/libexec/rt/HTML/Mason/Request.pm line 411
HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0x8086c8078)')
called at /v/openssl/sw/libexec/rt/HTML/Mason/ApacheHandler.pm line 168
HTML::Mason::Request::ApacheHandler::exec('HTML::Mason::Request::ApacheHandler=HASH(0x8086c8078)')
called at /v/openssl/sw/libexec/rt/HTML/Mason/ApacheHandler.pm line 826
HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x805152a20)',
'Apache2::RequestRec=SCALAR(0x805ce3a80)') called at
/v/openssl/sw/cgi/rt/webmux.pl line 125
eval {...} at /v/openssl/sw/cgi/rt/webmux.pl line 125
RT::Mason::handler('Apache2::RequestRec=SCALAR(0x805ce3a80)') called at
/v/openssl/sw/lib/perl/vendor_perl/5.12.3/Apache/Session/MySQL.pm line 0
eval {...} at
/v/openssl/sw/lib/perl/vendor_perl/5.12.3/Apache/Session/MySQL.pm line 0
-mike
signature.asc
Description: PGP signature
[openssl.org #2335] openssl-1.0.0a build problems on alpha/linux systems with new alpha assembly
first, let's ignore the alphacpuid.s not bundled problem as it is already filed as ticket #2309. once that is fixed, we hit a rash of other issues. seems this alpha assembly was tested with a toolchain other than the GNU one (meaning the GNU assembler or gas), and it was tested on a host other than Linux or glibc. first, when using gas, there is no implicit offset of 0 when using load/store insns. it must be explicitly specified as 0. otherwise alphacpuid.s fails with: alphacpuid.s:71: Error: inappropriate arguments for opcode `ldl_l' alphacpuid.s:73: Error: inappropriate arguments for opcode `stl_c' and then the alpha-mont.s fails with many errors like: alpha-mont.s:66: Error: inappropriate arguments for opcode `ldq' alpha-mont.s:207: Error: inappropriate arguments for opcode `stq' (credit to Matt Turner for this info + fix) next, on Linux/glibc systems, there is no asm.h or regdef.h headers. so trying to generate alpha-mont.s originally fails with: stdin:1:17: error: asm.h: No such file or directory stdin:2:20: error: regdef.h: No such file or directory there is however an asm/regdef.h which seems to provide everything this file is looking for in terms of register name defines. getting past this hits another gas syntax error: stdin:269: Error: unknown pseudo-op: `.rdata' stdin:270: Error: unknown pseudo-op: `.asciiz' gas uses .section .rodata and .asciz. but rather than fix/conditionalize this, it's a lot easier to simply remove it. i cant see any references in this or any other file to this string in the first place, so it wont be shown/used in the final library. finally, we're left with one warning: stdin:36: Warning: operand out of range (0xf000 is not between 0x and 0x00ff) which is due to this insn: mov -4096,$at i dont know the correct fix here, so i imagine the original author will need to chime in. at any rate, the attached patch fixes all the errors on alpha/Linux systems and i cant see it breaking any others ... it's against CVS head, but it should apply cleanly to the 1.0.0 branch as well. both places need it. -mike Index: crypto/alphacpuid.pl === RCS file: /usr/local/src/openssl/CVSROOT/openssl/crypto/alphacpuid.pl,v retrieving revision 1.2 diff -u -p -r1.2 alphacpuid.pl --- crypto/alphacpuid.pl 28 Jul 2010 08:17:15 - 1.2 +++ crypto/alphacpuid.pl 12 Sep 2010 04:25:26 - @@ -70,9 +70,9 @@ OPENSSL_wipe_cpu: OPENSSL_atomic_add: .frame $30,0,$26 .prologue 0 -1: ldl_l $0,($16) +1: ldl_l $0,0($16) addl $0,$17,$1 - stl_c $1,($16) + stl_c $1,0($16) beq $1,1b addl $0,$17,$0 ret ($26) Index: crypto/bn/asm/alpha-mont.pl === RCS file: /usr/local/src/openssl/CVSROOT/openssl/crypto/bn/asm/alpha-mont.pl,v retrieving revision 1.6 diff -u -p -r1.6 alpha-mont.pl --- crypto/bn/asm/alpha-mont.pl 10 Apr 2010 13:33:04 - 1.6 +++ crypto/bn/asm/alpha-mont.pl 12 Sep 2010 04:44:04 - @@ -41,8 +41,12 @@ $j=s4; $m1=s5; $code=___; +#ifdef __linux__ +#include asm/regdef.h +#else #include asm.h #include regdef.h +#endif .text @@ -106,9 +110,9 @@ bn_mul_mont: .align 4 .L1st: .set noreorder - ldq $aj,($aj) + ldq $aj,0($aj) addl $j,1,$j - ldq $nj,($nj) + ldq $nj,0($nj) lda $tp,8($tp) addq $alo,$hi0,$lo0 @@ -159,12 +163,12 @@ bn_mul_mont: .align 4 .Louter: s8addq $i,$bp,$bi - ldq $hi0,($ap) + ldq $hi0,0($ap) ldq $aj,8($ap) - ldq $bi,($bi) - ldq $hi1,($np) + ldq $bi,0($bi) + ldq $hi1,0($np) ldq $nj,8($np) - ldq $tj,(sp) + ldq $tj,0(sp) mulq $hi0,$bi,$lo0 umulh $hi0,$bi,$hi0 @@ -195,10 +199,10 @@ bn_mul_mont: .set noreorder ldq $tj,8($tp) #L0 nop #U1 - ldq $aj,($aj) #L1 + ldq $aj,0($aj) #L1 s8addq $j,$np,$nj #U0 - ldq $nj,($nj) #L0 + ldq $nj,0($nj) #L0 nop #U1 addq $alo,$hi0,$lo0 #L1 lda $tp,8($tp) @@ -247,7 +251,7 @@ bn_mul_mont: addq $hi1,v0,$hi1 addq $hi1,$hi0,$lo1 - stq $j,($tp) + stq $j,0($tp) cmpult $lo1,$hi0,$hi1 addq $lo1,$tj,$lo1 cmpult $lo1,$tj,AT @@ -265,8 +269,8 @@ bn_mul_mont: mov 0,$hi0 # clear borrow bit .align 4 -.Lsub: ldq $lo0,($tp) - ldq $lo1,($np) +.Lsub: ldq $lo0,0($tp) + ldq $lo1,0($np) lda $tp,8($tp) lda $np,8($np) subq $lo0,$lo1,$lo1 # tp[i]-np[i] @@ -274,7 +278,7 @@ bn_mul_mont: subq $lo1,$hi0,$lo0 cmpult $lo1,$lo0,$hi0 or $hi0,AT,$hi0 - stq $lo0,($rp) + stq $lo0,0($rp) cmpult $tp,$tj,v0 lda $rp,8($rp) bne v0,.Lsub @@ -288,7 +292,7 @@ bn_mul_mont: bis $bp,$ap,$ap # ap=borrow?tp:rp .align 4 -.Lcopy: ldq $aj,($ap) # copy or in-place refresh +.Lcopy: ldq $aj,0($ap) # copy or in-place refresh lda $tp,8($tp) lda $rp,8($rp) lda $ap,8($ap) @@ -309,8 +313,10 @@ bn_mul_mont: lda sp,48(sp) ret (ra) .end bn_mul_mont +#if 0 .rdata .asciiz Montgomery Multiplication for Alpha, CRYPTOGAMS by app...@openssl.org +#endif ___ print $code; signature.asc Description: PGP signature
Re: [openssl.org #2335] openssl-1.0.0a build problems on alpha/linux systems with new alpha assembly
On Monday, September 13, 2010 09:38:01 Andy Polyakov via RT wrote: finally, we're left with one warning: stdin:36: Warning: operand out of range (0xf000 is not between 0x and 0x00ff) which is due to this insn: mov -4096,$at i dont know the correct fix here, so i imagine the original author will need to chime in. Well, 'mov' is not real Alpha instruction and assembler is expected to replace it with equivalent real one. There is a number of ways it can be realized, and proper replacement for 'mov -4096,$n' is 'lda $n,-4096(zero)'. Apparently gas isn't bright enough and real instruction has to be explicitly coded. Did gas-compiled code work by the way? I mean it could have generated code that would SEGV... it segfaulted at any rate, the attached patch fixes all the errors on alpha/Linux systems and i cant see it breaking any others ... it's against CVS head, but it should apply cleanly to the 1.0.0 branch as well. both places need it. But HEAD branch has two more assembler modules, sha1-alpha.pl and ghash-alpha.pl, which couldn't have worked. At least because of missing #include. I've applied http://cvs.openssl.org/chngview?cn=19894. Could you test the HEAD branch? Once you confirm that it works (or some other issues are addressed), I'll propagate it to 1.0. it seems to work OK. i just built openssh against it and connected to a few systems. this segfaulted before, but latest HEAD runs OK. -mike signature.asc Description: This is a digitally signed message part.
[openssl.org #2324] convert c_rehash from perl to POSIX shell
while openssl requires perl in order to compile, nothing that it installs requires perl at runtime. that is except for the simple c_rehash script. for such a simple wrapper, i dont think the perl requirement is justified. fortunately, the PLD Linux guys have already rewritten things in POSIX shell, so it merely needs to be imported: http://cvs.pld-linux.org/cgi- bin/cvsweb.cgi/~checkout~/packages/openssl/openssl-c_rehash.sh -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2135] [patch] fix few LIBDIR refs in engines/
openssl-1.0.0-beta4 and the openssl-1.0.0-stable branch are still using
/lib/ instead of /$(LIBDIR)/ in a few places.
-mike
Index: engines/Makefile
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/engines/Makefile,v
retrieving revision 1.23.2.4
diff -u -p -r1.23.2.4 Makefile
--- engines/Makefile 10 Nov 2009 01:52:52 - 1.23.2.4
+++ engines/Makefile 11 Jan 2010 02:48:32 -
@@ -107,7 +107,7 @@ install:
@[ -n $(INSTALLTOP) ] # should be set by top Makefile...
@if [ -n $(SHARED_LIBS) ]; then \
set -e; \
- $(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines; \
+ $(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines; \
for l in $(LIBNAMES); do \
( echo installing $$l; \
pfx=lib; \
Index: engines/ccgost/Makefile
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/engines/ccgost/Makefile,v
retrieving revision 1.9.2.1
diff -u -p -r1.9.2.1 Makefile
--- engines/ccgost/Makefile 2 Apr 2009 15:04:01 - 1.9.2.1
+++ engines/ccgost/Makefile 11 Jan 2010 02:48:33 -
@@ -53,13 +53,13 @@ install:
*DSO_WIN32*) sfx=eay32.dll; pfx=;; \
*) sfx=.bad;; \
esac; \
- cp $${pfx}$(LIBNAME)$$sfx $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new; \
+ cp $${pfx}$(LIBNAME)$$sfx $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new; \
else \
sfx=.so; \
- cp cyg$(LIBNAME).dll $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new; \
+ cp cyg$(LIBNAME).dll $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new; \
fi; \
- chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new; \
- mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines/$${pfx}$(LIBNAME)$$sfx; \
+ chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new; \
+ mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$${pfx}$(LIBNAME)$$sfx; \
fi
links:
Re: [openssl.org #2135] [patch] fix few LIBDIR refs in engines/
On Sunday 10 January 2010 21:53:03 Mike Frysinger wrote: openssl-1.0.0-beta4 and the openssl-1.0.0-stable branch are still using /lib/ instead of /$(LIBDIR)/ in a few places. there is also a missing ref in the top level Makefile.org -mike Index: Makefile.org === RCS file: /usr/local/src/openssl/CVSROOT/openssl/Makefile.org,v retrieving revision 1.295.2.8 diff -u -p -r1.295.2.8 Makefile.org --- Makefile.org 15 Oct 2009 23:44:11 - 1.295.2.8 +++ Makefile.org 11 Jan 2010 03:01:02 - @@ -551,7 +551,7 @@ install_sw: fi; \ done; \ ( here=`pwd`; \ - cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \ + cd $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR); \ $(MAKE) -f $$here/Makefile HERE=$$here link-shared ); \ if [ $(INSTALLTOP) != /usr ]; then \ echo 'OpenSSL shared libraries have been installed in:'; \ signature.asc Description: PGP signature
Re: [openssl.org #2085] [patch] invert util/domd check to work with multiple compilers
On Wednesday 28 October 2009 10:18:10 Stephen Henson via RT wrote: [vap...@gentoo.org - Mon Oct 26 13:59:37 2009]: the current util/domd script defaults $MAKEDEPEND to `makedepend` and then checks the value against gcc. this doesnt work if $MAKEDEPEND is set to a gcc compiler by another name (i686-pc-linux-gcc, cc, etc...). so invert the script logic so that it runs the makedepend code when using makedepend and uses the gcc-compatible syntax for everything else. OpenSSL 1.0.0 instead does: if expr $MAKEDEPEND : '.*gcc$' /dev/null; then i.e. check if $MAKEDEPEND ends in gcc. Would backporting that test address your concerns? for all the use cases i care about, it should indeed work fine -mike signature.asc Description: PGP signature
[openssl.org #2080] [patch] respect $MAKE env var when creating links
if building on a system with GNU make installed as `gmake` and a
deficient/old/broken/crappy version of make installed as `make`, the perl
Configure script will hard code `make` when processing the links target
regardless of the make that was used.
this patch will leverage the env var $MAKE instead of hard coding `make` as
this corresponds to the practice of utilizing ${MAKE} in makefiles to get at
the active make version rather than also using `make`.
patch is against OpenSSL_0_9_8-stable tag, but should be trivial to port to
any other version ...
-mike
Index: Configure
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/Configure,v
retrieving revision 1.488.2.95
diff -u -p -r1.488.2.95 Configure
--- Configure 18 Oct 2009 14:24:47 - 1.488.2.95
+++ Configure 26 Oct 2009 10:12:19 -
@@ -1100,6 +1100,7 @@ $libdir=lib if $libdir eq ;
$default_ranlib= which(ranlib) or $default_ranlib=true;
$perl=$ENV{'PERL'} or $perl=which(perl5) or $perl=which(perl)
or $perl=perl;
+my $make = $ENV{'MAKE'} || make;
$cross_compile_prefix=$ENV{'CROSS_COMPILE'} if $cross_compile_prefix eq ;
@@ -1800,7 +1801,7 @@ if($IsMK1MF) {
EOF
close(OUT);
} else {
- my $make_command = make PERL=\'$perl\';
+ my $make_command = $make PERL=\'$perl\';
my $make_targets = ;
$make_targets .= links if $symlink;
$make_targets .= depend if $depflags ne $default_depflags $make_depend;
[openssl.org #2081] [patch] respect $AR and $RANLIB
if the toolchain env vars $AR and/or $RANLIB are set in the environment, the
Configure script should default to those. this matches behavior of many other
package build systems (like autotools) and usage already in place in openssl
itself (CC/etc...).
patch is against OpenSSL_0_9_8-stable, but it's simple and should be easy to
port elsewhere
-mike
Index: Configure
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/Configure,v
retrieving revision 1.488.2.95
diff -u -p -r1.488.2.95 Configure
--- Configure 18 Oct 2009 14:24:47 - 1.488.2.95
+++ Configure 26 Oct 2009 10:30:59 -
@@ -995,7 +995,8 @@ my $shared_target = $fields[$idx_shared_
my $shared_cflag = $fields[$idx_shared_cflag];
my $shared_ldflag = $fields[$idx_shared_ldflag];
my $shared_extension = $fields[$idx_shared_extension];
-my $ranlib = $fields[$idx_ranlib];
+my $ranlib = $ENV{'RANLIB'} || $fields[$idx_ranlib];
+my $ar = $ENV{'AR'} || ar;
my $arflags = $fields[$idx_arflags];
if ($fips)
@@ -1506,6 +1507,7 @@ while (IN)
}
else {
s/^CC=.*$/CC= $cc/;
+ s/^AR=.*/AR= $ar/;
s/^RANLIB=.*/RANLIB= $ranlib/;
}
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq gcc;
[openssl.org #2082] [patch] make sure to create engines dir before installing into it
the engines/Makefile install target will try to install files into $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines, but it doesnt make sure the directory exists before doing so. simple patch to use the included mkdir-p.pl script to create the dir first. the trivial patch is against the OpenSSL_0_9_8-stable branch -mike Index: engines/Makefile === RCS file: /usr/local/src/openssl/CVSROOT/openssl/engines/Makefile,v retrieving revision 1.6.2.12 diff -u -p -r1.6.2.12 Makefile --- engines/Makefile 10 Aug 2009 14:37:50 - 1.6.2.12 +++ engines/Makefile 26 Oct 2009 10:34:50 - @@ -92,6 +92,7 @@ install: @[ -n $(INSTALLTOP) ] # should be set by top Makefile... @if [ -n $(SHARED_LIBS) ]; then \ set -e; \ + $(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines; \ for l in $(LIBNAMES); do \ ( echo installing $$l; \ if [ $(PLATFORM) != Cygwin ]; then \
[openssl.org #2083] [patch] misc doc updates (include headers/fix indentation)
the openssl man pages should mention the headers that need to be included in order to use the function in question. the function prototypes should also be indented slightly for the perl code to process things correctly (and match the rest of the .pod file styles). patch is against OpenSSL_0_9_8-stable -mike Index: doc/crypto/ASN1_OBJECT_new.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/ASN1_OBJECT_new.pod,v retrieving revision 1.1 diff -u -p -r1.1 ASN1_OBJECT_new.pod --- doc/crypto/ASN1_OBJECT_new.pod 9 Oct 2002 12:06:11 - 1.1 +++ doc/crypto/ASN1_OBJECT_new.pod 26 Oct 2009 10:42:42 - @@ -6,6 +6,8 @@ ASN1_OBJECT_new, ASN1_OBJECT_free, - obj =head1 SYNOPSIS + #include openssl/asn1.h + ASN1_OBJECT *ASN1_OBJECT_new(void); void ASN1_OBJECT_free(ASN1_OBJECT *a); Index: doc/crypto/ASN1_STRING_length.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/ASN1_STRING_length.pod,v retrieving revision 1.1 diff -u -p -r1.1 ASN1_STRING_length.pod --- doc/crypto/ASN1_STRING_length.pod 20 Oct 2002 13:20:56 - 1.1 +++ doc/crypto/ASN1_STRING_length.pod 26 Oct 2009 10:42:42 - @@ -8,6 +8,8 @@ ASN1_STRING utility functions =head1 SYNOPSIS + #include openssl/asn1.h + int ASN1_STRING_length(ASN1_STRING *x); unsigned char * ASN1_STRING_data(ASN1_STRING *x); Index: doc/crypto/ASN1_STRING_new.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/ASN1_STRING_new.pod,v retrieving revision 1.1 diff -u -p -r1.1 ASN1_STRING_new.pod --- doc/crypto/ASN1_STRING_new.pod 20 Oct 2002 13:20:56 - 1.1 +++ doc/crypto/ASN1_STRING_new.pod 26 Oct 2009 10:42:42 - @@ -7,6 +7,8 @@ ASN1_STRING allocation functions =head1 SYNOPSIS + #include openssl/asn1.h + ASN1_STRING * ASN1_STRING_new(void); ASN1_STRING * ASN1_STRING_type_new(int type); void ASN1_STRING_free(ASN1_STRING *a); Index: doc/crypto/ASN1_generate_nconf.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/ASN1_generate_nconf.pod,v retrieving revision 1.6.2.2 diff -u -p -r1.6.2.2 ASN1_generate_nconf.pod --- doc/crypto/ASN1_generate_nconf.pod 23 Jan 2008 19:25:41 - 1.6.2.2 +++ doc/crypto/ASN1_generate_nconf.pod 26 Oct 2009 10:42:42 - @@ -6,6 +6,8 @@ ASN1_generate_nconf, ASN1_generate_v3 - =head1 SYNOPSIS + #include openssl/asn1.h + ASN1_TYPE *ASN1_generate_nconf(char *str, CONF *nconf); ASN1_TYPE *ASN1_generate_v3(char *str, X509V3_CTX *cnf); Index: doc/crypto/CRYPTO_set_ex_data.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/CRYPTO_set_ex_data.pod,v retrieving revision 1.1 diff -u -p -r1.1 CRYPTO_set_ex_data.pod --- doc/crypto/CRYPTO_set_ex_data.pod 30 Jan 2000 01:39:40 - 1.1 +++ doc/crypto/CRYPTO_set_ex_data.pod 26 Oct 2009 10:42:42 - @@ -6,6 +6,8 @@ CRYPTO_set_ex_data, CRYPTO_get_ex_data - =head1 SYNOPSIS + #include openssl/crypto.h + int CRYPTO_set_ex_data(CRYPTO_EX_DATA *r, int idx, void *arg); void *CRYPTO_get_ex_data(CRYPTO_EX_DATA *r, int idx); Index: doc/crypto/OBJ_nid2obj.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/OBJ_nid2obj.pod,v retrieving revision 1.2 diff -u -p -r1.2 OBJ_nid2obj.pod --- doc/crypto/OBJ_nid2obj.pod 20 Oct 2002 13:20:57 - 1.2 +++ doc/crypto/OBJ_nid2obj.pod 26 Oct 2009 10:42:42 - @@ -8,6 +8,8 @@ functions =head1 SYNOPSIS + #include openssl/objects.h + ASN1_OBJECT * OBJ_nid2obj(int n); const char * OBJ_nid2ln(int n); const char * OBJ_nid2sn(int n); Index: doc/crypto/PKCS7_decrypt.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/PKCS7_decrypt.pod,v retrieving revision 1.1 diff -u -p -r1.1 PKCS7_decrypt.pod --- doc/crypto/PKCS7_decrypt.pod 9 Oct 2002 12:06:11 - 1.1 +++ doc/crypto/PKCS7_decrypt.pod 26 Oct 2009 10:42:42 - @@ -6,7 +6,9 @@ PKCS7_decrypt - decrypt content from a P =head1 SYNOPSIS -int PKCS7_decrypt(PKCS7 *p7, EVP_PKEY *pkey, X509 *cert, BIO *data, int flags); + #include openssl/pkcs7.h + + int PKCS7_decrypt(PKCS7 *p7, EVP_PKEY *pkey, X509 *cert, BIO *data, int flags); =head1 DESCRIPTION Index: doc/crypto/PKCS7_encrypt.pod === RCS file: /usr/local/src/openssl/CVSROOT/openssl/doc/crypto/PKCS7_encrypt.pod,v retrieving revision 1.2 diff -u -p -r1.2 PKCS7_encrypt.pod --- doc/crypto/PKCS7_encrypt.pod 9 Oct 2002 13:10:23 - 1.2 +++ doc/crypto/PKCS7_encrypt.pod 26 Oct 2009 10:42:42 - @@ -6,7 +6,9 @@ PKCS7_encrypt - create a PKCS#7 envelope =head1 SYNOPSIS -PKCS7
[openssl.org #2084] [patch] add proper dependencies to some top level targets for parallel builds
a bunch of the top level targets do not list their dependencies which means building in parallel will often fail patch is against OpenSSL_0_9_8-stable -mike Index: Makefile.org === RCS file: /usr/local/src/openssl/CVSROOT/openssl/Makefile.org,v retrieving revision 1.256.2.24 diff -u -p -r1.256.2.24 Makefile.org --- Makefile.org 15 Oct 2009 14:14:33 - 1.256.2.24 +++ Makefile.org 26 Oct 2009 10:45:32 - @@ -335,15 +335,15 @@ build_crypto: dir=crypto; target=all; $(BUILD_ONE_CMD) build_fips: @dir=fips; target=all; [ -z $(FIPSCANLIB) ] || $(BUILD_ONE_CMD) -build_ssl: +build_ssl: build_crypto @dir=ssl; target=all; $(BUILD_ONE_CMD) -build_engines: +build_engines: build_crypto @dir=engines; target=all; $(BUILD_ONE_CMD) -build_apps: +build_apps: build_libs @dir=apps; target=all; $(BUILD_ONE_CMD) -build_tests: +build_tests: build_libs @dir=test; target=all; $(BUILD_ONE_CMD) -build_tools: +build_tools: build_libs @dir=tools; target=all; $(BUILD_ONE_CMD) all_testapps: build_libs build_testapps
[openssl.org #2085] [patch] invert util/domd check to work with multiple compilers
the current util/domd script defaults $MAKEDEPEND to `makedepend` and then checks the value against gcc. this doesnt work if $MAKEDEPEND is set to a gcc compiler by another name (i686-pc-linux-gcc, cc, etc...). so invert the script logic so that it runs the makedepend code when using makedepend and uses the gcc-compatible syntax for everything else. patch is against OpenSSL_0_9_8-stable -mike Index: util/domd === RCS file: /usr/local/src/openssl/CVSROOT/openssl/util/domd,v retrieving revision 1.9.2.1 diff -u -p -r1.9.2.1 domd --- util/domd 21 Jan 2009 21:44:52 - 1.9.2.1 +++ util/domd 26 Oct 2009 10:38:10 - @@ -14,7 +14,7 @@ if [ $MAKEDEPEND = ]; then MAKEDEPE cp Makefile Makefile.save # fake the presence of Kerberos touch $TOP/krb5.h -if [ $MAKEDEPEND = gcc ]; then +if [ $MAKEDEPEND != makedepend ]; then args= while [ $# -gt 0 ]; do if [ $1 != -- ]; then args=$args $1; fi
Re: [PROPOSAL] provide 7z snapshot archives for download
On Sunday 06 January 2008, David Schwartz wrote: Hi, the 7-Zip archiver has recently become very popular because of its good compression rate; f.e. recent snapshot is about 34% smaller when packed with 7z compared to tar.gz: -rw-r--r-- 1 root root 2484981 Jan 5 17:28 openssl-SNAP-20080105.7z -rw-r--r-- 1 root root 3781438 Jan 5 17:27 openssl-SNAP-20080105.tar.gz I'm not sure if the popularity of 7-Zip is high enough to justify the effort. But the benefit is significant. I ran some tests of an OpenSSL build using default settings for all compressors. It looked like this (higher is better): i really dont think the 7z archive format is widely accepted in any sort of numbers that would convince posting of a .7z archive. however, i would point out that lzma (the compression algorithm that the 7z archive format employs) is gaining traction in the open source world via the lzma-utils package. this provides a set of utilities with the same general interface as gzip/bzip2. for example, the autotool packages have integrated native support for it as have a number of other core projects in the GNU world. it also has the advantage of working seamlessly with existing utilities: gzip -c -d openssl-SNAP-20080105.tar.gz | tar xf bzip2 -c -d openssl-SNAP-20080105.tar.bz2 | tar xf lzma -c -d openssl-SNAP-20080105.tar.lzma | tar xf people know `tar`, they dont know `7z` 3781438 openssl-SNAP-20080105.tar.gz 2495545 openssl-SNAP-20080105.tar.lzma 2484981 openssl-SNAP-20080105.7z looks to me like tar+lzma is the way to go, not 7z -mike signature.asc Description: This is a digitally signed message part.
Re: [PROPOSAL] provide 7z snapshot archives for download
On Sunday 06 January 2008, David Schwartz wrote: looks to me like tar+lzma is the way to go, not 7z In my quick test, lzma got a 7.6, beating 7z by a negligible margin. I think it largely comes down to whether any of these are popular enough to justify the effort of offering in that format. We've been down this road before in the transition from compress to gzip and then from gzip to bzip2. sure, i perfectly understand there's more to it than just 1 more file, what's the big deal. please dont take my comments as you need to get on this!. i'm just trying to direct things such that if you do decide to start supporting/transitioning to a new format, it's the right one looking at things long term and such. if there is a new compression standard coming up in the open source world, i believe it's going to be lzma-utils. imo, .lzma is the only thing worth considering at this time. wait a few releases of openssl and you'll get a better feel for how viable lzma is (or isnt). conversely, i'd put hard cash that 7z will not supplant tar ... after all, that is what the comparison actually is. 7z is an archiver (that also does compression). tar is an archiver. bzip2/gzip/lzma do compression. tar+lzma ftw :). side note, lzma typically is slower during compression, but faster/leaner during decompression. which is what matters in this scenario -- the packager compresses once while everyone else decompresses many many times. a few more data points from glancing at wikipedia ... Inno Setup, NSIS, and RPM include lzma in the latest releases -mike signature.asc Description: This is a digitally signed message part.
ticket #1342 can be punted
i was flipping through the tracker when i noticed #1342 (bug/gentoo/bashdb/stdin) ... this isnt an openssl by any means so the ticket can simply be punted -mike signature.asc Description: This is a digitally signed message part.
Re: [patch] include sys/types.h in sha.h
On Friday 22 December 2006 10:58, Andy Polyakov wrote: right now you need to include sys/types.h yourself before trying to include openssl/sha.h or the build fails ... this patch does what some of other openssl headers do and include sys/types.h properly This is about size_t, isn't it? yes sys/types.h is wrong one to include. stddef.h is one required by standard and is universally available. i guess that depends on your definition of wrong ... POSIX requires that sys/types.h define size_t It's fixed now in HEAD and 098. A. you might want to fix buffer.h as well then ... i modeled the sha.h patch after that file -mike pgpQ7USfqzipt.pgp Description: PGP signature
Re: Digium and OpenSSL
On Tuesday 12 September 2006 18:10, James Jones wrote: Is anyone aware that digium is using openssl in there g729 codec code and license registration with it display the openssl copyright info. what's your point ? -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Any possibility of GPL-based license in the future?
On Tuesday 16 May 2006 10:56, Brad House wrote: It's the GPL license that's broken, not OpenSSL. I believe the main reason that you cannot link with OpenSSL's license is because of the BSD with credit/advertising clause. the advertising clause was dropped from the BSD license a long time ago -mike pgpFQ5AHB4lUP.pgp Description: PGP signature
[patch] respect env var settings for CC/AR/RANLIB
it's nice when a build system respects the env settings of CC/AR/RANLIB so
here's a minor patch to Configure to do just that
-mike
--- Configure
+++ Configure
@@ -949,7 +949,7 @@
print IsMK1MF=$IsMK1MF\n;
my @fields = split(/\s*:\s*/,$table{$target} . : x 30 , -1);
-my $cc = $fields[$idx_cc];
+my $cc = $ENV{'CC'} || $fields[$idx_cc];
my $cflags = $fields[$idx_cflags];
my $unistd = $fields[$idx_unistd];
my $thread_cflag = $fields[$idx_thread_cflag];
@@ -973,8 +973,9 @@ my $shared_target = $fields[$idx_shared_
my $shared_cflag = $fields[$idx_shared_cflag];
my $shared_ldflag = $fields[$idx_shared_ldflag];
my $shared_extension = $fields[$idx_shared_extension];
-my $ranlib = $fields[$idx_ranlib];
+my $ranlib = $ENV{'RANLIB'} || $fields[$idx_ranlib];
my $arflags = $fields[$idx_arflags];
+my $ar = $ENV{'AR'} || ar;
my $no_shared_warn=0;
my $no_user_cflags=0;
@@ -1329,6 +1330,7 @@ while (IN)
s/^PROCESSOR=.*/PROCESSOR= $processor/;
s/^RANLIB=.*/RANLIB= $ranlib/;
s/^ARFLAGS=.*/ARFLAGS= $arflags/;
+ s/^AR=ar /AR= $ar /;
s/^PERL=.*/PERL= $perl/;
s/^KRB5_INCLUDES=.*/KRB5_INCLUDES=$withargs{krb5-include}/;
s/^LIBKRB5=.*/LIBKRB5=$withargs{krb5-lib}/;
pgpPFsqTqPsd6.pgp
Description: PGP signature
[patch] touchup many document pod files
this patch adds an #include line to pod files that document API but dont mention the header file where you can find the documented functions also, i indented a few files as the standard seems to be to have one leading space with prototypes -mike --- doc/crypto/ASN1_generate_nconf.pod +++ doc/crypto/ASN1_generate_nconf.pod @@ -6,6 +6,8 @@ ASN1_generate_nconf, ASN1_generate_v3 - =head1 SYNOPSIS + #include openssl/asn1.h + ASN1_TYPE *ASN1_generate_nconf(char *str, CONF *nconf); ASN1_TYPE *ASN1_generate_v3(char *str, X509V3_CTX *cnf); --- doc/crypto/ASN1_OBJECT_new.pod +++ doc/crypto/ASN1_OBJECT_new.pod @@ -6,6 +6,8 @@ ASN1_OBJECT_new, ASN1_OBJECT_free, - obj =head1 SYNOPSIS + #include openssl/asn1.h + ASN1_OBJECT *ASN1_OBJECT_new(void); void ASN1_OBJECT_free(ASN1_OBJECT *a); --- doc/crypto/ASN1_STRING_length.pod +++ doc/crypto/ASN1_STRING_length.pod @@ -8,6 +8,8 @@ ASN1_STRING utility functions =head1 SYNOPSIS + #include openssl/asn1.h + int ASN1_STRING_length(ASN1_STRING *x); unsigned char * ASN1_STRING_data(ASN1_STRING *x); --- doc/crypto/ASN1_STRING_new.pod +++ doc/crypto/ASN1_STRING_new.pod @@ -7,6 +7,8 @@ ASN1_STRING allocation functions =head1 SYNOPSIS + #include openssl/asn1.h + ASN1_STRING * ASN1_STRING_new(void); ASN1_STRING * ASN1_STRING_type_new(int type); void ASN1_STRING_free(ASN1_STRING *a); --- doc/crypto/bn_internal.pod +++ doc/crypto/bn_internal.pod @@ -13,6 +13,8 @@ library internal functions =head1 SYNOPSIS + #include openssl/bn.h + BN_ULONG bn_mul_words(BN_ULONG *rp, BN_ULONG *ap, int num, BN_ULONG w); BN_ULONG bn_mul_add_words(BN_ULONG *rp, BN_ULONG *ap, int num, BN_ULONG w); --- doc/crypto/CRYPTO_set_ex_data.pod +++ doc/crypto/CRYPTO_set_ex_data.pod @@ -6,6 +6,8 @@ CRYPTO_set_ex_data, CRYPTO_get_ex_data - =head1 SYNOPSIS + #include openssl/crypto.h + int CRYPTO_set_ex_data(CRYPTO_EX_DATA *r, int idx, void *arg); void *CRYPTO_get_ex_data(CRYPTO_EX_DATA *r, int idx); --- doc/crypto/OBJ_nid2obj.pod +++ doc/crypto/OBJ_nid2obj.pod @@ -8,6 +8,8 @@ functions =head1 SYNOPSIS + #include openssl/objects.h + ASN1_OBJECT * OBJ_nid2obj(int n); const char * OBJ_nid2ln(int n); const char * OBJ_nid2sn(int n); --- doc/crypto/PKCS7_decrypt.pod +++ doc/crypto/PKCS7_decrypt.pod @@ -6,7 +6,9 @@ PKCS7_decrypt - decrypt content from a P =head1 SYNOPSIS -int PKCS7_decrypt(PKCS7 *p7, EVP_PKEY *pkey, X509 *cert, BIO *data, int flags); + #include openssl/pkcs7.h + + int PKCS7_decrypt(PKCS7 *p7, EVP_PKEY *pkey, X509 *cert, BIO *data, int flags); =head1 DESCRIPTION --- doc/crypto/PKCS7_encrypt.pod +++ doc/crypto/PKCS7_encrypt.pod @@ -6,7 +6,9 @@ PKCS7_encrypt - create a PKCS#7 envelope =head1 SYNOPSIS -PKCS7 *PKCS7_encrypt(STACK_OF(X509) *certs, BIO *in, const EVP_CIPHER *cipher, int flags); + #include openssl/pkcs7.h + + PKCS7 *PKCS7_encrypt(STACK_OF(X509) *certs, BIO *in, const EVP_CIPHER *cipher, int flags); =head1 DESCRIPTION --- doc/crypto/PKCS7_sign.pod +++ doc/crypto/PKCS7_sign.pod @@ -6,7 +6,9 @@ PKCS7_sign - create a PKCS#7 signedData =head1 SYNOPSIS -PKCS7 *PKCS7_sign(X509 *signcert, EVP_PKEY *pkey, STACK_OF(X509) *certs, BIO *data, int flags); + #include openssl/pkcs7.h + + PKCS7 *PKCS7_sign(X509 *signcert, EVP_PKEY *pkey, STACK_OF(X509) *certs, BIO *data, int flags); =head1 DESCRIPTION --- doc/crypto/PKCS7_verify.pod +++ doc/crypto/PKCS7_verify.pod @@ -6,9 +6,11 @@ PKCS7_verify - verify a PKCS#7 signedDat =head1 SYNOPSIS -int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, BIO *indata, BIO *out, int flags); + #include openssl/pkcs7.h -STACK_OF(X509) *PKCS7_get0_signers(PKCS7 *p7, STACK_OF(X509) *certs, int flags); + int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, BIO *indata, BIO *out, int flags); + + STACK_OF(X509) *PKCS7_get0_signers(PKCS7 *p7, STACK_OF(X509) *certs, int flags); =head1 DESCRIPTION --- doc/crypto/SMIME_read_PKCS7.pod +++ doc/crypto/SMIME_read_PKCS7.pod @@ -6,7 +6,9 @@ SMIME_read_PKCS7 - parse S/MIME message. =head1 SYNOPSIS -PKCS7 *SMIME_read_PKCS7(BIO *in, BIO **bcont); + #include openssl/pkcs7.h + + PKCS7 *SMIME_read_PKCS7(BIO *in, BIO **bcont); =head1 DESCRIPTION --- doc/crypto/SMIME_write_PKCS7.pod +++ doc/crypto/SMIME_write_PKCS7.pod @@ -6,7 +6,9 @@ SMIME_write_PKCS7 - convert PKCS#7 struc =head1 SYNOPSIS -int SMIME_write_PKCS7(BIO *out, PKCS7 *p7, BIO *data, int flags); + #include openssl/pkcs7.h + + int SMIME_write_PKCS7(BIO *out, PKCS7 *p7, BIO *data, int flags); =head1 DESCRIPTION --- doc/crypto/ui_compat.pod +++ doc/crypto/ui_compat.pod @@ -7,6 +7,8 @@ Compatibility user interface functions =head1 SYNOPSIS + #include openssl/des_old.h + int des_read_password(DES_cblock *key,const char *prompt,int verify); int des_read_2passwords(DES_cblock *key1,DES_cblock *key2, const char *prompt,int verify); --- doc/crypto/X509_NAME_add_entry_by_txt.pod +++
Re: ts/*.c files
On Wednesday 15 February 2006 06:04, Gisle Vanem wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 14 February 2006 11:26, Gisle Vanem wrote: Some of the new ts/ files are too long for a 8+3 filesystem. a ton of files are too long for 8+3 filesystem in the openssl tarball None of the *.[ch] files. They are all 8+3 unique AFAICS (and that's pretty unusual these days). there are a bunch of .c and .h files ... simply run something like: find -name '*.c' -o -name '*.h' and you'll see a lot more than the ts ones -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ts/*.c files
On Tuesday 14 February 2006 11:26, Gisle Vanem wrote: Some of the new ts/ files are too long for a 8+3 filesystem. a ton of files are too long for 8+3 filesystem in the openssl tarball -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1283] force C locale when using [a-z] in sed expressions
simple patch ... the current config script does not force LC_ALL=C when running sed with [a-z] ... this will break in some locales where Z is not the last letter -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1277] add support for m68k linux
attached patch is against current cvs head to add support for m68k linux targets -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rpath-ing openssl
On Saturday 14 January 2006 12:02, Lee Thompson wrote:
How does this approach look? Should be more generic.
looks much more sane
+# --with-rpath Use rpath linking, only makes sense with the use of
shared.
might want to say the shared libraries or the shared option
+# Default is to not use. If specified without a
value, it
+# guesses the gnu linker -Wl,-R${prefix}/lib
switch
might want to add a third check as it's a bit unintuitive that you're setting
the *ldflags* rather than just the path ...
--with-rpath=-Wl,-R/booga
elsif (/^--with-rpath=-(.*)$/)
$sldflags.=$1. ;
--with-rpath=/booga
elsif (/^--with-rpath=(.*)$/)
$sldflags.=-Wl,-R$1. ;
--with-rpath
elsif (/^--with-rpath$/)
$sldflags.=-Wl,-R$prefix/lib ;
-mike
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: rpath-ing openssl
On Friday 13 January 2006 01:48, Lee Thompson wrote: I'd be interested in your thoughts on this approach. well your hardcoding of -Wl,-R/opt/assembly/lib in the linux-elf-rpath line certainly wont work ... -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rpath-ing openssl
On Friday 13 January 2006 11:38, Lee Thompson wrote: The code certainly runs so is your issue a point of coding style? just because the path is correct on your machine has no relevance to anyone else, and forcing people to install into /opt/assembly/lib wont fly -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 02:39:47PM +0100, Dirk Mueller wrote: Ok, thanks for your help and the hint. I'd like to suggest the following patch for inclusion into OpenSSL. thanks, we've just been forcing -Wa,--noexecstack in Gentoo ... this is much nicer :) btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to generate some source files which are included in the final lib, it'll force back in exec stack markings ... %ifidn __OUTPUT_FORMAT__,elf section .note.GNU-stack noalloc noexec nowrite progbits %endif -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 03:21:20PM +0100, Dirk Mueller wrote: On Wednesday 09 November 2005 15:15, Mike Frysinger wrote: btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to generate some source files which are included in the final lib, it'll force back in exec stack markings ... It doesn't seem to be used here. i wasnt suggesting it was, just saying that 'hey, just in case, why the hell note' :) can you confirm that the stack is nonexecutable on your platform if you apply just the patch I posted? with openssl-0.9.8a/x86 your patch fixes GNU_STACK markings for me x86_64/ia64 though need another fix ... -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 05:38:39PM +0100, Andy Polyakov wrote: (and doesn't affect any non-linux platform anyway). How come it turns from unsure should be portable to definitive doesn't affect so easily:-) it should be portable across all ELF targets ... after all, you're just adding an elf program header which any elf loader worth its salt would ignore if it didnt support it the code itself though would require GNU as ... but i havent poked through the code before so maybe that requirement is already covered ? But anyway. My vote goes to alternative method, which can be deployed as easily as './config -Wa,--noexecstack' prior make. or maybe add it to the default configure code as a normal check ? i'm pretty sure there is no case where you wouldnt want to use the flag if your toolchain supported it -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote: the appended patch makes libcrypto.so compile without executable stack requirements. it should be portable accross all versions of binutils (and doesn't affect any non-linux platform anyway). it will break non-ELF builds though (but maybe the script isnt used for non-ELF targets so thats OK?) -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: cross compiling openssl for arm
On Thursday 06 October 2005 04:58 am, Anil Gunturu wrote: I am having trouble compiling compiling openssl for linux arm? I have added a target for linux-arm-elf (similar to linux-elf), but got rid of references to x86 why ? a linux-elf-arm target already exists ... i use it to cross-compile for arm all the time -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: cross compiling openssl for arm
On Thursday 06 October 2005 01:44 pm, Anil Gunturu wrote: Looks like latest openssl-0.9.8 doesn't have it this is why more details is better :p with 0.9.8, a lot of the linux targets were consolidated ... so try running: ./Configure linux-generic32 -DL_ENDIAN ... -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Using bzip2 for openssl.org downloads (was: Re: Using 7-Zip compressing for OpenSSL sources)
On Saturday 03 September 2005 03:19 pm, Dan Kegel wrote: Denis Andreevich wrote: Ok... ok... If you do not want use 7zip because it is win-app, 7zip is hardly standard and rarely found on any machine, regardless of operating system but why you don't want use standard tool like bzip2? Now you're asking the right question. openssl.org should consider offering sources in bzip2 format. yeah, i love when people provide .tar.bz2 archives along with .tar.gz -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1152] add support for Linux on SuperH
find attached a small patch which detects endian settings when building on SuperH machines ... this applies cleanly to cvs HEAD and the 0.9.8 branch but needs a little manual intervention for 0.9.7 branch -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [ANNOUNCE] OpenSSL 0.9.8 beta 5 released
On Monday 13 June 2005 12:19 am, Richard Levitte - VMS Whacker wrote:
OpenSSL version 0.9.8 Beta 5
`./config make make test` passed on Gentoo/armel
Gentoo/armeb failed the x509 certificate test ('test_ss') due to lack of
enough random data, but i'm pretty sure that's a system issue and unrelated
to openssl ;)
-mike
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8 API/ABI compatibility with 0.9.7 ?
On Thursday 09 June 2005 12:37 pm, Eduardo Pérez wrote: see the fun people had in upgrading from 0.9.7e to 0.9.7[fg] on x86_64 linux Wow!!! I didn't know there were breakage even there. But, that wasn't made on purpose, was it? no, i'm pretty sure it was just a simple mistake that is fixed in the current 0.9.7 branch ... then again i really havent researched beyond fixing it in Gentoo ... Do you know if there are more people interested in keeping API/ABI compatible? you're overlooking the fact that the soname is set to the full version of the library ... when you go to link with -lcrypto, the libname 'libcrypto.so.0.9.7' is recorded in the NEEDED section of the elf instead of 'libcrypto.so.0' ... so unless you have 0.9.8 install its library as 'libcrypto.so.0.9.8' (which it wont), applications are going to break -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificate verify failed on big-endian (Intel IXP425)
On Thursday 26 May 2005 08:43 am, vijay basav wrote: in Configure file chnge DL_ENDIAN(little endian) to DB_ENDIAN(big endian) and EL to EB the Configure script in the latest 0.9.7 version (i.e. g) does not set ENDIAN for arm targets ... it's been moved to the config script -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificate verify failed on big-endian (Intel IXP425)
On Wednesday 25 May 2005 09:11 am, Cesc wrote: I have done some more research and after seeing that the ssl code works on a little endian pc with 0.9.6, the problem is: - with the big-endian Intel IXP425 ARM running 0.9.6 - the code of the application (SER, voip proxy, with TLS). i posted some fixes a while ago for 0.9.7e which were accepted and are in 0.9.7g ... openssl configured all arm targets as little endian which is why it was failing -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1064] [patch] fix pointer truncating in ssl/ssltest.c
just a minor patch by Daniel Gryniewicz to fix truncating pointers on 64bit systems this is against cvs head and applies cleanly to 0.9.7g -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #990] [patch] update PARISC on Linux support
On Thursday 20 January 2005 10:21 am, Andy Polyakov via RT wrote: Just to double-check. Does parisc64 linux support 32-bit API? Is following statement true: even though parisc64 is recognized generated code is 32-bit one? Is following statement true: apparently there is no interest for 64-bit parisc64 build, which is unsupported? A. 32bit userspace works fine with 64bit kernelspace on parisc i dont believe anyone is doing any serious development (if any is being done at all) atm wrt to 64bit userspace on linux, but hpux supports it ... so yes, at this point in time, it makes sense to assume parisc on linux is 32bit userspace -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
