MIR licheerv-rtl8723ds-dkms
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
licheerv-rtl8723ds-dkms (Ubuntu) |
In Progress
|
Undecided
|
Unassigned |
Bug Description
[Availability]
The package licheerv-
The package licheerv-
It currently builds and works for architetcures: riscv64
Link to package [[https:/
[Rationale]
- The package licheerv-
images for the LicheeRV board with Wifi support since this board does not come with an
Ethernet port.
- The package licheerv-
our user base, but is important/helpful still because it allows to have network support
by default, which can be very helpful for anyone who does not have usb-ethernet cable or
any other means to connect to the network. That also makes the board support cleaner and
more useful, it would be hard to understand to not include this driver by default.
- The package licheerv-
due to the fact we announced the support for the LicheeRV board at this release.
[Security]
- No CVEs/security issues in this software in the past
- no executables in `/sbin` and `/usr/sbin`
- 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
(filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
- The package works well right after install: this is a DKMS package which automatically
recompiles the kernel module for each kernel.
[Quality assurance - maintenance]
- The package is maintained well in Ubuntu and has not too many
and long term critical bugs open: this is a new package that only exists in
Ubuntu.
- Ubuntu https:/
- The package does deal with exotic hardware: if we consider RISC-V boards as
exotic hardware, this board is the cheapest existing board and we expect many
developers to work on it.
[Quality assurance - testing]
- The package does not run a test at build time because it is DKMS package that
compiles a module when installing on the system.
- The package does not run an autopkgtest because we can't automatize the testing
of this Wifi driver.
- The package does not have failing autopkgtests right now
- The package can not be tested at build or autopktest time because it is a
DKMS package. To make up for that, we commit to install and test this package
for each new kernel that would be released, which is enough to make sure it
still works.
[Quality assurance - packaging]
- debian/watch is not present since upstream does not produce releases but
it is not a native package.
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Please link to a recent build log of the package:
https:/
- Please attach the full output you have got from lintian:
$ lintian --pedantic licheerv-
W: licheerv-
W: licheerv-
W: licheerv-
W: licheerv-
W: licheerv-
W: licheerv-
- Lintian overrides are not present
- This package does not rely on obsolete or about to be demoted packages.
- The package will be installed by default, but does not ask debconf
questions higher than medium
- Packaging and build is easy, see d/rules below:
#!/usr/bin/make -f
include /usr/share/
%:
dh $@ --with dkms
override_
dh_install -Xdebian * usr/src/
override_dh_dkms:
dh_dkms -V $(DEB_VERSION_
override_
override_
override_
override_
override_
[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed it is a driver.
[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]
- Team is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package has been built in the archive more recently than the last
test rebuild
[Background information]
The Package description explains the package well
Upstream Name is rtl8723ds
Link to upstream project https:/
Changed in licheerv-rtl8723ds-dkms (Ubuntu): | |
assignee: | nobody → Didier Roche-Tolomelli (didrocks) |
Changed in licheerv-rtl8723ds-dkms (Ubuntu): | |
status: | Confirmed → In Progress |
tags: | added: fr-4256 |
Review for Package: licheerv- rtl8723ds- dkms
[Summary] rtl8723ds- dkms
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.
As this dkms module is interacting a lot with HAL and the radio stack, I’m not confortable enough in my code review to be bullet proof. Consequently, this does need a security review, so I'll assign ubuntu-security.
List of specific binary packages to be promoted to main: licheerv-
Notes:
Required TODOs:
- There is no autopkgtests/build time test for this dkms module. There are some comments that the kernel team is going to do some testing for every release, which is OK. However, (as described in the MIR template), one requirement is to make this test plan written down (like, on the ubuntu wiki) and linked here. That way, we can ensure that every upload is tested with someone having access to the hardware as a minimal, QAed, assurance.
Recommended TODOs:
- There is no debian/watch. We also thus don’t know if the current release is packaged (we have latest commit from Git included though). Is it possible to modify debian/watch to take latest upstream main branch as it seems upstream don’t cut releases?
- It seems to me that it could be easy to fix the lintian warning (or override some of them), so that the output is cleaned when building. Mind having a look?
[Duplication]
There is no other package in main providing the same functionality.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- SRCPKG checked with `check-mir`
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring more tests now.
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- 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
[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root (but it’s a kernel module, running as root then, see problems)
- 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:
As part of the kernel itself, it does run as root. It’s interacting a lot with HAL and the wireless stack. It does parse many different binary protocols. This is why a security review is in order.
[Common blockers]
OK:
- does not FTBFS currently
- no new python2 dependency
Problems:
- There is no autopkgtests/build time test for this dkms module. There are some comments that the kernel team is going to do some testing for every release, which is OK. However, (as described in the MIR template), one requirement is to make this test plan written down (like, on the ubuntu wiki) and linked here. That way,...