[Pkg-xmpp-devel] Bug#932564: movim: should not use composer’s autoloader at runtime

[David Prévot]

Hi,

Sorry for the late answer, it seems like you forgot to CC me.

Adding PHP PEAR (and Composer) Maintainers to CC.

On Tue, Nov 19, 2019 at 10:40:35PM +0100, Thorsten Glaser wrote:
> On Sat, 20 Jul 2019, David Prévot wrote:
> 
> > I just noticed that the movim package depends on composer. Looking
> > further, it seems to use the ClassLoader feature of Composer.
> > 
> > I’m not sure this is a proper (nor optimal) way to load classes in a
> > production system, I’m not even confident that’s a secure way to do it.
> 
> It’s good enough for now.

It’s not “good enough” on a production system.

> > I thus would like to advise the use of a tool like phpab in order to
> > generate an autoload at build time, and let movim use this static
> > autoload at run time.
> 
> This would require binNMUs every time a dependency changes.
> I’d prefer to not do this.

No (binNMU are still a no-op with Arch:all packages currently anyway). I
don’t understand where you get that idea. If your autoload loads its
dependencies (and those dependencies load there dependencies), you don’t
need to update your own autoload when a dependency get updated (even if
that dependency updates its own set of dependencies in order to load
them).

> If I get a really good reason to write an own autoloader implementation
> similar to composer’s and use it instead, I might just do that, but I
> looked at the implementation, and it’s suitable for now.

I disagree it’s suitable for production use: this basically makes
accessible any package installed in /usr/share/php/ via the dynamic
loader. As long as everything behaves properly, you’re fine, but as soon
as you’re victim of an exploit, you open every doors.

Even Composer does not make use of it’s own dynamic loader when
providing an autoload the “normal” way (especially for production use).

> > Maybe some movim dependencies are affected by a similar issue, I didn’t
> 
> No, we’re installing them into /usr/share/php/ in a way that
> the include path contains them correctly, which we use in the
> composer autoloader invocation:
> 
> 	$movim_autoloader->setUseIncludePath(true);

I’m explicitly seeing php-robmorgan-phinx and php-defuse-php-encryption
(and civicrm-common) depending on composer, that’s what I’m referring to
(not cloning this current bug there, no need to split the discussion).

> > I’d like to advise hosting those dependencies under the “Debian PHP
> > PEAR (and Composer) Maintainers” umbrella by the way.
> 
> Are you kidding me? We’ve asked the PHP maintainers, ahead of
> time, multiple times, and never got *any* kind of usable reply,
> nor any kind of assistance regarding the way we should install
> and use the libraries.

I apologize for not using enough of my volunteer time for answering to
every request made to the team.

> It’s a bit surprising you complain *now*
> about *both* the way we use them (autoloader) *and* where they
> are hosted, when the PHP packagers have been extremely unhelpful
> when we asked.

I’m sorry to propose to offer help only now. I’m still willing to
provide a patch or a MR for this issue. I’m simply pointing that I would
probably have already pushed a fix for the above PHP libraries if they
where hosted with the other PHP libraries.

> We would have liked to have them maintained by people who know
> what they’re doing, but it turned out that it’s better to do it
> ourselves, perhaps not in the same style but not too badly, than
> to be under the umbrella of an unresponsive team.

I’m definitely not volunteering to maintain myself packages that you
need for your projects, but I still believe that having all PHP
libraries handled in the same team makes sense. It help working towards
more homogeneity and allow people to actually co-maintain those
packages.

Regards

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-xmpp-devel/attachments/20200228/c5f8f926/attachment.sig>