Thanks for pointing that out. Please create individual tickets for individual problems.

@terrafrost Disable the sourceforge bug tracker and link here?

I'll take a look when I get home. There's not much I can do about the PEAR channel at work.

The PEAR channel should now be installable, although you may need to do pear update-channels. Issue # 1 in https://sourceforge.net/p/phpseclib/bugs/5/ was due to a typo on my part. Issue # 2 was due to some changes I made to the tarball builder to accommodate SFTP/Stream.php which prevented Net_SFTP v0.3.5 from being installed via PEAR for a little while. Apparently those changes didn't work so well.

Really, the whole tarball builder could benefit greatly from a rewrite but, honestly, it's extremely low on my priority list.

Also, that said, while working on this it occurs to me there are probably going to be other issues with the 0.3.6 PEAR channel. In particular, the use of Crypt/Base.php. idk if multiple *.tgz files can include the same file or if Crypt_Base will need to be it's own package that all others require. I'll need to play around with that...

https://sourceforge.net/p/phpseclib/bugs/4/ has not been addressed yet.

I confirm PEAR channel is fixed, thanks.

The Crypt_Base issue has been resolved as well now.

I'll look at https://sourceforge.net/p/phpseclib/bugs/4/ and close the sourceforge.net thing as time permits.

Thanks!

See the PR. https://sourceforge.net/p/phpseclib/bugs/4/ doesn't do .. and as such will (probably) never find openssl.cfg. The ..'s are needed 'cause dirname(__FILE__) for Crypt/RSA.php will return Crypt/, whereas openssl.cfg resides in the parent of that directory.

I'll have to update the *.xml when I get home.

Also, per bantu, new tickets can no longer be created at the sourceforge bugtracker. Unfortunately, I do not know how to link people to this one..

I'm not sure openssl.cfg of phpseclib should be user-controllable. Probably not. Whatever the library user has to control should be done via method calls or a yet to introduce other mean to configure phpseclib.

I don't think the proposed change would make it user-configurable so much as it'd make it so that the config file is put in the same place as config files for other PEAR apps. eg.

http://pear.php.net/manual/en/pyrus.configuration.system.php

I suspect most PEAR users aren't doing that but I see this as more of a PEAR thing - not a user-config thing.

PEAR install the library as "system wide"
So a configuration file, is a "system" configuration file (in /etc/pear on Linux, editable by admin).

User can change their pear config if they want installation in some other dir (or use other installation method, such as composer).

That sounds pretty much like what I was saying (or at least thinking). I don't see why phpseclib's openssl.cfg file should be placed in /etc/pear.

Please clarify the role of this file.

There's no real reason why Net/SSH2.php needs to live inside /etc/pear, either, but if you're running PEAR that's what you get. It's kinda why you run PEAR I guess.

If PEAR (per the way it's configured) wants to place it's *.php files in one directory and it's config files in another... that's PEAR's prerogative I figure.

@terrafrost As far as I understand and can see on my system, php files are installed into /usr/share/php (and subdirectories) and configuration files (that are supposed to be used for actual configuration) are installed into /etc/pear.

Net/SSH2.php does certainly not belong into /etc/.

openssl.cnf is however not a configuration file that a user is supposed to edit, thus it does not belong into /etc in my opinion. @remicollet The role of openssl.cnf is to make the functionality of the PHP OpenSSL extension we use actually work. It was introduced by 1417463

Yah - PEAR files probably by default normally go in /usr/share/php.

I can't comment as to openssl.cnf. You're understanding of it's use, bantu, is correct. Whether or not it ought to go into /etc/ or whether or not the stuff in /etc/ is supposed to be user-editable... I can't answer that. Some of that goes to the intentions of the PEAR devs, which I can only speculate upon.

Whether or not it ought to go into /etc/ or whether or not the stuff in /etc/ is supposed to be user-editable... I can't answer that. Some of that goes to the intentions of the PEAR devs, which I can only speculate upon.

I am not sure this is the case. My understanding is that phpseclib has explicit control over whether the file ends up in /usr/share or /etc by marking it as code or config.

@remicollet The bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1047608#c2 says the definition "is obviously wrong", yet the ticket does not seem to explain why exactly it is wrong (what actual problems does the "incorrect" definition cause?). My impression is that the definition is exactly as intended.

@remicollet The role of openssl.cnf is to make the functionality of the PHP OpenSSL extension
we use actually work. It was introduced by 1417463

Thanks, but this doesn't give me any useful hit why this file is needed and why the system provided configuration is not suitable, and why this couldn't be changed by sysadmin.

Which is obvious is that this file is not a PHP script (so role="php" is bad in all cases). And the name is also not very obvious (it really seems to be a config file).

If it is a file which make sense to be editable by the system admin, then is have to be role="config".
It is MUST never be changed, then it have to be role = "data" (so outside the php include path), and in this case a comment explaining why in the file will be valuable.

P.S. not relying on system openssl provided configuration could raise some very strange "border-case-bugs", such as https://bugs.php.net/66833)

Notice that, even if you choose to not apply the proposed patch, the installation is badly choosen

WIthout any change:

# pear channel-update phpseclib.sourceforge.net
Updating channel "phpseclib.sourceforge.net"
Channel "phpseclib.sourceforge.net" is up to date
# pear install phpseclib/Crypt_RSA-0.3.6
Could not download from "http://phpseclib.sourceforge.org//get/Crypt_RSA-0.3.6.tgz", cannot download "phpseclib/Crypt_RSA" (Connection to `phpseclib.sourceforge.org:80' failed: php_network_getaddresses: getaddrinfo failed: Name or service not known)

So channel is still broken... so manually:

# wget http://phpseclib.sourceforge.net/get/Crypt_RSA-0.3.6.tgz
# pear install Crypt_RSA-0.3.6.tgz
install ok: channel://phpseclib.sourceforge.net/Crypt_RSA-0.3.6
# pear list-files phpseclib.sourceforge.net/Crypt_RSA
Installed Files For phpseclib.sourceforge.net/Crypt_RSA
=======================================================
Type Install Path
php  /usr/share/pear/Crypt/RSA.php
php  /usr/share/pear/openssl.cnf

=> /usr/share/pear/openssl.cnf is very bad, outside of Crypt tree, can create bad conflicts with other packages.

this file is not a PHP script (so role="php" is bad in all cases)

I am not sure what roles there are. What role does one assign to a data file, say a text file or a jpeg?

/usr/share/pear/openssl.cnf is very bad, outside of Crypt tree, can create bad conflicts with other packages.

That sounds suboptimal indeed. Maybe we should just ditch PEAR support altogether, but @terrafrost probably doesn't want that, hehe.

I am not sure what roles there are. What role does one assign to a data file, say a text file or a jpeg?

http://pear.php.net/manual/en/guide.users.concepts.filerole.php
So role="data" (will be installed in "data_dir"/Crypt_RSA)

(and in this case, my patch proposal, will also be required, just changing cfg_dir with data_dir)

I'm okay with doing data_dir.

I'll try to look at the current issue with Crypt_RSA as time permits.

That sounds suboptimal indeed. Maybe we should just ditch PEAR support altogether, but @terrafrost probably doesn't want that, hehe.

There's actually one thing about PEAR that I really like over Composer. You can have a package broken up into multiple files. With Composer it's all or none. If you want Net_SSH2 you're going to get File_X509 as well. With PEAR you just get Net_SSH2. ie. you get only what you need.

I guess to do that properly in Composer you'd need a separate github repo for each one. Which I suppose PEAR actually kinda does do itself but idk that I really want to do that.

There's actually one thing about PEAR that I really like over Composer. You can have a package broken up into multiple files. With Composer it's all or none. If you want Net_SSH2 you're going to get File_X509 as well. With PEAR you just get Net_SSH2. ie. you get only what you need.

That's not really true. You can do that as well with composer. The symfony framework does that at large.

Oh. How do we do that?

Also,

P.S. not relying on system openssl provided configuration could raise some very strange "border-case-bugs", such as https://bugs.php.net/66833)

Crypt_RSA only needs it for one function. The function for creating private keys. As such it doesn't really matter what the default digest is because Crypt_RSA doesn't use that anyway.

idk if this was fixed upstream in the Red Hat repo or not but idk that anyone uses PEAR these days anyway lol. Closing ticket.