修复 lj-cargo-5686192-0635719 问题 · Pull Request !14 · OpenHarmony/third_party_rust_rust-openssl

**关联issue** 
#I96JYC

**说明**
X509StoreRef::objects wraps X509_STORE_get0_objects. As OpenSSL documents:

X509_STORE_get0_objects() retrieves an internal pointer to the store's X509 object cache. The cache contains X509 and X509_CRL objects. The returned pointer must not be freed by the calling application.

https://www.openssl.org/docs/man3.0/man3/X509_STORE_get0_objects.html

As it's an internal cache, this is of course inappropriate for rust-openssl to export in a public API. In particular, other operations in OpenSS update that cache. The directory-based X509_LOOKUP adds things to the cache as it finds them:
https://github.com/openssl/openssl/blob/master/crypto/x509/by_dir.c#L332
https://github.com/openssl/openssl/blob/master/crypto/x509/by_file.c#L127
https://github.com/openssl/openssl/blob/master/crypto/x509/x509_lu.c#L430
https://github.com/openssl/openssl/blob/master/crypto/x509/x509_lu.c#L419

Although OpenSSL internally locks this, it cannot synchronize this with someone poking around with X509_STORE_get0_objects's return value. As a result, rust-openssl's API here is not safe: it takes a shared reference to the X509_STORE, but it races with APIs like X509StoreContextRef::init which also take a shared reference to the X509_STORE but may trigger the above code.

We just want to deprecate (or entirely remove?) this and expose an API based on X509_STORE_get1_all_certs, which I imagine is what everyone actually wants in the first place.

类型	指派人员	状态
审查	Xingwa 已审查通过 chenmudan	已完成 (1/1人)
测试	openharmony_ci 已测试通过	已完成 (1/1人)

OpenHarmony/third_party_rust_rust-openssl关闭 .gitee-modal { width: 500px !important; }

搜索帮助

OpenHarmony/third_party_rust_rust-openssl
关闭