Am 25.11.2019 um 19:45 hat Max Reitz geschrieben:
> On 22.11.19 15:22, Maxim Levitsky wrote:
> > Hi!
> >
> > This is the second version of the proposed QMP API for key management,
> > after discussion with Keven and Max.
> >
> > Will this work?
> >
> > Adding Peter Krempa to CC, to hear his opin
On Mon, 2019-11-25 at 19:45 +0100, Max Reitz wrote:
> On 22.11.19 15:22, Maxim Levitsky wrote:
> > Hi!
> >
> > This is the second version of the proposed QMP API for key management,
> > after discussion with Keven and Max.
> >
> > Will this work?
> >
> > Adding Peter Krempa to CC, to hear his op
On 22.11.19 15:22, Maxim Levitsky wrote:
> Hi!
>
> This is the second version of the proposed QMP API for key management,
> after discussion with Keven and Max.
>
> Will this work?
>
> Adding Peter Krempa to CC, to hear his opinion from the
> libvirt side.
>
> Best regards,
> Maxim Levit
Hi!
This is the second version of the proposed QMP API for key management,
after discussion with Keven and Max.
Will this work?
Adding Peter Krempa to CC, to hear his opinion from the
libvirt side.
Best regards,
Maxim Levitsky
diff --git a/qapi/block-core.json b/qapi/block-core.json
On Tue, 2019-11-12 at 10:12 +0100, Kevin Wolf wrote:
> Am 11.11.2019 um 19:34 hat Daniel P. Berrangé geschrieben:
> > On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
> > > One of the concerns that was raised during the review was that amend
> > > interface for luks that I propose i
On Tue, 2019-11-12 at 11:02 +, Daniel P. Berrangé wrote:
> On Tue, Nov 12, 2019 at 10:12:45AM +0100, Kevin Wolf wrote:
> > Am 11.11.2019 um 19:34 hat Daniel P. Berrangé geschrieben:
> > > On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
> > > > One of the concerns that was raised
On Mon, 2019-11-11 at 18:34 +, Daniel P. Berrangé wrote:
> On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
> > Hi!
> >
> > I would like to discuss the API for LUKS key management.
> >
> > First of all very brief overview of LUKS v1 format:
> >
> > Each sector of the image is
On Tue, Nov 12, 2019 at 10:12:45AM +0100, Kevin Wolf wrote:
> Am 11.11.2019 um 19:34 hat Daniel P. Berrangé geschrieben:
> > On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
> > > One of the concerns that was raised during the review was that amend
> > > interface for luks that I pr
On 12.11.19 10:12, Kevin Wolf wrote:
> Am 11.11.2019 um 19:34 hat Daniel P. Berrangé geschrieben:
>> On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
>>> One of the concerns that was raised during the review was that amend
>>> interface for luks that I propose is
>>> different from
On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
> I will try to explain the interface with bunch of examples:
I want to fill in equiv examples from cryptsetup for sake
of comparison
> # adds a new password, defined by qemu secret 'sec0' to first unused slot
> # give user a error i
Am 11.11.2019 um 19:34 hat Daniel P. Berrangé geschrieben:
> On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
> > One of the concerns that was raised during the review was that amend
> > interface for luks that I propose is
> > different from the amend inteface used currently for qc
On Mon, Nov 11, 2019 at 05:58:20PM +0200, Maxim Levitsky wrote:
> Hi!
>
> I would like to discuss the API for LUKS key management.
>
> First of all very brief overview of LUKS v1 format:
>
> Each sector of the image is encrypted with same master key, which
> is not stored directly on the disk.
>
Hi!
I would like to discuss the API for LUKS key management.
First of all very brief overview of LUKS v1 format:
Each sector of the image is encrypted with same master key, which
is not stored directly on the disk.
Instead in the LUKS header we have 8 slots. Each slot optionally stores
an encry
13 matches
Mail list logo
