Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher
On Fri, 2016-07-08 at 23:59 +0200, Kurt Roeckx wrote: > > Can you describe how DTLS1_BAD_VER is supposed to work? Is this > version send over the wire? Is it negotiated? It does indeed appear on the wire. In the AnyConnect/OpenConnect case — which, as you rightly observe, is the only remaining user of this version of the protocol — it's not actually negotiated in the normal sense at all; we "resume" a session having established the master secret and session-id over a separate channel. http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/dtls.c#l157 > We have no test suite coverage doing anything with DTLS1_BAD_VER > and I think the OpenConnect VPN is the only user of it. Yeah, test coverage would be useful... I'm not sure how complete our *server* side support of DTLS1_BAD_VER is. I did start looking at it briefly once, but got distracted. I'll have another look. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher
On Fri, Jul 08, 2016 at 05:43:21PM +0100, David Woodhouse wrote: > > This broke the OpenConnect VPN client, which now fails thus: > > DTLS handshake failed: 1 > 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers > available:ssl/statem/statem_clnt.c:927: > > I tried the naïvely obvious step of changing all instances of > DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help. Can you describe how DTLS1_BAD_VER is supposed to work? Is this version send over the wire? Is it negotiated? We have no test suite coverage doing anything with DTLS1_BAD_VER and I think the OpenConnect VPN is the only user of it. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher
On Fri, 2016-07-08 at 19:13 +, Viktor Dukhovni wrote: > > Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests > that you're actually doing a comparison. Well, 'cmp' with one argument isn't *so* easily interpreted as a comparison, but OK :) I've also added a comment explaining a little about what's going on. > Given this macro, one > might consider complementing the versions, so that the ordinals > compare in the usual way: > > #define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0x ^ > (v))) I suppose we can, if someone feels strongly about it. It didn't seem worth the additional churn. One of 4 patches in https://github.com/openssl/openssl/pull/1296 which actually make OpenConnect work again... -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Fix missing return value checks in SCTP
On Tue, 2015-08-11 at 19:36 +0100, Matt Caswell wrote:
> There are some missing return value checks in the SCTP code. In master this
> was causing a compilation failure when config'd with
> "--strict-warnings sctp".
>
> Reviewed-by: Tim Hudson
> ---
> ssl/d1_clnt.c | 16
> ssl/d1_srvr.c | 18 +-
> 2 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/ssl/d1_clnt.c b/ssl/d1_clnt.c
> index 566c154..d411614 100644
> --- a/ssl/d1_clnt.c
> +++ b/ssl/d1_clnt.c
> @@ -364,11 +364,15 @@ int dtls1_connect(SSL *s)
> sizeof(DTLS1_SCTP_AUTH_LABEL),
> DTLS1_SCTP_AUTH_LABEL);
>
> -SSL_export_keying_material(s, sctpauthkey,
> +if (SSL_export_keying_material(s, sctpauthkey,
> sizeof(sctpauthkey),
> labelbuffer,
> sizeof(labelbuffer), NULL, 0,
> - 0);
> + 0) <= 0) {
> +ret = -1;
> +s->state = SSL_ST_ERR;
> +goto end;
> +}
>
> BIO_ctrl(SSL_get_wbio(s),
> BIO_CTRL_DGRAM_SCTP_ADD_AUTH_KEY,
This commit (d8e8590e) and its backport to 1.0.2 (b3a62dc0) have broken
OpenConnect when SCTP is enabled, because SSL_export_keying_material()
*does* fail there. Perhaps it shouldn't...
diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index 08e3673..6db4f3a 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -2231,7 +2231,7 @@ int SSL_export_keying_material(SSL *s, unsigned char
*out, size_t olen,
const unsigned char *p, size_t plen,
int use_context)
{
-if (s->version < TLS1_VERSION)
+if (s->version < TLS1_VERSION && s->version != DTLS1_BAD_VER)
return -1;
return s->method->ssl3_enc->export_keying_material(s, out, olen, label,
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher
On Fri, Jul 08, 2016 at 07:30:26PM +0100, David Woodhouse wrote: > > I tried the naïvely obvious step of changing all instances of > > DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help. > > Of course, it's because DTLS_VERSION_LT and friends are doing precisely > the opposite of what their names imply, numerically. I hesitate to call > this a 'fix' but it highlights the issue: Yes, unfortunately, the DTLS "bad" version of 0x0100 looks like a very high DTLS version. So comparisons require a special case. Given that DTLS1_VERSION is 0xFEFF, indeed the next "lower" version is 0xFF00 as you suggest below: > diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h > index ef5eb8c..218dcce 100644 > --- a/ssl/ssl_locl.h > +++ b/ssl/ssl_locl.h > @@ -259,10 +259,11 @@ >c[1]=(unsigned char)(((l)>> 8)&0xff), \ >c[2]=(unsigned char)(((l))&0xff)),c+=3) > > -#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2)) > -#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2)) > -#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2)) > -#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2)) > +#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1)) > +#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2)) > +#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2)) > +#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2)) > +#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2)) Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests that you're actually doing a comparison. Given this macro, one might consider complementing the versions, so that the ordinals compare in the usual way: #define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0x ^ (v))) -- Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct?
Brian Smith wrote: > When doing math on short Weierstrass curves like P-256, we have to > special case points at infinity. In Jacobian coordinates (X, Y, Z), > points at infinity have Z == 0. However, instead of checking for Z == > 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it > does, in some sense, the opposite of what I expect it to do. > I exchanged email with both of the original authors of the code, Shay and Vlad. He that the ecp_nistz256_point_* functions indeed intend to represent the point at infinity as (0, 0) and it is expected (but I did not verify) that those functions should work when the point at infinity is encoded as (0, 0, _). The authors > instead decided to encode the point at infinity as (0, 0), since the > affine point (0, 0) isn't on the P-256 curve. It isn't clear why the > authors chose to do that though, since the point at infinity doesn't > (can't, logically) appear in the table of precomputed multiples of G > anyway. Actually, as the code says, the point at infinity implicitly occurs in the table implicitly. Obviously the accumulator point will be at infinity until at least a one bit is found in the scalar. > But, it seems like the functions that do the computations, like > ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the > point at infinity as (_, _, 0), not necessarily (0, 0, _). Also, > ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and > ec_GFp_simple_point_set_to_infinity, which represent the point at > infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine > uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0. > This inconsistency is confusing, if not wrong. Given this, it seems > like the point-at-infinity checks in the ecp_nistz256_point_add and > ecp_nistz256_point_add_affine code should also be checking that z == 0 > instead of (x, y) == (0, 0). > Instead, when we convert a point from EC_POINT to P256_POINT or P256_POINT_AFFINE, we should translate the (_, _, 0) form into the (0, 0, 0) form. And/or reject points at infinity as inputs to the function. Similarly, when we convert the resultant P256_POINT to an EC_POINT, we chould translate the (0, 0) encoding of the point at infinity to the (0, 0, 0) form or at least the (_, _, 0) form. In particular, consider the case where you have an EC_POINT that isn't at infinity, e.g. (x, y, 1). Then you call EC_POINT_set_to_infinity on it. Then it is (x, y, 0). Then you pass it to EC_POINT_mul/EC_POINTs_mul even though you shouldn't. Maybe the precondition of EC_POINT_mul/EC_POINTs_mul is that none of the input points are at infinity, in which case it doesn't matter. (But if so, maybe these functions should do a point-at-infinity check.) But if it is allowed to pass in the point at infinity, then the ecp_nistz256 code should translate the input point from (_, _, 0) form to (0, 0, _) form before doing the computation. It can use is_zero and copy_conditional and friends to do this. Similarly, after the computation, it should translate the (0, 0, _) form to (_, _, 0) form. In particular, it should do such a translation before the code sets Z_is_one, AFAICT. Note that the nistz256 code might be using the form (0, 0, 0) instead of (0, 0, _) in which case this translation might not be necessary. Regardless, it would be useful to write tests for these cases: 1. Verify that the result is correct when any of the input points are (0, 0, 0) 2. Verify that the result is correct when any of the input points are (_, _, 0). 3. Verify that the result is correct, and in particular that Z_is_one is set correctly on the result, when the final result is at infinity, especially for the cases where neither the input points are at infinity, e.g. when adding (n-1)G to 1G. Note that all of the above cases have interesting sub-cases: the G scalar is NULL, the G scalar is non-NULL and zero-valued, G scalar is a multiple of G, G scalar is larger than G. And same for the P scalars. Cheers, Brian -- https://briansmith.org/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher
On Fri, 2016-07-08 at 17:43 +0100, David Woodhouse wrote:
> On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> > Reviewed-by: Viktor Dukhovni
> >
> > MR: #1595
> > ---
> > ssl/s3_lib.c | 534
> > +++
> > ssl/ssl_ciph.c | 196 +
> > ssl/ssl_lib.c | 4 +-
> > ssl/ssl_locl.h | 21 +-
> > ssl/ssl_txt.c | 2 +-
> > ssl/statem/statem_clnt.c | 18 +-
> > ssl/statem/statem_lib.c | 6 +-
> > ssl/t1_lib.c | 41 ++--
> > 8 files changed, 504 insertions(+), 318 deletions(-)
> >
> > diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> > index 51fb161..093ff09 100644
> > --- a/ssl/s3_lib.c
> > +++ b/ssl/s3_lib.c
> > @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
> > SSL_aRSA,
> > SSL_eNULL,
> > SSL_MD5,
> > - SSL_SSLV3,
> > + SSL3_VERSION, TLS1_2_VERSION,
> > + DTLS1_VERSION, DTLS1_2_VERSION,
>
> This broke the OpenConnect VPN client, which now fails thus:
>
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers
> available:ssl/statem/statem_clnt.c:927:
>
> I tried the naïvely obvious step of changing all instances of
> DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.
Of course, it's because DTLS_VERSION_LT and friends are doing precisely
the opposite of what their names imply, numerically. I hesitate to call
this a 'fix' but it highlights the issue:
diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
index ef5eb8c..218dcce 100644
--- a/ssl/ssl_locl.h
+++ b/ssl/ssl_locl.h
@@ -259,10 +259,11 @@
c[1]=(unsigned char)(((l)>> 8)&0xff), \
c[2]=(unsigned char)(((l))&0xff)),c+=3)
-#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2))
-#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2))
-#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2))
-#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2))
+#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1))
+#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2))
+#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2))
+#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2))
+#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2))
/* LOCAL STUFF */
>
> Having said that, reverting this change isn't *sufficient* to fix
> OpenSSL 1.1; it still fails with
>
> DTLS handshake failed: 1
> 67609664:error:14160098:SSL routines:read_state_machine:excessive message
> size:ssl/statem/statem.c:586:
>
> ... which goes back to before 1.1.0-pre1. I'll find that one later...
That one's simpler:
diff --git a/ssl/statem/statem_clnt.c b/ssl/statem/statem_clnt.c
index 26c4d10..b2160cd 100644
--- a/ssl/statem/statem_clnt.c
+++ b/ssl/statem/statem_clnt.c
@@ -704,6 +704,8 @@ unsigned long ossl_statem_client_max_message_size(SSL *s)
return SERVER_HELLO_DONE_MAX_LENGTH;
case TLS_ST_CR_CHANGE:
+if (s->client_version == DTLS1_BAD_VER)
+return 3;
return CCS_MAX_LENGTH;
case TLS_ST_CR_SESSION_TICKET:
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold
On Fri, Jul 8, 2016 at 8:33 AM, Salz, Rich via RT wrote: > I don't know what you expect us to do. We don't use the LD variable. Right. I'm just pointing out gaps. It only gets worse for users. What happens when someone tries a cross-compile by setting CC, AR, RANLIB, LD and a CFLAGS with --sysroot? As far as I know, there is no RTFM for cross-compiles. Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 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] [PATCH] Add support for minimum and maximum protocol version supported by a cipher
On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> Reviewed-by: Viktor Dukhovni
>
> MR: #1595
> ---
> ssl/s3_lib.c | 534
> +++
> ssl/ssl_ciph.c | 196 +
> ssl/ssl_lib.c | 4 +-
> ssl/ssl_locl.h | 21 +-
> ssl/ssl_txt.c | 2 +-
> ssl/statem/statem_clnt.c | 18 +-
> ssl/statem/statem_lib.c | 6 +-
> ssl/t1_lib.c | 41 ++--
> 8 files changed, 504 insertions(+), 318 deletions(-)
>
> diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> index 51fb161..093ff09 100644
> --- a/ssl/s3_lib.c
> +++ b/ssl/s3_lib.c
> @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
> SSL_aRSA,
> SSL_eNULL,
> SSL_MD5,
> - SSL_SSLV3,
> + SSL3_VERSION, TLS1_2_VERSION,
> + DTLS1_VERSION, DTLS1_2_VERSION,
This broke the OpenConnect VPN client, which now fails thus:
DTLS handshake failed: 1
67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers
available:ssl/statem/statem_clnt.c:927:
I tried the naïvely obvious step of changing all instances of
DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.
Having said that, reverting this change isn't *sufficient* to fix
OpenSSL 1.1; it still fails with
DTLS handshake failed: 1
67609664:error:14160098:SSL routines:read_state_machine:excessive message
size:ssl/statem/statem.c:586:
... which goes back to before 1.1.0-pre1. I'll find that one later...
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4592] [docs] SSL_set_app_data() returns 'int', not 'void'
fixed in master. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4592 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 #4609] Configure does not honor requests for ld.gold
I don't know what you expect us to do. We don't use the LD variable. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4610] Incorrect handling of malformed Client Key Exchange messages for ECDHE_RSA key exchange
Current 1.0.1, 1.0.2 and master don't handle malformed Client Key Exchange messages correctly. when a malformed message, or message with incorrect parameters is received openssl server just closes the connection instead of sending an Alert message reproducer script: https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-ecdhe-rsa-key-exchange-with-bad-messages.py to reproduce: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch openssl s_server -key localhost.key -cert localhost.crt -www 2>server.err >server.out & openssl_pid=$! git clone https://github.com/tomato42/tlsfuzzer pushd tlsfuzzer git clone https://github.com/tomato42/tlslite-ng .tlslite-ng ln -s .tlslite-ng/tlslite tlslite git clone https://github.com/warner/python-ecdsa .python-ecdsa ln -s .python-ecdsa/ecdsa ecdsa PYTHONPATH=. python scripts/test-ecdhe-rsa-key-exchange-with-bad-messages.py popd kill $openssl_pid -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4610 Please log in as guest with password guest if prompted signature.asc Description: PGP signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MGF1-OAEP with SHA2
On Thu, Jul 07, 2016, c.hol...@ades.at wrote: > > I try to get RSA enryption/decryption (over the API) with MGF1 > OAEP-padding other then SHA1. > You need to use the EVP_PKEY API and pass the required algotithm to EVP_PKEY_CTX_set_rsa_oaep_md() which is currently undocumented (fix coming up). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold
On Fri Jul 08 09:33:01 2016, noloa...@gmail.com wrote: > Hmmm... If I want to use ld.gold as my linker, the easiest path is to > set LD=ld.gold. It makes perfect sense to some Did it work for you when doing this? ./config -fuse-ld=gold -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 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 #4609] Configure does not honor requests for ld.gold
On Fri, Jul 8, 2016 at 4:33 AM, Richard Levitte via RT wrote: > On Fri Jul 08 07:47:14 2016, noloa...@gmail.com wrote: >> $ ./config LD=ld.gold >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) >> target already defined - linux-x86_64 (offending arg: LD=ld.gold) >> >> And: >> >> $ LD=ld.gold ./config >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> ... >> >> $ cat Makefile | grep ld.gold >> $ cat Makefile.shared | grep ld.gold >> $ >> >> I don't believe CFLAG -fuse-ld=gold is an option because the linker is >> invoked directly rather than using the compiler driver. (Or at least >> it used to be that way). > > 'ld' is only used in one case, in Makefile.shared. That's for AIX, when > building shared objects directly from object files instead of going from the > static library. Therefore, trying to set LD makes absolutely no sense. Hmmm... If I want to use ld.gold as my linker, the easiest path is to set LD=ld.gold. It makes perfect sense to some > Also, please please please read INSTALL, it tells you what environment > variables are considered by the configuration scripts, and please please > please > understand that our configuration scripts are not autoconf generated ones and > currently do not understand 'FOO=value' arguments. This has been pointed out > quite a few times already. Why be normal :) ... but I understand why it does not make perfect sense to others. Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold
On Fri Jul 08 07:47:14 2016, noloa...@gmail.com wrote: > $ ./config LD=ld.gold > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) > target already defined - linux-x86_64 (offending arg: LD=ld.gold) > > And: > > $ LD=ld.gold ./config > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > ... > > $ cat Makefile | grep ld.gold > $ cat Makefile.shared | grep ld.gold > $ > > I don't believe CFLAG -fuse-ld=gold is an option because the linker is > invoked directly rather than using the compiler driver. (Or at least > it used to be that way). 'ld' is only used in one case, in Makefile.shared. That's for AIX, when building shared objects directly from object files instead of going from the static library. Therefore, trying to set LD makes absolutely no sense. Also, please please please read INSTALL, it tells you what environment variables are considered by the configuration scripts, and please please please understand that our configuration scripts are not autoconf generated ones and currently do not understand 'FOO=value' arguments. This has been pointed out quite a few times already. That being said, have you tried the following (the configuration scripts will assume that any argument starting with a dash that they don't understand internally are to be taken as C flags... this too has been pointed out before)? ./config -fuse-ld=gold Cheers, Richard -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold
$ ./config LD=ld.gold Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) target already defined - linux-x86_64 (offending arg: LD=ld.gold) And: $ LD=ld.gold ./config Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 ... $ cat Makefile | grep ld.gold $ cat Makefile.shared | grep ld.gold $ I don't believe CFLAG -fuse-ld=gold is an option because the linker is invoked directly rather than using the compiler driver. (Or at least it used to be that way). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
