Composer: json لا تتطابق مع إصدار التوقيع الخاص بها

تم إنشاؤها على ١٥ أبريل ٢٠١٦  ·  64تعليقات  ·  مصدر: composer/composer

مع الملحن التالي json:
(لا أحد)

{
    ...
}

عندما أقوم بتشغيل هذا الأمر:

composer command -vvv (please include -vvv!)

أحصل على هذا الناتج:

  [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.                    

وتوقعت أن يحدث هذا:
تثبيت حزمة cakephp.

Support

التعليق الأكثر فائدة

أضف هذا إلى الملحن الخاص بك

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

ال 64 كومينتر

يرجى تعديل النموذج قليلاً لتقديم حالة مشكلة فعلية.

عندما أحاول التثبيت بواسطة الأمر "php composer.phar create-project --prefer-dist laravel / laravel public" أتلقى رسالة الخطأ المرفقة.

أتساءل ما إذا كانت المشكلة مع CRT على جهاز الكمبيوتر الخاص بي أو على الخوادم؟

هل تعمل خلف وكيل أو تستخدم أي نوع من برامج جدار الحماية؟

إذا حدث الخطأ باستمرار ، فمن المحتمل أن يكون أحد الأخطاء المذكورة أعلاه يفسد اتصالاتك.

مهلا،

لا يوجد استخدام للوكيل ، لقد غيرت الجهاز وما زلت أحصل على نفس الخطأ.

[Composer \ Repository \ RepositorySecurityException]
محتويات http://packagist.org/p/provider-2014٪24778fe81238370a6a10514fa2191d8c49e3b0df47ad7c25361bda5e7c0f48797c.json لا تتطابق مع علامتها
أتور. يجب أن يشير هذا إلى هجوم man-in-the-middle. حاول تشغيل الملحن مرة أخرى وأبلغ عن هذا إذا كنت تعتقد أنه خطأ.

آلة مختلفة ، ولكن نفس الشبكة؟

نعم ، أجهزتها الافتراضية على جهاز الكمبيوتر الخاص بي (دبيان).

آسف ، لست متأكدا حقا ما يمكن أن يكون الخطأ هنا. لكنها بالتأكيد مشكلة شبكات ، ولا يمكننا حل أي شيء من أجلك.

أضف هذا إلى الملحن الخاص بك

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

"المستودعات": {
"الحزمة": {"url": " https://packagist.org "، "type": "composer"}
}
هذا الرمز أعلاه إصلاح مشكلة التوقيع.

[Composer \ Repository \ RepositorySecurityException]
محتويات http://packagist.org/p/provider-2014٪24778fe81238370a6a10514fa2191d8c49e3b0df47ad7c25361bda5e7c0f48797c.json لا تتطابق مع علامتها
أتور. يجب أن يشير هذا إلى هجوم man-in-the-middle. حاول تشغيل الملحن مرة أخرى وأبلغ عن هذا إذا كنت تعتقد أنه خطأ.

لقد واجهت هذه المشكلة في صباح أمس واليوم ، وفي أيام مختلفة في الماضي. في المنطقة الزمنية الخاصة بي التي هي في وقت مبكر صباحًا بالتوقيت العالمي المنسق. ثم تختفي المشكلة بعد الظهر. لذلك أنا متشكك في وجود تحديثات يومية لقائمة الحزم ، ويتم أيضًا تحديث ملف التوقيع ، ولكن في مكان ما "في الإنترنت السيئ الكبير" يتم تخزينها مؤقتًا بشكل مختلف. وهكذا أستلم ملفًا جديدًا لبضع ساعات + توقيع قديم أو ملف قديم + توقيع جديد. إنه أمر مزعج إلى حد ما!

[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.     

سأحاول الآن بانتظام لمعرفة ما إذا كان هناك نمط في الوقت الحقيقي لذلك.
الكود أعلاه لإضافته إلى composer.json هو "أمر جيد" (tm) ويعمل على حل المشكلة.

يجب أن يشير هذا إلى هجوم man-in-the-middle.

يجب أن يقول في الواقع "يمكن" الكالينجيون.

أحصل على خطأ مشابه عند تشغيل برنامج composer يتطلب 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.
مضيفا
"repositories": { "packagist": { "url": "https://packagist.org", "type": "composer" } }
لا يساعد. نرحب بأي اقتراحات.
شكرا لك.

@ furious-snail يبدو أن packagist.org معطلة الآن.

يبدو أنه يعمل مرة أخرى!

حاولت عدة مرات. عند الوصول إلى https://packagist.org ، فإنه يعمل.
شكرا لك.

نفس المشكلة هنا. مضيفا
"repositories": { "packagist": { "url": "https://packagist.org", "type": "composer" } }
لا يساعد.

نفس المشكلة هنا ، لم تنجح إضافة عنوان url الخاص بحزمة البيانات بشكل صريح

يمكنني الوصول إلى موقع الويب https://packagist.org ، لكن ما زلت أحصل على ما يلي عندما أحصل على composer update :

محتويات https://packagist.org/p/provider-latest٪240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json لا تتطابق مع توقيعه. قد يشير هذا إلى هجوم رجل في الوسط. حاول تشغيل الملحن مرة أخرى وأبلغ عن هذا إذا كنت تعتقد أنه خطأ

كذلك هنا

بصورة مماثلة..

نعم ، يبدو أن packagist معطلة ، أو على الأقل الخدمة لا تعمل كما هو متوقع.

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

كذلك هنا :/

فقط انتظر

أعتقد أن هذا مرتبط بانقطاع الخدمة الأخير للرازم.
capture d ecran 2018-01-16 a 15 28 13
مزيد من المعلومات على: https://twitter.com/packagist

كذلك هنا

شكرًا لتحديث Okipa ، المشكلة المتعلقة بـ FYI DNS في Packagist.

نعم ، نحن فقط بحاجة إلى الانتظار قليلاً.

لمستخدم ماك:
sudo killall -HUP mDNSResponder
nslookup packagist.org
الاسم: packagist.org
العنوان: 144.217.203.53.53.53
عملت من أجلي

أعتقد أن الأمر يتعلق بتوقف Packagist في الساعة الماضية. أنا أيضا أحصل على أخطاء. أرسلتها على Twitter ، وسوف أقوم بتحديث هذا الموضوع عندما أسمع المزيد.

endyjasmi Packagist DNS معطل. انتقل إلى أعلى.

فلوشينغ DNS كما قيل في تويتر عملت. ذهبت المشكلة في النهاية.

أعتقد أنه في استضافة مشتركة ، سيتعين علي الاتصال بمسؤولي النظام لإجراء مسح DNS؟

هذه مشكلتي أيضًا

لديك نفس المشكلة أيضا

في الواقع ، ما ساعدنا هو استخدام DNS مختلف:

https://developers.google.com/speed/public-dns/

حاولت الآن محليًا وهي تعمل! لم يكن يعمل محليًا قبل ثوانٍ

مسح ذاكرة التخزين المؤقت لـ DNS (أو استخدام خوادم Google DNS المؤقتة) يعمل بالنسبة لي.

تم حلها هنا أيضًا ، فأنا على نظام Linux لذلك قمت بالتبديل إلى Google DNS -> https://developers.google.com/speed/public-dns/

لمستخدمي macOs ، امسح DNS الخاص بك: dscacheutil -flushcache;sudo killall -HUP mDNSResponder; .
ثم ping packagist.org ، يجب أن يكون عنوان IP هو 144.217.203.53.

الغريب أن مسح DNS لم ينجح بعد. لا يزال يحصل

[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.

أنا على Linux واستخدمنا service dnsmasq restart (لأننا لا نملك nscd )

ربما تضيف Google DNS ..

كذلك هنا. لم يساعد Google DNS (Ubuntu 16.04 في VirtualBox لنظام التشغيل Windows 10).

تضمين التغريدة
التبديل إلى Google DNS يحلها. وباستخدام ما يلي لمسح أي بقايا لنظام أسماء النطاقات:

إعادة تشغيل systemctl systemd -olved.service
تحرير: إنه لا يتدفق في نظام أسماء النطاقات ، إنه إعادة تشغيل كاملة للخدمة.

أنا على Mac

مسح DNS لا يعمل
لا تعمل إضافة مستودعات في composer.json

عمل تغيير DNS إلى google DNS

باستخدام نظام أسماء النطاقات من google ، لذلك لا يوجد حل هناك.
تشغيل الملحن من خلال الوكيل العام المدمج في toranproxy يعمل.

تم أيضًا حل Google DNS لي (CentOS)

هل يعرف أي شخص حلا للاستضافة المشتركة ؟ حيث لا يمكنني تشغيل البرامج النصية ، قم بتغيير الإعدادات ..

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

لا يعمل.

notflip يمكنك محليًا تثبيت الملحن ونقل الحزم يدويًا بنفسك. لا أرى حلًا آخر لك.

Keirul أخشى أن يكون الأمر. شكرا لك!

يعمل Flushing DNS بالنسبة لي.
هل هناك طريقة لتجنب هذا في المستقبل؟

@ denisov1985 ليس حقا. سيكون الأمر مشابهًا للتخطيط لاستخدام بديل عند تعطل Google.

ما يمكنك فعله هو إنشاء مستودع خاص واستضافة الحزم التي تستخدمها شخصيًا لهذا المشروع. لذلك إذا كنت تستخدم هذه التبعيات في مكان آخر ، يمكنك استعادتها بنفسك.

لكن من الحكمة التحديث لا يمكنك تغيير أي شيء.

أهلا بالجميع. هل يعرف شخص ما كيفية مسح DNS على سطح مكتب Ubuntu 16.04؟

@ Reserford1991 عملت لدي: systemctl restart systemd-resolved.service

@ Reserford1991 في الواقع ، akadko كان أسرع مني ، لقد قمت بالفعل بنشر ذلك من قبل :)

akadko ، Keirul شكرًا يا رفاق ، لكن الملحن يتطلب Laravel / المثبت لا يزال لا يعمل بشكل صحيح. سنحاول تنزيل برنامج التثبيت يدويًا.

لكل من يستخدم Windows ، ما عليك سوى مسح DNS الخاص بك بـ ipconfig /flushdns في CMD الخاص بك.

هذا عمل لي

تحديث على الوضع
يتطلب الملحن أعمال Laravel / المثبت بالفعل

composer update يعمل مرة أخرى!

كان فريقنا يراقب هذه المشكلة على مدار الساعة الماضية ، وهو يعمل الآن مرة أخرى. يبدو أن شيئًا ما كان يسيء التصرف من جانب المؤلف / كاتب العبوة.
ومن المثير للاهتمام ، أنه أثناء حدوث المشكلة ، كان الطلب GET https://packagist.org/p/provider-latest%240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json يعيد 200 بجسم فارغ ، والآن يُرجع 404 - ربما يكون له علاقة بالمشكلة التي واجهها معظمنا هنا.

WallTearer هذه provider-latest%240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973.json عبارة عن عنوان URL تم اختراق ذاكرة التخزين المؤقت (انظر الجزء 240cbfb40ab72a881d21b70f78286d39cd72e3b0eb8704c13e79dc49624e549973 باعتباره تجزئة الملف؟). يتم إسقاط الملفات بعد مرور بعض الوقت عند استبدالها (يقوم cron بإلقاء الملفات كل بضع دقائق ، ومن المحتمل أن يتغير الملف latest عند كل تفريغ).
ابحث في packages.json عن التجزئة الجديدة لملف provider-latest .

ساعدني تشغيل composer self-update في التخلص من هذا الخطأ.

هذا لأن آليتين تحاولان إخفاء الكثير من الآلات خلف أحدهما في الغالب الضحايا على واحدة والمجرمين على أحدهما لأن هناك الكثير من الانتهاكات على الآخر ...

adette لقد علقت على مشكلة قديمة تم حلها نظرًا لأن packagist.org كانت بها مشكلات في نظام أسماء النطاقات.
"يجب أن يشير هذا إلى هجوم رجل في الوسط."

هذا السطر من النص يعني ضمنا ذلك ، وأنا أوافق. لكن هذا لم يكن هو المشكلة.
يظهر بوضوح أنك لم تقرأ التعليقات الأخرى ، وهذا أمر مؤسف حقًا.

كانت صياغة "ينبغي" مؤسفة إلى حد ما ، ولهذا السبب قمت بتغييرها . تقول الآن بشكل صحيح "قد يشير هذا إلى هجوم man-in-the-middle" لأنه ببساطة من المستحيل تحديد السبب الحقيقي من نهاية البرنامج بخلاف أن هناك شيئًا خاطئًا في الاتصال الأولي.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات