Am 30.01.2020 um 22:39 hat Daniel Henrique Barboza geschrieben: > The version 8 of this patch series got buried and it's now > conflicting with master. Rebase and re-sending it. > > Also, I contemplated the idea of moving/copying the password > verification in qcrypto_block_luks_create() all the way back to the > start of block_crypto_co_create_opts_luks(), failing early before the > bdrv_create_file(), avoiding the problem altogether without the > need of a delete_file API I'm trying to push here (see patch 03 > commit message for detailed info about the bug). > > This idea was dropped after I saw that: > > - We would need to store the resulting password, now being retrieved > early in block_crypto_co_create_opts_luks(), in a new > QCryptoBlockCreateOptions string to be used inside > qcrypto_block_luks_create() as intended. An alternative would be to > call qcrypto_secret_lookup_as_utf8() twice, discarding the first > string; > > - There are a lot of ways to fail in qcrypto_block_luks_create() > other than a non-UTF8 password that would trigger the same problem. > A more appropiate way of doing what I intended, instead of > copying/hacking code around to fail before bdrv_create(), is some sort > of bdrv_validate() API that would encapsulate everything that is > related to user input validation for the security drivers. This > API could then be called before the file creation (maybe inside > bdrv_create itself) and fail early if needed. This is too overkill > for what I'm trying to fix here, and I'm not sure if it would be > a net gain compared to the delete_file API. > > > All that said, I believe that this patch series presents a sane > solution with the code we have ATM. > > > changes in this version: > - rebase with current master at 204aa60b37 > - previous version: > https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg01551.html
Thanks, applied to the block branch. Kevin