Re: Problems with Plasma NetworkManagement

[Dan Williams <dcbw redhat com>]

On Tue, 2011-07-19 at 21:53 -0300, Lamarque Vieira Souza wrote:
> Em Saturday 09 July 2011, Lamarque Vieira Souza escreveu:
> 
> > Em Sunday 03 July 2011, Lamarque Vieira Souza escreveu:
> 
> > > Em Saturday 02 July 2011, Dan Williams escreveu:
> 
> > > > Yeah, the applet and editor are two separate processes. We can
> send an
> 
> > > > Update() along anyway if you wish though, I simply had to make a
> 
> > > > behavior call at the time it was implemented, and we can change
> that
> 
> > > > behavior. Obviously agents should be smart enough to know when
> the
> 
> > > > incoming secrets are different than what they already have and
> possibly
> 
> > > > ignore the Update() if nothing has actually changed.
> 
> > > > 
> 
> > > > If NM is passing the old secrets, that's clearly not cool, and
> we need
> 
> > > > to fix that.
> 
> > > 
> 
> > > Well, a new Update() call is not necessary, I just need NM to call
> 
> > > 
> 
> > > Update() with the new secrets instead of the old ones. The
> attached patch
> 
> > > does exactly that and fix the problem for me. But NM's API does
> not allow
> 
> > > me to list all settings from a connection, I have to name them one
> by
> 
> > > one, so I created the patch only for NMSettingWirelessSecurity. I
> think
> 
> > > you can improve it to work with all other secret settings, right?
> 
> > 
> 
> > Dan Willians, can you comment the patch I sent you last week? This
> 
> > problem is a show-stop for Plasma NM and I would like to have it
> solve as
> 
> > soon as possible.
> 
> 
> Hi again, any news about this bug?

Yeah, I did look into it earlier this week.  The patch you posted hacks
around it but is not the correct fix obviously.  What might be happening
here is the patch to keep agent-owned secrets when re-reading the config
files after committing changes to disk.  The original problem was that
when secrets come back from the secret agent, those may include
system-owned secrets which need to get written out to disk.  That
triggers an inotify event which re-reads the connection; the newly read
connection is compared to the in-memory one, but they differ because the
in-memory one can contain agent-owned or always-ask secrets that don't
get written to disk.  We need those in-memory secrets of course since we
just asked for them.  That's why the code keeps some of the secrets
around, and that might be why you're seeing "old" secrets.

So what's the flow here?  Is it during connection, or just editing some
random connection?  ie if you edit a connection that you're not
currently using, somehow the secrets are the old ones the secret agent
used to have?

Dan