Ubuntu
xdp-tools package

[MIR] xdp-tools

Bug #2002103 reported by Frode Nordahl on 2023-01-06

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	xdp-tools (Ubuntu)	Fix Released	High	Unassigned

Bug Description

[Availability]
- The package xdp-tools is already in Ubuntu universe.
- The package xdp-tools build for the architectures it is designed to work on.
- It currently builds and works for architetcures:
- amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package: [[https://launchpad.net/ubuntu/+source/xdp-tools|xdp-tools]]

[Rationale]
- The package xdp-tools is required in Ubuntu main for openvswitch.
- AF_XDP, Address Family of the eXpress Data Path, is a new Linux socket type
  built upon the eBPF and XDP technology. It is aims to have comparable
  performance to DPDK but cooperate better with existing kernel’s networking
  stack. The original author of Open vSwitch has written a paper about it [0].
- The feature is still in the experimental stage, but it is important to make
  it available to the masses in order to support its further development.
- Competing Linux distributions are vocal about supporting this feature.
- The package xdp-tools complements libbpf, and is a new runtime
  dependency of package openvswitch which we already support.
- The package xdp-tools is required in Ubuntu main no later than 2023-02-09
  due to openvswitch 3.1.0 enabling build of AF_XDP support by default which
  we want included in Ubuntu 23.04.

0: https://qmro.qmul.ac.uk/xmlui/bitstream/handle/123456789/73562/Antichi%20revisiting%20the%20open%20vSwitch%20dataplane%20ten%20years%20later%202021%20Accepted.pdf

[Security]
- No CVEs/security issues in this software in the past
- no `suid` or `sgid` binaries
- Binary xdp-filter, xdp-loader and xdpdump in `/usr/sbin` are admin tools
that require super user access to run.
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software

[Quality assurance - function/usage]
- The package provides admin tools with manual pages, a library and
header files and works as expected.

[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
  and long term critical bugs open
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/xdp-tools/+bug
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xdp-tools
- The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
- The package does not run a test at build time because tests require root and
  break the testbed.
- The package runs an autopkgtest, and is currently passing on
  amd64 arm64 ppc64el s390x, link to test logs:
  https://autopkgtest.ubuntu.com/packages/xdp-tools

[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Link to a recent build log of the package https://launchpadlibrarian.net/639539109/buildlog_ubuntu-lunar-amd64.xdp-tools_1.2.9-1_BUILDING.txt.gz
- Lintian overrides are present, but ok because BPF binaries appear to be
from other architecture.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will be installed by default, but does not ask debconf
questions higher than medium.
- Packaging and build is easy

[UI standards]
- Application is not end-user facing (does not need translation)

[Dependencies]
- No further depends or recommends dependencies that are not yet in main

[Standards compliance]
- This package correctly follows FHS and Debian Policy

[Maintenance/Owner]
- Owning Team will be OVN
- Team is not yet, but will subscribe to the package before promotion
- This does not use static builds
- This does not use vendored code
- This package is not rust based

[Background information]
- The Package description explains the package well
- Upstream Name is xdp-tools
- Link to upstream project https://github.com/xdp-project/xdp-tools

See original description

Tags:

Frode Nordahl (fnordahl) on 2023-01-06

Changed in xdp-tools (Ubuntu):
importance:	Undecided → High
description:	updated

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-01-10:

FYI: related use case description https://docs.openvswitch.org/en/latest/intro/install/afxdp/

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-01-10:

Download full text (4.0 KiB)

Review for Package: xdp-tools

[Summary]
This rather new, but well packaged - I did not find a blocker in regard to the
general MIR rules.
=> MIR team ACK

But several risks make it prone to attacks, so this does need a security
review, I'll assign ubuntu-security

List of specific binary packages to be promoted to main: libxdp1, libxdp-dev
Specific binary packages built, but NOT to be promoted to main: xdp-tools, xdp-tests

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this (libbpf1 and libc6 are in main)
- no -dev/-debug/-doc packages that need exclusion (libxdp-dev has no
problematic dependencies)
- No dependencies in main that are only superficially tested requiring
more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no static linking (bpf programs are special, but not static in the sense
that is meant here)
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems:
- embedded source present for libbpf, but the build takes care to enforce
the use of the packages libbpf via setting FORCE_SYSTEM_LIBBPF in d/rules

[Security]
OK:
- history of CVEs does not look concerning
  Note there are other XDP related issues, but those are - for now - related
  to the kernel XDP components and those of other XDP users
  https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xdp
- 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)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems:
- does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source => Network packages.
- Although the package itself didn't yet trigger CVEs there are two reasons
  that makes this critical. First it is about network traffic which directly
  means externally craftable content.
  Furthemore this brings BPF programs which are loaded into the kernel. And
  while BPF provides security layers, that still is an elevated risk IMHO.

[Common blockers]
OK:
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest
- This does not need special HW for build or test (only for HW support which
is rare, as of today this is mostyl SW)
- no new python2 dependency

Problems:
- does not have a test suite that runs at build time - it is explicitly
  disabled as it requires root and brekas the testbed. That is not perfect but
  ok since there is a quality autopkgetest to make up for it.
  => https://autopkgtest.ubuntu.com/packages/x/xdp-tools/lunar/amd64

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and...

Review for Package: xdp-tools

[Summary]
This rather new, but well packaged - I did not find a blocker in regard to the
general MIR rules.
=> MIR team ACK

But several risks make it prone to attacks, so this does need a security
review, I'll assign ubuntu-security

List of specific binary packages to be promoted to main: libxdp1, libxdp-dev
Specific binary packages built, but NOT to be promoted to main: xdp-tools, xdp-tests

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this (libbpf1 and libc6 are in main)
- no -dev/-debug/-doc packages that need exclusion (libxdp-dev has no
  problematic dependencies)
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no static linking (bpf programs are special, but not static in the sense
  that is meant here)
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems:
- embedded source present for libbpf, but the build takes care to enforce
  the use of the packages libbpf via setting FORCE_SYSTEM_LIBBPF in d/rules

[Common blockers]
OK:
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest
  - This does not need special HW for build or test (only for HW support which
    is rare, as of today this is mostyl SW)
- no new python2 dependency

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is good, but it is relatively new
- Debian/Ubuntu update history is ok (so far, as it is new)
- 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: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- 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 (lib/dev usage only)

Problems: None

Changed in xdp-tools (Ubuntu):
assignee:	nobody → Ubuntu Security Team (ubuntu-security)

Seth Arnold (seth-arnold) on 2023-01-10

tags:

added: sec-1571

Camila Camargo de Matos (ccdm94) on 2023-01-25

Changed in xdp-tools (Ubuntu):
assignee:	Ubuntu Security Team (ubuntu-security) → Camila Camargo de Matos (ccdm94)
status:	New → In Progress

Revision history for this message

Camila Camargo de Matos (ccdm94) wrote on 2023-01-27 (last edit on 2023-01-27):

Download full text (14.0 KiB)

I reviewed xdp-tools 1.2.9-2 as checked into lunar. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

xdp-tools is a library and collection of utilities for working with the eXpress Data Path facility of the kernel, meaning it can be used when working with AF_XDP sockets and also to attach eBPF programs to the XDP layer. It also includes a set of tools to help debug and test functionalities of the main library, libxdp.

- CVE History:
- No CVEs registered to this package.

- Build-Depends?
  - clang, debhelper-compat (= 13), libbpf-dev, libelf-dev, libpcap-dev, llvm, pkg-config, zlib1g-dev and gcc-multilib (all packages in main).
  - This package does not depend on encryption or networking libraries. It's main dependency could be considered 'libbpf', which is to be expected, given the goal the software wished to achieve.
  - Of the dependencies, 'elfutils' seems to be the package with the most CVEs associated to it. The related vulnerabilities, however, are all patched for releases affected, and lunar is not one of them

- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- No sudo fragments
- No polkit files
- No udev rules
- No cronjobs rules

- Binaries in PATH:
- 'xdp-filter', 'xdp-loader' and 'xdpdump' are installed in 'usr/sbin' (not SUID, owned by 'root:root'). The associated binary package is 'xdp-tools', meaning it can be installed separately or not at all, according to the user's needs. It is common for packages with extra tools such as this one to have various CVEs be reported against the tools only. At the same time that this could be an issue, I also think that having the tools could be an advantage when it comes to patching problems in these tools and in the library itself. That is because the tools allows us to test PoCs against the libraries in a way that the presence (or lack of it) of the vulnerability is clear. Also, should the tools themselves be vulnerable, the user can choose to simply not install them.

- Unit tests / autopkgtests:
- The package does have autopkgtests.
- The package also seems to contain unit tests, even if they can not be run during package build due to the need for root privileges. The unit tests can be called from '.sh' scripts and those will then run C code based programs. Building the code locally and running the tests is a fairly easy process, which is an advantage when we consider testing the code for regressions after patching. The presence of the tools in this aspect is also positive because we can then use those to further test the application and even create more automated tests for the package in the future.

- Build logs:
  - The package builds quickly.
  - No warning messages or error messages generated during the build.
  - A few lintian errors, but I believe that they are no reason for concern.

- Processes spawned
- No processes spawned inside the code.
- Testing directory contains a few shell scripts to setup the testing environment.

- Memory management
- The code seems to perform memory management carefully in most instances, an example being the choice to use 'calloc' calls ...

I reviewed xdp-tools 1.2.9-2 as checked into lunar.  This shouldn't be considered a full audit but rather a quick gauge of maintainability.

- CVE History:
  - No CVEs registered to this package.

- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- No sudo fragments
- No polkit files
- No udev rules
- No cronjobs rules

- Binaries in PATH:
  - 'xdp-filter', 'xdp-loader' and 'xdpdump' are installed in 'usr/sbin' (not SUID, owned by 'root:root'). The associated binary package is 'xdp-tools', meaning it can be installed separately or not at all, according to the user's needs. It is common for packages with extra tools such as this one to have various CVEs be reported against the tools only. At the same time that this could be an issue, I also think that having the tools could be an advantage when it comes to patching problems in these tools and in the library itself. That is because the tools allows us to test PoCs against the libraries in a way that the presence (or lack of it) of the vulnerability is clear. Also, should the tools themselves be vulnerable, the user can choose to simply not install them.

- Unit tests / autopkgtests:
  - The package does have autopkgtests.
  - The package also seems to contain unit tests, even if they can not be run during package build due to the need for root privileges.  The unit tests can be called from '.sh' scripts and those will then run C code based programs. Building the code locally and running the tests is a fairly easy process, which is an advantage when we consider testing the code for regressions after patching. The presence of the tools in this aspect is also positive because we can then use those to further test the application and even create more automated tests for the package in the future.

- Build logs:
  - The package builds quickly.
  - No warning messages or error messages generated during the build.
  - A few lintian errors, but I believe that they are no reason for concern.

- Processes spawned
  - No processes spawned inside the code.
  - Testing directory contains a few shell scripts to setup the testing environment.

- Memory management
  - The code seems to perform memory management carefully in most instances, an example being the choice to use 'calloc' calls rather than 'malloc' calls in almost all cases when memory allocation is needed. There are upstream commits that have been made where it is explicitly mentioned that 'malloc' calls are being changed to 'calloc' calls in order to guarantee initialization of certain variables (3e91edf) and avoid errors. This shows concern from upstream regarding these types of issues. When 'malloc' is used, it is also usually done properly. Memory is freed after allocation. There is bounds checking when functions that copy memory data from one location to the other are called.
  - In 'lib/util/xpcapng.c', there is use of flexible arrays, as well as use of 'calloc's and 'memcpy's that deal with those. This part of the code seems less openly clear with its memory checks compared to other parts of the code, however, even if not immediately obvious, it is possible to verify that memory copying operations are being perfomed appropriately (with the minimum concern with security and avoidance of overflows) nonetheless. It is even possible to see a 'WARNING' comment enforcing that calculations for space must be done correctly previously to a certain point should a new variable be added tothe group involved in the calculations, which shows that at least so far, there has been a concern with that by part of the developers.
  - I feel like memory allocation is done defensively enough. Looking at the 'libxdp' code especially, there is always a concern for checking bounds, looking for NULL pointers and freeing memory in all instances. The code is also very clean and very well organized in these places such that it is easy to not miss all the operations that are being done and guarantee that everything will work as expected. For some files under the 'lib/utils' directories, for example, the code might not be as clear at times, but memory management also is done appropriately enough that it seems like there will not be constant issues affecting this software when it comes to this type of thing. Commits such as e4601603 also show upstream's desire to cleanup the code and remove memory related problems, even if minimal, such as leaks.
  - One concern might be the use of string management functions such as 'strlen' and 'strncpy' in a less careful way. More information about this in the Coverity section.

- File IO
  - In 'lib/util/xpcapng.c', function 'xpcapng_dump_open' seems to create a file responsibly, opening the file only to perform necessary operations, setting permissions to '0600' and truncating the file upon it being opened. However, the file path is not checked, nor are the contents being added to the file, so it is possible to use 'xdpdump' to simply overwrite '/etc/shadow', for example. That being said, this is not considered super concerning, as we expect users to configure their system in a secure manner, if they are looking for security, and expect them to set 'sudo' users wisely (the tools can only be executed by root users or 'sudo' users). Therefore, we would also expect that a conscious user will not overwrite '/etc/shadow' with invalid data for that type of file (PCAP style output).
  - 'lib/util/util.c' reads system files to obtain information on the system (statistics, meaning, it accesses files in '/proc'). It also does so to obtain information on the bpf mountpoint, for example. The other type of file that is opened/created is a lock file, which has is contents properly flushed after creation, in order to guarantee that shared resources contain correct information.
  - Properly locks bpffs filesystem before attempting to access it. However, when 'xdp_lock_release' is used to release locks, some return values are not checked (even though the lock is released anyway because the file is closed?).  
  - Comment at the beggining of 'lib/libxdp/libxdp.c' (right above '#define MIN_FD 3') seems to show concern and care when dealing with files.

- Logging
  - All logging and debugging messages are presented to the user through 'pr_warn' and 'pr_debug' commands. There seem to be no string format vulnerabilities associated with the messages, as the function is always called with more than one argument whenever there is content to be filled in by data stored in a variable. They are called only with one argument whenever it is a simple hardcoded string. Coverity brought up a few format string vulnerabilities but those were false positives.
  - Error messages seem to be printed to 'stderr' only.

- Environment variable usage
  - Checks for the presence of 'secure_getenv' in 'configure', although it does not seem to enforce it. However, file 'lib/libxdp/compat.h' exists to implement this function in case there is no local version of it. Files that use this function test the variable in case it is NULL before using it, so it seems like this function is being used in a conscious manner.

- Use of privileged functions
  - Test files force the use of 'sudo' when running the tests. However, tests are not run during build.
  - Performs a few 'ioctl' calls to check socket information or to set promiscuous mode.

- Use of temp files
  - The 'configure' script uses 'mktemp' safely, creating a directory with the 'XXX' template. The same is done in 'lib/libxdp/tests/test_runner.sh'. The bash variable '$RANDOM' is also used when generating temporary files and directories as well. There is, therefore, an attempt to not use predictable names, even in tests.

- Use of networking
  - 'xdpdump' opens a few sockets to gather interface data.
  - 'xdpdump' properly disables promiscuous mode from interface if it has been previously set.
  - There is not much to say in regards to filtering or sanitizing of input, as the purpose of the library is to allow the user to apply their own filtering to the system using XDP and eBPF. It provides the means for the user to do this, but it leaves responsibility to the user of the library itself to process the data that is being received.
  - External websites referenced are all in documentation or comments.

- No cryptography / random number sources
- No WebKit
- No PolicyKit

- Significant Coverity results:
  - 'xdpdump' suffers from a few NULL pointer dereference errors. 
  - In 'lib/util/utils.c' there are a few calls to 'unlink' that do not have their return values checked. In 'lib/libxdp/libxdp.c' this happens as well, with calls to 'rmdir' and to 'unlink' in function 'xdp_multiprog__pin' not having their return values checked. Coverity presents evidence of other instances where these functions are called and return values are checked, so it is not clear, even after code analysis, why there is a lack of a check in these specific locations.
  - There are a few null pointer dereferencing issues in 'libxdp.c'. Most of them are connected to calls made to functions 'btf__type_by_id' and 'btf__name_by_offset' where return values are not checked. Right after these calls, the variable that receives such return values, which could be NULL, is sent as an argument to functions that manipulate strings, such as 'strdup', 'strncpy', etc. These string functions, when given a NULL pointer as an argument will have undefined behavior, which would most likely result in a program crash, should we end up with the situation proposed by Coverity. Once again, for MOST cases, it was not possible to understand why the checks were not being made considering that other parts of the code which call the same functions perform these checks. Analysis of the code itself for those cases do not justify the absence of a check. There are some other cases, however, where further analysis has indicated that the possibility of this null dereferencing happening is non-existent (meaning a Coverity false positive) because other checks performed previously (and not considered by Coverity) will guarantee that' btf__type_by_id' never gets to the point where it returns a NULL value. That being said, even for these cases, it would be best for the checks to still be performed, just in case. This is especially true for the cases where we cannot guarantee that we will not have a NULL return, as it is reckless to call string functions that have undefined behavior when called with NULL arguments without checking said arguments beforehand. As the code expands, this lack of checks in functions deeper in the call chain might cause problems. However, there were only a few warnings involving this.

- At the time of the making of this report, the upstream repository only has 12 open issues and 3 open PRs. It seems like the upstream developers are pretty on top of implementing that which is needed or fixing problems reported by the community (and even identified by themselves). An example of an issue that tracks future code improvements: https://github.com/xdp-project/xdp-tools/issues/80.

- The upstream repository is very well organized. Issues are tagged in PRs and vice-versa, which makes it easier to identify fixes to reported issues. That is good in case any CVE is set for this package and we need to patch it. The releases page is also very well organized, meaning it can be used as a reference when looking for certain fixes, or when someone is researching information about the package in general (this means it is good when we need to triage the CVE as well to define if a certain version is vulnerable or not). Commits have understandable names that make sense with the fix, and some include more detailed descriptions of what is being fixed.

- The code is actively being maintained, maintainers seem to be very careful and committed to the well-being of the code and organized when applying fixes, which makes this a very good candidate for security maintenance.

- Uses the system 'libbpf', so errors involving the local 'libbpf' copy were mostly ignored.

- 'lib/util/params.c' seems to implement its own command line parser, which could be dangerous. This code, however, is used by the tools code, and not by the library itself.

CONCLUSIONS
The package does seem to contain a few errors involving null pointer dereferencing, concerning the lack of verification before calls to string manipulation functions, and involving the lack of verification of return values. However, these do not seem to be a common occurence, nor does it look like they are results of common coding practice by part of upstream (given that they seem to continually fix errors reported to them, memory related errors being a part of those), which might indicate that they are simply regular mistakes that might be fixed in the future. It also could be that some of these issues reported by Coverity are still false positives, but with my current knowledge of the code, even after analysis, it is not as clear to me why that would be so. Upstream is very active and seems to be very willing to apply fixes to issues such as the ones mentioned previously in this report, so I believe in future releases, many of those could be fixed. Given that the code is very well organized in general, and that upstream is also very well organized, maintaining this code from a security point of view will probably not be an issue.

Security team ACK for promoting xdp-tools to main.

Changed in xdp-tools (Ubuntu):
assignee:	Camila Camargo de Matos (ccdm94) → nobody

Camila Camargo de Matos (ccdm94) on 2023-01-27

Changed in xdp-tools (Ubuntu):
status:	In Progress → Fix Committed
status:	Fix Committed → In Progress

Revision history for this message

Lukas Märdian (slyon) wrote on 2023-02-22:

@ccdm94: This sounds like a security team ACK, is that correct?

If so, I think the status of this MIR could be "Fix Committed", as the package has a team bug subscriber and is already being pulled in as a dependency.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-02-28:

[16:38] <sarnold> cpaelzer: xdp-tools looks ready to migrate to main

setting fix committed

Changed in xdp-tools (Ubuntu):
status:	In Progress → Fix Committed

Revision history for this message

Steve Langasek (vorlon) wrote on 2023-02-28:

missing the team subscriber in launchpad

Changed in xdp-tools (Ubuntu):
status:	Fix Committed → Incomplete

Revision history for this message

Steve Langasek (vorlon) wrote on 2023-02-28:

I see that ~ubuntu-ovn-eng is a structural subscriber, but this is not a recognized team for main ownership. Why is this not using ~ubuntu-openstack as the subscriber?

Frode Nordahl (fnordahl) on 2023-02-28

Changed in xdp-tools (Ubuntu):
status:	Incomplete → Fix Committed

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-03-01:

This is fully approved and in component mismatches, I wanted to promote it to main, but found that
the OVN/Openstack team is not yet subscribed.

In case you are already subscribed the following might be the problem.
You mentioned "OVN Team" and usually it is "ubuntu-openstack".
If your org started to now subscribe the OVN team independently you'd need to become a team known tho the archive admins [1]

[1]: https://git.launchpad.net/ubuntu-archive-tools/tree/lputils.py#n46

Frode Nordahl (fnordahl) on 2023-03-01

Changed in xdp-tools (Ubuntu):
status:	Fix Committed → Incomplete

Frode Nordahl (fnordahl) on 2023-03-01

Changed in xdp-tools (Ubuntu):
status:	Incomplete → Fix Committed

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-03-01:

Thanks for fixing the subscription Fnordahl!

As agreed I left xdp-tools and xdp-tests in universe.

Override component to main
xdp-tools 1.3.0-2ubuntu2 in lunar: universe/misc -> main
Override [y|N]? y
1 publication overridden.

Override component to main
libxdp1 1.3.0-2ubuntu2 in lunar amd64: universe/libs/optional/100% -> main
libxdp1 1.3.0-2ubuntu2 in lunar arm64: universe/libs/optional/100% -> main
libxdp1 1.3.0-2ubuntu2 in lunar armhf: universe/libs/optional/100% -> main
libxdp1 1.3.0-2ubuntu2 in lunar ppc64el: universe/libs/optional/100% -> main
libxdp1 1.3.0-2ubuntu2 in lunar riscv64: universe/libs/optional/100% -> main
libxdp1 1.3.0-2ubuntu2 in lunar s390x: universe/libs/optional/100% -> main
libxdp-dev 1.3.0-2ubuntu2 in lunar amd64: universe/libdevel/optional/100% -> main
libxdp-dev 1.3.0-2ubuntu2 in lunar arm64: universe/libdevel/optional/100% -> main
libxdp-dev 1.3.0-2ubuntu2 in lunar armhf: universe/libdevel/optional/100% -> main
libxdp-dev 1.3.0-2ubuntu2 in lunar ppc64el: universe/libdevel/optional/100% -> main
libxdp-dev 1.3.0-2ubuntu2 in lunar riscv64: universe/libdevel/optional/100% -> main
libxdp-dev 1.3.0-2ubuntu2 in lunar s390x: universe/libdevel/optional/100% -> main
Override [y|N]? y
12 publications overridden.

Changed in xdp-tools (Ubuntu):
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

auto-github-xdp-project-xdp-tools #80
[open] Edit

Bug watches keep track of this bug in other bug trackers.

Ubuntuxdp-tools package

[MIR] xdp-tools

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
xdp-tools package