Re: Re: [PATCH BlueZ v2 00/10] Distribution inspired fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Luiz,

On Wed, 14 Feb 2024 at 21:31, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:


> > >
> > > --with-phonebook=tracker
> > >
> > > It does seem to work,
> >
> > I think you meant to say s/work/is allowed/ :-) Commit "obex: remove
> > phonebook tracker backend" bans this as an option.
> Hmm, I don't have anything like that on git log, do you have the actual hash?

It hasn't been merged yet - it is 7/10 of the series.


> For messages I guess you are right, we can just remove them since they
> were never really used, but at least the phonebook-ebook was used at
> some point, so perhaps we just switch to use it by default, so we can
> remove the backend options, etc.

Just double-checking:
Your proposal is to implicitly and unconditionally enable
--with-phonebook=ebook, remove the configure option alongside the
other phonebook-dummy.c backend?
Overall I like the idea of having fewer knobs to manage and things
that could go wrong.

Looking at libebook, I'm not 100% sure it's a wise move though ...
 - size: indirectly pulls well over 60 libraries - blkid, brotli,
camel, gpg, krb5, lzma, libsecret, libsoup, sqlite, nss, tpm2-tss,
nspr, libnghttp2, libpsl
 - users: cannot find anyone outside of Gnome circle - KDE, XFCE,
elementary, etc nothing
 - functionality: the dummy backend produces simple vcf files,
supported by a wide range of tools

As a selfish example, switching to libebook will force extra ~200MiB
worth of packages, while simultaneously removing the vcf/VCard

Ignoring my choice of DE and distribution, I am not sure that
quadrupling the dependencies is a good idea - currently obexd pulls
~20, with the proposal we're looking at over 80. Since the obex daemon
can receive potentially malicious data and with so many dependencies
the word "honeypot" comes to mind.

Just earlier today, a distribution maintainer highlighted something
interesting. Overall when managing/packaging/shipping software one
should consider a) the overall number of package/library dependencies
and b) how often they are hit by CVEs.
I'm grossly paraphrasing, only part of what they said but I think the
message is clear.

With that in mind, I would prefer if (lib)ebook is not the default.


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux