Нет способа помешать SSL_set_bio
освободить текущий BIO в общедоступном API.Вы можете увидеть в исходном коде, что он просто проверяет, является ли каждая биография не нулевым, а затем освобождает ее.
Основная идея заключается в том, что после вызова SSL_set_bio
OpenSSL владеет BIO и отвечает за него.
void SSL_set_bio(SSL *s,BIO *rbio,BIO *wbio)
{
/* If the output buffering BIO is still in place, remove it
*/
if (s->bbio != NULL)
{
if (s->wbio == s->bbio)
{
s->wbio=s->wbio->next_bio;
s->bbio->next_bio=NULL;
}
}
if ((s->rbio != NULL) && (s->rbio != rbio))
BIO_free_all(s->rbio);
if ((s->wbio != NULL) && (s->wbio != wbio) && (s->rbio != s->wbio))
BIO_free_all(s->wbio);
s->rbio=rbio;
s->wbio=wbio;
}
Если бы у меня была законная причина сохранить биобуфер в производственном коде, я бы написал свою биографию и использовал бы ее.Это не так сложно, как кажется.Просто скопируйте <openssl source>/crypto/bio/bss_mem.c
, переименуйте функции и таблицу mem_method
, а затем замените поведение mem_free()
.Затем вместо BIO_s_mem
, передайте BIO_custom_mem_bio
или как вы называете функцию доступа для вашей биографии.
Если бы я нуждался в ней для целей отладки, а не для производственного кода, я бы, вероятно, просто впал во внутренниеssl_st
struct (SSL *
) и сделать все bios NULL перед вызовом SSL_set_bio
.Но я бы не стал этого делать в рабочем коде, потому что будущие версии SSL могут нарушить этот код.