Satis http basic auth - pass credentials - php

I have set up satis private composer packet manager.
Satis is running on "packages.asc.company", I protected the site by apache2 http basic authentication and can open it in browser by entering http basic auth credentials.
Now my question: How can I pass composer the credentials to access the satis site in the best and most secure manner when running e.g. "composer update"?
Currently I registered only one user with a password in apache .htpasswd file and need to pass its credentials somewhere to be able to connect from composer to satis.
There are two cases where I need to connect from:
1) From the project during development
2) From jenkins during continuous integration process.
3) Edit: SSL
I am trying to use openssl now to secure the credentials when logging in. On my linux, where the apache runs, I created a private key and a .crt file (see: Apache SSL . On my linux, I can now open the satis packages page with https, and I even redirect http to https, all working (Im using my own certificate generating with openssl because its an internal application and I don't need a trusted ca).
Now, when I switch to my Windows from my Linux vm (here I am coding), and I try to run composer update, I get the following error message:
(hosts file is configured correct)
[Composer\Downloader\TransportException]
The "https://packages.asc.company/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
What did I miss? I'm pretty new to ssl, but read the whole day now information about it and can't get it to work.
From getcomposer satis site, I have this information but don't know how to use it.
{
"repositories": [
{
"type": "composer",
"url": "https://example.org",
"options": {
"ssl": {
"local_cert": "/home/composer/.ssl/composer.pem"
}
}
}
]
}
Regards.

There is a documentation page for this.
Composer will work with adding user names into the Satis URL. Works for me, I just wanted to get around the useless default passworded server in the local network. There's a read only account, and I used it.
Additionally: Every developer in the company has an account on the repository server, and there isn't much use in protecting downloaded ZIP files with even more security. Composer itself currently doesn't support any code signing methods or hash comparison, so there is no way to know if a package has been tampered with either where stored or during transmission.
According to the docs, not giving credentials in the URL will make Composer ask for them, or you can add them to auth.json. On the other hand: Saving clear text passwords in a dedicated file doesn't sound like the best idea, and transmitting them without using HTTPS is even worse.
You have to define what kind of security you want to have. What is the goal or the threat scenario you want to protect against?

Related

curl error 28 for composer update/install laravel

i searched several sites, several topics in stackoverflow tried several ways to solve it
reinstalled composer
reinstalled xampp
changed IPv6 to IPv4 -> temporary resolved it
tried on another pc -> same network
i took my github token saved it in composer.json and got another error
used vpn as suggested
i cloned laravel in github but when i need update its composer "autoload", i still get same error on randomized subjects sometimes laravel/symfony and so on..
i tried changing php.ini according to Fileinfo not working in Xampp v3.2.1 [duplicate] : first of all there was no ";extension=php_fileinfo.dll" instead i found extension=fileinfo which itself wasnt commented
for its timeout i changed extention_max from 120 to 360 // my ram is 16
im in an online php boot-camp no one else have same error and no one couldnt help me when i asked for help
i am ready to provide more info , maybe i tried a good way in a wrong manner
appreciate.
- Downloading laravel/sail (v1.16.2)
Failed to download symfony/http-foundation from dist: curl error 28 while downloading https://api.github.com/repos/symfony/http-foundation/zipball/90f5d9726942db69490fe467a3acb5e7154fd555: Operation timed out after 10008 milliseconds with 0 out of 0 bytes received
Now trying to download from source
- Syncing symfony/http-foundation (v6.1.5) into cache
Cloning failed using an ssh key for authentication, enter your GitHub credentials to access private repos
When working with _public_ GitHub repositories only, head to https://github.com/settings/tokens/new?scopes=&description=Composer+on+Mom+2022-10-06+2353 to retrieve a token.
This token will have read-only permission for public information only.
When you need to access _private_ GitHub repositories as well, go to https://github.com/settings/tokens/new?scopes=repo&description=Composer+on+Mom+2022-10-06+2353
Note that such tokens have broad read/write permissions on your behalf, even if not needed by Composer.
Tokens will be stored in plain text in "C:/Users/whowe/AppData/Roaming/Composer/auth.json" for future use by Composer.
For additional information, check https://getcomposer.org/doc/articles/authentication-for-private-packages.md#github-oauth
Token (hidden):
new tries:
as suggested by mr. NicoHaase i reviewed IPv6 Section
the result was as below:
Downloading laravel/laravel (v9.3.8)
Failed to download laravel/laravel from dist: curl error 28 while downloading api.github.com/repos/laravel/laravel/zipball/…:
Operation timed out after 10005 milliseconds with 0 out of 0 bytes
received Now trying to download from source
(i can take screenshot of every step i made)
all limits lifted my problem sloved by itself
but i think the lost answer was about the proxy (31/10/2022)
Use proxy!
if you are in linux:
export http_proxy='your_proxy'
export https_proxy='your_proxy'
then use composer command
If using socks5:
export http_proxy=socks5://ip:port https_proxy=socks5://ip:port
then use composer command.
I guess you're iranian as same as I am

How to connect to a WebSphere MQ Queue using SSL authentification in PHP

I want to connect to a WebSphere MQ Queue using SSL authentification from a PHP application (script).
Queue Manager Version is 7.0 or 7.5
MQ Client Version is 8.0
PHP Version is 7.0 (docker)
Using PHP mqseries pecl extension v0.15 (with custom fixes)
So far I was able to connect without SSL connection.
Here are the steps I have to done so far:
I have installed the WebSphere MQ Client v8 for Linux (CentOS in my case)
I have downloaded the PECL 0.15 version of the mqseries php extension. (There as a small bug in the extension, I had to recompile it to make it work properly. I used to get a segmentation fault on MQGET).
I linked the the mqseries.so to php and enabled the extension.
I succesfully (without SSL)
Connect to the queue manager
Open the queue for reading
Get messages on the queue
Close the connection
When I set the USE_SSL in my script to true, I get the error code 2393 that means "An MQCONN or MQCONNX call was issued with SSL configuration options specified, but an error occurred during the initialization of the SSL environment." This error message is very generic and does not help me pin point where is the problem.
The MQ_KEYSTORE is set as /path/to/my/key and my filename is key.kdb and has at the same level key.sth as suggested by this documentation
The MQ_SSL_CIPHER_SPEC is the same in the script than specified by on the queue manager for the specified MQ_CHANNEL_SSL. Checked multiple times. These are NOT the Cipher Suite used with JMS connections
The security cache has been refreshed on the queue manager.
On the server side, I checked the error logs for the queue manager and didn't seem to see my channel name. I say "seem" because there was a lot of noise and there were a few ??? channel name in the lot. So I feel like it did not reach the queue manager for some reason.
I also used the "amqssslc" command found in the MQ Client installation bin folder to test my ssl config. I get the same error than using the PHP script.
I also used WireShark to sniff packets on the corresponding MQ_PORT. The content of the packages contained certificate information. So there is something that looks like a SSL hand shake going on.
I am now out of ideas as of how to debug the case. Does anyone has an idea of what to check next? Is there connection logs on my MQ Client installation that I should check?
Here is an example of a connection using SSL in PHP
Here is a simplified version of my MQ script (I removed the outputs). Some of the constants are not disclosed for security purposes.
All MQSERIES_* constants are defined in the extension
All MQ_* are hardcoded parameters to test my script but their definition does not appear in the script excerpt.
<?php
// Constants defined here
$options = [
'Version' => MQSERIES_MQCNO_VERSION_4,
'Options' => MQSERIES_MQCNO_STANDARD_BINDING,
'MQCD' => [
'Version' => 7,
'ChannelName' => MQ_CHANNEL,
'ConnectionName' => sprintf('%s(%s)', MQ_HOST, MQ_PORT),
'TransportType' => MQSERIES_MQXPT_TCP,
]
];
if (USE_SSL) {
$options['MQSCO'] = [
'KeyRepository' => MQ_KEYSTORE
];
$options['MQCD']['ChannelName'] = MQ_CHANNEL_SSL;
$options['MQCD']['SSLCipherSpec'] = MQ_SSL_CIPHER_SPEC;
}
mqseries_connx(MQ_QUEUE_MANAGER, $options, $conn, $comp_code, $reason );
$mqods2 = [
'ObjectType' => MQSERIES_MQOT_Q,
'ObjectName' => MQ_QUEUE
];
mqseries_open($conn, $mqods2, MQSERIES_MQOO_INPUT_AS_Q_DEF | MQSERIES_MQOO_FAIL_IF_QUIESCING, $obj, $comp_code, $reason);
$gmd = [];
$gmo = [
'Options' => MQSERIES_MQGMO_FAIL_IF_QUIESCING | MQSERIES_MQGMO_WAIT, 'WaitInterval' => 3000
];
$msg = "";
$data_length = "";
for ($i = 0; $i < 1000; $i++) {
mqseries_get($conn, $obj, $gmd, $gmo, 10000, $msg, $data_length, $comp_code, $reason);
if ($reason === 2033) {
printf("No more messages to process\n");
break;
}
// Business logic
}
mqseries_disc($conn, $comp_code, $reason);
?>
UPDATE
Using the client side logs that I didn't know existed. We finally found out that our server was not using a proper certificate. The server's certificate was actually self-signed, thus not granting us access because our .kdb file didn't have it's public key. We added the server's own public key to the .kdb file making that step work out.
As suggested in the comments from JoshMC, for our next problem, we suspect the label is wrong in the keystore file. We did not specify a specific label from the .kdb file. From the docs "For queue managers and clients respectively, the following sources are searched in sequence for a non-empty value. The first non-empty value determines the certificate label. The certificate label must exist in the key repository. If no matching certificate in the correct case and format is found that matches a label, an error occurs and the SSL or TLS handshake fails."
And it also states that "The certificate label cannot contain spaces.".
I will try again tomorrow with proper label naming and sending a specific label name. I will try to see if the name convention ibmwebspheremq<user_that_runs_the_php_process> actually impacts the validity.
UPDATE 2
It finally worked out. As mentioned by JoshMC, the private key needs to have the specific label ibmwebspheremq. I didn't try the CertificateLabel yet. I might dig into that next week.
At first we were using the GUI (ikeyman) from ibm to generate the .kdb file. But we found out it had quite a few bugs in it. For instance, it imports twice the private key with the same label (auto-generated label from the certificate). Editing the label name was not possible (hence the connection problems). To solve that part we used the command line tool ikeycmd that basically offers the same features on the command line (minus the bugs). To run the command, you need the IBM jre (Not verified, needs to be checked out) and run it as java com.ibm.gsk.ikeyman.ikeycmd. From here, there is a whole world of documentation on IBM web site about how to create a certificate, rename labels, check details, etc. Lots and lots of fun!
With a full IBM MQ client install, client side errors will be logged to the directory: /var/mqm/errors
The errors if any will be logged to the file AMQERR01.LOG (this gets rotated with two other files ending in 02 and 03. If the error is something that MQ is not expecting it may also create a file that ended in .FDC with additional details.
The Queue Manager will log a channel name of ??? if the connection has failed during the channel negotiating prior to the client the sending the channel name. If the IBM MQ the queue manager is using v7.5 or lower the channel name is not exchanged until after the TLS handshake is complete.
With v8 and later clients connecting to v8 and later queue managers, MQ will use TLS SNI to exchange the channel name during TLS negotiation, however I am unsure if MQ has also been enhanced to log this channel name where in prior versions it logged ???. Note that IBM MQ Classes for Java and IBM MQ Classes for JMS client even at v8 and later do not support the SNI feature and do not send the channel name until after the TLS handshake is complete.
Check that your client key.kdb has a private key. There are three ways which MQ uses to identify which private key to use.
With MQ Client v7.5 and earlier the label of the private key must be:
ibmwebspheremq<user_that_runs_the_php_process>
With MQ client v7.5 and earlier an alternative is to set the private key as the default certificate and make sure the following environment variable is set in the environment which executes the program. Note this also works with 8.0.0.7/9.0.0.1 but I prefer the next method over this one.
AMQ_SSL_ALLOW_DEFAULT_CERT=1
With MQ Client v8 and later you can use CertificateLabel=anylabelvalue in the SSL stanza of the mqclient.ini. Example below:
SSL:
CertificateLabel=anylabelvalue
The CertificateLabel setting is documented in the IBM MQ v8 KC page "SSL
stanza of the client configuration file".
A template for mqclient.ini can be copied from /var/mqm/mqclient.ini and placed in the same directory where the application executes. The location can also be specified via a environment variable and MQ will look in a few other locations for the file if it the variable is not set and it does not find it in the same directory where the application executes. The various ways in which MQ will look for this file is documented in the IBM MQ v8 KC page "Location of the client configuration file"

Using local google Datastore with dev_appserver.pyp

At the moment I am able to write to the datastore once I deploy my code, but I can't write to the datastore emulator with code running locally since it throws a ca-bundle error. The local datastore is visible at localhost:8000
use google\appengine\api\users\User;
use google\appengine\api\users\UserService;
use google\appengine\api\app_identity\AppIdentityService;
echo AppIdentityService::getApplicationId()."<br>";
echo AppIdentityService::getDefaultVersionHostname()."<br>";
# Includes the autoloader for libraries installed with composer
require __DIR__ . '/vendor/autoload.php';
use Google\Cloud\ServiceBuilder;
$cloud = new ServiceBuilder([
'projectId' => AppIdentityService::getApplicationId(),
'keyFilePath'=>'review-9504000716d8.json'
]);
$datastore = $cloud->datastore();
# The kind for the new entity
$kind = 'Task';
# The name/ID for the new entity
$name = 'sampletask1';
# The Cloud Datastore key for the new entity
$taskKey = $datastore->key($kind, $name);
# Prepares the new entity
$task = $datastore->entity($taskKey, ['description' => 'Buy milk']);
# Saves the entity
$datastore->upsert($task);
This code runs without any issues when deployed. But locally throws:
Fatal error: Uncaught exception 'Google\Cloud\Exception\ServiceException' with message 'No system CA bundle could be found in any of the the common system locations. PHP versions earlier than 5.6 are not properly configured to use the system's CA bundle by default. In order to verify peer certificates, you will need to supply the path on disk to a certificate bundle to the 'verify' request option: http://docs.guzzlephp.org/en/latest/clients.html#verify. If you do not need a specific certificate bundle, then Mozilla provides a commonly used CA bundle which can be downloaded here (provided by the maintainer of cURL): https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt. Once you have a CA bundle available on disk, you can set the 'openssl.cafile' PHP ini setting to point to the path to the file, allowing you to omit the 'verify' request option. See http://curl.haxx.se/docs/sslcerts.html for more information.' in D:\Google\php\appengine-php-guestbook-phase0-helloworld\appengine-php-guestbook-phase0-hellowo in D:\Google\php\appengine-php-guestbook-phase0-helloworld\appengine-php-guestbook-phase0-helloworld\vendor\google\cloud\src\RequestWrapper.php on line 219
I didn't manage to make the local server even consider the php.ini file nor did I manage to upgrade the bundled php55 to at least php56.
Thus I actually have 2 questions:
how to properly connect from the local instance (dev_appserver.py) on windows to Google's remote datastore?
how to properly connect from the local instant to the local emulated datastore so I can view the data on localhost:8000?
The APIs are using CA certificate files for authentication more specifically they are using curl.cainfo.
Now you server might already have this file configured in php.ini. You can check in server file. Remember there could be different ini files for different environments like apache, cli.
Now you can either copy that file or Create your own authority file
Option 1:
Set absolute path in php.ini
Option 2:
Use ini_set to set this config.
Option 3:
Try with some other mode of authentication, i am sure google will have that.
Option 4:
As given in your question itself.
If you do not need a specific certificate bundle, then Mozilla provides a commonly used CA bundle which can be downloaded here
https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt. Once you have a CA bundle available on disk, you can set the 'openssl.cafile' PHP ini setting to point to the path to the file, allowing you to omit the 'verify' request option

cURL error: [77] error setting certificate verify locations

I use paypal IPN class Quixotix-PHP-PayPal-IPN
Now, I get notifcation from paypal to my ipn listener,
and i activate the class, but i get the next error:
exception 'Exception' with message 'cURL error: [77] error setting certificate verify locations:
CAfile: /home/star1231/public_html/cert/api_cert_chain.crt
CApath: none' in /home/star1231/public_html/ipn.php:79
Stack trace:
#0 /home/star1231/public_html/ipn.php(175): IpnListener->curlPost('cmd=_notify-val...')
#1 /home/star1231/public_html/ipn.php(7): IpnListener->processIpn()
#2 {main}
I search about this error,
and i read that i need to install ca-certificates package,
in this question: How do I deal with certificates using cURL while trying to access an HTTPS url?
i have no exprince in that staff, and i dont know where to run commands and what i need to download
so someone can please explain me how can i install the package in Cpanel on Godaddy?
Check out: https://github.com/Quixotix/PHP-PayPal-IPN/issues/37
seting $listener->use_curl = FALSE; problem was solved
I am not a PHP dev, and I will be of little help assisting you with Linux, but you should be able to get this working by thoroughly reviewing the answers to these two questions:
Paypal IPN Getting blank confirmation ( should be "VERIFIED" or "INVALID" )
How do I deal with certificates using cURL while trying to access an HTTPS url?
The problem appears to be your Certificate Authority bundle, as meda writes: (source: https://stackoverflow.com/a/26260710/399124)
curl performs SSL certificate verification by default, using a
"bundle" of Certificate Authority (CA) public keys (CA certs). The
default bundle is named curl-ca-bundle.crt ... If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
To verify that that is the problem, I would try is adding the -k or --insecure switch to the code in Quixotix-PHP-PayPal-IPN that's failing. Based on the stack trace, that's probably in /home/star1231/public_html/ipn.php(175).
Assuming that fixes it, we now need to figure out what's wrong with the bundle.
Does the file at /home/star1231/public_html/cert/api_cert_chain.crt even exist? If not, download it from (https://raw.githubusercontent.com/Quixotix/PHP-PayPal-IPN/master/cert/api_cert_chain.crt) and put it in the folder.
If you're still having trouble after you're sure the file is in the right place, you could have a security issue:
if there is no tls/certs folder: create one and change permissions using chmod 777 -R folderNAME
OK, if someone need the solution ...
First, Download api_cert_chain.crt
(if this link dosent work, just search in google "download api_cert_chain.crt" or something like that.)
Second, After you download this file put this file in "cert" Folder where your ipn listener is found.
and you ready to go.

zend framework2 issue while installing composer.phar

I have downloaded the zf2 skeleton application and after that,
WHile running
php composer.phar install the following error comes
[Composer\Downloader\TransportException]
The "http://packagist.org/p/zendframework/skeleton-application$65da2ae415c0
9e4b944964efe964f41b27e5b8bbe9cd7345515b4d2eea8ee5e6.json" file could not b
e downloaded: failed to open stream: HTTP request failed!
Please give me some advice
this is an open issue you can find it here :
github Composer issues 2624
Maybe some solutions in comments may help you.
Try :
Update composer.phar with
composer.phar self-update
First off, if you're running a web filter, especially K9 Web Protection, uninstall that first and retry. If the problem persists, read ahead:
The problem is that Composer downgrades to http requests after the first https request to the server. This is done to improve performance/speed and to ensure file integrity/security via the sha256 hashes. In any case, this will cause a 10053 error (errno=10053 An established connection was aborted
by the software in your host machine ... failed to open stream: HTTP request failed!) on some machines.
The reason this happens to some people and not others seems to be the manner in which your ISP handles http requests. In my case, they're re-routed through a caching proxy; which doesn't work well with the way Composer crafts its http requests. That's what happened with me - others may have a different cause. In any case, the fix is to force Composer to use https requests instead of http requests:
Add the following to your Composer installation's config file (composer.json). In Windows, you may find this file at C:\Users{Your Username}\AppData\Roaming\Composer.
"repositories": [
{
"packagist": false
},
{
"type": "composer",
"url": "https://packagist.org/"
}
],
Then go ahead and create your project again with the same command you had used: php composer.phar install. It should work now.

Categories