Review needed of php-code-lts-u2f-php-server

[Remi Collet]

Hi,

https://bugzilla.redhat.com/show_bug.cgi?id=2044209
php-code-lts-u2f-php-server - Server side handling class for FIDO U2F 
registration and authentication

This is a fork of php-samyoul-u2f-php-server (dead project)
which is now used by phpMyAdmin
(different namespace, so not compatible)

This block phpMyAdmin Security update to 5.1.2

Cheers,
Remi

[Remi Collet]

Le 24/01/2022 à 11:51, Remi Collet a écrit :
> Hi,
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2044209
> php-code-lts-u2f-php-server - Server side handling class for FIDO U2F 
> registration and authentication

I give up on this one
Will also use bundled libraries, including on Fedora
(mostly because of Symfony 5)

Remi

[François Kooman]

On 24.01.22 15:45, Remi Collet wrote:
> I give up on this one
> Will also use bundled libraries, including on Fedora
> (mostly because of Symfony 5)

Just at this moment I wanted to start the review, but I'll stop then.

Still willing to do it if you change your mind...

How much work would be Symfony 5, i.e. how many packages?

Regards,
François

[Remi Collet]

Le 24/01/2022 à 16:05, François Kooman a écrit :
> How much work would be Symfony 5, i.e. how many packages?

Symfony is mostly a single package generating 55 sub-packages
(42 components, 5 Bridges, 6 bundles)

There is Symfony 5 released (5.4.2) and also Symfony 6 (6.0.2)

Symfony upstream is so terrible that we are not even able to
run its test suite, and we give up a few release ago, ex some
components requires some component of higher major version (or
even from git)

There is also so much things in the dependency tree

Ex phpMyAdmin 5.2 newly requires

paragonie/sodium_compat
phpmyadmin/shapefile (v3)
phpmyadmin/twig-i18n-extension (v4)
slim/psr7
code-lts/u2f-php-server
symfony/* (v5)
pragmarx/google2fa-qrcode (v2)
(perhaps other I miss)

I haven't dig for symfony

Perhaps we should split the packaging
with 1 src package for each needed component ?

And if we want system libraries we have to fight with upstreams
which only want project libraries, with code relying on
vendor content (ex using Composer\InstalledVersions)

Even if we solved a lot of issues with fedora/autoloader, and
with multiple versions, we probably hit some complexity limit

Sorry if I seem disappointed and tired...
but I now prefer to concentrate my work on binary ext and php-src.

Remi

[François Kooman]

On 25.01.22 09:15, Remi Collet wrote:
> Symfony upstream is so terrible that we are not even able to
> run its test suite, and we give up a few release ago, ex some
> components requires some component of higher major version (or > even from git)

That sucks, I was expecting them to be better! Especially the LTS 
version.... but yeah, if apps depend on non-LTS versions it can become 
tricky indeed...

The support cycle does look reasonable (for LTS): 
https://symfony.com/releases
> Perhaps we should split the packaging
> with 1 src package for each needed component ?

What do you mean exactly?
> Even if we solved a lot of issues with fedora/autoloader, and
> with multiple versions, we probably hit some complexity limit

Yeah, I notice this with almost all software, also in Go. The dependency 
mess gets completely out of hand, totally unmanageable. Also the quality 
seems to go down with every release, every (minor) update pulls in some 
new dependencies, totally insane.

It is clear that most developers do not feel the pain of dependencies 
and don't care at all about supply chain security and code quality.
> Sorry if I seem disappointed and tired...
> but I now prefer to concentrate my work on binary ext and php-src.

I feel the same, probably best indeed, at least that is still doable 
(for now).

Regards,
François

[Remi Collet]

Le 26/01/2022 à 12:54, François Kooman a écrit :
> > Perhaps we should split the packaging
> > with 1 src package for each needed component ?
>
> What do you mean exactly?

Instead of build a single php-symfony# package
from https://github.com/symfony/symfony

Build needed components individually

Ex: php-symfony#-console from
https://github.com/symfony/console

And its dependencies
Ex: php-symfony#-string from
https://github.com/symfony/string

Is what have been done for Laminas
https://rpms.remirepo.net/rpmphp/rpm.php?type=composer&what=%23packagist...

Don't know if this is a good idea...

- more packages, so more work
- symfony upstream don't really care (they release all components
even unchanged ones on each version), while Laminas are better
about this.

Remi