secp256k1-sys: remove CPtr impl for &[T] and associated weirdness
#816
Conversation
In rust-bitcoin#794 I accidentally changed a *mut to *const. This is incorrect and unsound.
We take an optional `data` argument to `shared_secret`, but the upstream function we call never uses it. However, this argument *does* use the CPtr impl on &[T] in order to obtain a pointer to pass across the FFI boundary. This impl is very dangerous, and its use here is sound only because the resulting pointer is never used. See rust-bitcoin#627 (comment)
In sort_pubkeys() we convert a slice of PublicKeys to a slice of ffi::PublicKeys. This is OK, because we have repr(transparent) allowing us to do this. But we do so in an unnecessarily-complicated way, which winds up going through the CPtr implementation on &[u8], and which I think may technically be unsound. Simplify it and avoid using this impl. The next commit will remove it entirely.
|
I am equivocating on whether I should backport the last commit to secp256k1-sys 0.9.x, 0.10.x and 0.11.x. Doing so would be a breaking change (and would break rust-secp256k1, necessitating a minor release of those) and technically speaking there is no unsoundness here so it is not urgent to do so. But on the other hand, |
|
For anyone struggling to follow my story here -- checkout |
Fixes the signature of secp256k1_ec_pubkey_sort to use
*mutrather than*const.Separately, our call to
secp256k1_ec_pubkey_sort, while correctly starting from a&mut [PublicKey], briefly constructed a&[ffi::PublicKey]slice before obtaining a*mutpointer from this. This was unsound for completely unnecessary reasons, and only compiled because we have an impl of theCPtrtrait for&[T], which provides aas_mut_c_ptr()method which basically cannot be safely used.Removing that
&[T]impl revealed another case where it was (unnecessarily) being used: inEllSwift::shared_secret, where we use it to obtain a*mutpointer from a&[u8], which we pass across the FFI boundary which simply drops it.