Bug #1603072 “[MIR] libsmbios” : Bugs : libsmbios package : Ubuntu

Mario Limonciello (superm1) on 2016-07-14

description:

updated

Michael Terry (mterry) on 2016-07-15

Changed in libsmbios (Ubuntu):
assignee:	nobody → Jamie Strandboge (jdstrand)

Jamie Strandboge (jdstrand) on 2016-08-19

Changed in libsmbios (Ubuntu):
assignee:	Jamie Strandboge (jdstrand) → Ubuntu Security Team (ubuntu-security)

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-08-29:

#1

Hello,

Any updates on this? The new version of fwupd was just released that allows libsmbios support. I'm intending to update the whole stack in Debian unstable shortly and would like to keep Ubuntu in sync.

Thanks,

Revision history for this message

Tyler Hicks (tyhicks) wrote on 2016-08-29:

#2

No update from the security team yet as our security review queue for Yakkety is quite large right now.

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-09-06:

#3

Update from my side, the packages that include this functionality (fwupdate 8-1 and fwupd 0.7.3-1) are in Debian now. When synced to Ubuntu, this bug will be a blocker for them (FFe currently here: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1620698).

description:

updated

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-10-13:

#4

This bug has been open since July. Any updates on this?

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-10-28:

#5

In zesty fwupd, fwupdate, fwupdate-signed migration is now blocked.

libfwup1/amd64 unsatisfiable Depends: libsmbios2v5
libfwup1/i386 unsatisfiable Depends: libsmbios2v5
fwupd/i386 unsatisfiable Depends: libsmbios2v5
fwupd/amd64 unsatisfiable Depends: libsmbios2v5

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-11-10:

#6

Hello, can this please be looked at? It's been 4 months now.

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2016-11-15:

#7

Thanks for your patience Mario.

My first question, is this actively supported and loved? There's 262 warnings in the build logs along the lines of: "class std::auto_ptr is deprecated" which gives me the strong impression that there's no longer upstream support for this library.

Thanks

Changed in libsmbios (Ubuntu):
assignee:	Ubuntu Security Team (ubuntu-security) → Seth Arnold (seth-arnold)
status:	New → In Progress

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-11-15: Re: [Bug 1603072] Re: [MIR] libsmbios

#8

Seth,

It does have someone assigned to maintain it upstream, but there hasn't
been heavy activity on the code.

The person maintaining upstream will review anything you feel needs to be
addressed.

On Mon, Nov 14, 2016, 18:25 Seth Arnold <email address hidden> wrote:

> Thanks for your patience Mario.
>
> My first question, is this actively supported and loved? There's 262
> warnings in the build logs along the lines of: "class std::auto_ptr is
> deprecated" which gives me the strong impression that there's no longer
> upstream support for this library.
>
> Thanks
>
> ** Changed in: libsmbios (Ubuntu)
> Assignee: Ubuntu Security Team (ubuntu-security) => Seth Arnold
> (seth-arnold)
>
> ** Changed in: libsmbios (Ubuntu)
> Status: New => In Progress
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1603072
>
> Title:
> [MIR] libsmbios
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/libsmbios/+bug/1603072/+subscriptions
>

Revision history for this message

Iain Lane (laney) wrote on 2016-11-24:

#9

Seth, any progress?

This is blocking gnome-software updates in zesty atm, as there's a component-mismatch from fwupd.

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2016-11-28:

#10

Hi Iain, progress is slow, I haven't given it undivided attention for several hours at a single time yet. It's complicated enough code that it's not easy to pick it back up again after an absence.

Thanks

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2016-12-08:

#11

Mario, could you walk me through how this library is going to be used?

- What processes use this library?
- How are they started?
- What user interaction do they have? How about their parents?
- What controls are in place to avoid operating on untrusted inputs?

I'm worried that the tool may not be suitable for unattended undirected automated use when fed malicious inputs. If inputs can be determined to only come via cryptographically signed sources we may be able to work with this tool all the same.

(I'd feel most comfortable if the instructions here were, "download a new bios from https://support.dell.com/... ; gpg --import verylongkeyhash ; gpg --verify bios.gpg bios && updatebios ./bios". Any amount of automation beyond that has me worried.)

Thanks

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-12-08:

#12

Seth,

In Ubuntu it's going to be used for two purposes: fwupd, and fwupdate. Although the library features functionality that could be used for RBU firmware flashing, that feature is not going to be used in Ubuntu.

The strategy for Dell client systems BIOS updates is to continue to use UEFI capsule which you have already verified the stack previously.

Here's how it will be used in Ubuntu:

fwupdate
--------
For fwupdate, the code is used to query and activate tokens. The code for that was added since after you reviewed fwupdate last year.
This functionality can be seen here:
https://github.com/rhinstaller/fwupdate/blob/master/linux/libfwup.c#L130

It's used when a user queries if the system supports firmware updates and the ESRT is not available.
It can be used two ways:
1) from the fwupdate command line tool (as root)
2) from fwupd using libfwup and calling those same function calls.

In the case of fwupd using libfwup, the code that uses it is available here:
https://github.com/hughsie/fwupd/blob/master/src/fu-provider-uefi.c#L241
The user would need to call the unlock function using fwupdmgr or gnome-software. Policykit would authenticate them and fwupd would use libfwup to do the unlock (which will adjust those token values).

fwupd
-----
For fwupd, libsmbios is used for the following functions:
0) as mentioned above, unlocking ESRT table from token.
1) parsing SMBIOS tables to determine if it's usable on the system and if flashes were successful.
Example: https://github.com/hughsie/fwupd/blob/master/src/fu-provider-dell.c#L672

2) Executing SMI's to put the CPU into SMM and read information about embedded TPM and connected docks.
Example, but there are others: https://github.com/hughsie/fwupd/blob/master/src/fu-provider-dell.c#L759

3) Executing a SMI that will put the dock into a flashing mode to accept a runtime payload.
Example: https://github.com/hughsie/fwupd/blob/master/src/fu-provider-dell.c#L1087

I'm not sure how much of the architecture you recall about fwupd, but I'll give you the 100 ft view as a reminder. fwupd is a d-bus activated daemon. fwupdmgr and gnome-software communicate over d-bus with fwupd. fwupd supports "providers" as plugins that activate functionality for different types of firmware flashing and querying. A special Dell plugin was created that uses libsmbios for querying TPM and dock information specifically.

So a user will query from fwupdmgr for supported devices and fwupd will run a routine in all it's providers to see what devices are available. This will cause for example a few SMI requests when fwupd is first started to see the information on the TPM on the system if applicable.

Please feel free to double check everything, but all of the inputs that get passed through SMI in these cases are hardcoded into fwupd code and can't be passed an untrusted input.

Seth,

In Ubuntu it's going to be used for two purposes: fwupd, and fwupdate.  Although the library features functionality that could be used for RBU firmware flashing, that feature is not going to be used in Ubuntu.

The strategy for Dell client systems BIOS updates is to continue to use UEFI capsule which you have already verified the stack previously.

Here's how it will be used in Ubuntu:

fwupdate
--------
For fwupdate, the code is used to query and activate tokens.  The code for that was added since after you reviewed fwupdate last year.
This functionality can be seen here:
https://github.com/rhinstaller/fwupdate/blob/master/linux/libfwup.c#L130

It's used when a user queries if the system supports firmware updates and the ESRT is not available.
It can be used two ways:
1) from the fwupdate command line tool (as root)
2) from fwupd using libfwup and calling those same function calls.

In the case of fwupd using libfwup, the code that uses it is available here:
https://github.com/hughsie/fwupd/blob/master/src/fu-provider-uefi.c#L241
The user would need to call the unlock function using fwupdmgr or gnome-software.  Policykit would authenticate them and fwupd would use libfwup to do the unlock (which will adjust those token values).

fwupd
-----
For fwupd, libsmbios is used for the following functions:
0) as mentioned above, unlocking ESRT table from token.
1) parsing SMBIOS tables to determine if it's usable on the system and if flashes were successful.
Example: https://github.com/hughsie/fwupd/blob/master/src/fu-provider-dell.c#L672

2) Executing SMI's to put the CPU into SMM and read information about embedded TPM and connected docks.
Example, but there are others: https://github.com/hughsie/fwupd/blob/master/src/fu-provider-dell.c#L759

3) Executing a SMI that will put the dock into a flashing mode to accept a runtime payload.
Example: https://github.com/hughsie/fwupd/blob/master/src/fu-provider-dell.c#L1087

I'm not sure how much of the architecture you recall about fwupd, but I'll give you the 100 ft view as a reminder.  fwupd is a d-bus activated daemon.  fwupdmgr and gnome-software communicate over d-bus with fwupd.  fwupd supports "providers" as plugins that activate functionality for different types of firmware flashing and querying.  A special Dell plugin was created that uses libsmbios for querying TPM and dock information specifically.

So a user will query from fwupdmgr for supported devices and fwupd will run a routine in all it's providers to see what devices are available.  This will cause for example a few SMI requests when fwupd is first started to see the information on the TPM on the system if applicable.

Please feel free to double check everything, but all of the inputs that get passed through SMI in these cases are hardcoded into fwupd code and can't be passed an untrusted input.

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2016-12-09:

#13

Mario, thanks so much for the overview. Really, it saved me hours. :)

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2016-12-09:

#14

Download full text (7.0 KiB)

I reviewed libsmbios version 2.3.1-0ubuntu1 as checked into Yakkety. This
should not be considered a full security audit but rather a quick check of
maintainability.

- libsmbios provides libraries and utilities for working with Dell BIOS
- No CVEs in our database

- The library is used by fwupd and fwupdate
- Build-Depends: debhelper, autotools-dev, libcppunit-dev, doxygen,
  graphviz, python, chrpath, libxml2-dev, pkg-config, autoconf, automake,
  libtool, autopoint
- provides the following binaries and symlinks in /usr/sbin:
  -rwxr-xr-x root/root dellBiosUpdate-compat
  -rwxr-xr-x root/root dellLEDCtl
  -rwxr-xr-x root/root dellMediaDirectCtl
  -rwxr-xr-x root/root smbios-battery-ctl
  -rwxr-xr-x root/root smbios-get-ut-data
  -rwxr-xr-x root/root smbios-keyboard-ctl
  -rwxr-xr-x root/root smbios-lcd-brightness
  -rwxr-xr-x root/root smbios-passwd
  -rwxr-xr-x root/root smbios-rbu-bios-update
  -rwxr-xr-x root/root smbios-state-byte-ctl
  -rwxr-xr-x root/root smbios-sys-info
  -rwxr-xr-x root/root smbios-sys-info-lite
  -rwxr-xr-x root/root smbios-thermal-ctl
  -rwxr-xr-x root/root smbios-token-ctl
  -rwxr-xr-x root/root smbios-upflag-ctl
  -rwxr-xr-x root/root smbios-wakeup-ctl
  -rwxr-xr-x root/root smbios-wireless-ctl
  lrwxrwxrwx root/root dellBiosUpdate -> smbios-rbu-bios-update
  lrwxrwxrwx root/root dellLcdBrightness -> smbios-lcd-brightness
  lrwxrwxrwx root/root dellWirelessCtl -> smbios-wireless-ctl
  lrwxrwxrwx root/root getSystemId -> smbios-sys-info
- I don't believe any packages daemonize
- pre/post inst/rm scripts autogenerated
- No initscripts / systemd units
- No dbus services itself
- No setuid executables
- No sudo fragments
- No udev rules
- The test suites are not run during build -- please do so
- Build logs have hundreds of warnings

- No subprocesses spawned in C/C++ code
- Subprocesses spawned in Python BackCompatRbu::doUpdate() looks unsafe
  but I think this is dead code
- Memory management is extremely difficult to decipher
  - "memory factory" is way too much trouble for whatever benefits it may
    provide
  - many C++ operator new allocations are checked for NULL returns when
    those would instead throw an exception
  - many memory-failure error pathways try to use facilities that would
    fail when memory is scarce (gettext especially)
  - I suspect copy_mmap() / trycopy() / remap() is probably not safe
- files usually passed in as parameters, sometimes writing to current
  working directory
- logging looked fine, assuming the debug logs aren't enabled
- Environment variable handling looked fine
- Uses iopl()
- No cryptography
- No networking
- Portions that use iopl are very privileged; what felt like minimal
  sanity checks before using iopl() are used first
- No files in /tmp
- No webkit
- No javasript
- No policykit
- One cppcheck error for Windows:
  - [src/libsmbios_c++/memory/Memory_Windows.cpp:336]: (error) Mismatching
    allocation and deallocation: MemoryAtRequestedOffSet

Here's my notes collected while reading the sources:

- /etc/yum/ -- etc/yum/pluginconf.d/dellsysid.conf is packaged in
smbios-utils
- many binaries without manpages
- lintian warning about embedded js libraries in docs
- ...

I reviewed libsmbios version 2.3.1-0ubuntu1 as checked into Yakkety. This
should not be considered a full security audit but rather a quick check of
maintainability.

- libsmbios provides libraries and utilities for working with Dell BIOS
- No CVEs in our database

- The library is used by fwupd and fwupdate
- Build-Depends: debhelper, autotools-dev, libcppunit-dev, doxygen,
  graphviz, python, chrpath, libxml2-dev, pkg-config, autoconf, automake,
  libtool, autopoint
- provides the following binaries and symlinks in /usr/sbin:
  -rwxr-xr-x root/root dellBiosUpdate-compat
  -rwxr-xr-x root/root dellLEDCtl
  -rwxr-xr-x root/root dellMediaDirectCtl
  -rwxr-xr-x root/root smbios-battery-ctl
  -rwxr-xr-x root/root smbios-get-ut-data
  -rwxr-xr-x root/root smbios-keyboard-ctl
  -rwxr-xr-x root/root smbios-lcd-brightness
  -rwxr-xr-x root/root smbios-passwd
  -rwxr-xr-x root/root smbios-rbu-bios-update
  -rwxr-xr-x root/root smbios-state-byte-ctl
  -rwxr-xr-x root/root smbios-sys-info
  -rwxr-xr-x root/root smbios-sys-info-lite
  -rwxr-xr-x root/root smbios-thermal-ctl
  -rwxr-xr-x root/root smbios-token-ctl
  -rwxr-xr-x root/root smbios-upflag-ctl
  -rwxr-xr-x root/root smbios-wakeup-ctl
  -rwxr-xr-x root/root smbios-wireless-ctl
  lrwxrwxrwx root/root dellBiosUpdate -> smbios-rbu-bios-update
  lrwxrwxrwx root/root dellLcdBrightness -> smbios-lcd-brightness
  lrwxrwxrwx root/root dellWirelessCtl -> smbios-wireless-ctl
  lrwxrwxrwx root/root getSystemId -> smbios-sys-info
- I don't believe any packages daemonize
- pre/post inst/rm scripts autogenerated
- No initscripts / systemd units
- No dbus services itself
- No setuid executables
- No sudo fragments
- No udev rules
- The test suites are not run during build -- please do so
- Build logs have hundreds of warnings

- No subprocesses spawned in C/C++ code
- Subprocesses spawned in Python BackCompatRbu::doUpdate() looks unsafe
  but I think this is dead code
- Memory management is extremely difficult to decipher
  - "memory factory" is way too much trouble for whatever benefits it may
    provide
  - many C++ operator new allocations are checked for NULL returns when
    those would instead throw an exception
  - many memory-failure error pathways try to use facilities that would
    fail when memory is scarce (gettext especially)
  - I suspect copy_mmap() / trycopy() / remap() is probably not safe
- files usually passed in as parameters, sometimes writing to current
  working directory
- logging looked fine, assuming the debug logs aren't enabled
- Environment variable handling looked fine
- Uses iopl()
- No cryptography
- No networking
- Portions that use iopl are very privileged; what felt like minimal
  sanity checks before using iopl() are used first
- No files in /tmp
- No webkit
- No javasript
- No policykit
- One cppcheck error for Windows:
  - [src/libsmbios_c++/memory/Memory_Windows.cpp:336]: (error) Mismatching
    allocation and deallocation: MemoryAtRequestedOffSet

Here's my notes collected while reading the sources:

- /etc/yum/ -- etc/yum/pluginconf.d/dellsysid.conf is packaged in
  smbios-utils
- many binaries without manpages
- lintian warning about embedded js libraries in docs
- memory_obj_factory() appears to leak toReturn if either
  init_mem_struct_filename() or init_mem_struct() return failure
- smbios_table_factory() appears to leak toReturn if init_smbios_struct()
  fails
- ./src/bin/biosacpi.c main() assumes well-formatted input file; it looks
  vastly unsafe for 'arbitrary file' access.
- _init_cmos_std_stuff() (and elsewhere) try to use gettext() (via _()) in
  many error paths, including out-of-memory errors. This seems prone to
  failure.
- init_mem_struct_filename() strlen(errbuf) isn't protected by the
  if (errbuf) guard
- I'm just plain baffled with memory_obj_factory() and friends
- I'm just plain baffled with dell_smi_factory() and friends
- There's more const_cast<> and reinterpret_cast<> than I'm accustomed to
  seeing in C++ code
- There's a few hundred uses of deprecated std::auto_ptr.
- Some calls to new check result for non-NULL; but C++ throws an exception
  when 'new' fails (unless new (std::nothrow) is used); it might be worth
  re-examining the uses of 'new' to see if the std::nothrow variant should
  be used instead, or if the throw variant is still intended.
- cmos::readByteArray() calls fopen()/fseek()/fclose() once for every byte
  that is read
- cmos::writeByteArray() calls fopen()/fseek()/fclose() once for every
  byte that is written
- CmosTokenD5::setString() allocates targetBuffer and I can't figure out
  why
- I suspect copy_mmap() / trycopy() / remap() is probably not safe
- SmiArchStrategy::lock() flock() call lacks error handling
- SmiArchStrategy::lock() the writes are not flushed; they may not happen
  until fclose() is called in the destructor.
- Extensive references to Xerces in sources even though xerces-c
  apparently hasn't been needed for nine years?

This package is a confusing amalgamation of C, C++, Python, baffling
"memory object factory", probably wasteful optimizations, extremely
wasteful extra complexity. I think it could have been a quarter the size,
or less, if three programs for three architectures been written in one
language instead of one tool to handle Windows, Solaris, and Linux,
in three languages. I think a simple C toolkit with shims to C++ and
Python would have been a lot less work.

The extreme number of const_cast, static_cast, and reinterpret_cast
calls suggests that this code was written hastily, made to work just
well enough, and then left unmaintained since. The compiler warnings
reinforces the impression that this package is severely unloved.

auto_ptr was deprecated in C++11 and C++17 removes it entirely. Fixing
this package to use the replacement pointer types will probably take
some time. We cannot support this package indefinitely in its current
state. Upstream needs to invest in reducing the outstanding technical
debt.

This was a difficult choice; Mario has convinced me that this package is
used in significantly restricted capacities, so its many oddities and
cruft may not represent as much attack surface as it looks like. I
recognize that this code does work for its purpose but I'm worried that
making it run in an automated fashion is beyond its purpose.

There are tests in src/cppunit and src/pyunit that don't appear to be
run during the build. Please enable these and make sure that they fail
the build if tests fail.

Security team ACK for promoting libsmbios to main is given once a new
package is checked into the archive with tests enabled and passing.

Thanks

[I'd like to assign some homework for upstream:
- compile with UBSAN and make sure it's clean
- compile with ASAN and make sure it's clean
- fix the readByteArray() / writeByteArray() to work on more than one byte
  at a time
- replace auto_ptr with the correct replacements at each use
- remove the factories altogether
- refactor copy_mmap() / trycopy() / remap()
- try afl-fuzz on the different tools

If the above steps are taken with a view towards removing code as a side
goal, I think this project could be a lot easier to maintain. It won't be
easy to get there.]

Changed in libsmbios (Ubuntu):
assignee:	Seth Arnold (seth-arnold) → nobody

Revision history for this message

Michael Terry (mterry) wrote on 2016-12-09:

#15

And from my (packaging) side:

Blockers:
- Needs a team bug subscriber that will look after this in Ubuntu

Non-blocker comments:
- smbios-utils should use ${python:Depends}
- Do we have a delta we care about from Debian anymore? I see their latest upload claims to sync with us, then adds a few more changes. We could potentially import their version.

Changed in libsmbios (Ubuntu):
status:	In Progress → Incomplete

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-12-09:

#16

I've just uploaded a new package to zesty that does the following:
- fixes smbios-utils python depends
- turns on the test suite at build time

@mterry
Can you subscribe foundations bugs for this?
As for the delta, yes the most recent upload to Debian did sync with us until this new delta was introduced in this upload for turning on the test suite. I expect that we'll sync up again over the period of the next release.

@seth-arnold
Thanks for the thorough review. I'm passing your feedback onto the right people internally to look at this from an upstream perspective. It will take some time to get people tasked to fixing up that stuff, but I'll keep poking them to do so.
Frankly I think the best thing to do at this point is to drop the c++ implementation rather than fix it, but we'll need to double check what other people are using it for first. The C implementation actually came later, and I believe was intended to supersede the C++ one.

Mario Limonciello (superm1) on 2016-12-10

Changed in libsmbios (Ubuntu):
status:	Incomplete → In Progress

Revision history for this message

Matthias Klose (doko) wrote on 2016-12-12:

#17

hmm, we are trying to move away from Python2. Can smbios be used with Python3 instead? I'd like to avoid new Python2 using packages in main given that we plan to demote it for the next LTS.

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-12-12:

#18

Is it an all or nothing approach on moving binaries packages to main? If
not, only care about the library package in main.

It will take some work to adjust them to Python3 (wish this was raised
sooner) but it can be done.

On Mon, Dec 12, 2016, 06:05 Matthias Klose <email address hidden> wrote:

> hmm, we are trying to move away from Python2. Can smbios be used with
> Python3 instead? I'd like to avoid new Python2 using packages in main
> given that we plan to demote it for the next LTS.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1603072
>
> Title:
> [MIR] libsmbios
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/libsmbios/+bug/1603072/+subscriptions
>

Revision history for this message

Iain Lane (laney) wrote on 2016-12-12:

#19

The python package can stay in Universe if it's not needed as a dependency/recommends of anything in main

Revision history for this message

Michael Terry (mterry) wrote on 2016-12-12:

#20

Well with the tests enabled, I believe that's an ACK from Seth. From my end, all that's missing is the bug subscriber.

Mario, you asked me to sub ~foundations-bugs, but I'm not an admin for that team. I poked Steve Langasek on IRC, but he was away at the time. We'll see.

Revision history for this message

Michael Terry (mterry) wrote on 2016-12-12:

#21

Steve subscribed. Approved.

Changed in libsmbios (Ubuntu):
status:	In Progress → Fix Committed

Revision history for this message

Matthias Klose (doko) wrote on 2016-12-12:

#22

On 12.12.2016 13:07, Mario Limonciello wrote:
> It will take some work to adjust them to Python3 (wish this was raised
> sooner) but it can be done.

sure, it doesn't have to be done now, but could you address this for 17.04, or
if not possible, for 17.10?

Revision history for this message

Mario Limonciello (superm1) wrote on 2016-12-12:

#23

Yes, I'll make sure it's added to the list of stuff upstream needs to work
on.

On Mon, Dec 12, 2016, 10:15 Matthias Klose <email address hidden> wrote:

> On 12.12.2016 13:07, Mario Limonciello wrote:
> > It will take some work to adjust them to Python3 (wish this was raised
> > sooner) but it can be done.
>
> sure, it doesn't have to be done now, but could you address this for
> 17.04, or
> if not possible, for 17.10?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1603072
>
> Title:
> [MIR] libsmbios
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/libsmbios/+bug/1603072/+subscriptions
>

Revision history for this message

Steve Langasek (vorlon) wrote on 2016-12-17:

#24

Override component to main
libsmbios 2.3.1-0ubuntu2 in zesty: universe/libs -> main
libsmbios-dev 2.3.1-0ubuntu2 in zesty amd64: universe/libdevel/optional/100% -> main
libsmbios-dev 2.3.1-0ubuntu2 in zesty i386: universe/libdevel/optional/100% -> main
libsmbios-doc 2.3.1-0ubuntu2 in zesty amd64: universe/libs/optional/100% -> main
libsmbios-doc 2.3.1-0ubuntu2 in zesty arm64: universe/libs/optional/100% -> main
libsmbios-doc 2.3.1-0ubuntu2 in zesty armhf: universe/libs/optional/100% -> main
libsmbios-doc 2.3.1-0ubuntu2 in zesty i386: universe/libs/optional/100% -> main
libsmbios-doc 2.3.1-0ubuntu2 in zesty powerpc: universe/libs/optional/100% -> main
libsmbios-doc 2.3.1-0ubuntu2 in zesty ppc64el: universe/libs/optional/100% -> main
libsmbios-doc 2.3.1-0ubuntu2 in zesty s390x: universe/libs/optional/100% -> main
libsmbios2v5 2.3.1-0ubuntu2 in zesty amd64: universe/libs/optional/100% -> main
libsmbios2v5 2.3.1-0ubuntu2 in zesty i386: universe/libs/optional/100% -> main
python-libsmbios 2.3.1-0ubuntu2 in zesty amd64: universe/admin/optional/100% -> main
python-libsmbios 2.3.1-0ubuntu2 in zesty arm64: universe/admin/optional/100% -> main
python-libsmbios 2.3.1-0ubuntu2 in zesty armhf: universe/admin/optional/100% -> main
python-libsmbios 2.3.1-0ubuntu2 in zesty i386: universe/admin/optional/100% -> main
python-libsmbios 2.3.1-0ubuntu2 in zesty powerpc: universe/admin/optional/100% -> main
python-libsmbios 2.3.1-0ubuntu2 in zesty ppc64el: universe/admin/optional/100% -> main
python-libsmbios 2.3.1-0ubuntu2 in zesty s390x: universe/admin/optional/100% -> main
smbios-utils 2.3.1-0ubuntu2 in zesty amd64: universe/admin/optional/100% -> main
smbios-utils 2.3.1-0ubuntu2 in zesty i386: universe/admin/optional/100% -> main
Override [y|N]? y
21 publications overridden.

Changed in libsmbios (Ubuntu):
status:	Fix Committed → Fix Released

Ubuntu
libsmbios package

[MIR] libsmbios

Bug Description

Other bug subscribers

Remote bug watches

Ubuntulibsmbios package

[MIR] libsmbios

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
libsmbios package