json do not match its signature issue

[omerbsh]

With the following composer.json:
(none)

{
    ...
}

When I run this command:

composer command -vvv (please include -vvv!)

I get this output:

  [Composer\Repository\RepositorySecurityException]                                                                                                   
  The contents of http://packagist.org/p/provider-2014%24778fe81238370a6a10514fa2191d8c49e3b0df47ad7c25361bda5e7c0f48797c.json do not match its signature. This should indicate a man-in-the-middle attack. Try running composer again and report this if you think it is a mistake.                    

And I expected this to happen:
install cakephp package.

[curry684]

Please edit the template a bit more to supply an actual problem case.

[omerbsh]

When I try to install by the command "php composer.phar create-project --prefer-dist laravel/laravel public" i get the attached error message.

I wonder if the problem is with the CRT on my computer or on the servers?

[alcohol]

Are you behind a proxy or using any kind of firewall software?

If the error consistently occurs, one of the above is probably mangling your connections.

[omerbsh]

Hey,

no use of proxy, i changed machine and i still get the same error.

[Composer\Repository\RepositorySecurityException]
The contents of http://packagist.org/p/provider-2014%24778fe81238370a6a10514fa2191d8c49e3b0df47ad7c25361bda5e7c0f48797c.json do not match its sign
ature. This should indicate a man-in-the-middle attack. Try running composer again and report this if you think it is a mistake.

[alcohol]

Different machine, but same network?

[omerbsh]

Yes, its virtual machines on my computer (Debian).

[alcohol]

Sorry, not really sure what could be wrong here. But it is definitely a networking issue, nothing we can solve for you.

[Kendysond]

add this to your composer

"repositories": {
    "packagist": { "url": "https://packagist.org", "type": "composer" }
 }

[smilezv]

"repositories": {
"packagist": { "url": "https://packagist.org", "type": "composer" }
}
This code above fix the signature issue.

[Composer\Repository\RepositorySecurityException]
The contents of http://packagist.org/p/provider-2014%24778fe81238370a6a10514fa2191d8c49e3b0df47ad7c25361bda5e7c0f48797c.json do not match its sign
ature. This should indicate a man-in-the-middle attack. Try running composer again and report this if you think it is a mistake.

[phil-davis]

I have had this problem in the morning yesterday and today, and on various days in the past. In my timezone that is early AM hours UTC. Then the problem goes away in the afternoon evening. So I am suspicious that there are daily updates to the package list, and the signature file also gets updated, but somewhere "in the big bad internet" they are cached differently. And so for some hours I receive a new file+old signature or old file+new signature. It is rather annoying!

[Composer\Repository\RepositorySecurityException]                                                                          
The contents of http://packagist.org/p/provider-2013%2453bd1fb568f984a10d7aa50e4d388dce7787e9d744d748e09a2f3ceadaae5cd1.json do not match its signature. This should indicate a man-in-the-middle attack. Try running composer again and report this if you think it is a mistake.     

I will try regularly now to see if there is a real time pattern to this.
The code above to add to composer.json is "a good thing" (tm) and works around the issue.

[curry684]

This should indicate a man-in-the-middle attack.

That should actually say "could" hehe.

[EmilCataranciuc]

I get a similar error when running composer require symfony/security-checker:
[Composer\Repository\RepositorySecurityException] The contents of https://packagist.org/p/providerlatest%240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json do not match its signature. This could indicate a man-in-the-middle attack. Try running composer again and report this if you think it is a mistake.
Adding
"repositories": { "packagist": { "url": "https://packagist.org", "type": "composer" } }
doesn't help. Any suggestions are welcome.
Thank you.

[rickselby]

@Furious-Snail Looks like packagist.org is down right now.

[laurentvd]

It seems to be working again!

[EmilCataranciuc]

I tried a couple of times. When accessing the https://packagist.org it is working.
Thank you.

[munzeedaniel]

Same problem here. Adding
"repositories": { "packagist": { "url": "https://packagist.org", "type": "composer" } }
does not help.

[hoonzis]

Same problem here, adding packagist url explicitly didn't work

[necipallef]

I can access the website https://packagist.org, but I still get the following when I composer update:

The contents of https://packagist.org/p/provider-latest%240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json do not match its signature. This could indicate a man-in-the-middle attack. Try running composer again and report this if you think it is a mistake

[jscontrust]

Same here

[yuriyse]

Similarly..

[svenfinke]

Yeah, seems like packagist is down, or at least the service does not work as expected.

https://twitter.com/packagist/status/953257504565334016

[jibay]

Same here :/

[ghost]

Just wait

[Okipa]

I think this is related to the recent service interruption of packagist.

More infos on : https://twitter.com/packagist

[milosilic]

same here

[Keirul]

Thanks for the update @Okipa, FYI DNS related issue at Packagist.

[Keirul]

Solved here as well, I'm on Linux so I switched to Google DNS -> https://developers.google.com/speed/public-dns/

[Okipa]

For macOs users, flush your DNS : dscacheutil -flushcache;sudo killall -HUP mDNSResponder;.
Then ping packagist.org, the IP should be 144.217.203.53.

[ghost]

Odd, flushing the DNS still hasnt worked. Still getting

[Composer\Repository\RepositorySecurityException]                                                                                                                                                                                                                                     
  The contents of https://packagist.org/p/provider-latest%240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json do not match its signature. This could indicate a man-in-the-middle attack. Try running composer again and report this if you think it is a mistake.

Im on Linux and used service dnsmasq restart (as we dont have nscd)

Maybe adding a Google dns..

[kiaplayer]

Same here. Google DNS didn't help (Ubuntu 16.04 in VirtualBox for Windows 10).

[Keirul]

@snightingale @kiaplayer
Switching to Google DNS solves it. And using the following to clear any leftover dns:

systemctl restart systemd-resolved.service
EDIT: It doesn't flush the dns, it's a full restart of the service.

[Rui-Git]

I'm on Mac

Flushing DNS doesn't work
Adding repositories in composer.json doesn't work

Changing DNS to google DNS Worked

[ghost]

already using google dns, so there's no resolution there.
running composer through the public proxy built into toranproxy does work, however.

[ikas]

Google DNS also solved for me (CentOS)

[notflip]

Does anyone know a solution for a shared hosting? Where I can't run scripts, change settings..

[vrkansagara]

"repositories": {
    "packagist": {
      "url": "https://packagist.org",
      "type": "composer"
    }
  }

not working.

[Keirul]

@notflip You could locally do a composer install and manually move the packages yourself. I don't see another solution for you.

[notflip]

@Keirul I'm affraid that will be it. Thank you!

[ddenysov]

Flushing DNS works for me.
Is there any way to avoid this in the future?

[Keirul]

@denisov1985 Not really. It would be the same thing as planning to use an alternative for when Google is down.

What you could do is create a private repository and host the packages you personally use for that project. So if you use those dependencies elsewhere you can retrieve them yourself.

But update-wise you can't change a thing.

[Reserford1991]

Hello everyone. Does somebody know how to flush DNS on Ubuntu desktop 16.04?

[akadko]

@Reserford1991 Worked for me: systemctl restart systemd-resolved.service

[Keirul]

@Reserford1991 Indeed, @akadko was faster then me, I have already posted that before :)

[Reserford1991]

@akadko, @Keirul Thanks guys, but composer require laravel/installer still does not work properly. Will try to download installer manually.

[ZenelB]

For everyone who is using Windows, just flush your DNS with ipconfig /flushdns in your CMD.

This worked for me

[Reserford1991]

Update on situation
composer require laravel/installer works already

[treuter]

composer update is working again!

[randomComitter]

Our team was monitoring this issue for the past hour, and now it works again. Looks like something was misbehaving on the composer/packagist side.
Interestingly, while the issue was happening, the request GET https://packagist.org/p/provider-latest%240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json was returning 200 with an empty body, and now it returns 404 - maybe it has something to do with the issue that most of us had here.

[stof]

@WallTearer these provider-latest%240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json is a cache-busted URL (see the 240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973 part being a hash of the file ?). The files are dropped after some time when they got replaced (the cron is dumping files every few minutes, and the latest file probably changes at each dump).
Look in packages.json for the new hash of the provider-latest file.

[nguyentamgm]

Running composer self-update helped me to get rid of this error.

[adette]

Thats because 2 machines n their trying to hide plenty machines behind one mostly the victims on one and the crimunals on one as theres plenty violations on the other one...

[Keirul]

@adette You commented on an old issue which was resolved since packagist.org had dns issues.
"This should indicate a man-in-the-middle attack."

This line of text implies it, I agree. But that wasn't the issue.
It clearly shows you haven't read the other comments, which is really unfortunate.

[curry684]

The 'should' wording was also rather unfortunate, hence why I had it changed. It now correctly says "This could indicate a man-in-the-middle attack" as it's simply impossible to determine the true cause from the program's end other than that something is wrong with upstream communication.