Así que tengo un ejemplo muy básico de hablar con un servidor de Facebook sobre https, pero valgrind se queja con tristeza. Así que supongo que no estoy configurando algo incorrectamente ... ¿Alguien sabe lo que estoy haciendo mal?valgrind informa problemas con libcurl al usar https
Aquí está mi código:
#include <string>
#include <iostream>
#include <curl/curl.h>
size_t write_fn_impl(void* ptr, size_t size, size_t nmemb, void * data)
{
std::string * result = static_cast<std::string*>(data);
*result += std::string((char*)ptr, size*nmemb);
return size*nmemb;
}
int main()
{
std::string url_full="https://graph.facebook.com/me";
std::string useragent = "Facebook API C++ Client (curl)";
CURL * ch_ = curl_easy_init();
char error_buffer[CURL_ERROR_SIZE];
curl_easy_setopt(ch_, CURLOPT_ERRORBUFFER, error_buffer);
curl_easy_setopt(ch_, CURLOPT_WRITEFUNCTION, &write_fn_impl);
std::string result;
curl_easy_setopt(ch_, CURLOPT_WRITEDATA, &result);
int id = 1;
curl_easy_setopt(ch_, CURLOPT_VERBOSE, id);
curl_easy_setopt(ch_, CURLOPT_URL, url_full.c_str());
curl_easy_setopt(ch_, CURLOPT_USERAGENT, useragent.c_str());
curl_easy_setopt(ch_, CURLOPT_CONNECTTIMEOUT, 10);
curl_easy_setopt(ch_, CURLOPT_TIMEOUT, 30);
curl_easy_perform(ch_);
curl_easy_cleanup(ch_);
std::cout<< result<<std::endl;
}
Y lo que dice es valgrind:
==14149== Memcheck, a memory error detector
==14149== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==14149== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==14149== Command: ./a.out
==14149==
* About to connect() to graph.facebook.com port 443 (#0)
* Trying 66.220.146.47... * connected
* Connected to graph.facebook.com (66.220.146.47) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
==14149== Syscall param write(buf) points to uninitialised byte(s)
==14149== at 0x4268113: __write_nocancel (in /lib/tls/i686/cmov/libc-2.10.1.so)
==14149== by 0x44A5A8E: BIO_write (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x43E49B8: ssl23_write_bytes (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x43E39AB: ssl23_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x43F0D49: SSL_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x4050EB0: ossl_connect_common (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4052202: Curl_ossl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x406597F: Curl_ssl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x403FF1B: Curl_http_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4046F6D: Curl_protocol_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x404C396: Curl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4059B23: Curl_perform (in /usr/lib/libcurl.so.4.1.1)
==14149== Address 0x47e92df is 15 bytes inside a block of size 21,848 alloc'd
==14149== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==14149== by 0x4446EFD: ??? (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x444755B: CRYPTO_malloc (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x44A4EF7: BUF_MEM_grow (in /lib/i686/cmov/libcrypto.so.0.9.8)
==14149== by 0x43E3BAB: ssl23_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x43F0D49: SSL_connect (in /lib/i686/cmov/libssl.so.0.9.8)
==14149== by 0x4050EB0: ossl_connect_common (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4052202: Curl_ossl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x406597F: Curl_ssl_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x403FF1B: Curl_http_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x4046F6D: Curl_protocol_connect (in /usr/lib/libcurl.so.4.1.1)
==14149== by 0x404C396: Curl_connect (in /usr/lib/libcurl.so.4.1.1)
y las páginas más ....
ese artículo era interesante, pero no tiene en cuenta el hecho de que valgrind * descubrió efectivamente un error * en OpenSSL. OpenSSL estaba (y probablemente aún lo es) dependiendo de * comportamiento indefinido * como fuente de entropía, en lugar de obtener entropía de una fuente legítima. El mismo "error" que Debian agregó podría haber aparecido tan fácilmente en los cambios del compilador o de la biblioteca que hicieron que los datos no inicializados OpenSSL fueran "menos aleatorios". En resumen, si valgrind está reportando problemas como este, seguramente significa que el código * está mal *, pero la solución trivial podría ser aún peor. :-) –
@R No recuerdo los detalles, pero creo que su interpretación es un poco desalentadora. Mi recuerdo es que no confiaron en la memoria no inicializada, sino que la solución eliminó accidentalmente otra fuente de entropía "real" junto con ella. Mi recuerdo es vago ... pero la conclusión sigue siendo válida: no te metas con OpenSSL. –
@MK: según el artículo, el problema tiene que ver más con un desarrollador que intenta una solución de "estimación educada" que con cualquier otra cosa. Si la lib venía con un archivo de supresión de valgrind adecuado que indicaba que se trataba de un comportamiento intencionado (o un comentario en el código), o si el desarrollador había revisado el "error" con los desarrolladores de OpenSSL y les había pedido consejo, no habría habido cualquier problema. Moraleja de la historia: se necesita más que una herramienta para corregir errores ... ¿pero no sabíamos eso ya? –