[Summary]
- After some longer checks it seems fine from a MIR/Packaging POV,
but will need a security review as well.
=> MIR Team ack
- Assigning security
There are a few todos left open thou, nothing that would block the security
review:
@Openstack Team:
- it seems you need to maintain these on your own
- have you contributed the 3.x versions to Debian?
- nfs-ganesha is the only rev-dep so it might really be on you alone
- if no one there steps up are you ok to self-maintain those as needed?
- you are not yet subscribed to the package this is a requirement before
promoting it
- there seem to be very little self-tests but maybe those could be enabled
on build (rpcping / citytest)?
- Probably an artifact of the new version, but symbols need to be updated
- also shlibs fails should be made fatal IMHO
[Duplication]
With no other dependency than nfs-ganesha* it seems that this isn't a full
lib widely used yet.
It seemed more like a sibling or broken out of ganesha itself itself, but then
I found it has a changelog back to 2004 so it seems separate.
A bit of research later I realized this is in fact very old.
The main committer of the latter two seems to be the same person.
=> https://github.com/dang
So the middle one might be dead?
The problem here is that the "classic" tirpc is in main since forever (at
least precise, maybe even further).
It doesn't have many releases beign at v2.5 for years now.
But in terms of code-duplicity for things in main that is a problem.
The old lib still has plenty of dependencies so we can't just switch one for
the other.
Usually on such cases security isn't keen on maintaining both nor is Ubuntu
in general. I mean it even seems that nfs* packages use the classic tiprc lib.
I haven't tracked all the history and difference that has accrued between
those projects. But It seems that the differences might make maintaining
both valid. Without having everyone consider moving all the other projects
to the new lib or to find out why that isn't a good move either.
Changes introduced in the ntirpc library include:
* Bi-directional operation.
* Full-duplex operation on the TCP (vc) transport.
* Thread-safe operating modes:
* new locking primitives and lock callouts (interface change).
* stateless send/recv on the TCP transport (interface change).
* Flexible server integration support.
* Event channels.
This was also discussed in [1] and already back then it was "libntirpc has
diverged significantly from libtirpc; the changes are incompatible with
upstream libtirpc."
Therefore while it is sort of duplicating the functionality, we will need both
libs in main to get nfs-ganesha which is the driver of this.
[Embedded sources and static linking]
- no embedded source present
- no static linking
[Security]
Seems fine:
- does not run a daemon as root
- 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 authentication (eg, pam), etc)
Security sensitive:
- does parse data formats
- does open a port (indirectly, but this libs code is used to plug RPC calls)
- history of CVEs
Yes NTIRPC only has had one.
But I'd think that any finding on TIRPC potentially affects, but isn't tracked
against NTIRPC, as well.
This clearly needs a security review ...
[Common blockers]
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- no python considerations needed
There are a few tests, but they are not enabled yet.
You said in comment #6 that tests are functional or performance - but at
least rpcping could maybe be enabled?
It is already built in the buildlog.
openstack isn't yet subscribed to the package
[Packaging red flags]
- Ubuntu delta to be ahead?
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is (good/slow/sporadic)
- the current release is packaged
- no massive Lintian warnings
- d/rules is rather clean
- d/rules is rather clean
- not using Built-Using
@Openstack Team:
- I'm glad you did the uploads of the new version. But given the slow/sporadic
Debian maintenance I wanted to check if you are willing and ok to sort of
maintain this on your own?
[Upstream red flags]
- no incautious use of malloc/sprintf
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
There are a few upstream, but none clear to the point what would need to
be fixed
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks
But:
- Errors/warnings during the build are present
This should bre resolved either by getting the symbols back if it is a
configuration issue or by bumping the symbols files.
[Summary]
- After some longer checks it seems fine from a MIR/Packaging POV,
but will need a security review as well.
=> MIR Team ack
- Assigning security
There are a few todos left open thou, nothing that would block the security
review:
@Openstack Team:
- it seems you need to maintain these on your own
- have you contributed the 3.x versions to Debian?
- nfs-ganesha is the only rev-dep so it might really be on you alone
- if no one there steps up are you ok to self-maintain those as needed?
- you are not yet subscribed to the package this is a requirement before
promoting it
- there seem to be very little self-tests but maybe those could be enabled
on build (rpcping / citytest)?
- Probably an artifact of the new version, but symbols need to be updated
- also shlibs fails should be made fatal IMHO
[Duplication]
With no other dependency than nfs-ganesha* it seems that this isn't a full
lib widely used yet.
It seemed more like a sibling or broken out of ganesha itself itself, but then
I found it has a changelog back to 2004 so it seems separate.
A bit of research later I realized this is in fact very old.
Orig: libtirpc => https:/ /sourceforge. net/projects/ libtirpc/ /github. com/linuxbox2/ ntirpc /github. com/nfs- ganesha/ ntirpc
Fork: libntirpc => https:/
Ganesha-special: libntirpc => https:/
The main committer of the latter two seems to be the same person. /github. com/dang
=> https:/
So the middle one might be dead?
The problem here is that the "classic" tirpc is in main since forever (at
least precise, maybe even further).
It doesn't have many releases beign at v2.5 for years now.
But in terms of code-duplicity for things in main that is a problem.
The old lib still has plenty of dependencies so we can't just switch one for
the other.
$ reverse-depends -r focal src:libtirpc
Reverse-Depends
===============
* autofs (for libtirpc3)
* glusterfs-common (for libtirpc3)
* glusterfs-server (for libtirpc3)
* libassa-3.5-5-dev (for libtirpc-dev)
* libgfapi0 (for libtirpc3)
* libgfchangelog0 (for libtirpc3)
* libgfrpc0 (for libtirpc3)
* libgfxdr0 (for libtirpc3)
* libnis1 (for libtirpc3)
* nfs-common (for libtirpc3)
* nfs-kernel-server (for libtirpc3)
* quota (for libtirpc3)
* rpcbind (for libtirpc3)
* yp-tools (for libtirpc3)
Usually on such cases security isn't keen on maintaining both nor is Ubuntu
in general. I mean it even seems that nfs* packages use the classic tiprc lib.
I haven't tracked all the history and difference that has accrued between
those projects. But It seems that the differences might make maintaining
both valid. Without having everyone consider moving all the other projects
to the new lib or to find out why that isn't a good move either.
Changes introduced in the ntirpc library include:
* Bi-directional operation.
* Full-duplex operation on the TCP (vc) transport.
* Thread-safe operating modes:
* new locking primitives and lock callouts (interface change).
* stateless send/recv on the TCP transport (interface change).
* Flexible server integration support.
* Event channels.
This was also discussed in [1] and already back then it was "libntirpc has
diverged significantly from libtirpc; the changes are incompatible with
upstream libtirpc."
Therefore while it is sort of duplicating the functionality, we will need both
libs in main to get nfs-ganesha which is the driver of this.
[1]: https:/ /pagure. io/packaging- committee/ issue/363
[Embedded sources and static linking]
- no embedded source present
- no static linking
[Security]
Seems fine:
- does not run a daemon as root
- 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 authentication (eg, pam), etc)
Security sensitive:
- does parse data formats
- does open a port (indirectly, but this libs code is used to plug RPC calls)
- history of CVEs
Yes NTIRPC only has had one.
But I'd think that any finding on TIRPC potentially affects, but isn't tracked
against NTIRPC, as well.
This clearly needs a security review ...
[Common blockers]
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- no python considerations needed
There are a few tests, but they are not enabled yet.
You said in comment #6 that tests are functional or performance - but at
least rpcping could maybe be enabled?
It is already built in the buildlog.
openstack isn't yet subscribed to the package
[Packaging red flags] sporadic)
- Ubuntu delta to be ahead?
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is (good/slow/
- the current release is packaged
- no massive Lintian warnings
- d/rules is rather clean
- d/rules is rather clean
- not using Built-Using
@Openstack Team:
- I'm glad you did the uploads of the new version. But given the slow/sporadic
Debian maintenance I wanted to check if you are willing and ok to sort of
maintain this on your own?
[Upstream red flags]
- no incautious use of malloc/sprintf
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
There are a few upstream, but none clear to the point what would need to
be fixed
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks
But:
- Errors/warnings during the build are present
This should bre resolved either by getting the symbols back if it is a
configuration issue or by bumping the symbols files.
dpkg-gensymbols: warning: some libraries disappeared in the symbols file: libntirpc_ tracepoints. so.3.0 libntirpc3. 0/DEBIAN/ symbols doesn't match completely debian/ libntirpc3. 0.symbols libntirpc3. 0.symbols (libntirpc3. 0_3.0-0ubuntu1_ amd64) AbfBAJ 2019-12-10 09:44:43.362589355 +0000 NTIRPC_ 3.0 3.0 g@NTIRPC_ 3.0 3.0 ncreate@ NTIRPC_ 3.0 3.0 tracepoints. so.3.0 libntirpc3.0 #MINVER# provider_ rpcping@ Base 3.0 provider_ xprt@Base 3.0 =cmake =cmake =cmake =cmake =cmake
dpkg-gensymbols: warning: debian/
--- debian/
+++ dpkg-gensymbols
@@ -183,6 +183,3 @@
xdr_void@
xdr_wrapstrin
xdrmem_
-libntirpc_
- __tracepoint_
- __tracepoint_
dh_shlibdeps -O--parallel -O--buildsystem
dh_installdeb -O--parallel -O--buildsystem
dh_gencontrol -O--parallel -O--buildsystem
dh_md5sums -O--parallel -O--buildsystem
dh_builddeb -O--parallel -O--buildsystem