Hi!

Since NetworkManager 0.9, a simple user is not allowed to connect to
some wireless network unless it is granted (through policy kit or
appropriate permissions)
org.freedesktop.NetworkManager.settings.modify.system. This permission
allows to alter existing connections as well. An active user should be
authorized to use any wireless network if he wants to by default (like
in previous versions). Or it should be possible to configure network
manager to allow users to connect to wireless networks without
enabling them to modify other system settings.



- -- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager depends on:
ii  adduser                3.113
ii  dbus                   1.4.14-1
ii  isc-dhcp-client        4.1.1-P1-17
ii  libc6                  2.13-21
ii  libdbus-1-3            1.4.14-1
ii  libdbus-glib-1-2       0.94-4
ii  libgcrypt11            1.5.0-3
ii  libglib2.0-0           2.28.6-1
ii  libgnutls26            2.12.10-2
ii  libgudev-1.0-0         172-1
ii  libnl1                 1.1-7
ii  libnm-glib4            0.9.0-2
ii  libnm-util2            0.9.0-2
ii  libpolkit-gobject-1-0  0.102-1
ii  libuuid1               2.19.1-5
ii  lsb-base               3.2-28
ii  udev                   172-1
ii  wpasupplicant          0.7.3-3.1

Versions of packages network-manager recommends:
ii  dnsmasq-base  2.58-3
ii  iptables      1.4.12-1
ii  modemmanager  0.5-1
ii  policykit-1   0.102-1
ii  ppp           2.4.5-5

Versions of packages network-manager suggests:
pn  avahi-autoipd  <none>

- -- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
no-auto-default=60:eb:69:ce:6e:a0,
[ifupdown]
managed=false


- -- no debconf information
iEYEARECAAYFAk53hrAACgkQKFvXofIqeU7MZgCfUhWv55uMe7XwAloAlsV5luLq
fI8AnRgNNKT/2gFxN/zbNdDvO/wDPOCf
=PlLS
-----END PGP SIGNATURE-----

tags 642136 moreinfo
thanks

Am 19.09.2011 20:15, schrieb Vincent Bernat:

This is of course possible.
Was the connection you tried to enable created by another user? What's the name
of the user trying to activate the connection?
Which GUI frontend (and which version) do you use?
Was the connection imported from earlier versions i.e. created by nm-applet < 0.9?

As connections are now all stored in /etc/NetworkManager/system-connections/ ,
could you attach the corresponding keyfile (make sure it doesn't contain any
confidential data)

Michael

OoO En cette soirée bien amorcée du lundi 19 septembre 2011, vers 22:48,
Michael Biebl <biebl@debian.org> disait :

The   connection    did   not   exist    (it   does   not    appear   in
nm-connection-editor). I  am using  nm-applet 0.9.0-2. I  have restarted
both nm-applet and Network Manager to ensure they are in sync.

As the connection does not exist, there is no keyfile for it.

Thanks!

Am 20.09.2011 07:42, schrieb Vincent Bernat:

Now you have me confused. How can you activate a connection which does not exist?

Michael

This is a wireless network I never connected to. I choose it from the
available wireless network detected by Network Manager. Through polkit
helper, Network Manager is asking me for administrative rights just to
connect to this new wireless network.

I can connect to an unknown wire network without password but I need to
grant administrative rights to connect an unknown wireless network. I
would like to not be prompted for something like this but the right
requested is overly general. If I grant it to the active users, he will
be able to tamper with existing connections. In previous version,
connecting to an unknown wireless network was granted without passwords
to the active user.

Am 20.09.2011 09:56, schrieb Vincent Bernat:

What desktop environment do you use?
If GNOME, is /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 running?
If not, does it help if you start it manually?

Am 20.09.2011 09:56, schrieb Vincent Bernat:
With NM 0.9, the user settings service is gone, i.e. connections are no longer
stored in the user session but always system wide (using the keyfile in
/etc/NetworkManager/system-connections).
Wireless connections are shared by default (ie. the setting "Available to all
users" is selected).
Writing a system setting and making it available to everyone requires
administrative privileges. That's why you get the PolicyKit prompt.

If you create a Wireless connection manually via nm-connection-editor:
Run nm-connection-editor
select tab "Wireless"
Click "Add"
Fill in SSID and Security settings.
*Uncheck* "Available to all users".
Then you shouldn't get a PK prompt, right?

Michael

Yes.

I think by default, a user should not be prompted for administrative
rights to connect to a wireless network. This could be done with a
policy stating that
org.freedesktop.NetworkManager.settings.modify.system is granted to
active users (but I think this is far too wide). Or this could be done
by not sharing wireless connections by default (in this case, I suppose
that org.freedesktop.NetworkManager.settings.modify.own will be used and
by default, active users are granted this permission).

Maybe I could retitle this bug to "Add a settings to allow
unprivilegied user to connect to unknown wireless network without
administrative rights" and set severity to wishlist. Would it be
clearer?

Am 20.09.2011 11:18, schrieb Vincent Bernat:

It's the "unknown" part which is important, because it's about *creating* a new
connection configuration. I initially was about activating an existing connection.

Granting org.freedesktop.NetworkManager.settings.modify.system to every active
user means that they will be able to read the Wireless PSK without admin
privileges, so I'm not convinced yet that this is actually a good idea.
An alternative could be, to make wireless connections not available to everyone
by default and doing so requires explicit configuration.

Michael

OoO En  cette fin de matinée  radieuse du mardi 20  septembre 2011, vers
11:36, Michael Biebl <biebl@debian.org> disait :

How could this be configured? I  think this should be the default but it
is only my opinion. Being able  to configure like this on my system will
be fine by me.

Thanks!

Le mardi 18 oct. 2011 à 22:38:33 (+0200 CEST), Michael Biebl a écrit :

True, but then, the user has to know what an SSID is, what kind of
encryption scheme is used etc. Which I think is against NM philosophy.
*my* password to my girlfriend by SMS yesterday, as she *had* to connect to
a new wireless network and could not do it herself.

Policykit default configuration doesn't help. My user is in the sudo group,
but I still use the root account. Then, the only "administrative user" is
me. I had to add my girlfriend account to the sudo group to avoid similar
situations in the future, but I do not think it is optimum (I know I could
add a .pkla file to allow specific user/group to deal with NM system wide
settings, but I don't consider it a nice workaround neither).

The default NM behaviour should definitively be configurable, I totally
agree with Vincent on this point.

All my apologies, I have missed this bug report when looking for similar
issues.

Cheers,
Julien

Hi!

I'm facing the same problem as Vincent and Julien and I agree with them:
a normal user (not an admin) should be able to create its own
connections especially for new wireless networks.

On a laptop shared by several users it's annoying to have to add all the
users in the sudo group in order just to let them connect to the
wireless networks they will find on their way (of course you can pre
configure all the wireless networks they will find).

There is a special policy kit permission for this:
org.freedesktop.NetworkManager.settings.modify.own.

It would be good if there was a check box (unchecked by default) named
"Make this connection available for all users" in the configuration
dialog of new wireless connections and the admin password would be asked
just in case that check box is ticked.

Thanks in advance.

Yann

Analogous to that: there exists 'netdev' group to allow use and switch existing connection profiles. Add 'netadmin' group to allow managing system connections.

A simple policy as described here https://wiki.archlinux.org/index.php/Network_manager#Can.27t_edit_connections_as_normal_user applied to new 'netadmin' group would increase manageability of the system.

Regardless of group policy, new wireless connection profile should be created with user acl, without asking for privilege escalation.

I think we all agree that from a user point of view we can't have a
password required to connect to a wireless network.

On my side I get an extra bit of annoyance, as @home when I'm far from
the AP NM will try to connect, fail (because of the bad link) assume
it's because the password is wrong (wtf?), ask for the password again
(hence), ask for my user password, then the wifi password, then my user
password ...quite annoying.

anyway, in Fedora 17 this is what they have:

 grep -ve xml /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>

  <vendor>NetworkManager</vendor>
  <vendor_url>http://www.gnome.org/projects/NetworkManager</vendor_url>
  <icon_name>nm-icon</icon_name>

  <action id="org.freedesktop.NetworkManager.enable-disable-network">
    <description>Enable or disable system networking</description>
    <message>System policy prevents enabling or disabling system networking</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.sleep-wake">
    <description>Put NetworkManager to sleep or wake it up (should only be used by system power management)</description>
    <message>System policy prevents putting NetworkManager to sleep or waking it up</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>no</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.enable-disable-wifi">
    <description>Enable or disable WiFi devices</description>
    <message>System policy prevents enabling or disabling WiFi devices</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.enable-disable-wwan">
    <description>Enable or disable mobile broadband devices</description>
    <message>System policy prevents enabling or disabling mobile broadband devices</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.enable-disable-wimax">
    <description>Enable or disable WiMAX mobile broadband devices</description>
    <message>System policy prevents enabling or disabling WiMAX mobile broadband devices</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.network-control">
    <description>Allow control of network connections</description>
    <message>System policy prevents control of network connections</message>
    <defaults>
      <allow_inactive>yes</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.wifi.share.protected">
    <description>Connection sharing via a protected WiFi network</description>
    <message>System policy prevents sharing connections via a protected WiFi network</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.wifi.share.open">
    <description>Connection sharing via an open WiFi network</description>
    <message>System policy prevents sharing connections via an open WiFi network</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.settings.modify.own">
    <description>Modify personal network connections</description>
    <message>System policy prevents modification of personal network settings</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.settings.modify.system">
    <description>Modify network connections for all users</description>
    <message>System policy prevents modification of network settings for all users</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.NetworkManager.settings.modify.hostname">
    <description>Modify persistent system hostname</description>
    <message>System policy prevents modification of the persistent system hostname</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>

</policyconfig>

Ubuntu has a separate package called policykit-desktop-privileges [1],
which ships a file
 /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla
containing the following entry (among others)

[Adding or changing system-wide NetworkManager connections]
Identity=unix-group:admin;unix-group:sudo
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultActive=yes

This means, "admin" users, i.e. users which are in group sudo or admin,
won't get prompted when modifying system connections, this includes
creating new wireless connections.

This is not a perfect solution, yet maybe something we can/should
consider for Debian, too.


Michael

[1] http://packages.ubuntu.com/precise/policykit-desktop-privileges

nice,

there are quite a few 'don-t-annoy-users-too-much' things in that package.

should we add netdev to the groups and push this into the nm package ?

or do we want to look into more of this and get
policykit-desktop-priviledges all in ?

Identity=unix-group:admin;unix-group:sudo

This works for Ubuntu because they default to using sudo. It will not
help Debian systems with a root password, which do not put the desktop
user in the sudo group. It would work if you used the netdev group.
I don't know if that is a good idea.

Why not make network-manager default to having "Available to all users"
unchecked. Then it would not prompt for passwords for new wifi networks.
This would mean that, until the desktop user logs in, the machine would
not be on the network, so for reliable remote access, the admin would
need to override this new default, and enter their password. Seems sane
to me.

The problem with #97 is that those privs also control software installation.

I've done a trial upgrade from squeeze -> wheezy

In squeeze, the user was able to connect to access points without being
prompted for the root password

After the upgrade, the user is not able to use their system the way it
worked before.

Even if this default behavior is desired for fresh installs of NM, I
believe that users upgrading from wheezy should retain the legacy
behavior (automatically saving APs to their per-user profile rather than
the system profile)

----- Workaround -----

Here is a step by step version of the workaround that can be given to users:

- click `Activities' in the top left corner of the screen

- click `Applications'

- click `Accessories'

- click `Terminal'

- a terminal window appears.  In the window, type the following and
press enter:

      nm-connection-editor

- click `Wireless'

- click `Add'

- in the SSID box, type the exact name of the wifi network you want
(copy it from the list of available networks)

- the box at the top, `Connection name', it says `Wireless connection
1', delete that name and type the same name used for SSID

- if there is a password for the network, click `Wireless security',
select `WPA2 Personal' and type the password

- at the bottom of the window, REMOVE the tick from the box `Available
to all users'

- now click `Save...'

- click `Close' to make the connections window go away

- now go to the network icon at the top of the screen and click the
network: it should make the connection properly

Here is an upstream discussion thread mentioning the issue:

https://mail.gnome.org/archives/networkmanager-list/2011-March/msg00098.html


Apparently it was deliberately changed (not just a regression) after a
request from Ubuntu: but searching the Ubunutu forums reveals Ubuntu
users are also confused and frustrated with the situation

It is not clear whether upstream provides a compatibility option to make
things work consistently for people upgrading.

Looking in upstream git, it appears that it was not just a tweak, but a
rewrite of the system/user settings related code:

commit 443c95a6b9c8709f5d9038421df1856f190eeb24
Author: Daniel Gnoutcheff <daniel@gnoutcheff.name>
Date:   Tue Jul 13 18:09:56 2010 -0400

    nm-manager: start removing user settings services

    It turns out that user settings services are strange and complicated
    beasts. We will remove support for them, and we will later implement
    security mechanisms on the system settings service that will do what
    user settings services were intended to do.

    This commit is a bulk removal of nm-manager's internal support code for
    user settings services. The external API is largely unchanged, but
    errors are returned if anyone ties to do something with user settings.

    Work remaining includes some possible flattening of nm-manager's
    internal code, along with code removal and API changes in other modules.

There is a Debian bug concerning the new behavior, prompting for root
password every time a user adds a wifi network:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642136

I found it was discussed previously in this thread:

https://mail.gnome.org/archives/networkmanager-list/2011-March/msg00098.html

There are probably a lot of users who would like it to work the old way,
each time the user connects to some new wifi network, they should not be
prompted for the root password.

Is there already some fix for this in 0.9.6?  Debian has 0.9.4

Or is anyone else contemplating a fix?

Various ideas come to mind:

a) simply creating a connection (without overwriting or asking to view
existing credentials) should not require authentication (but maybe a
test to ensure the user is logged in at a physical console)

b) some option in NetworkManager.conf to preserve legacy behavior (new
connections are per-user by default)

tags 642136 + patch
thanks

I agree with Joey Hess: "Available to alle users" should not be the
default for new wifi connections, so that unprivileged users can
connect to new networks without needing a sudo or root password, or
additional policykit privileges.

The attached patch to the network-manager-applet (!) source modifies
nm-applet such that a new wifi connection created through the applet
belongs to the user, and not the system. If a wifi connection is to be
made available to all users, this has to be done in a separate step,
e.g. using nm-connection-editor.

I've tested this successfully with an open and a WPA2 secured network,
but I haven't had a chance to check if 802.1x networks have additional
settings that need to be set to "agent owned".

Florian

tags 642136 - patch
thanks

Unfortunately, things are a little more complicated, as Michael was so
kind to explain to me on IRC. I'm trying to sum up our conversation:

GENERAL PROBLEMS
- when changing the default for new connections in one client
  (nm-applet), other clients should be changed accordingly. This means
  at least gnome-shell (KDE may use different defaults anyway)
- in addition to wifi connections, also VPN and mobile broadband
  connections should be user-administrateable
- a system-wide connection has advantages, and upstream changed the
  default for a reason / in response to user feedback. E.g. it is not
  unreasonable to expect to be able to ssh into a running laptop, even
  when there's nobody logged in.

MY PATCH SPECIFICALLY
- in the interest of a minimal patch, marking the connection
  user-private *and* all secrets agent-owned is unnecessary;
  user-private is enough. The two are orthogonal really: marking secrets
  agent-owned determines whether the wifi password is stored in the
  /etc/NetworkManager/system-connections/<ssid> file or handled by the
  user's polkit authentication agent, whereas the user-private setting
  determines whether NetworkManager.settings.modify.system privileges
  are necessary and anybody but the current user can see the connection.

OPTIONS FOR A SOLUTION OF #642136
- do not change the default for new connections (system-wide), but add a
  polkit rule allowing members of the netdev and sudo groups to modify
  those connections. Group sudo can do everything anyway, and netdev is
  specifically meant for that. In addition, the user created during
  installation is automatically added to the netdev group, so that this
  would solve the "annoying password prompt" issue for the
  single-user-laptop case. The polkit rule would look like this:

    [Adding or changing system-wide NetworkManager connections]
    Identity=unix-group:netdev;unix-group:sudo
    Action=org.freedesktop.NetworkManager.settings.modify.system
    ResultAny=no
    ResultInactive=no
    ResultActive=yes

- this leaves open multi-user machines, where ordinary users should be
  able to e.g. add their home wifi, without being given the additional
  privileges that come with group membership (e.g., seeing the other
  guy's home wifi password). Think managed laptop repeatedly borrowed to
  students. Here, the system administrator could install a
  gsettings-override (provided in examples) that would make user-private
  connections the default. The gsetting would have to be added, as well
  as code to check it and switch to user-private when configured.

- personally, I'd prefer if things would "just work", that is: a
  user-private connection is created automatically if the user is not
  entitled to create a system-wide one, without the need to find out
  about a gsetting and install the override. Unfortunately, it is
  unclear if there is a way to query polkit whether the user would need
  to be asked for a password in order to execute an action with the
  NetworkManager.settings.modify.system privilege, without actually
  doing so.¹ An alternative would be to assume the existence of the above
  polkit rule and check the user's group memberships (getgid), but that
  approach is ugly because it hard-codes what is really just a default
  policy, and it may require the user to re-login in order for changes
  in group membership to take effect.

    ¹ there is a flag to polkit_authority_check_authorization to
    AllowUserInteraction, which is meant e.g. to decide whether a UI
    element should be displayed in an inactive style. This is exposed in
    nm_auth_chain_add_call.


Would the above polkit rule plus an automatic switch to user-private
connections solve this issue for all conceiveable use cases? What about
users who would have to type the root password, but are able and in fact
expect to do so? There's always nm-connection-editor to turn a
user-private connection into a system-wide one...

too tired to not be confused,
Florian

tags 642136 + patch
clone 642136 -1
reassign -1 gnome-shell
severity -1 important
clone 642136 -2
reassign -2 network-manager-gnome
severity -2 important
tags -2 + patch
clone 642136 -3
reassign -3 gnome-control-center
severity -3 important
thanks

..


Yeah, for simpler use-cases, especially the single-user-laptop case,
this .pkla file is sufficient and should solve the problem for most users.

This bug, #642136, will deal with that problem.

Joss found a way to do just that, i.e. query polkit and automatically
fall back to user settings if
org.freedesktop.NetworkManager.settings.modify.system would require an
admin password prompt. I think this is the ideal solution, so I'd like
to go with that, especially since Joss already has prepared a patch for
nm-applet [1]. Thanks a lot Joss!

Other NM clients which need to be updated accordingly are gnome-shell
and gnome-control-center, which both allow to setup NM connections. So
I'm cloning and re-assigning this bug accordingly.


Michael




[1] http://malsain.org/~joss/debian/

We believe that the bug you reported is fixed in the latest version of
gnome-shell, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 696257@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Biebl <biebl@debian.org> (supplier of updated gnome-shell package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Thu, 17 Jan 2013 10:43:30 +0100
Source: gnome-shell
Binary: gnome-shell gnome-shell-common gnome-shell-dbg
Architecture: source all amd64
Version: 3.4.2-6
Distribution: unstable
Urgency: low
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Michael Biebl <biebl@debian.org>
Description:
 gnome-shell - graphical shell for the GNOME desktop
 gnome-shell-common - common files for the GNOME graphical shell
 gnome-shell-dbg - Debugging symbols for GNOME Shell
Closes: 691436 696257
Changes:
 gnome-shell (3.4.2-6) unstable; urgency=low
 .
   [ Josselin Mouette ]
   * 28_network_user_connections.patch: new patch. Set connections and
     passwords as user-owned, following matching changes in nm-applet and
     gnome-control-center. The logic is:
     - Wired connections: always system-owned.
     - Modem (GSM/UMTS) connections are created by the control center.
     - Bluetooth PAN connections are now always user-owned.
     - Wireless connections are system-owned if the user has permissions
       (in Debian this means group sudo or netdev). Otherwise, it is
       user-owned, with the password in the keyring only for WPA.
     - 802.1x (wired or wireless) is always handled by the control
       center.
     Closes: #696257
 .
   [ Michael Biebl ]
   * Refresh patches to apply without fuzz.
   * 40-force-online.patch: If NM has an active unmanaged device it will
     forcefully set the online state to CONNECTED_GLOBAL. In that case show a
     wired connection icon instead of an offline icon. Closes: #691436
   * 28_network_user_connections.patch: Treat WEP keys like WPA-PSK secrets and
     store them in the keyring for user-owned connections.
Checksums-Sha1:
 371e2031a3f633d42c258cac481d561c7b64f33a 3239 gnome-shell_3.4.2-6.dsc
 36e828e2f4f3995c3e03f3241a68b48b2792b029 30961 gnome-shell_3.4.2-6.debian.tar.gz
 04d9bd62e3c2929c4df7be6012f515c0929a5739 664648 gnome-shell-common_3.4.2-6_all.deb
 9b6c94b4be2ad10b1f2aebca595ebf2672964550 280824 gnome-shell_3.4.2-6_amd64.deb
 294e7812532bf7aa4ca4750402df40dcce07a44e 758300 gnome-shell-dbg_3.4.2-6_amd64.deb
Checksums-Sha256:
 b92ee4de9e41af515319f89a4b685e0648c4ef5408ae121af618cc9d0d758e39 3239 gnome-shell_3.4.2-6.dsc
 433b1dafe0e6c982b4f091e867f4b7fdccd6c27babe71cfd3c95e20c8760aab5 30961 gnome-shell_3.4.2-6.debian.tar.gz
 1e3ad21e594f4b255c919c9573fb9f8c0b3cef58df0161536092e6cf7cc04f16 664648 gnome-shell-common_3.4.2-6_all.deb
 82986b8384a23fb561398f857a338cb3330f0a4846af5690b200a77a2155b2da 280824 gnome-shell_3.4.2-6_amd64.deb
 538a2f4629e3810e07c2578b5eec296533c840d7acc321af41d6ca418d78d6bc 758300 gnome-shell-dbg_3.4.2-6_amd64.deb
Files:
 9a723b0bd8dc2dab37f7f7a4cd874360 3239 gnome optional gnome-shell_3.4.2-6.dsc
 26d0830405207691af00eb6a70987740 30961 gnome optional gnome-shell_3.4.2-6.debian.tar.gz
 088f7516847d7d376fd756065b872f10 664648 gnome optional gnome-shell-common_3.4.2-6_all.deb
 874c7dbc63035d96c59cfa14052450f5 280824 gnome optional gnome-shell_3.4.2-6_amd64.deb
 eae3b38d16712a833653d6a53eaa21ec 758300 debug extra gnome-shell-dbg_3.4.2-6_amd64.deb
iQIcBAEBCAAGBQJQ98nQAAoJEGrh3w1gjyLc9BYP/3u/rGJLCuSURuoyZL0BcCgX
GwjgeicQvYLe442WGi4JLVe4LUS6ur+dH7AF7QO9nVF/TjVpXZzOXLfzGM0yhr9X
rqzoONitWR7o9mRJE8nn3ez7vrtnY1snVSC5XdsFvvpbsbcfWha8oWJRx3wNsoXG
aQVV5BjHOMdgVToGoxoAgDMCVmxYeWuODQNfRyQF8/mDieDwqLYloPTvctsjQZnb
60XA2nfxGujwK1YFhZuBjBGHaeJFyn9gVnUAAlpkPGCbzsZH3PHnvqv+IS7QvbmG
zQi/nk91edj4z/Sy9ZcO3nVvLwAoAmy8FKNXnAm8ftobQiJa1wkts7TiQmA6Bq75
OBROxQMBYJ8t9gNFg/kxNeonXNLrtGzbvLqFW0lymbs5md6LjOVTEznkQ8BrQP7L
utNU+T13hdb20f+z5VHEhSosECIOCmFqRpqAHa+hOe43E4neYsKNHo2vCkrrOtlK
nOoL/kJruEQww4HwYvhyB5WE44DRI6Qkqr+VP3kumtSqz+wJmndobyiLQX42L2zi
lWcPtNiUbO1O4rFg1DS+boqpDHLVNxX5bIfgSf0FvMDwFbKIZN58mx3R4O8uIDvy
BZ3tx0dWhv/swCgcPh3WFdk5FfnGHDTvdjhdNeBk6yWes3bn7RicuqdWF9veqz20
FFTjRxoHJS3dW4IbIPO8
=krFD
-----END PGP SIGNATURE-----