Bug #1956617 “[MIR] protobuf-c” : Bugs : protobuf-c package : Ubuntu

Revision history for this message

Sebastien Bacher (seb128) wrote on 2022-01-11:

#1

The original MIR request was bug #801735

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-01-11:

#2

Hi Mario,
Thanks for the request, given so much time passed I think we might want to apply the full process of today which has much harder quality bars to pass.

Furthermore this got demoted so long ago that according to [1] no team owns it anymore, not even for trusty or such. Therefore this won't be just "bring it back in".

We'd need to find a team that is willing to commit owning protobuf-c and once that is clear kick off the MIR process by filling in all of the template (as if it is entirely new).

[1]: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html

Changed in protobuf-c (Ubuntu):
status:	New → Incomplete

Revision history for this message

Sebastien Bacher (seb128) wrote on 2022-01-18:

#3

@Christian, I've written the MIR content to help moving things forward but the owning team should probably be foundation since it's a requirement from fwupd that they own.

From the MIR perspective those items need work

- the package doesn't include autopkgtests
- there is no debian/watch
- there are some lintian warnings

Changed in protobuf-c (Ubuntu):
status:	Incomplete → New
description:	updated
description:	updated

Lukas Märdian (slyon) on 2022-01-18

tags:

added: rls-jj-incoming

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-01-21:

#4

Thank you for updating the MIR content. Foundations agreed to take ownership of this package in our weekly #ubuntu-meeting and signed up as a team subscriber. The outstanding issues are still to be done.

tags:	added: fr-1990
tags:	removed: rls-jj-incoming

Christian Ehrhardt  (paelzer) on 2022-01-25

Changed in protobuf-c (Ubuntu):
assignee:	nobody → Christian Ehrhardt  (paelzer)

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-01-27:

#5

Download full text (4.4 KiB)

Review for Package: protobuf-c

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: protobuf-c-compiler
Specific binary packages built, but NOT to be promoted to main: libprotobuf-c1 (at least not needed for the current case, but should be ok to promote if needed later)

Notes:
- Needed in fwupd due to https://github.com/fwupd/fwupd/pull/3609

Required TODOs:
- please add a debian/watch file to help auto-detecting new versions
Recommended TODOs:
- consider adding an autopkgtest, at least running the self-tests in
autopkgtest or better some use case using the lib/compiler
- have a look at the compiler warnings if we could help upstream to fix those

[Duplication]
This is rather interesting in this case, as there are many users and
implementations of protobuf in general. The "main" src:protobuf is the core
project and provides c++, python, ruby, java, ... bindings.
https://developers.google.com/protocol-buffers
But no "C" in that, so protobuf-c exists.
But TBH also several other projects. Of the 6 listed by upstream:
https://github.com/protocolbuffers/protobuf/blob/master/docs/third_party.md
Only two are packaged upb and protobuf-c, both in universe.
Also - as outlined in the report - formerly protobuf-c was in main.
So there is similarity, but no duplication problem here.

[Dependencies]
OK:
- no other Dependencies to MIR due to this

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)

Problems:
- does parse data formats

Depending on where it is used that could be from external sources.
Also the current reason for the MIR is the use to update firmware which usually
runs with high privilege, so being able to inject some protobuf data on the
download could then - if it breaks in the handling - cause quite some issues.
I think a security review is needed here.
Also confirmed by the fact that the more common lib "protobuf" also had a bunch
of CVEs in the past.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- if special HW does prevent build/autopkgtest is there a test plan, code,
  log provided?
- if a non-trivial test on this level does not make sense (the lib alone
  is only doing rather simple things), is the overall solution (app+libs)
  extensively covered i.e. via end to end autopkgtest ?
- no new...

Review for Package: protobuf-c

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: protobuf-c-compiler
Specific binary packages built, but NOT to be promoted to main: libprotobuf-c1 (at least not needed for the current case, but should be ok to promote if needed later)

Notes:
- Needed in fwupd due to https://github.com/fwupd/fwupd/pull/3609

Required TODOs:
- please add a debian/watch file to help auto-detecting new versions
Recommended TODOs:
- consider adding an autopkgtest, at least running the self-tests in
  autopkgtest or better some use case using the lib/compiler
- have a look at the compiler warnings if we could help upstream to fix those

[Duplication]
This is rather interesting in this case, as there are many users and
implementations of protobuf in general. The "main" src:protobuf is the core
project and provides c++, python, ruby, java, ... bindings.
https://developers.google.com/protocol-buffers
But no "C" in that, so protobuf-c exists.
But TBH also several other projects. Of the 6 listed by upstream:
https://github.com/protocolbuffers/protobuf/blob/master/docs/third_party.md
Only two are packaged upb and protobuf-c, both in universe.
Also - as outlined in the report - formerly protobuf-c was in main.
So there is similarity, but no duplication problem here.

[Dependencies]
OK:
- no other Dependencies to MIR due to this

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)

Problems:
- does parse data formats

Depending on where it is used that could be from external sources.
Also the current reason for the MIR is the use to update firmware which usually
runs with high privilege, so being able to inject some protobuf data on the
download could then - if it breaks in the handling - cause quite some issues.
I think a security review is needed here.
Also confirmed by the fact that the more common lib "protobuf" also had a bunch
of CVEs in the past.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- if special HW does prevent build/autopkgtest is there a test plan, code,
  log provided?
- if a non-trivial test on this level does not make sense (the lib alone
  is only doing rather simple things), is the overall solution (app+libs)
  extensively covered i.e. via end to end autopkgtest ?
- no new python2 dependency

Problems:
- does not have a non-trivial test suite that runs as autopkgtest

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- Upstream update history is slow but ok
- Debian/Ubuntu update history is as slow as upstream
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems:
- d/watch is present and looks ok (if needed, e.g. non-native)

[Upstream red flags]
RULE: flag common issues:
RULE: - if you see anything else odd, speak up and ask for clarification

OK:
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (user visible)?

Problems: None
- Errors/warnings during the build - nothing severe, but there are some
  -Wdeclaration-after-statement and -Wc99-c11-compat which we all know are
  informational now, but could be a problem later on.

Changed in protobuf-c (Ubuntu):
assignee:	Christian Ehrhardt  (paelzer) → Ubuntu Security Team (ubuntu-security)

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-02-04:

#6

I've uploaded https://launchpad.net/ubuntu/+source/protobuf-c/1.3.3-1ubuntu1 to contain a debian/watch file and run the unit-tests/self-tests as an autopkgtest, too.

Also, I've send those suggestions to the Debian maintainer:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004962

So I think this is just pending on security-review now.

Steve Beattie (sbeattie) on 2022-04-15

tags:

added: sec-754

Revision history for this message

Mark Esler (eslerm) wrote on 2022-07-07:

#7

There are two open security vulnerabilities for protobuf-c [0][1] and each has a pull request [2][3]. One is designated CVE-2022-33070.

protobuf-c is used in sudo and sudo's maintainer has reviewed or created the pull requests.

On the protobuf-c mailing list I requested a release for vulnerability fixes [4].

[0] https://github.com/protobuf-c/protobuf-c/issues/499
[1] https://github.com/protobuf-c/protobuf-c/issues/506
[2] https://github.com/protobuf-c/protobuf-c/pull/500
[3] https://github.com/protobuf-c/protobuf-c/pull/508
[4] https://groups.google.com/g/protobuf-c/c/LCNHAGPkk60

Revision history for this message

Mark Esler (eslerm) wrote on 2022-07-11:

#8

protobuf-c maintainer released an update patching the above:
https://github.com/protobuf-c/protobuf-c/releases/tag/v1.4.1

Revision history for this message

Mark Esler (eslerm) wrote on 2022-07-11:

#9

I reviewed protobuf-c 1.3.3-1 as checked into focal, protobuf-c 1.3.3-1ubuntu2 as checked into jammy, and protobuf-c 1.4.0 from upstream's git repo.

"This is protobuf-c, a C implementation of the Google Protocol Buffers data serialization format. It includes libprotobuf-c, a pure C library that implements protobuf encoding and decoding, and protoc-c, a code generator that converts Protocol Buffer .proto files to C descriptor code, based on [Google's] original protoc."

- CVE History:
  - two recent vulnerabilities
  - one was assigned CVE-2022-33070
  - patched in v1.4.1
- Build-Depends?
  - protobuf
  - ldd /usr/bin/protoc-gen-c
    - linux-vdso.so.1
    - libprotobuf.so.23 => /lib/x86_64-linux-gnu/libprotobuf.so.23
    - libprotoc.so.23 => /lib/x86_64-linux-gnu/libprotoc.so.23
    - libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
    - libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
    - libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
    - libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
    - /lib64/ld-linux-x86-64.so.2
    - libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
  - ldd /usr/lib/x86_64-linux-gnu/libprotobuf-c.so.1.0.0
    - no additional dependencies
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - /usr/bin/protoc-gen-c
  - proto-c -> protoc-gen-c
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004962
- cron jobs?
  - none
- Build logs:
  - OK
  - No errors. All warnings are trivial.
- Processes spawned?
  - only for documentation generation
- Memory management?
  - See vulnerabilities above
  - Use of memcpy, malloc, free, and memset LGTM
  - An OOB memory access exists in test file
  - Defensive programming reasoning commented throughout code
- File IO?
  - none
- Logging?
  - none
- Environment variable usage?
  - none (outside of debian build scripts)
- Use of privileged functions?
  - none
- Use of cryptography / random number sources etc?
  - none
- Use of temp files?
  - none
- Use of networking?
  - none
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none
- Any significant cppcheck results?
  - none
- Any significant Coverity results?
  - none
  - OOB in a test
- Any significant shellcheck results?
  - none
- Any significant bandit results?
  - none

Packages in Main already use protobuf-c as part of their build (such as sudo). The two recent vulnerabilities in protobuf-c's history were patched promptly. One of the patches is by sudo's maintainer. protobuf-c is also tracked by Google's OSS-Fuzz. The authors of protobuf-c took a lot of care to handle input and protect memory. It is well written and a good candidate for Main.

Security team ACK for promoting protobuf-c to Main.

I reviewed protobuf-c 1.3.3-1 as checked into focal, protobuf-c 1.3.3-1ubuntu2 as checked into jammy, and protobuf-c 1.4.0 from upstream's git repo.

"This is protobuf-c, a C implementation of the Google Protocol Buffers data serialization format. It includes libprotobuf-c, a pure C library that implements protobuf encoding and decoding, and protoc-c, a code generator that converts Protocol Buffer .proto files to C descriptor code, based on [Google's] original protoc."

- CVE History:
  - two recent vulnerabilities
  - one was assigned CVE-2022-33070
  - patched in v1.4.1
- Build-Depends?
  - protobuf
  - ldd /usr/bin/protoc-gen-c
    - linux-vdso.so.1                                                       
    - libprotobuf.so.23 => /lib/x86_64-linux-gnu/libprotobuf.so.23        
    - libprotoc.so.23 => /lib/x86_64-linux-gnu/libprotoc.so.23
    - libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
    - libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1      
    - libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
    - libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
    - /lib64/ld-linux-x86-64.so.2
    - libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6                
  - ldd /usr/lib/x86_64-linux-gnu/libprotobuf-c.so.1.0.0      
    - no additional dependencies    
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - /usr/bin/protoc-gen-c                          
  - proto-c -> protoc-gen-c
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004962
- cron jobs?
  - none
- Build logs:
  - OK
  - No errors. All warnings are trivial.
- Processes spawned?
  - only for documentation generation
- Memory management?
  - See vulnerabilities above
  - Use of memcpy, malloc, free, and memset LGTM
  - An OOB memory access exists in test file
  - Defensive programming reasoning commented throughout code
- File IO?
  - none
- Logging?
  - none
- Environment variable usage?
  - none (outside of debian build scripts)
- Use of privileged functions?
  - none
- Use of cryptography / random number sources etc?
  - none
- Use of temp files?
  - none
- Use of networking?
  - none
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none
- Any significant cppcheck results?
  - none
- Any significant Coverity results?
  - none
  - OOB in a test
- Any significant shellcheck results?
  - none
- Any significant bandit results?
  - none

Packages in Main already use protobuf-c as part of their build (such as sudo). The two recent vulnerabilities in protobuf-c's history were patched promptly. One of the patches is by sudo's maintainer. protobuf-c is also tracked by Google's OSS-Fuzz. The authors of protobuf-c took a lot of care to handle input and protect memory. It is well written and a good candidate for Main.

Security team ACK for promoting protobuf-c to Main.

Changed in protobuf-c (Ubuntu):
assignee:	Ubuntu Security Team (ubuntu-security) → nobody

Seth Arnold (seth-arnold) on 2022-07-12

Changed in protobuf-c (Ubuntu):
status:	New → In Progress

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-12:

#10

I've merged protobuf-c 1.4.1 from Debian unstable: https://launchpad.net/ubuntu/+source/protobuf-c/1.4.1-1ubuntu1

We got the security team ACK and all MIR team required TODOs have been resolved. I think this is good to be promoted!

Changed in protobuf-c (Ubuntu):
status:	In Progress → Fix Committed

Lukas Märdian (slyon) on 2022-07-12

Changed in protobuf-c (Ubuntu):
status:	Fix Committed → In Progress

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-12:

#11

fwupd.debdiff Edit (975 bytes, text/plain)

CC @superm1

Here's a debdiff to enable this feature in fwupd (and pull in the protobuf-c dependency) in Debian.

Revision history for this message

Mario Limonciello (superm1) wrote on 2022-07-12:

#12

Thanks Lukas! The MIR is only going to be effective for kinetic and newer right?

As fwupd tends to get backported for new hardware support lately I want to make sure that we don't accidentally enable this in focal/jammy if it backports again when it shouldn't.

So in that case maybe we want to look at the target OS in debian/rules and only enable if kinetic or newer?
If the MIR can be retroactive it would make this easier though of course.

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-13:

#13

We have done retroactive MIRs in the past. Also, the security team ACKed the 1.3 version (Focal), the 1.3 version + Ubuntu delta (Jammy) and the upstream 1.4 version (now Kinetic), so we should be fine on that.

I've created the bug tasks for Kinetic/Jammy/Focal, so we can have explicit MIR approval for each series. Let's try to get feedback from the original MIR reviewer about this case.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-07-13:

#14

Correct - as long as all reviewers along the way were aware and agreed we can promote things in active releases.

I rechecked the versions in Focal and later - they are not changing massively, my MIR Ack is valid for >=Focal.

I might only wonder (not sure) if it would be worth to bring the test improvements to those releases as well. @Lukas that should be fairly simple and provide at least a basic coverage for future SRUs right?

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-13 (last edit on 2022-07-13):

#15

Thanks for the confirmation @paelzer! I think it'd make sense in this case, as we tend to backport fwupdate to the LTS series and we would like to have support for updating the Logitech webcams there, too.

The Ubuntu delta of protobuf-c is fairly simple and should apply 1:1 to the Focal version. So yes, it is worth preparing this for future SRUs. It's already included in Jammy. I'll prepare an SRU bug for Focal and tag it "block-proposed-focal", as we probably don't want to push an update just for that (no benefit to the user), but have it staged in -proposed for whenever the next SRU happens so that tests will be included.

And @superm1 can go ahead and enable the feature in Debian, so we can sync it into Kinetic. Afterwards, it can slowly trickle down into the LTS series.

Changed in protobuf-c (Ubuntu Jammy):
status:	New → In Progress

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-13:

#16

Focal SRU prepared in bug #1981538 and uploaded into the Focal "unapproved" queue, to be reviewed/accepted by the SRU-team.

https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=protobuf-c

Changed in protobuf-c (Ubuntu Focal):
status:	New → In Progress

Revision history for this message

Mario Limonciello (superm1) wrote on 2022-07-13:

#17

> Here's a debdiff to enable this feature in fwupd (and pull in the protobuf-c dependency) in Debian.

Thanks!

Merged upstream packaging
https://github.com/fwupd/fwupd/commit/7a9fffe3a6ccc185a19b2b2a70d0ba2dca7cb435

Also staged in next fwupd upload for Debian (with your attribution, thanks!)
https://salsa.debian.org/efi-team/fwupd/-/commit/44bcf084717cb0cbc78d8e31d87186d5e63f4db7

Revision history for this message

Mark Esler (eslerm) wrote on 2022-07-14:

#18

I am hoping to see protobuf-c version 1.4.1 in kinetic which fixes several vulnerabilities. To ACK focal >= we should update the package or add security patches first.

Mario Limonciello (superm1) on 2022-07-18

Changed in protobuf-c (Ubuntu Kinetic):
status:	In Progress → Fix Released

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-18:

#19

protobuf-c 1.4.1 landed in Kinetic, as well as fwupd pulling in the new protobuf-c dependency. Now, we need an Archive Admin to promote protobuf-c to "main".

Changed in protobuf-c (Ubuntu Kinetic):
status:	Fix Released → Fix Committed

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-18:

#20

@eslerm Is applying the security patches to protobuf-c for Focal/Jammy something the security team will take care of?

Revision history for this message

Steve Langasek (vorlon) wrote on 2022-07-18:

#21

Override component to main
protobuf-c 1.4.1-1ubuntu1 in kinetic: universe/devel -> main
libprotobuf-c-dev 1.4.1-1ubuntu1 in kinetic amd64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.4.1-1ubuntu1 in kinetic arm64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.4.1-1ubuntu1 in kinetic armhf: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.4.1-1ubuntu1 in kinetic i386: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.4.1-1ubuntu1 in kinetic ppc64el: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.4.1-1ubuntu1 in kinetic riscv64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.4.1-1ubuntu1 in kinetic s390x: universe/libdevel/optional/100% -> main
libprotobuf-c1 1.4.1-1ubuntu1 in kinetic amd64: universe/libs/optional/100% -> main
libprotobuf-c1 1.4.1-1ubuntu1 in kinetic arm64: universe/libs/optional/100% -> main
libprotobuf-c1 1.4.1-1ubuntu1 in kinetic armhf: universe/libs/optional/100% -> main
libprotobuf-c1 1.4.1-1ubuntu1 in kinetic i386: universe/libs/optional/100% -> main
libprotobuf-c1 1.4.1-1ubuntu1 in kinetic ppc64el: universe/libs/optional/100% -> main
libprotobuf-c1 1.4.1-1ubuntu1 in kinetic riscv64: universe/libs/optional/100% -> main
libprotobuf-c1 1.4.1-1ubuntu1 in kinetic s390x: universe/libs/optional/100% -> main
protobuf-c-compiler 1.4.1-1ubuntu1 in kinetic amd64: universe/devel/optional/100% -> main
protobuf-c-compiler 1.4.1-1ubuntu1 in kinetic arm64: universe/devel/optional/100% -> main
protobuf-c-compiler 1.4.1-1ubuntu1 in kinetic armhf: universe/devel/optional/100% -> main
protobuf-c-compiler 1.4.1-1ubuntu1 in kinetic i386: universe/devel/optional/100% -> main
protobuf-c-compiler 1.4.1-1ubuntu1 in kinetic ppc64el: universe/devel/optional/100% -> main
protobuf-c-compiler 1.4.1-1ubuntu1 in kinetic riscv64: universe/devel/optional/100% -> main
protobuf-c-compiler 1.4.1-1ubuntu1 in kinetic s390x: universe/devel/optional/100% -> main
22 publications overridden.

Changed in protobuf-c (Ubuntu Kinetic):
status:	Fix Committed → Fix Released

Revision history for this message

Mark Esler (eslerm) wrote on 2022-07-19:

#22

@slyon can do.

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-07-28 (last edit on 2022-07-28):

#23

Thanks @eslerm! The security fixes are now included in Focal & Jammy.

So the next fwupd SRU should be able to depend on it and pull it into main!

Lukas Märdian (slyon) on 2022-07-28

Changed in protobuf-c (Ubuntu Focal):
status:	In Progress → Fix Committed
Changed in protobuf-c (Ubuntu Jammy):
status:	In Progress → Fix Committed
status:	Fix Committed → In Progress
Changed in protobuf-c (Ubuntu Focal):
status:	Fix Committed → In Progress

Revision history for this message

Mark Esler (eslerm) wrote on 2022-07-28:

#24

@slyon the updated versions of Focal and Jammy are live.

Revision history for this message

Lukas Märdian (slyon) wrote on 2022-08-03:

#25

@superm1 Would you be interested in preparing those fwupd (hardware enablement) SRUs for Jammy & Focal? I guess we could also include the fix for bug #1969976 in the same uploads.

Revision history for this message

Mario Limonciello (superm1) wrote on 2022-08-03:

#26

YC is already working on them in another bug.

Revision history for this message

Luís Infante da Câmara (luis220413) wrote on 2022-08-04 (last edit on 2022-08-04):

#27

If the packages libprotobuf-c1 and libfstrm0 are promoted to the main component in Focal and later releases, DNSTAP support can be enabled in BIND 9 in those releases and Unbound, that is highly recommended online as a local validating resolver for Ubuntu, can be promoted to main in those releases (the source package is already in main).

I would really like to have DNSTAP support in BIND 9 and Unbound in the main component in Focal and Jammy.

Yuan-Chen Cheng (ycheng-twn) on 2022-08-15

Changed in oem-priority:
importance:	Undecided → High
status:	New → Confirmed
status:	Confirmed → In Progress
tags:	added: fwupd
tags:	added: oem-priority

Revision history for this message

Luís Infante da Câmara (luis220413) wrote on 2022-08-16:

#28

I just completed a MIR for the fstrm source package in bug #1986591.

Revision history for this message

Luís Infante da Câmara (luis220413) wrote on 2022-08-20 (last edit on 2022-08-20):

#29

Why did the protobuf-c-compiler binary package move to the universe component in Ubuntu Kinetic?

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-09-05 (last edit on 2022-09-05):

#30

It was universe all the time AFAICS:

Probably it lost a dependency that kept it in before?

Found it, fwupd is what is in main already (it is directly seeded).
That in turn depend only on: libprotobuf-c1

That is still in main
libprotobuf-c1 | 1.4.1-1ubuntu1 | kinetic | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

The other binary packages of protobuf-c will auto-demote if not being needed by something in main.
libprotobuf-c-dev stays in main as all -dev/-doc packges get added automatically if the source is in main.

But if you want/need protobuf-c-compiler in main then:
a) it isn't for fwupd, as that is not having a dependency to it
b) that needs a change in the seeds

You can see what germinate finds while walking the tree from the seeds in https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.kinetic/all+extra

It was universe all the time AFAICS:

Probably it lost a dependency that kept it in before?

Found it, fwupd is what is in main already (it is directly seeded).
That in turn depend only on: libprotobuf-c1

That is still in main
 libprotobuf-c1 | 1.4.1-1ubuntu1   | kinetic                 | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

The other binary packages of protobuf-c will auto-demote if not being needed by something in main.
libprotobuf-c-dev stays in main as all -dev/-doc packges get added automatically if the source is in main.

But if you want/need  protobuf-c-compiler in main then:
a) it isn't for fwupd, as that is not having a dependency to it
b) that needs a change in the seeds

You can see what germinate finds while walking the tree from the seeds in https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.kinetic/all+extra

Revision history for this message

Łukasz Zemczak (sil2100) wrote on 2022-09-12:

#31

Download full text (4.2 KiB)

Per check-in with Christian, I'm promoting the jammy protobuf-c to main (it's causing component-mismatch issues with the new fwupd in jammy-proposed).

$ change-override -c main -S protobuf-c -s jammy-security
Override component to main
protobuf-c 1.3.3-1ubuntu2.1 in jammy: universe/devel -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy amd64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy arm64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy armhf: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy i386: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy ppc64el: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy riscv64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy s390x: universe/libdevel/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy amd64: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy arm64: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy armhf: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy i386: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy ppc64el: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy riscv64: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy s390x: universe/libs/optional/100% -> main
protobuf-c-compiler 1.3.3-1ubuntu2.1 in jammy amd64: universe/devel/optional/100% -> main
protobuf-c-compiler 1.3.3-1ubuntu2.1 in jammy arm64: universe/devel/optional/100% -> main
protobuf-c-compiler 1.3.3-1ubuntu2.1 in jammy armhf: universe/devel/optional/100% -> main
protobuf-c-compiler 1.3.3-1ubuntu2.1 in jammy i386: universe/devel/optional/100% -> main
protobuf-c-compiler 1.3.3-1ubuntu2.1 in jammy ppc64el: universe/devel/optional/100% -> main
protobuf-c-compiler 1.3.3-1ubuntu2.1 in jammy riscv64: universe/devel/optional/100% -> main
protobuf-c-compiler 1.3.3-1ubuntu2.1 in jammy s390x: universe/devel/optional/100% -> main
Override [y|N]? y
22 publications overridden.

$ change-override -c main -S protobuf-c -s jammy-updates
Override component to main
protobuf-c 1.3.3-1ubuntu2.1 in jammy: universe/devel -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy amd64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy arm64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy armhf: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy i386: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy ppc64el: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy riscv64: universe/libdevel/optional/100% -> main
libprotobuf-c-dev 1.3.3-1ubuntu2.1 in jammy s390x: universe/libdevel/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy amd64: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jammy arm64: universe/libs/optional/100% -> main
libprotobuf-c1 1.3.3-1ubuntu2.1 in jam...

Ubuntu
protobuf-c package

[MIR] protobuf-c

Bug Description

CVE References

Other bug subscribers

Patches

Remote bug watches

	Status	Importance	Assigned to
OEM Priority Project	In Progress	High	Unassigned
protobuf-c (Ubuntu)	Fix Released	Undecided	Unassigned
Focal	Fix Committed	Undecided	Unassigned
Jammy	Fix Released	Undecided	Unassigned
Kinetic	Fix Released	Undecided	Unassigned

Ubuntuprotobuf-c package

[MIR] protobuf-c

Bug Description

CVE References

Other bug subscribers

Patches

Remote bug watches

Ubuntu
protobuf-c package