Review for Source Package: linuxp2p
[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: linuxptp
Specific binary packages built, but NOT to be promoted to main: -
Required TODOs:
- #1 This is exposed externally and runs with high permission as well as
influence due to the importance of time to certificate checks. I really
would want to see better use of isolation features before we encourage
use more widely. In particular please look at:
- surely: use a lof of the systemd isolation features
- surely: create and test apparmor profiles for the binaries that run
as service
- maybe: running less privileged
- #6 Please merge the latest version (4.2 at the moment)
Recommended TODOs:
- #2 I'm happy to see that you have added clknetsim based autopkgtests already.
But since this has no build time tests at all and also upstream testing
seems to be manual according to https://linuxptp.sourceforge.net/ we should
try to do a bit more. The content in debian/tests/linuxptp-testsuite is the
same as clknetsim - so I guess that can be removed.
I'm not sure what can be done without upstreams support on e.g. unit
tests. But I'd ask to discuss it with them and refer the discussion here.
If there is something that could be done, do it. Otherwise at least we
know why.
- #3 You mentioned that checkbox, but that includes setup steps with physical
access to the device. Could you outline how one could trigger these tests
(e.g. after a bigger change or merge) themselve. Or if it really needs
a person in front of the device who would be needed to get contacted to
run such a test against a new build e.g. in a PPA?
- #4 If we'd onboard that today (not a MIR rule, but a server team rule since
we shall own it later) it would also need some reasonable documentation
entries like
https://ubuntu.com/server/docs/how-to-serve-the-network-time-protocol-with-chrony
Along your testing e.g. to get isolation right you will have gained the
experience how to set this up well which will enable you to write that.
- #5 submit the Delta (your testing and the former config path change) to Debian
Nothing we have is super-special, mostly added QA which helps us as well
if spotted earlier or even in Debian already.
- #7 There are some bugs open that can get very painful later but need some
time to dive deeper to get fixed. In particular into how it can manage
service dependencies to its configured network devices better.
Some are easy, other might need complex things, maybe even netlink
enablement in the code? But it does not have to be that complex, the
services should wait on %I network device and php2sys waits on a
synchronized ptp4l. Yet the bug exists so give these an evaluation so
we only skip them once we have a good reason why:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004744
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070847
[Rationale, Duplication and Ownership]
There is no other package in main providing the same functionality.
It is easily mistaken for doing the same as systemd-timesyncd and chrony, but
it is different. For a large or partially uncontrollable network NTP based
implementations will be better. Yet on small, controlled networks where
it can be ensured that all HW on the path supported PTP it is better to use
PTP.
There is a fusion of the two using PTP based HW features as PHC clock in chrony
but that isn't the same either.
A team is committed to own long term maintenance of this package.
In this particular case the current approach is (we will let you know
if that changes) that PE/Industrial will do the enablement work to get it
ready for main and the Server team will do the long term maintenance and
monitoring comittment.
The rationale given in the report seems valid and useful for certain sets
of Ubuntu users.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems: None
[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
Problems: None
[Security]
OK:
- history of CVEs does not look concerning
- does not use webkit1,2
- does not use lib*v8 directly
- 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
