Aleksander Morgado writes ("Bug#877024: modemmanager should ask before messing
with serial ports"):
> Hey Ian!
> > Since the maintainers and upstream evidently disagree with this
> > tradeoff, it has been necessary for me to ask the TC to step in.
>
> The maintainers don't actually disagree. Why didn't you bring this
> issue to the ModemManager mailing list in the first place? I
> personally don't follow any downstream ModemManager bug, and we even
> have a bug open upstream:
> https://bugs.freedesktop.org/show_bug.cgi?id=85007
Thanks for your response. It's excellent to see someone taking an
interest in this bug.
However, I have to say that that upstream bug log does not really
suggest to me that upstream thinks that the current probing behaviour
is unacceptable. It has been open since 2014 and if the bug is to be
believed the modemmanager default behaviour in upstream has not
changed.
The key part of your response in #683839 is as follows:
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.
Your concern here is precisely the user convenience which I am saying
needs to be traded off for safety and reliability.
"Every TTY" is rather hyperbolic, of course. We are only speaking
here of tty devices which might be modems. modemmanager already
refrains from autoprobing builtin serial devices ttyS* and I assume it
ignores things like multiport serial cards. So we are speaking mostly
of USB-attached serial ports. And we only need confirmation the first
time one is plugged in.
As I have explained, a blocklist is not sufficiently safe or reliable.
A passlist of things known definitely to be modems (not generic USB to
serial chips) would help reduce the user query burden.
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.
In those situations, obviously, I would expect use of a command-line
tool or configuration file.
> > * Say that, in the absence of a better solution, my patch should
> > be applied to modemmanager.
>
> I commented about that patch in bug 683839, please don't apply it,
> it would break all modems not only those with TTYs.
Sorry about that. I wasn't able to get modemmanager working with my
MBIM device (which I'm now using in Hilink mode, hence without
modemmanager, anyway) so I wasn't able to test that path.
Please can you point me to the right place to make this change ?
I can try revising my patch by myself but it will be more likely
to be right if you help.
> Again, I'd have suggested to bring this patch to the ModemManager
> mailing list before just saying that the patch should be applied in
> absence of a better solution...
As a Debian user, experiencing a problem with the default
configuration of my Debian system, and trying to use Debian's
governance processes to escalate the bug, it is appropriate for me to
use a Debian channel for this.
But I really appreciate you taking an interest.
> An easier thing would be to allow just "dpkg -R
> modemmanager", there should be no other package depending on the
> daemon itself.
That's no help because someone might have (for example) both a modem
and a braille display, or whatever.
Ian.
--
Ian Jackson <ijack...@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.
