From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60123 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PIfAc-0002UJ-KP
	for qemu-devel@nongnu.org; Wed, 17 Nov 2010 05:23:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PIfAb-0007HN-HN
	for qemu-devel@nongnu.org; Wed, 17 Nov 2010 05:23:18 -0500
Received: from mx1.redhat.com ([209.132.183.28]:25320)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1PIfAb-0007HG-9e
	for qemu-devel@nongnu.org; Wed, 17 Nov 2010 05:23:17 -0500
Message-ID: <4CE3AD0F.5030407@redhat.com>
Date: Wed, 17 Nov 2010 11:23:11 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 2/3] vnc: support password expire
References: <1286450121-17153-1-git-send-email-kraxel@redhat.com>	<1286450121-17153-3-git-send-email-kraxel@redhat.com>	<4CAE2521.2070500@codemonkey.ws>
	<20101008100841.GB9279@redhat.com>	<4CDABF56.8020804@codemonkey.ws>
	<4CDBD5E3.8080008@redhat.com> <4CE2E8F3.6030105@codemonkey.ws>
In-Reply-To: <4CE2E8F3.6030105@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

   Hi,

>>> Having an expiration policy builtin to QEMU (as
>>> opposed to libvirt) seems like the wrong place.
>>
>> IMHO it doesn't build policy into qemu. It is still up to libvirt (or
>> the management app building on top of libvirt) to decide if and when
>> the password will expire.
>
> Except if you want to cancel the expiration because the expiration
> policy changes. You'd have to set the password without an expiration
> time and you may not have ready access to the password.

Point.

>> set-password $protocol $secret
>> [ let $time pass ]
>> expire-password $protocol
>>
>> I fail to see why this is better though. The former is more robust and
>> easier to implement in the management. The amount of code needed in
>> qemu is probably quite similar ...
>
> But the later let's a management tool implement arbitrarily complex
> expiration policies.

Hmm, we could do this:

set-password $protocol $secret
expire-password $protocol [ now | never | $seconds ]

Comments?

cheers,
   Gerd