search for: luks_open_ro

...This means that callers of these APIs + * will be able to open BitLocker drives transparently. (If + * we wanted to be strict we would pass ~crypttype:"luks" + * here, but that seems to have only downsides). + *) +let luks_open device key mapname = cryptsetup_open device key mapname +let luks_open_ro device key mapname = + cryptsetup_open ~readonly:true device key mapname +let luks_close = cryptsetup_close diff --git a/daemon/luks.c b/daemon/luks.c index d631cb100..51ced585d 100644 --- a/daemon/luks.c +++ b/daemon/luks.c @@ -81,89 +81,6 @@ remove_temp (char *tempfile) free (tempfile); }...

...This means that callers of these APIs + * will be able to open BitLocker drives transparently. (If + * we wanted to be strict we would pass ~crypttype:"luks" + * here, but that seems to have only downsides). + *) +let luks_open device key mapname = cryptsetup_open device key mapname +let luks_open_ro device key mapname = + cryptsetup_open ~readonly:true device key mapname +let luks_close = cryptsetup_close diff --git a/daemon/luks.c b/daemon/luks.c index d631cb100..51ced585d 100644 --- a/daemon/luks.c +++ b/daemon/luks.c @@ -81,89 +81,6 @@ remove_temp (char *tempfile) free (tempfile); }...

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.

I'm currently working on gobject bindings for libguestfs. I haven't got as far as compiling anything yet, but I've attached the C header for initial review. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -------------- next part -------------- An embedded and

This is a follow-up to the other generator changes in: https://www.redhat.com/archives/libguestfs/2017-February/msg00217.html Rich.

...evice"); String (Key, "key"); String (PlainString, "mapname")], []; optional = Some "luks"; shortdesc = "open a LUKS-encrypted block device"; longdesc = "\ @@ -5875,7 +5875,7 @@ devices." }; { defaults with name = "luks_open_ro"; added = (1, 5, 1); - style = RErr, [Device "device"; Key "key"; String "mapname"], []; + style = RErr, [String (Device, "device"); String (Key, "key"); String (PlainString, "mapname")], []; optional = Some "luks&quot...

Very large but mechanical change to the generator. Rich.

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

Split up the huge generator/actions.ml into several smaller files. Rich.