[MIR] libblockdev

 - missing bug subscriber

 - why don't we build the plugin on s390x? The Debian comment is
   terse, and we should not diverge a library package across
   architectures.

  - warning: Depends field of package python-blockdev: unknown \
       substitution variable ${python2:Depends}
    That one doesn't exist, leaving the package without dependencies.

 - the package maybe should get a security review.

Ubuntu Desktop Bugs is subscribed now although the Desktop Team thinks that Foundations should be responsible for udisks-related packages.

python-blockdev issue fixed by dropping that unused Python2 package.

libblockdev is built the same across architectures. Upstream offers an extra s390 plugin that didn't work correctly and that has been disabled.

Security review team is not subscribed if it needs so.

also please add symbols files for the library files

Imho, s390 plugin should be built. It should not bring any more additional runtime dependencies, but without it, none of the s390 hard drives could be operated on with this package.

Dimitri, we tried to get the s390 plugin to work but it caused the package to FTBFS on s390x. If you want it, you're welcome to fix the issue.

See for instance https://launchpad.net/ubuntu/+source/libblockdev/2.12-3

@jbicha

That include is deprecated, and this got fixed in 2.14, see NEWS entry
- Do not include s390utils/vtoc.h in s390 plugin

See how it builds fine in e.g.:

https://launchpadlibrarian.net/357610446/buildlog_ubuntu-bionic-s390x.libblockdev_2.14-3ubuntu1+ppa1_BUILDING.txt.gz
dh_missing --fail-missing
dh_missing: usr/lib/s390x-linux-gnu/libbd_s390.so.2.0.0 exists in debian/tmp but is not installed to anywhere
dh_missing: usr/lib/s390x-linux-gnu/libbd_s390.so.2 exists in debian/tmp but is not installed to anywhere
dh_missing: usr/lib/s390x-linux-gnu/libbd_s390.so exists in debian/tmp but is not installed to anywhere
dh_missing: usr/include/blockdev/s390.h exists in debian/tmp but is not installed to anywhere
dh_missing: missing files, aborting

Built correctly, just needs shipping in a package.

Dimitri,

Michael Biebl would rather not build the s390 plugin in Debian. He pointed to this comment which says that it's currently not used by udisks but only by Fedora/Red Hat-specific utilities.

https://github.com/storaged-project/libblockdev/pull/275#issuecomment-328516293

symbols have been added in 2.16-1 which should auto-sync to bionic-proposed soon.

I reviewed libblockdev version 2.16-2 as checked into bionic. This should
not be considered a full security audit but rather a quick gauge of
maintainability.

- libblockdev is a plugin-based library to work with block devices,
  providing an API based interface that knows how to either perform
  underlying operations directly or call the necessary command line
  applications as appropriate.

- There are no CVEs in our database

- Build-Depends: debhelper, libtool, dh-python, python3:any, libglib2.0-dev
  libgirepository1.0-dev, libcryptsetup-dev libdevmapper-dev libudev-dev
  libsystemd-dev, libdmraid-dev, libvolume-key-dev, libbytesize-dev,
  libnss3-dev libparted-dev libmount-dev libblkid-dev libpython3-dev,
  libkmod-dev gtk-doc-tools, gobject-introspection, pylint

- libblockdev does not itself daemonize
- no networking
- automatically generated pre/post inst/rm scripts
- no initscripts
- no dbus services
- no setuid files
- no executables in PATH
- no sudo fragments
- no udev rules
- There is a test suite; it is not run during the build. I suspect keeping
  this test suite disabled is the right approach.
- No cronjobs
- Noisy build logs, primarily from the documentation tools; not ideal, but
  at least not much from the code itself

- Several plugins execute helper tools; the glib helpers make the
  resulting code fairly complex, but it looks like the executions were
  carefully written
- memory management is careful; allocated memory is quickly freed when it
  is no longer used to simplify error handling
- normally 'files' being opened are block devices
- Logging functions looked careful
- No environment variable use
- Does not itself do cryptography -- drives LUKS, VeraCrypt, etc via
  helpers
- Does not do networking
- Does not use temporary files
- Does not use WebKit
- Does not use PolicyKit
- Does not use JavaScript
- Mostly clean cppcheck results; s390 code has legitimate errors:
  [src/plugins/s390.c:293]: (error) Used file that is not opened.
  [src/plugins/s390.c:293]: (error) Resource handle 'fd' freed twice.
  [src/plugins/s390.c:968]: (error) Resource leak: fd

The s390 code does not feel as mature as the rest of the code base.
I suspect a deeper inspection of the s390 sources would find more issues.
If it can be disabled without significant loss of functionality then I
recommend we disable it.

Security team ACK for promoting libblockdev to main.

Here's some notes I took while reviewing the code, in the hopes that they
are useful:

- bd_s390_dasd_online() double-closes fd, uses fd when it isn't open
- bd_s390_zfcp_offline() leaks fd in rc == EOF branch
- bd_s390_zfcp_online() calls fclose(fd) in a branch when fd is known to
  be NULL
- bd_s390_zfcp_scsi_offline() does not check fopen(hba_path, "r") for an
  error return
- bd_s390_zfcp_scsi_offline() does not check fopen(wwpn_path, "r") for an
  error return
- bd_s390_zfcp_scsi_offline() does not check fopen(lun_path, "r") for an
  error return

- bd_crypto_tc_open(), luks_format(), (and other functions) do not zero
  out secrets such as passwords. (This is difficult to do; the goal is not
  to be perfect, but to try. Simply adding memset_s() calls would be a
  step in th...

Here are a list of libblockdev's binary packages that depend on universe packages that I think we don't need in main now.

libblockdev-plugins-all
libblockdev-btrfs2
libblockdev-btrfs-dev
libblockdev-crypto2
libblockdev-crypto-dev
libblockdev-kbd2
libblockdev-kbd-dev
libblockdev-lvm2
libblockdev-lvm-dev
libblockdev-mdraid2
libblockdev-mdraid-dev

crypto requires volume-key (LP: #1754422)
mdraid requires thin-provisioning-tools
btrfs, kbd, and mdraid requires libbytesize

I updated the supported seed so that these won't try to be automatically pulled in.

Ack on libblockdev, provided only the listed binaries are promoted.

udisks2 also deals with crypto even though the libblockdev- packages are not installed; I do believe it should be reviewed as well.

Override component to main
libblockdev 2.16-2 in bionic: universe/misc -> main
gir1.2-blockdev-2.0 2.16-2 in bionic amd64: universe/introspection/optional/100% -> main
gir1.2-blockdev-2.0 2.16-2 in bionic arm64: universe/introspection/optional/100% -> main
gir1.2-blockdev-2.0 2.16-2 in bionic armhf: universe/introspection/optional/100% -> main
gir1.2-blockdev-2.0 2.16-2 in bionic i386: universe/introspection/optional/100% -> main
gir1.2-blockdev-2.0 2.16-2 in bionic ppc64el: universe/introspection/optional/100% -> main
gir1.2-blockdev-2.0 2.16-2 in bionic s390x: universe/introspection/optional/100% -> main
libblockdev-btrfs-dev 2.16-2 in bionic amd64: universe/libdevel/optional/100% -> main
libblockdev-btrfs-dev 2.16-2 in bionic arm64: universe/libdevel/optional/100% -> main
libblockdev-btrfs-dev 2.16-2 in bionic armhf: universe/libdevel/optional/100% -> main
libblockdev-btrfs-dev 2.16-2 in bionic i386: universe/libdevel/optional/100% -> main
libblockdev-btrfs-dev 2.16-2 in bionic ppc64el: universe/libdevel/optional/100% -> main
libblockdev-btrfs-dev 2.16-2 in bionic s390x: universe/libdevel/optional/100% -> main
libblockdev-btrfs2 2.16-2 in bionic amd64: universe/libs/optional/100% -> main
libblockdev-btrfs2 2.16-2 in bionic arm64: universe/libs/optional/100% -> main
libblockdev-btrfs2 2.16-2 in bionic armhf: universe/libs/optional/100% -> main
libblockdev-btrfs2 2.16-2 in bionic i386: universe/libs/optional/100% -> main
libblockdev-btrfs2 2.16-2 in bionic ppc64el: universe/libs/optional/100% -> main
libblockdev-btrfs2 2.16-2 in bionic s390x: universe/libs/optional/100% -> main
libblockdev-crypto-dev 2.16-2 in bionic amd64: universe/libdevel/optional/100% -> main
libblockdev-crypto-dev 2.16-2 in bionic arm64: universe/libdevel/optional/100% -> main
libblockdev-crypto-dev 2.16-2 in bionic armhf: universe/libdevel/optional/100% -> main
libblockdev-crypto-dev 2.16-2 in bionic i386: universe/libdevel/optional/100% -> main
libblockdev-crypto-dev 2.16-2 in bionic ppc64el: universe/libdevel/optional/100% -> main
libblockdev-crypto-dev 2.16-2 in bionic s390x: universe/libdevel/optional/100% -> main
libblockdev-crypto2 2.16-2 in bionic amd64: universe/libs/optional/100% -> main
libblockdev-crypto2 2.16-2 in bionic arm64: universe/libs/optional/100% -> main
libblockdev-crypto2 2.16-2 in bionic armhf: universe/libs/optional/100% -> main
libblockdev-crypto2 2.16-2 in bionic i386: universe/libs/optional/100% -> main
libblockdev-crypto2 2.16-2 in bionic ppc64el: universe/libs/optional/100% -> main
libblockdev-crypto2 2.16-2 in bionic s390x: universe/libs/optional/100% -> main
libblockdev-dev 2.16-2 in bionic amd64: universe/libdevel/optional/100% -> main
libblockdev-dev 2.16-2 in bionic arm64: universe/libdevel/optional/100% -> main
libblockdev-dev 2.16-2 in bionic armhf: universe/libdevel/optional/100% -> main
libblockdev-dev 2.16-2 in bionic i386: universe/libdevel/optional/100% -> main
libblockdev-dev 2.16-2 in bionic ppc64el: universe/libdevel/optional/100% -> main
libblockdev-dev 2.16-2 in bionic s390x: universe/libdevel/optional/100% -> main
libblockdev-dm-dev 2.16-2 in bionic amd64: universe/libdevel/optional/1...