Abandoned dependency pear/console_commandline

[W0rma]

pear/console_commandline, which is a dependency of this package, has been abandoned.

The only usage of console_commandline seems to be in https://github.com/pear/Crypt_GPG/blob/master/Crypt/GPG/PinEntry.php.

It should be investigated how to get rid of the abandoned dependency.

[chilimatic]

the parser (CommandLine) is used twice. once to read to open the interface and than to print into stderr.

I would need to read up a bit more but it seems more like a simple replacement.

[alecpl]

Seems that the pin entry tool is needed for GnuPG >= 2.0 and <= 2.1.13. So, dropping support for these at some point is at stake if we were to drop it without a replacement. I'm not sure how complicated it would be to get rid of the console_commandline but not the pin entry itself. Help needed.

[chilimatic]

@alecpl

I can offer 2 options since it literally just is about parameter handling and error output.

either I add a very simple class just doing that. easy to read/maintain - if you understand the basics of CLI programming.
or I add something like symfony console to it ... which does offer longterm maintainability etc. but is bloated in comparison.

it looks at least to me like an easy quickfix ... I just need to know what the repo preferences are.
I don't like to have to many taste posthoc discusions. I don't mind the work and appreciate the scrutiny, but I learned to assert and not to assume.

[alecpl]

I'd prefer something simple. Thing is we do not run tests against GnuPG v2.0/v2.1, as it's console tricks didn't work in GA. I wonder if it would be possible these days, so we could test the change. I'm afraid that installing a specific GnuPG version in GA itself may be not trivial.

That said, GnuPG 2.2 is already 9 years old, so maybe we should just move forward and drop older versions support. In such case we could also consider dropping PHP5 and PHP7 support.

[chilimatic]

i mean we could in theory go for wheezy as a container maybe? or we can try and just get create a musl target of it? since it's statically linked?

do we have stats of the possible impact?

[chilimatic]

okay just using guesswork ... or as we like to call it ... heuristics.
the last big surge of downloads were 2018

https://pear.php.net/package-stats.php?cid=6&pid=747

which would put us with php 7.2.

upgrades within php 7.2 - 7.4 are quite easy i mean ... unless they do some weird array reference based additions or some other hacky things ...

so i personally would say it is valid to at least drop php 5. but it also depends on how much effort it is for us to maintain php5.
because if it's a 1 hour no brainer and we can help some poor admin who inherited some old code, I personally appreciate when the FOSS does go the extra mile. but at the same time I understand that this free time and in theory official support for php5 is dropped and we don't know if Zend has some paying customers for whom they patch the old code paid.

so ... yeah. just my thoughts.

[alecpl]

Just note the package is available at Packagist, and these days people can use Composer, so these stats aren't complete.

There was no need to drop PHP5 and PHP7 as the package has not that many significant changes in the last few years. At least, I don't recall it being a problem. However, if we were to do drop support for old GnuPG, we could drop old PHP support as well. Of course with a major version bump.

If you can make the change simple, still supporting PHP5 or 7, then of course dropping PHP support will not be needed, and probably no major version bump would be needed too.

[chilimatic]

okay, I will attempt to create a simple solution and keep you updated. :)

[chilimatic]

So I basically just added roave since we use composer. i can remove it though it's just a classic security package thing.
and the most works was replacing how the parameters are parsed.

this is just a general commit the pr is not done.

i did mainly manual testing i need to write the unitest for the console as well. and than the php 5 + gnupg testing

also with my current system php version i always have one error:

1) ExportPrivateKeyTest::testExportPrivateKey_with_bad_pass
fwrite(): Write of 5 bytes failed with errno=32 Broken pipe

./Crypt_GPG/Crypt/GPG/Engine.php:1390
./Crypt_GPG/Crypt/GPG/Engine.php:776
./Crypt_GPG/Crypt/GPG.php:1473
./Crypt_GPG/Crypt/GPG.php:352
./Crypt_GPG/tests/ExportPrivateKeyTest.php:118

it tells me the exception is correct and based how i write it can be flakey correct ... no idea, i will try to have a look into it. if it is in the end just my local problem ... i will ignore it.

[chilimatic]

what is new since the new composer now does automatically scan for vulnerabilities.
composer.json now has

"config": {
        "audit": {
            "block-insecure": false
        }
    }

because ofc the old unitest libs are not secure anymore ...

i think the options are:

1. we leave it in there
2. we pin a different version of composer (not sure about the testing matrix though)
3. we do some SED magic at the end and just add it for all the tests below php 8

and since I remember what a pain it is to do interactive semaphore based process testing from programming low level :D ...
in theory i could make the console parts static ... but that would make the isolation for the liskov substitution principle a bit less clear.

so i will just add tests for the "validation" of the parameters. for now

[chilimatic]

@alecpl I think i am done.

i will update the PR information accordingly and would prefer a squash merge :)

[chilimatic]

done. ready when you are. just let me know if it's okay or what i should change.
i admit there was a bit of a scope creep ... but I restrained myself.