Debian Bug report logs - #683839
modemmanager fiddles with ttyUSB devices without asking first

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: submit@bugs.debian.org

Subject: modemmanager fiddles with ttyUSB devices without asking first

Date: Sat, 4 Aug 2012 18:52:36 +0100

Package: modemmanager
Version: 0.4+git.20100624t180933.6e79d15-2
Severity: serious

I have been having trouble getting our reprap (open hardware 3D
printer) connecting reliably.  Sometimes the host control softare gets
EBUSY and at other times it appears to suffer protocol violations
during startup.  The reprap shows up as a ttyUSB emulated serial
device.

EBUSY indicates that something else on the system is opening the
serial port.  Having investigated this, in particular grepping the
logs, I see things like this:

/var/log/daemon.log:Aug  4 14:04:09 zealot modem-manager: (ttyUSB0): probe requested by plugin 'Generic'
/var/log/daemon.log:Aug  4 14:04:20 zealot modem-manager: (ttyUSB0) closing serial device...
/var/log/daemon.log:Aug  4 14:04:21 zealot modem-manager: (ttyUSB0) opening serial device...
/var/log/daemon.log:Aug  4 14:04:27 zealot modem-manager: (ttyUSB0) closing serial device...

It is not appropriate for a package like modemmanager to
unconditionally open and "probe" serial devices.  Serial devices,
including both conventional ttyS* devices and USB-serial adapters such
as ttyUSB, might be connected to arbitrary hardware.

Indeed serial ports are often used for connection to ad-hoc
peripherals such as the microcontrollers controlling machine tools and
other real-world physical systems.  Sending "probe" messages to them
might cause arbitrarily weird or dangerous behaviour, since such
peripherals by their nature speak their own private protocols.  Even
opening the port might interfere with control software.

The modemmanager package should therefore obtain permission before
allowing probing of arbitrary serial ports.  (Automatic probing,
without permission, of "serial" ports which modemmanager knows, eg via
the USB device ID or kernel device name, are actually modems is fine.)

The default value for this permission must be "off".

I don't know exactly how I got modemmanager installed, but the most
likely cause is the Recommends from network-manager, which I do use on
this system.  I did try to get my GSM/HSPA modem connection working
with network-manager, but failed; I use a simple shell script to
invoke pppd by hand for that; so luckily for me I am able to deinstall
modemmanager.  Users who are using modemmanager for their network
connection /and/ also trying to do machinery control with the same
computer would probably benefit from a more selective workaround which
disables the scan for certain devices.

Severity justification: This behaviour of modemmanager can undoubtedly
cause trouble for unrelated software on the system.

It might cause machinery connected to the computer to malfunction,
perhaps causing physical damage or even personal injury.  These latter
consequences are perhaps unlikely but it is difficult to analyse the
risk because we can't know what protocols such hardware speaks.

Thanks,
Ian.

Message #10 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 683839@bugs.debian.org

Subject: Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first

Date: Mon, 20 Aug 2012 16:15:26 +0200

[Message part 1 (text/plain, inline)]

On 04.08.2012 19:52, Ian Jackson wrote:
> 
> I have been having trouble getting our reprap (open hardware 3D
> printer) connecting reliably.  Sometimes the host control softare gets
> EBUSY and at other times it appears to suffer protocol violations
> during startup.  The reprap shows up as a ttyUSB emulated serial
> device.

Please attach the output of
 udevadm info --attribute-walk --name=/dev/ttyUSB0
This should include the  VID/PID and driver name which should be enough
to blacklist this particular device.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 683839@bugs.debian.org

Subject: Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first

Date: Wed, 22 Aug 2012 18:18:18 +0100

Michael Biebl writes ("Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first"):
> Please attach the output of
>  udevadm info --attribute-walk --name=/dev/ttyUSB0
> This should include the  VID/PID and driver name which should be enough
> to blacklist this particular device.

For the reasons I have explained in my bug report, a blacklist is not
the appropriate way to deal with this.  There should be a whitelist
instead.

Ian.

Message #22 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 683839@bugs.debian.org

Subject: Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first

Date: Tue, 11 Sep 2012 21:24:27 +0200

[Message part 1 (text/plain, inline)]

On 22.08.2012 19:18, Ian Jackson wrote:
> Michael Biebl writes ("Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first"):
>> Please attach the output of
>>  udevadm info --attribute-walk --name=/dev/ttyUSB0
>> This should include the  VID/PID and driver name which should be enough
>> to blacklist this particular device.
> 
> For the reasons I have explained in my bug report, a blacklist is not
> the appropriate way to deal with this.  There should be a whitelist
> instead.

A whitelist is not an acceptable solution with the amount of new devices
popping up every day. This would be a losing battle.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #27 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Michael Biebl <biebl@debian.org>

Cc: 683839@bugs.debian.org

Subject: Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first

Date: Tue, 11 Sep 2012 21:07:03 +0100

Michael Biebl writes ("Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first"):
> A whitelist is not an acceptable solution with the amount of new devices
> popping up every day. This would be a losing battle.

Then the question is whether it is better to ask users a question when
they try to use what may be a modem, or to risk destroying hardware or
injuring people.

Ian.

Message #32 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Maximilian Gaukler <development@maxgaukler.de>

To: 683839@bugs.debian.org

Subject: modemmanager fiddles with ttyUSB devices without asking first

Date: Wed, 19 Sep 2012 16:51:04 +0200

Hi,

this also breaks apcupsd when connecting a UPS through a USB-serial 
converter. It took some time to find this out, so I am not very amused.

This behaviour is not okay because modem-manager is installed by default 
and there is no simple standardised way for other applications to stop 
it from interfering with a particular device.

Because the status lines are changed when opening and closing a device, 
some boards like Arduino-based 3D printer controls even reset because of 
modem-manager testing them!

We need to find some solution so that this autoprobing is not active by 
default (only enabled after user interaction), since it is impossible to 
change every single control software using a serial port.

Thanks

Max Gaukler

Message #37 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Maximilian Gaukler <development@maxgaukler.de>, 683839@bugs.debian.org

Subject: Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first

Date: Wed, 19 Sep 2012 17:21:14 +0200

[Message part 1 (text/plain, inline)]

On 19.09.2012 16:51, Maximilian Gaukler wrote:

> this also breaks apcupsd when connecting a UPS through a USB-serial 
> converter. It took some time to find this out, so I am not very amused.

https://bugzilla.redhat.com/show_bug.cgi?id=544121 is a related bug report.

> 
> This behaviour is not okay because modem-manager is installed by default 
> and there is no simple standardised way for other applications to stop 
> it from interfering with a particular device.

You could try the workaround described at
https://bugzilla.redhat.com/show_bug.cgi?id=544121#c54 for now


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #42 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Bill Alexander <billtrash@gmail.com>

To: 683839@bugs.debian.org

Subject: Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first

Date: Sat, 1 Dec 2012 18:48:24 -0800

Add radio interfaces to the list of devices that have suffered from
modem manager's interference.  When modem manager asserts RTS, a radio
may be destroyed or an operator placed into violation of the law if
the radio is not correctly configured for transmission.

I concur with the other comments that a blacklist is not the "right"
way to fix this.  But I will be absolutely delighted to have one
versus nothing at all.

The following link contains udev rules for blacklisting two affected
radio interfaces.

https://bugzilla.redhat.com/show_bug.cgi?id=771010

Many thanks,

- Bill

Message #47 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 683839@bugs.debian.org

Subject: Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first

Date: Tue, 05 Mar 2013 21:11:09 +0100

[Message part 1 (text/plain, inline)]

On 11.09.2012 22:07, Ian Jackson wrote:
> Michael Biebl writes ("Re: Bug#683839: modemmanager fiddles with ttyUSB devices without asking first"):
>> A whitelist is not an acceptable solution with the amount of new devices
>> popping up every day. This would be a losing battle.
> 
> Then the question is whether it is better to ask users a question when
> they try to use what may be a modem, or to risk destroying hardware or
> injuring people.

Not sure if this addresses your issue fully, but thought it might be
interesting nonetheless:

https://bugzilla.gnome.org/show_bug.cgi?id=647556
http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=8450b7b2a39a6e1c9fda950dc3f821984c73c56b

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #52 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Lincoln Roop <lroop@club.cc.cmu.edu>

To: 683839@bugs.debian.org

Subject: Request for blacklist entry

Date: Thu, 18 Jun 2015 15:31:57 -0400

Can the following USB VID/PID combination be added to the blacklist of devices that modem-manager should not attempt to probe?  VID 0830, PID 0003.  Device is an old Palm M515 PDA, modem-manager probing breaks HotSync with pilot-link, JPilot, etc. and casues the Palm to hang with a "Fatal Error" message.  I know this is a very old piece of hardware, but as it has no use as a modem I can't see there being any need for modem-manager to probe it.

Thanks,
Lincoln R.

Message #57 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Lincoln Roop <lroop@club.cc.cmu.edu>

To: 683839@bugs.debian.org

Subject: Re: Bug#683839: Info received (Request for blacklist entry)

Date: Fri, 19 Jun 2015 00:52:57 -0400

I did some testing this evening, and can confirm that on Wheezy and 
Jessie, adding a file to /lib/udev/rules.d/ containing the following 
lines will prevent modem-manager from crashing Palm M500, M505, and M515 
handhelds.  If it's beneficial, I can try to dig through the source for 
the Palm/Visor driver for other USB PID/VID pairs that correspond to old 
Palm handhelds.

# Rules to blacklist Palm Pilot devices from modem-manager probing

ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"

# Palm M500
ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0001", 
ENV{ID_MM_DEVICE_IGNORE}="1"

# Palm M505
ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0002", 
ENV{ID_MM_DEVICE_IGNORE}="1"

# Palm M515
ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0003", 
ENV{ID_MM_DEVICE_IGNORE}="1"

Message #62 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Lincoln Roop <lroop@club.cc.cmu.edu>, 683839@bugs.debian.org

Subject: Re: Bug#683839: Info received (Request for blacklist entry)

Date: Fri, 19 Jun 2015 12:08:13 +0200

[Message part 1 (text/plain, inline)]

Am 19.06.2015 um 06:52 schrieb Lincoln Roop:
> I did some testing this evening, and can confirm that on Wheezy and
> Jessie, adding a file to /lib/udev/rules.d/ containing the following
> lines will prevent modem-manager from crashing Palm M500, M505, and M515
> handhelds.  If it's beneficial, I can try to dig through the source for
> the Palm/Visor driver for other USB PID/VID pairs that correspond to old
> Palm handhelds.
> 
> # Rules to blacklist Palm Pilot devices from modem-manager probing
> 
> ACTION!="add|change", GOTO="mm_usb_device_blacklist_end"
> SUBSYSTEM!="usb", GOTO="mm_usb_device_blacklist_end"
> ENV{DEVTYPE}!="usb_device",  GOTO="mm_usb_device_blacklist_end"
> 
> # Palm M500
> ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0001",
> ENV{ID_MM_DEVICE_IGNORE}="1"
> 
> # Palm M505
> ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0002",
> ENV{ID_MM_DEVICE_IGNORE}="1"
> 
> # Palm M515
> ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0003",
> ENV{ID_MM_DEVICE_IGNORE}="1"

Thanks for this information, Lincoln.
Can you please file a bug upstream at [1] and report back with the bug
number.

Regards,
Michael


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=ModemManager
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #67 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Lincoln Roop <lroop@club.cc.cmu.edu>

To: 683839@bugs.debian.org

Subject: Re: Bug#683839: Info received (Bug#683839: Info received (Request for blacklist entry))

Date: Fri, 19 Jun 2015 14:50:40 -0400

Submitted upstream bug report #91032:

https://bugs.freedesktop.org/show_bug.cgi?id=91032

Message #72 received at 683839@bugs.debian.org (full text, mbox, reply):

From: M G Berberich <debian@oss.m-berberich.de>

To: 683839@bugs.debian.org

Subject: still a problem in stretch

Date: Fri, 11 Sep 2015 09:47:05 +0200

Hello,

modemmanager messes up my ttyS3 with my 1-wire DS9097 interface and
ttyS2 with my serial terminal (vt320), to a point I can’t get them
work without reboot.

There seems to be no way to prevent modemmanager to mess up these
interfaces.

There seems to be no way to prevent modemmanager from starting if it
is installed.

There seems to be no easy way to prevent modemmanager to be constantly
reinstalled by aptitude because of dependencies.

	MfG
	bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“          | berberic@fmi.uni-passau.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | www.fmi.uni-passau.de/~berberic

Message #77 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 683839@bugs.debian.org

Subject: Patch to disable scanning of unsafe devices by default

Date: Mon, 25 Sep 2017 12:00:59 +0100

Control: tags -1 patch

Please find attached a very basic patch which inverts the logic,
introducing a udev ENV attribute to specify which devices are safe to
probe, and assuming that devices are not safe unless specified
otherwise.

It is evident from the history of this bug that the maintainers don't
agree with this as an approach.

IMO this situation is a very serious bug because it has possible
personal safety implications.  If I don't get a positive response, I
will escalate this (belatedly!) to the TC.

By a "positive response" I mean a promise to arrange that (at least in
buster), Debian will no longer by default probe unknown serial devices
without explicit user permission of some kind.

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Message #84 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 683839@bugs.debian.org

Subject: Re: Patch to disable scanning of unsafe devices by default

Date: Mon, 25 Sep 2017 12:01:52 +0100

[Message part 1 (text/plain, inline)]

Ian Jackson writes ("Patch to disable scanning of unsafe devices by default"):
> Control: tags -1 patch

Forgot to actually attach the patch.

[0001-Prove-serial-devices-only-when-known-to-be-safe.-Clo.patch (text/plain, inline)]

From b491dba87b85fc8f1b6e27be02b9bcd8ef6d61be Mon Sep 17 00:00:00 2001
From: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Mon, 25 Sep 2017 11:55:35 +0100
Subject: [PATCH] Prove serial devices only when known to be safe. 
 Closes:#683839

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
 src/mm-base-manager.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mm-base-manager.c b/src/mm-base-manager.c
index 275a855..c047deb 100644
--- a/src/mm-base-manager.c
+++ b/src/mm-base-manager.c
@@ -374,8 +374,8 @@ device_added (MMBaseManager *manager,
 
     /* Is the device in the manual-only greylist? If so, return if this is an
      * automatic scan. */
-    if (!manual_scan && g_udev_device_get_property_as_boolean (physdev, "ID_MM_DEVICE_MANUAL_SCAN_ONLY")) {
-        mm_dbg ("(%s/%s): port probed only in manual scan", subsys, name);
+    if (!manual_scan && !g_udev_device_get_property_as_boolean (physdev, "ID_MM_DEVICE_AUTO_SCAN_SAFE")) {
+        mm_dbg ("(%s/%s): port not known to be safe, probed only in manual scan", subsys, name);
         goto out;
     }
 
-- 
2.11.0

Message #91 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Aleksander Morgado <aleksander@aleksander.es>

To: 683839@bugs.debian.org

Subject: Re: Patch to disable scanning of unsafe devices by default

Date: Thu, 28 Sep 2017 17:30:59 +0200

> It is evident from the history of this bug that the maintainers don't
> agree with this as an approach.
> 

I wonder how that is evident given that we (maintainers) still keep the bug open upstream and discuss about it from time to time...
https://bugs.freedesktop.org/show_bug.cgi?id=85007

I personally acknowledge the problem, but so far I've failed to find time to think of what the proper solution would be...

A full whitelist is something we don't really consider, given the large amount of devices coming out all over the world, and the lack of time we already have.

Asking the user... well, what would we ask? Should we ask "is this a modem" for every TTY we find? Is it better to annoy thousands of users each time a TTY is found instead of blacklist for all of them? We try to keep the blacklist in stable releases updated and stables happening each 2-3 months. Plus, there isn't always a "user" to ask when a modem is plugged in, ModemManager (as NetworkManager) don't really require a GUI to work and lots of headless systems out there use it.

One thing to maybe consider is whether we should just assume that it is a modem if:
 * We have more than one TTY exposed by the same USB device (are there non-modem devices out there that would usually do this?).
 * We have a TTY and a NET port exposed by the same USB device.

Or in other words, don't autoprobe a TTY if the USB device only has that one single TTY... Less and less mobile broadband modems fall in that last case, and definitely none of the recent modems I've seen would fall into the single-TTY category (except for maybe "professional" ruggerized devices and such but sometimes they're not even USB but pure RS232, and those aren't probed automatically anyway). Maintaining a whitelist of single-TTY modems may be feasible...

Blindly requiring a udev tag for a TTY to be probed during automatic scans will break all non-QMI non-MBIM modems :/

So yeah, totally open to discussion here.

-- 
Aleksander

Message #96 received at 683839@bugs.debian.org (full text, mbox, reply):

From: Aleksander Morgado <aleksander@gnu.org>

To: 683839@bugs.debian.org

Subject: Re: Patch to disable scanning of unsafe devices by default

Date: Thu, 28 Sep 2017 17:40:59 +0200

[Message part 1 (text/plain, inline)]

> 
>      /* Is the device in the manual-only greylist? If so, return if this is an
>       * automatic scan. */
> -    if (!manual_scan && g_udev_device_get_property_as_boolean (physdev, "ID_MM_DEVICE_MANUAL_SCAN_ONLY")) {
> -        mm_dbg ("(%s/%s): port probed only in manual scan", subsys, name);
> +    if (!manual_scan && !g_udev_device_get_property_as_boolean (physdev, "ID_MM_DEVICE_AUTO_SCAN_SAFE")) {
> +        mm_dbg ("(%s/%s): port not known to be safe, probed only in manual scan", subsys, name);
>          goto out;
>      }

That will effectively block probing for all device ports (QMI, MBIM, net...), not only TTYs.

-- 
Aleksander

[signature.asc (application/pgp-signature, attachment)]

Message #101 received at 683839-close@bugs.debian.org (full text, mbox, reply):

From: Mathieu Trudel-Lapierre <mathieu.tl@gmail.com>

To: 683839-close@bugs.debian.org

Subject: Bug#683839: fixed in modemmanager 1.7.990-1

Date: Mon, 05 Mar 2018 15:55:32 +0000

Source: modemmanager
Source-Version: 1.7.990-1

We believe that the bug you reported is fixed in the latest version of
modemmanager, 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 683839@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mathieu Trudel-Lapierre <mathieu.tl@gmail.com> (supplier of updated modemmanager 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@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 01 Mar 2018 09:20:02 -0500
Source: modemmanager
Binary: modemmanager modemmanager-dev modemmanager-doc libmm-glib0 libmm-glib-dev libmm-glib-doc gir1.2-modemmanager-1.0
Architecture: source
Version: 1.7.990-1
Distribution: unstable
Urgency: medium
Maintainer: Mathieu Trudel-Lapierre <mathieu.tl@gmail.com>
Changed-By: Mathieu Trudel-Lapierre <mathieu.tl@gmail.com>
Description:
 gir1.2-modemmanager-1.0 - GObject introspection data for modemmanager
 libmm-glib-dev - D-Bus service for managing modems - library development files
 libmm-glib-doc - D-Bus service for managing modems - library documentation
 libmm-glib0 - D-Bus service for managing modems - shared libraries
 modemmanager - D-Bus service for managing modems
 modemmanager-dev - D-Bus service for managing modems - development files
 modemmanager-doc - D-Bus service for managing modems - documentation files
Closes: 683839 884617
Changes:
 modemmanager (1.7.990-1) unstable; urgency=medium
 .
   * New upstream version 1.7.990.
   * debian/control: Bump libqmi-glib-dev and libmbim-glib-dev Depends to new
     required versions (libmbim > 1.16, libqmi > 1.20) for this release.
   * Update Maintainer field for my 'real' address. (Closes: #884617)
   * debian/control: Update Vcs-* fields: moved project to salsa.d.o.
   * debian/control: Bump to Standards-Version 4.1.3.
   * debian/copyright:
     - Fix Format: URL to use https.
     - Drop extra stanza for libwmc; it really is only GPL2, not GPL2+.
   * debian/rules: set DPKG_GENSYMBOLS_CHECK_LEVEL=4; more verbose when there
     are added/changed symbols.
   * debian/libmm-glib0.symbols: update symbols for new release.
   * debian/patches/default_strict_probing_policy.patch: set the filtering
     policy for probing to 'strict' by default: this will avoid probing devices
     that are not modems, and potentially interfering with RNGs, braille, etc.
     (Closes: #683839)
Checksums-Sha1:
 23d5b30a61c68c105b1887a63f4c77cae85fca24 2681 modemmanager_1.7.990-1.dsc
 6ca7fab3dae346b8815ecb2f2f8699d9f017172c 1982056 modemmanager_1.7.990.orig.tar.xz
 01b7e1309394c6e78760510b59858b13ed625929 21768 modemmanager_1.7.990-1.debian.tar.xz
 d32c7881ae6c55aff0959f91565982670a7cda32 10416 modemmanager_1.7.990-1_source.buildinfo
Checksums-Sha256:
 7f05f487098f30c242743f4591af0b0f220d0541874a2746779cf6bad192bfdd 2681 modemmanager_1.7.990-1.dsc
 d465094fc6fc173354f5a00d212049056829cc245d60a9083f3c53f86a8f90ec 1982056 modemmanager_1.7.990.orig.tar.xz
 bcfdfda38f119a850c9a2d2d6dfb708c11996a7e11e6e1640f7f30b483959efd 21768 modemmanager_1.7.990-1.debian.tar.xz
 65eca33aee8ff354435675a16db47fb57606b647ff93171e25135ff37734a4a0 10416 modemmanager_1.7.990-1_source.buildinfo
Files:
 aea07d873d7a94c0155ffc723960d904 2681 net optional modemmanager_1.7.990-1.dsc
 b050387fdee6ca3530282de338ab94e4 1982056 net optional modemmanager_1.7.990.orig.tar.xz
 0a4e2b974d549505786963d527d4a2e1 21768 net optional modemmanager_1.7.990-1.debian.tar.xz
 b6e6433b1a05c094ef144af434dfc6cc 10416 net optional modemmanager_1.7.990-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEOXpIEO6xMwaMLot69mTSVrRpGn0FAlqdYRsACgkQ9mTSVrRp
Gn3nhA//be5tjvKlSimCP+a7JV9Ov7k5FAsXdq7tLpvtrqBezNkkVOclKFamu20C
Tc32KUTmbnnWo+A3VxZpjSnTdSGY0PaepRvRCl816Be8IC6nZqXYrf87JU+lC6Vl
QlgXo8D/Wb6mRdodvQtca7cNF70fIHxbdcWAHbGS1KqNyNmaZ3yVbFzxojKvnzjb
qBxxq+AaEUfN7XqGGt1vx2ZojLd0X6UAfmG2icNGFa3Mpv0YZPMs6C0tidORB3IT
N9cSIW017G/YCwlHVmTg1NDALYguzlRGjfv9SaGRrNixFuzFN6/zWaLzXoKEWESb
AmTs3ESZPtu9irYznHsPjSTZfjJblR4wWeciN9d1/uffk1ZyCidqooaCQw+mw/Rp
Ok/2doDKPDHBE5eVohPwVR1reOuF8Lf/d0j6TJ+2r+nacKSGQXdE0eEIFiUxXb2k
D8Mck9RkOgpgMXpBrkYNM+XWPknj7eW2Tod60iu0gpFiLgK/9qOfv3iFDozyYXIq
vziybL8FSA6fnim+4QekcbDEg7xBES/UkVFRrWRm3sK7y4nNPin8W5qb4tyRsdPQ
pNmaBcBWXia0jdDpCChISsUP3rDF7qB20je0qYzRVA09Rwy+Zk1kfU8qrPZyMcxA
ToiWfrgWxIsQlqPp2O8E+WQLQ2JbJmXI/B9GjOK8UiXwNCjZrTI=
=Hdot
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.