I already wrote into webrtc google webgroup but nobody can't help me. I am in a problem and here is best option for helping me. So my problem annoying me because from webrtc version 87 and down the problem does't exists, but from 88 and up openssl and boringssl messup with some functions.
For any versionI build webrtc in same few steps
1. edit webrtc.gni and set
rtc_use_dummy_audio_file_devices=true
rtc_builtin_ssl_root_certificates = false
rtc_ssl_root = "/usr/include" -for my system openssl header files
2. gn gen ~/webrtcm88 --args='target_os="linux" target_cpu="x64" enable_iterator_debugging=false is_component_build=false is_debug=false use_rtti=true use_custom_libcxx=false is_clang =false treat_warnings_as_errors=false rtc_build_ssl=false rtc_ssl_root="/usr/include"'
3.ninja -C ~/webrtcm88 protobuf_lite p2p base webrtc jsoncpp -j22
After step 3 libwebrtc.a is build and everything is fine up and running. My app use boost, websockets and other stuff and libwebrtc.a + libssl.a and libcrypto.a.- because I need some functions to use from openssl( to generate keys and other stuff), boost use openssl for ssl connections and etc.
Now I build and link myApp using these libs
LIBS = -lz -lstdc++ -lc -lrt -lboost_system -rdynamic -lwebsockets
-lboost_log_setup -lboost_regex -lboost_thread -lboost_chrono -lavcodec
-lavdevice -lavfilter -lavformat -lavutil -lswscale -lswresample -lvpx
-lcrypto -lssl -lwebrtc -ldl -lX11 -lpthread
Ok I link them using g++10, compile build and every step is OK UNTIL version 88. I dont realy know WHAT IS WRONG with this version. Yes, the building steps for libwebrtc.a are the same as I wrote above. No problem. No problem to build my app- in fact other two libs are included from 88 version lgobject-2.0 -lglib-2.0. Build is OK.
But when I runn my program, when I start using my program (wirten in C++) I have functions using openssl and one of them use ECDSA_do_sign. When hit this function CRASH with SIGSEGV- yes segmentation fault. This function WORKS perfeclty with 87, 86, 85,84... I DONT KNOW WHAT REALYY HAPPEN and why with version 88,89,90 everythink go CRASH.
When I compile myapp with libwebrtc.a version m88 and m89, then nm my binary
nm -C myapp | grep ECDSA_do_sign
00000000011c2110 t ECDSA_do_sign
nm -C myapp | grep EC_GROUP_new_by_curve_name
00000000011ae150 t EC_GROUP_new_by_curve_name
and so on
When I compile my app with libwebrtc.a version m87 m86 m85...
nm -C myapp | grep ECDSA_do_sign
U ECDSA_do_sign@@OPENSSL_1_1_0
nm -C myapp | grep EC_GROUP_new_by_curve_name
U EC_GROUP_new_by_curve_name@@OPENSSL_1_1_0
It is obvious that 't' and 'U' are two cases and those functions with 't' are loaded not from openssl libs. How to resolve this problem- I want to use 88, 89, 90 versions of webrtc but I cant because of this linking.
something strange happen with new versions. There is no errors in build but when I try using ECDSA_do_sign, EC_GROUP_new_by_curve_name or other function from openssl libs, myapp crashes with SIGSEV
What I have tried:
this is a little part/fragment from my code using current openssl version (1.1.0 using libssl a libcrypto) using it from myApp. It is shown function called opensslecdsa_sign:
static
int
opensslecdsa_sign(popt_live_sig_alg_t alg,EVP_PKEY *pkey, EVP_MD_CTX *evp_md_ctx, Buffer *evb)
ECDSA_SIG *ecdsasig;
EC_KEY *eckey = EVP_PKEY_get1_EC_KEY(pkey);
unsigned
int
dgstlen, siglen;
unsigned
char
digest[EVP_MAX_MD_SIZE];
if
(eckey == NULL)
return
0
;
if
(alg == POPT_LIVE_SIG_ALG_ECDSAP256SHA256)
siglen = DNS_SIG_ECDSA256SIZE;
siglen = DNS_SIG_ECDSA384SIZE;
unsigned
char
*sigdata =
new
unsigned char[siglen];
if
(sigdata == NULL) {
EC_KEY_free(eckey);
return
0
;
if
(!EVP_DigestFinal(evp_md_ctx, digest, &dgstlen)) {
EC_KEY_free(eckey);
return
0
;
ecdsasig = ECDSA_do_sign(digest, dgstlen, eckey);
if
(ecdsasig == NULL) {
EC_KEY_free(eckey);
return
0
;
BN_bn2bin_fixed(ECDSA_SIG_get0_r(ecdsasig), sigdata, siglen /
2
);
BN_bn2bin_fixed(ECDSA_SIG_get0_s(ecdsasig), sigdata+siglen/2, siglen /
2
);
ECDSA_SIG_free(ecdsasig);
evb->AppendData(sigdata,siglen);
delete [] sigdata;
EC_KEY_free(eckey);
return
1
;
For version
88
89
and
90
when
hit ECDSA_do_sign: SIGNAL:
11
(Segmentation fault) address:
0x40000002a
from
:
0x5627158af081
but
for
version
87
,
86
,
85
,
84
... everything
is
OK
static
int
check_sign(Buffer *evb)
int
function_status = -1;
EC_KEY *eckey=EC_KEY_new();
if
(NULL == eckey)
printf(
"
Failed to create new EC Key\n"
);
function_status = -1;
EC_GROUP *ecgroup= EC_GROUP_new_by_curve_name(NID_secp192k1);
if
(NULL == ecgroup)
ERR_print_errors_fp(stderr);
printf(
"
Failed to create new EC Group\n"
);
function_status = -1;
int
set_group_status = EC_KEY_set_group(eckey,ecgroup);
const
int
set_group_success =
1
;
if
(set_group_success != set_group_status)
printf(
"
Failed to set group for EC Key\n"
);
function_status = -1;
const
int
gen_success =
1
;
int
gen_status = EC_KEY_generate_key(eckey);
if
(gen_success != gen_status)
printf(
"
Failed to generate EC Key\n"
);
function_status = -1;
ECDSA_SIG *signature = ECDSA_do_sign(evb->data(), evb->size(), eckey);
if
(NULL == signature)
printf(
"
Failed to generate EC Signature\n"
);
function_status = -1;
int
verify_status = ECDSA_do_verify(evb->data(), evb->size(), signature, eckey);
const
int
verify_success =
1
;
if
(verify_success != verify_status)
printf(
"
Failed to verify EC Signature\n"
);
function_status = -1;
printf(
"
Verifed EC Signature\n"
);
function_status =
1
;
EC_GROUP_free(ecgroup);
EC_KEY_free(eckey);
return
1
Again for version 88 89 and 90
when check ecgroup for NULL
139709136627456:error:0F071007:common libcrypto routines:get_and_lock:BUF lib:../crypto/ex_data.c:55:
139709136627456:error:0F00007B:common libcrypto routines:common libcrypto routines:reason(123):../../RawInstall/webrtcm88/src/third_party/boringssl/src/crypto/fipsmodule/ec/ec.c:520:
Failed to create new EC Group
but with 87,86,85,84... everything is OK with groups and Signatures
If the people who know the software best can't help you, why do you think we can?
If they can't get to the bottom of it you have two choices:
1) Use version 87.
2) Write a minimal app that shows the problem - absolute bare minimum code, nothing at all that isn't essential to making the problem happen. Check that it works with 87, and fails with 88. Submit it as a bug report to the authors.
We really can't help you, this isn't a "Quick answer" question in any way!
Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad
spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or
edit the question
and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it.
Provide an answer or move on to the next question.
Let's work to help developers, not make them feel stupid.
