qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/11] Merge authz core patches


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PULL 00/11] Merge authz core patches
Date: Wed, 27 Feb 2019 11:12:43 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Tue, Feb 26, 2019 at 07:09:29PM +0000, Peter Maydell wrote:
> On Tue, 26 Feb 2019 at 19:07, Philippe Mathieu-Daudé <address@hidden> wrote:
> >
> > On 2/26/19 8:04 PM, Peter Maydell wrote:
> > > On Mon, 25 Feb 2019 at 12:35, Daniel P. Berrangé <address@hidden> wrote:
> > >>
> > >> The following changes since commit 
> > >> 8eb29f1bf5a974dc4c11d2d1f5e7c7f7a62be116:
> > >>
> > >>   Merge remote-tracking branch 
> > >> 'remotes/awilliam/tags/vfio-updates-20190221.0' into staging (2019-02-22 
> > >> 15:48:04 +0000)
> > >>
> > >> are available in the Git repository at:
> > >>
> > >>   https://github.com/berrange/qemu tags/authz-core-pull-request
> > >>
> > >> for you to fetch changes up to cfde05c6c0db7d3122a5491d50f62f7910ab8abb:
> > >>
> > >>   authz: delete existing ACL implementation (2019-02-25 12:28:25 +0000)
> > >>
> > >> ----------------------------------------------------------------
> > >> Add a standard authorization framework
> > >>
> > >> The current network services now support encryption via TLS and in some
> > >> cases support authentication via SASL. In cases where SASL is not
> > >> available, x509 client certificates can be used as a crude authorization
> > >> scheme, but using a sub-CA and controlling who you give certs to. In
> > >> general this is not very flexible though, so this series introduces a
> > >> new standard authorization framework.
> > >>
> > >
> > > Applied, thanks.
> >
> > Argh there is a v2... Daniel didn't NACK'd this one.
> 
> Oops. Yes, I process my pullreq queue oldest-first and unless you
> follow up to the cover letter to say "don't apply this v1" I'm
> not necessarily going to notice a v2. I'm afraid you'll have to
> send whatever the v1->v2 fixes were as a separate set of patches now.

Actually there is no problem here.  git-publish will always use the
same tag name when sending a pull request, so the v2 tag name was
the same as the v1 tag name & thus you automatically applied the
correct v2 pull request.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]