search for: bitlk

...is not present then > +libguestfs tries to guess the correct type (for example > +LUKS or BitLocker). However you can override this by > +specifying one of the following types: > + > +=over 4 > + > +=item C<luks> > + > +A Linux LUKS device. > + > +=item C<bitlk> > + > +A Windows BitLocker device. > + > +=back Maybe add: Please refer to the L<cryptsetup(8)> documentation for all the supported types. -- Pino Toscano

...rmine the encryption type. *) + let crypttype = + match crypttype with + | Some s -> s + | None -> + let t = Blkid.vfs_type (Mountable.of_device device) in + match t with + | "crypto_LUKS" -> "luks" + | "BitLocker" -> "bitlk" + | _ -> + failwithf "%s: unknown encrypted device type" t in + + (* Write the key to a temporary file. *) + let keyfile, chan = Filename.open_temp_file "crypt" ".key" in + fchmod (descr_of_out_channel chan) 0o600; + output_string chan key;...

...rmine the encryption type. *) + let crypttype = + match crypttype with + | Some s -> s + | None -> + let t = Blkid.vfs_type (Mountable.of_device device) in + match t with + | "crypto_LUKS" -> "luks" + | "BitLocker" -> "bitlk" + | _ -> + failwithf "%s: unknown encrypted device type" t in + + (* Write the key to a temporary file. *) + let keyfile, chan = Filename.open_temp_file "crypt" ".key" in + fchmod (descr_of_out_channel chan) 0o600; + output_string chan key;...

Original version linked from here: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 There is no change in the code in this series, but feedback from the original series was we shouldn't lose the error message in patch 7. When I tested this just now in fact we don't lose the error if debugging is enabled, but I have updated the commit message to note what the error message is in the

These commits, along with the associated changes to common: https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html support the transparent decryption and inspection of Windows guests encrypted with BitLocker encryption. To do the BitLocker decryption requires cryptsetup 2.3.0 (although cryptsetup 2.3 is not required for existing LUKS use). It also requires a new-ish Linux kernel, I

As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.