[MIR] gupnp

[Sebastien Bacher]

* Availability

Builds on all supported architectures in Ubuntu and on sync from Debian, the package was in main in the past and needs to be re-promoted

* Rationale

We would like to enable dlna sharing of media files, which is a GNOME upstream feature and relying on rygel which depends on the gupnp libraries

* Security

There is an old CVE recorded/fixed
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2174

* Quality assurance

- the desktop-packages team is subscribed to the package
- the bug lists in upstream, the Debian PTS and launchpad are empty
- upstream has a testsuit which is used during build

* Dependendies

The package uses standard desktop libraries that are already in main

* Standards compliance

the package is using standard packaging (dh10), the standards-version is 4.2, the package is in sync from Debian

* Maintainance

Upstream is active and the desktop team is going to look after the package in ubuntu

[Didier Roche-Tolomelli (didrocks)]

* -doc package: I think we should promote it as well in main, if the -dev is promoted. If so, this dep should be fixed: Depends: lynx | www-browser (first is lynx, in universe, www-browser is a virtual package not fullfiled?). In addition, it ships the doc in devhelp format (despite symlink from doc/ to gtk-doc/).
I don't think anyway that those are needed, we don't tend to have -doc dep on a browser implementation.

Opened question: should the tests run as autopkgtests? (Unsure if they are pure unit or interact with the rest of the system)

Second time a copyright file is up to date (last update in 2015 ;))

So, once the -doc thingy is sorted out, +1 for me. Same than other, security review would be nice as part of the dlna stack.

[Sebastien Bacher (seb128)]

Same as gssdp, the doc/depends issue is fixed in 1.0.3-2 in Debian/going to be autosynced. The tests are not integration tests so unsure there is much value having them as autopkgtests?

[Didier Roche-Tolomelli (didrocks)]

Thanks! Do you mind listing the exact binary package list which should then be promoted?

Agreed with you on the autopkgtests. This could have helped if vala were to regressed the lib build, but unsure this is really needed as a separate autopkgtests.

So, +1 for me, the security team should feel free to have a look at this one as well.

[Sebastien Bacher (seb128)]

The only binary we care about is 'libgupnp-1.0-4'.We can promote the documentation if that's standard practice but that's not needed.

[Chris Coulson (chrisccoulson)]

This one could do with a quick review from the security team.

[Chris Coulson (chrisccoulson)]

I reviewed gupnp 1.2.1-1 as checked in to eoan. This isn't a full security audit, but rather a quick gauge of maintainability.

- gupnp is a gobject based library for implementing and consuming UPnP services, and is required by Rygel.
- It's part of the GNOME project.
- It's written in C.
- One CVE in our database from 2009 (a DoS). Doesn't affect current releases, although it doesn't look like it was fixed in Ubuntu before the affected releases went EoL.
- Build-dependencies in main except for libgssdp-doc and libgssdp-1.2-dev (bug 1799977). Also gnome-pkg-tools, meson, valac, gtk-doc-tools, docbook-xml, docbook-xsl - none of these create binary dependencies.

- No maintainer scripts
- No init scripts / systemd units.
- No dbus services.
- No setuid binaries.
- Only binary is gupnp-binding-tool-1.2 in libgupnp-1.2-dev
- No sudo fragments.
- No udev rules.
- There's a few tests that seem to run in the build.
- No cron jobs.
- Build logs clean other than some documentation warnings.
- Lintian clean

- Doesn't spawn any subprocesses.
- Memory management looks ok - there is a g_malloc in strip_camel_case that allocates memory based on a multiplication that isn't overflow safe, but the source of this isn't attacker controlled and I don't think it can overflow anyway.
- The only file IO it seems to do is using glib's GMappedFile API, which is used for providing file contents to libsoup for hosting local files. See below for how paths are looked up.
- Not much logging - a few g_debugs (not enabled by default) and some g_message calls. It doesn't look like anything sensitive is logged.
- Reads a couple of variables from the environment - GUPNP_DEBUG and GUPNP_DEBUG_NETLINK. The first one enables logging to stdout of headers + request/response bodies in libsoup, and enables reporting of warnings and errors in libxml when loading local XML files. The second one enables the dumping of netlink packets to stdout.
- Doesn't call any privileged commands.
- No crypto.
- Doesn't use temporary files.

- GUPnPContext creates a HTTP server using libsoup. There is one GUPnPContext per network interface, created and managed by GUPnPContextManager. The availability of services is advertised via SSDP (using gssdp - GUPnPContext sub-classes GSSDPClient for this)
  - The default handler just returns 404.
  - It provides a simple API for hosting local paths for read access. The default libsoup handler (host_path_handler) for this supports directory listing and automatic redirection to index.html for paths to directories. This API is used by root device instances to host device and service XML descriptions.
  - host_path_handler() uses construct_local_path() to build a local file path, which just appends the request path to the handler's base path. It's relying on a feature of libsoup to not be vulnerable to path traversal attacks, which I've tested and seems to work.
  - GUPnPContext provides a mechanism to register handler functions for specific server paths, which is used by service instances to implement action handlers. I believe rygel also uses this for hosting media files.
  - It provides a mechanism for applications to implement ACLs by registering an ACL handl...