NM 0.9 asks for PK auth without need

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

NM 0.9 asks for PK auth without need

Ludwig Nussel
Hi,

802.11x connections that are configured to always prompt for the
password also always require polkit authentication (bgo#646187).

I tried to find out why but got stuck. AFAICS one culprit is
has_system_secrets() in src/settings/nm-agent-manager.c. It iterates
over all properties of a connection and checks whether the flags are
NM_SETTING_SECRET_FLAG_NONE. Of course the flags for 'password'
don't match but since the iterates goes over all properties, others
like 'psk' are at their default value which happens to be
NM_SETTING_SECRET_FLAG_NONE too. So has_system_secrets() always
returns true.
I suppose there needs to be a set_secrets_not_required() call
somewhere to indicate that the other potential secrets actually do
not apply to this connection. Alternatively an extra flag != NONE
could be set explicitly to indicate system secrets.

Suppose that bug is fixed and NM rightfully choses that code path
the PK popup at that point would be still annyoing. It's there to
avoid leaking system stored secrets to the user's agent. What are
those secrets needed for in the user's agent anyways though?

After hacking has_system_secrets() to always return false still the
attached patch is needed to make NM take the supplied secrets.

Btw, why does NM actually distinguish agent owned and not saved?
Shouldn't that decision just be left to the user's agent? The user
agent could lie about where it got the secret from anyways.

Btw2, for 802.1x it would make sense to also not store the user name
globally.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list

0001-treat-not-saved-secrets-just-like-agent-owned-when-cl.diff (944 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NM 0.9 asks for PK auth without need

Ludwig Nussel
Ludwig Nussel wrote:
> 802.11x connections that are configured to always prompt for the
> password also always require polkit authentication (bgo#646187).

Here's a potentially embarrassing patch to fix or rather work around
the issue. Improvements welcome, I don't really know the first thing
about NM :-)

After struggling with the code for some hours I think there are
several problems that make this situation complicated to fix though:
- NM does not know whether a secret is (intentionally) not in the
  config file. It just looks at gobject properties that don't know
  why they are at their default value.
- there doesn't seem to be a flag that tells NM whether a connection
  is just being set up for the first time. Ie there is no need to
  ask for auth again until the setup phase is complete.
- I wonder whether the general concept of suddenly prompting the
  user for passwords/passphrases (with potential PK popup) after the
  initial setup phase is a good idea. It might be better and less
  annoying to simply fail the connection attempt and require the
  user to manually use the edit dialog.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list

0001-don-t-consider-not-needed-secrets-for-has_system_secr.diff (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NM 0.9 asks for PK auth without need

Dan Williams
On Fri, 2011-10-07 at 15:43 +0200, Ludwig Nussel wrote:
> Ludwig Nussel wrote:
> > 802.11x connections that are configured to always prompt for the
> > password also always require polkit authentication (bgo#646187).

So the PK stuff is a mix of permissions and historic configuration.
First off, network configuration is potentially a privileged operation
since you have a lot of power to screw up the machine.

But storing your WPA PSK in your user session doesn't make a ton of
sense since it's required by everyone who connects to the network. In
contrast to a VPN password or a EAP password, which are specific to your
user, not to the machine (typically).  Windows and Mac OS X both make
WiFi PSK networks system-wide, so NM's previous behavior also didn't
match up with common expectations.

But of course, to create a system-wide WiFi network, you need to be able
to edit system config files, so that means we should require some
permission to create the network and to request the password when
showing a UI.  Perhaps that's why Windows never shows you the password
again after the initial connection :)

So when creating a new wifi network, you first need to authenticate to
create the network in the first place.  That gets creating without the
PSK since the applet doesn't necessarily want to include a ton of
complex code that checks what specific passwords might be required.
Instead, it waits for NM to ask the applet what is required.  Then the
applet throws up a dialog, but since users want to see any old passwords
(since this case is no different than the "password is wrong" case)
another request is triggered to read the secrets so we can populate the
UI with the old key.  Of course it's a new network, so that key isn't
there yet.  But there's no way to know that without requesting it,
really.

Obviously the secret could be stored in the user session and be visible
to the creating user only; but that kills the feature of system-wide
connections by default, which should be doing for most network types
(excluding VPN and possibly 3G).  That's essentially what 0.8 and
earlier did, and we had reasonable requests to change that.

The question has been asked before of why we don't just let people have
system config permission by default in 0.9.  That's because there might
be old connections that were created before when users didn't have
system config permission by default, and it seems somewhat insecure to
suddenly allow access to those previously protected connections on an
upgrade.

There are probably ways to reduce the PK spammage, and I hope there are,
and I'm very interested in figuring out how we can do that.  But this
also could be handled better at the PolicyKit level; perhaps we should
simply default to auth_admin_keep or auth_self_keep?  That should kill
the need for the second dialog, I think.  Does that make a difference in
the usability?

Dan

> Here's a potentially embarrassing patch to fix or rather work around
> the issue. Improvements welcome, I don't really know the first thing
> about NM :-)
>
> After struggling with the code for some hours I think there are
> several problems that make this situation complicated to fix though:
> - NM does not know whether a secret is (intentionally) not in the
>   config file. It just looks at gobject properties that don't know
>   why they are at their default value.
> - there doesn't seem to be a flag that tells NM whether a connection
>   is just being set up for the first time. Ie there is no need to
>   ask for auth again until the setup phase is complete.
> - I wonder whether the general concept of suddenly prompting the
>   user for passwords/passphrases (with potential PK popup) after the
>   initial setup phase is a good idea. It might be better and less
>   annoying to simply fail the connection attempt and require the
>   user to manually use the edit dialog.
>
> cu
> Ludwig
>
> _______________________________________________
> networkmanager-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/networkmanager-list


_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Reply | Threaded
Open this post in threaded view
|

Re: NM 0.9 asks for PK auth without need

Ludwig Nussel
Dan Williams wrote:

> On Fri, 2011-10-07 at 15:43 +0200, Ludwig Nussel wrote:
> > Ludwig Nussel wrote:
> > > 802.11x connections that are configured to always prompt for the
> > > password also always require polkit authentication (bgo#646187).
>
> So the PK stuff is a mix of permissions and historic configuration.
> First off, network configuration is potentially a privileged operation
> since you have a lot of power to screw up the machine.
>
> But storing your WPA PSK in your user session doesn't make a ton of
> sense since it's required by everyone who connects to the network. In
> contrast to a VPN password or a EAP password, which are specific to your
> user, not to the machine (typically).  Windows and Mac OS X both make
> WiFi PSK networks system-wide, so NM's previous behavior also didn't
> match up with common expectations.

ACK

> So when creating a new wifi network, you first need to authenticate to
> create the network in the first place.  That gets creating without the
> PSK since the applet doesn't necessarily want to include a ton of
> complex code that checks what specific passwords might be required.
> Instead, it waits for NM to ask the applet what is required.  Then the
> applet throws up a dialog, but since users want to see any old passwords
> (since this case is no different than the "password is wrong" case)
> another request is triggered to read the secrets so we can populate the
> UI with the old key.  Of course it's a new network, so that key isn't
> there yet.  But there's no way to know that without requesting it,
> really.

Yes, I got that. It's fine that nm-applet doesn't make a difference
and just implements generic prompts for simplicity. The problem with
the polkit popup when asking for a 802.11x password for an existing
connection first and foremost really is just a bug of
has_system_secrets(). The patch I sent tries to fix that.

> Obviously the secret could be stored in the user session and be visible
> to the creating user only; but that kills the feature of system-wide
> connections by default, which should be doing for most network types
> (excluding VPN and possibly 3G).  That's essentially what 0.8 and
> earlier did, and we had reasonable requests to change that.

The way NM 0.9 treats all connections as system connections is fine
in principle AFAICT. It just needs some fine tuning to prompt for PK
auth in the right moments IMO. Granting users privileges to edit
connections by default is not the solution.

> There are probably ways to reduce the PK spammage, and I hope there are,
> and I'm very interested in figuring out how we can do that.  But this
> also could be handled better at the PolicyKit level; perhaps we should
> simply default to auth_admin_keep or auth_self_keep?  That should kill
> the need for the second dialog, I think.  Does that make a difference in
> the usability?

You already rely on _keep when configuring new connections. Ie

1. user clicks on ESSID he wants to connect to
2. nm-applet shows the new connection edit dialog and posts results to NM
3. NM asks PK for auth
4. NM creates the new connection without secrets and stores it in /etc
5. NM starts the connection and detects missing secrets
6. NM asks PK for auth to determine whether it's allowed to send
   existing system secrets to nm-applet
7. NM asks nm-applet to prompt for secrets
8. nm-applet sends secrets back to NM
9. NM checks whether the auth at 6 was fine to determine whether to
   actually use the secrets the user sent.

That could be further improved IMO.

By exchanging 2 and 3 the users that are not allowed to administer
their machine would not even try to start setting up connections.

6 could be skipped because the user is already authenticated by 3
so you would not rely on PK's _keep.

To achieve that NM could store an extra key with the connection that
indicates that the connection is still incomplete and missing pieces
are supposed to be filled in by user XY.
Alternatively NM could use a special virtual connection (like the
"auto eth*" connections) during setup phase. When the connection is
successful it could convert it into a real one and actually save in
/etc only then¹.

Wrt wrong-password-dialogs you could avoid surprising PK popups by
showing the dialog in a read only view with an unlock button first.
Those popups are surprising because they are shown before the user
actually knows what the authentication is for.
However, even better might be to just avoid wrong-password-dialogs in
the first place. Just fail the connection.

cu
Ludwig

[1] That way of implementing it would probably also allow to probe
for other things, like e.g. IPv6 connectivity. Ie if there was no
IPv6 prefix announcement during setup NM doesn't need to wait for
one later either and therefore set the option to ignore v6.

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Reply | Threaded
Open this post in threaded view
|

Re: NM 0.9 asks for PK auth without need

Dan Williams
On Tue, 2011-10-11 at 16:23 +0200, Ludwig Nussel wrote:

> Dan Williams wrote:
> > On Fri, 2011-10-07 at 15:43 +0200, Ludwig Nussel wrote:
> > > Ludwig Nussel wrote:
> > > > 802.11x connections that are configured to always prompt for the
> > > > password also always require polkit authentication (bgo#646187).
> >
> > So the PK stuff is a mix of permissions and historic configuration.
> > First off, network configuration is potentially a privileged operation
> > since you have a lot of power to screw up the machine.
> >
> > But storing your WPA PSK in your user session doesn't make a ton of
> > sense since it's required by everyone who connects to the network. In
> > contrast to a VPN password or a EAP password, which are specific to your
> > user, not to the machine (typically).  Windows and Mac OS X both make
> > WiFi PSK networks system-wide, so NM's previous behavior also didn't
> > match up with common expectations.
>
> ACK
>
> > So when creating a new wifi network, you first need to authenticate to
> > create the network in the first place.  That gets creating without the
> > PSK since the applet doesn't necessarily want to include a ton of
> > complex code that checks what specific passwords might be required.
> > Instead, it waits for NM to ask the applet what is required.  Then the
> > applet throws up a dialog, but since users want to see any old passwords
> > (since this case is no different than the "password is wrong" case)
> > another request is triggered to read the secrets so we can populate the
> > UI with the old key.  Of course it's a new network, so that key isn't
> > there yet.  But there's no way to know that without requesting it,
> > really.
>
> Yes, I got that. It's fine that nm-applet doesn't make a difference
> and just implements generic prompts for simplicity. The problem with
> the polkit popup when asking for a 802.11x password for an existing
> connection first and foremost really is just a bug of
> has_system_secrets(). The patch I sent tries to fix that.
>
> > Obviously the secret could be stored in the user session and be visible
> > to the creating user only; but that kills the feature of system-wide
> > connections by default, which should be doing for most network types
> > (excluding VPN and possibly 3G).  That's essentially what 0.8 and
> > earlier did, and we had reasonable requests to change that.
>
> The way NM 0.9 treats all connections as system connections is fine
> in principle AFAICT. It just needs some fine tuning to prompt for PK
> auth in the right moments IMO. Granting users privileges to edit
> connections by default is not the solution.
>
> > There are probably ways to reduce the PK spammage, and I hope there are,
> > and I'm very interested in figuring out how we can do that.  But this
> > also could be handled better at the PolicyKit level; perhaps we should
> > simply default to auth_admin_keep or auth_self_keep?  That should kill
> > the need for the second dialog, I think.  Does that make a difference in
> > the usability?
>
> You already rely on _keep when configuring new connections. Ie
>
> 1. user clicks on ESSID he wants to connect to
> 2. nm-applet shows the new connection edit dialog and posts results to NM
> 3. NM asks PK for auth
> 4. NM creates the new connection without secrets and stores it in /etc
> 5. NM starts the connection and detects missing secrets
> 6. NM asks PK for auth to determine whether it's allowed to send
>    existing system secrets to nm-applet
> 7. NM asks nm-applet to prompt for secrets
> 8. nm-applet sends secrets back to NM
> 9. NM checks whether the auth at 6 was fine to determine whether to
>    actually use the secrets the user sent.
>
> That could be further improved IMO.
>
> By exchanging 2 and 3 the users that are not allowed to administer
> their machine would not even try to start setting up connections.

I tried to think of how this would happen but didn't get there.  Did you
have any implementation thoughts here?  Ideally the applets wouldn't
even let you do this (since they can ask whether they are allowed to
perform the action too) since it's pointless to present choices to the
user that are just going to be denied by NM.

> 6 could be skipped because the user is already authenticated by 3
> so you would not rely on PK's _keep.

But I thought that's what _keep did for us already?  Basically, we still
need to check authorization in NM, and I had assumed use of _keep would
simply return "success" since PK should be tracking whether the user is
authorized and for how long.  Would be somewhat odd if PK didnt' do this
for us.  Unless we're not requesting the same permission in (3) and (6)?
I didn't go check the code, but I *thought* it was still the same
permission there, and thus that PK would simply return "authorized" for
(6) because the user had already authenticated, and we specified _keep.

> To achieve that NM could store an extra key with the connection that
> indicates that the connection is still incomplete and missing pieces
> are supposed to be filled in by user XY.

Well, we could use timestamp for this; NM tracks that in a lookaside
file, and if the connection has never been successfully used, the
timestamp will be 0.  These days NM keeps the timestamp separate from
the connection data, so we're guaranteed that timestamp will be updated.
That didn't used to be the case for 0.8 and earlier.  I'm not sure we
need to track which user created it since PK should be handling the
authentication for us if we use _keep.  AFAIUI.

> Alternatively NM could use a special virtual connection (like the
> "auto eth*" connections) during setup phase. When the connection is
> successful it could convert it into a real one and actually save in
> /etc only then¹.
>
> Wrt wrong-password-dialogs you could avoid surprising PK popups by
> showing the dialog in a read only view with an unlock button first.

Yeah, I'd thought about this when implementing this stuff.  At least in
nm-applet we could do that, and I'd be interested in a patch for it.  ie
leave the secrets blank and only if the unlock button got clicked, like
you suggest, fill in the entry with existing secrets.  So we wouldn't
need to do read-only, but jsut dont' request existing secrets (and thus
don't trigger a PK request) until the unlock button got clicked.

But still, I'd think PK would handle the second request for us since the
user already authenticated to add the connection in the first place...?
And I thought the permissions were the same for the add connection and
the get secrets requests (ie, modify.system).

Dan

> Those popups are surprising because they are shown before the user
> actually knows what the authentication is for.
> However, even better might be to just avoid wrong-password-dialogs in
> the first place. Just fail the connection.
>
> cu
> Ludwig
>
> [1] That way of implementing it would probably also allow to probe
> for other things, like e.g. IPv6 connectivity. Ie if there was no
> IPv6 prefix announcement during setup NM doesn't need to wait for
> one later either and therefore set the option to ignore v6.
>


_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Reply | Threaded
Open this post in threaded view
|

Re: NM 0.9 asks for PK auth without need

Ludwig Nussel
Dan Williams wrote:

> On Tue, 2011-10-11 at 16:23 +0200, Ludwig Nussel wrote:
>> [...]
>> 1. user clicks on ESSID he wants to connect to
>> 2. nm-applet shows the new connection edit dialog and posts results to NM
>> 3. NM asks PK for auth
>> 4. NM creates the new connection without secrets and stores it in /etc
>> 5. NM starts the connection and detects missing secrets
>> 6. NM asks PK for auth to determine whether it's allowed to send
>>    existing system secrets to nm-applet
>> 7. NM asks nm-applet to prompt for secrets
>> 8. nm-applet sends secrets back to NM
>> 9. NM checks whether the auth at 6 was fine to determine whether to
>>    actually use the secrets the user sent.
>>
>> That could be further improved IMO.
>>
>> By exchanging 2 and 3 the users that are not allowed to administer
>> their machine would not even try to start setting up connections.
>
> I tried to think of how this would happen but didn't get there.  Did you
> have any implementation thoughts here?  Ideally the applets wouldn't
> even let you do this (since they can ask whether they are allowed to
> perform the action too) since it's pointless to present choices to the
> user that are just going to be denied by NM.

No, I haven't looked at the actual implementation.

>> 6 could be skipped because the user is already authenticated by 3
>> so you would not rely on PK's _keep.
>
> But I thought that's what _keep did for us already?  Basically, we still
> need to check authorization in NM, and I had assumed use of _keep would
> simply return "success" since PK should be tracking whether the user is
> authorized and for how long.  Would be somewhat odd if PK didnt' do this
> for us.  Unless we're not requesting the same permission in (3) and (6)?
> I didn't go check the code, but I *thought* it was still the same
> permission there, and thus that PK would simply return "authorized" for
> (6) because the user had already authenticated, and we specified _keep.

Yes, that works as long as noone changes auth_admin_keep to auth_admin.
So nothing wrong with the code if you rely on _keep.
I actually changed to auth_admin intentionally to find out where NM asks
PK while debugging the 802.11x annoyance. NM enters the exact same code
at step 5 as listed above if it needs to prompt for user owned secrets.
So hopefully users won't actually see this in practice.

> [...]
> But still, I'd think PK would handle the second request for us since the
> user already authenticated to add the connection in the first place...?
> And I thought the permissions were the same for the add connection and
> the get secrets requests (ie, modify.system).

That's how it works but personally I don't really trust it :-) AFAIK
_keep means polkit remembers the authorization for some unspecified
time. If the user needs longer than that (like distracted by a phone
call) PK would ask again.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Reply | Threaded
Open this post in threaded view
|

Re: NM 0.9 asks for PK auth without need

Dan Williams
On Tue, 2011-10-11 at 17:14 +0200, Ludwig Nussel wrote:

> Dan Williams wrote:
> > On Tue, 2011-10-11 at 16:23 +0200, Ludwig Nussel wrote:
> >> [...]
> >> 1. user clicks on ESSID he wants to connect to
> >> 2. nm-applet shows the new connection edit dialog and posts results to NM
> >> 3. NM asks PK for auth
> >> 4. NM creates the new connection without secrets and stores it in /etc
> >> 5. NM starts the connection and detects missing secrets
> >> 6. NM asks PK for auth to determine whether it's allowed to send
> >>    existing system secrets to nm-applet
> >> 7. NM asks nm-applet to prompt for secrets
> >> 8. nm-applet sends secrets back to NM
> >> 9. NM checks whether the auth at 6 was fine to determine whether to
> >>    actually use the secrets the user sent.
> >>
> >> That could be further improved IMO.
> >>
> >> By exchanging 2 and 3 the users that are not allowed to administer
> >> their machine would not even try to start setting up connections.
> >
> > I tried to think of how this would happen but didn't get there.  Did you
> > have any implementation thoughts here?  Ideally the applets wouldn't
> > even let you do this (since they can ask whether they are allowed to
> > perform the action too) since it's pointless to present choices to the
> > user that are just going to be denied by NM.
>
> No, I haven't looked at the actual implementation.
>
> >> 6 could be skipped because the user is already authenticated by 3
> >> so you would not rely on PK's _keep.
> >
> > But I thought that's what _keep did for us already?  Basically, we still
> > need to check authorization in NM, and I had assumed use of _keep would
> > simply return "success" since PK should be tracking whether the user is
> > authorized and for how long.  Would be somewhat odd if PK didnt' do this
> > for us.  Unless we're not requesting the same permission in (3) and (6)?
> > I didn't go check the code, but I *thought* it was still the same
> > permission there, and thus that PK would simply return "authorized" for
> > (6) because the user had already authenticated, and we specified _keep.
>
> Yes, that works as long as noone changes auth_admin_keep to auth_admin.
> So nothing wrong with the code if you rely on _keep.
> I actually changed to auth_admin intentionally to find out where NM asks
> PK while debugging the 802.11x annoyance. NM enters the exact same code
> at step 5 as listed above if it needs to prompt for user owned secrets.
> So hopefully users won't actually see this in practice.
>
> > [...]
> > But still, I'd think PK would handle the second request for us since the
> > user already authenticated to add the connection in the first place...?
> > And I thought the permissions were the same for the add connection and
> > the get secrets requests (ie, modify.system).
>
> That's how it works but personally I don't really trust it :-) AFAIK
> _keep means polkit remembers the authorization for some unspecified
> time. If the user needs longer than that (like distracted by a phone
> call) PK would ask again.

Yeah, though I'd hope we can rely on that.  Basically, my suggestion
here would be to use _keep, and make it explicit that stuff isn't
expected to be as smooth if you just use auth_admin/auth_self.  If you
do, that's your problem, since that's just dumb.  I think the defaults
for keeping the auth are reasonable.

But, we *also* can make the change for lock/unlock button in the secrets
dialog so that we don't request PK auth again unless the button gets
pressed.  These two things should fix most occurrences of this, right?

One other thing to think about: creating a new wifi network for
sharing :)  Not a common action, but this one actually requires *two* PK
requests: one for checking whether you are allowed to share via wifi,
and the second to create the connection.

Dan

_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Reply | Threaded
Open this post in threaded view
|

Re: NM 0.9 asks for PK auth without need

Ludwig Nussel
Dan Williams wrote:
> [...]
> But, we *also* can make the change for lock/unlock button in the secrets
> dialog so that we don't request PK auth again unless the button gets
> pressed.  These two things should fix most occurrences of this, right?

Yes.

> One other thing to think about: creating a new wifi network for
> sharing :)  Not a common action, but this one actually requires *two* PK
> requests: one for checking whether you are allowed to share via wifi,
> and the second to create the connection.

IIUC PK git head recently gained a feature where one privilege
automatically authorizes another. That could be of help here.

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
_______________________________________________
networkmanager-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/networkmanager-list