[MIR] lerc
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lerc (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Availability]
The package lerc is already in Ubuntu universe.
The package lerc build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64 arm64 armhf ppc64el riscv64
s390x fails since upstream doesn't support big endian architecture
https:/
which was discussed on in Debian
https:/
Debian is built tiff without lerc support to workaround that issue.
Ideally it would be available on every architecture but it's probably not important for s390x users so we think the current solution is acceptable.
Link to package https:/
[Rationale]
- The package lerc is required in Ubuntu main as a new depends of tiff.
- The package lerc is required in Ubuntu main no later than aug 25 due to feature freeze
[Security]
- No CVEs/security issues in this software in the past
- no `suid` or `sgid` binaries
- 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
[Quality assurance - function/usage]
- The package works well right after install
[Quality assurance - maintenance]
The package is rather now but seems well maintained in Debian/Ubuntu and has no open bug reports
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
- The package runs a test suite on build time, if it fails
it makes the build fail, link to build log https:/
- The package runs an autopkgtest, and is currently passing on
this amd64 arm64 armhf ppc64el list of architectures, link to test logs https:/
The i386 failure is due to python3 packages installability issues on that architecture. The s390x one is due to the fact that the library isn't build on that architecture as explained earlier. This is ok because neither of those are sign of problems with the library.
[Quality assurance - packaging]
- debian/watch is present and works
# lintian --pedantic
running with root privileges is not recommended!
P: lerc source: package-
P: lerc source: very-long-
P: lerc source: very-long-
those are only minor warnings
- Lintian overrides are not present
- 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, link to d/rules https:/
[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 desktop-packages
- Team is not yet, but will subscribe to the package before promotion
- The package successfully built during the most recent test rebuild
[Background information]
The Package description explains the package well
Upstream Name is lerc
Link to upstream project https:/
Changed in lerc (Ubuntu): | |
assignee: | nobody → Lukas Märdian (slyon) |
tags: | added: sec-1089 |
Changed in lerc (Ubuntu): | |
status: | Fix Committed → In Progress |
Review for Package: src:lerc
[Summary] /www.osgeo. org/projects/ lerc-limited- error-raster- compression/
https:/
LERC is an open-source image or raster format which supports rapid encoding
and decoding for any pixel type (not just RGB or Byte). The codebase seems
mature and didn't see many updates recently. It does provide an internal
test-suite that is being run at build time, using the just build binaries and
during autopkgtest using the installed library version.
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: liblerc3, python3-lerc
Specific binary packages built, but NOT to be promoted to main: liblerc-dev
Notes:
#0 Big endian architectures (s390x) are not supported upstream.
#1 The -dev package contains a static build of the library.
It should therefore be excluded from the promotion
#2 Requesting security review because it's parsing image/TIFF data
Required TODOs: /dh_makeshlibs, ignoring the symbols
#3 d/rules uses "-c0" in dpkg-gensymbols
check. Why is this? Please explain, or fix this behavior. It should fail
the build as usual, if symbols change.
Recommended TODOs: uses-old- debhelper- compat- version 12 cationWarning: setup.py install is deprecated.
#4 Lintian: lerc source: package-
dh-compat should be updated or at least a bug should be reported against
the Debian package
#5 SetuptoolsDepre
This deprecation warning should be fixed or at least a bug should be reported
against the Debian package
[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`
- all dependencies can be found in `seeded-in-ubuntu` (already in main)
- none of the (potentially auto-generated) dependencies (Depends
and Recommends) that are present after build are not in main
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems:
- exclude liblerc-dev, as it includes a statically linked library
[Embedded sources and static linking]
OK:
- no embedded source present
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
Problems:
- statically linked library inside the -dev package, built in parallel to the
dynamic library in "build-static" directory from debian/rules
[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 (image/TIFF data)
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build up...