[Pkg-openmpi-maintainers] Bug#767411: torque: should not be released with jessie

[Salvatore Bonaccorso]

Hi Julien,

On Sat, Nov 01, 2014 at 07:09:04PM +0100, Julien Cristau wrote:
> On Sat, Nov  1, 2014 at 16:46:12 +0100, Salvatore Bonaccorso wrote:
> 
> > Hi Julien,
> > 
> > On Fri, Oct 31, 2014 at 02:07:25PM +0100, Julien Cristau wrote:
> > > On Thu, Oct 30, 2014 at 22:27:53 +0100, Salvatore Bonaccorso wrote:
> > > 
> > > > pbs-drmaa as reverse dependency of torque is easy as it is a leaf
> > > > package. The more complicated one would be openmpi which would need to
> > > > drop the build dependency on libtorque2-dev. The reason for this
> > > > dependency was in https://bugs.debian.org/592887 , which needs to be
> > > > dropped again.
> > > > 
> > > There's two solutions here.  One is to drop torque support from openmpi;
> > > the other is to keep the torque source package but only build the
> > > libtorque library, as I'm assuming the security issues are on the torque
> > > server side.  Though that's only useful is that library can still talk
> > > to newer torque version.
> > 
> > Given Dominique's reply on #767411, from my POV I think the best
> > solution would be to remove torque completely for jessie (i.e. first
> > drop support from openmpi to be able to remove the package and
> > remaining reverse dependencies).
> > 
> I don't know how much of that reply applies to the library...

To answer the question: actually I don't know if it the library can
talk to newer torque versions. Michael Milligan's reply seem to
indicate that it does not make much sense. I simply don't know. The
security issues were mostly relevant only in context of the torque
components. For example CVE-2013-4319 was about pbs_mom not properly
restricting access, which allowed authenticated users to execute
code as root. CVE-2013-4495 was also about arbitrary code execution.
The full story is found in http://security-tracker.debian.org/torque

To answr Mike's questsion: the patches were not particulary hard to
create, and in one case I also got help from upstream to have a
correct backport to 2.4.x.

>From my understanding though, nobody would use this outdated version
anymore for real use as resource and queue mangager in production, and
we would need to keep to support this old unmaintained/outdated
version for another release cycle.

How about the following: remove torque support from openmpi in jessie
(possibly in unstable depending on how torque evolves in unstable).
Remove torque from jessie, to avoid jessie releasing with torque
2.4.x. Keep the RC bug open to avoid migration of torque to stretch,
unless it get's updated to a newer upstream version which is
supported, and also the license issues are clarified.

Does this sounds sensible?

Regards,
Salvatore