You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am playing with thephpleague flysystem and under the hood it use phpseclib. When there is a connection problem in the stack trace are thrown credentials:
in SSH2.php line 1011
at HandleExceptions->handleError(1024, 'Cannot connect to my-host.com:22. Error 0. php_network_getaddresses: getaddrinfo failed: Name or service not known', '/home/vagrant/Code/my-project/vendor/phpseclib/phpseclib/phpseclib/Net/SSH2.php', 1011, array('start' => 1492543756.398536, 'errno' => 0, 'errstr' => 'php_network_getaddresses: getaddrinfo failed: Name or service not known', 'host' => 'my-host.com:22'))
at user_error('Cannot connect to my-host.com:22. Error 0. php_network_getaddresses: getaddrinfo failed: Name or service not known') in SSH2.php line 1011
at SSH2->_connect() in SSH2.php line 1888
at SSH2->_login('username', 'secret')
at call_user_func_array(array(object(SFTP), '_login'), array('username', 'secret')) in SFTP.php line 390
at SFTP->login('username', 'secret') in SftpAdapter.php line 193
...
I consider it as a security hole. Username and password should not be thrown in the stacktrace.
At least by default. If for some reason you still prefer to throw password in the stacktrace it should be enabled by explicit configuration. By default password should not be thrown as part of a stack trace.
The text was updated successfully, but these errors were encountered:
I guess thephpleague takes errors and turns them into exceptions that are thrown. So in that case you could simply put the login() method around a try / catch block and catch all Exceptions.
I am playing with thephpleague flysystem and under the hood it use phpseclib. When there is a connection problem in the stack trace are thrown credentials:
I consider it as a security hole. Username and password should not be thrown in the stacktrace.
At least by default. If for some reason you still prefer to throw password in the stacktrace it should be enabled by explicit configuration. By default password should not be thrown as part of a stack trace.
The text was updated successfully, but these errors were encountered: