PyPI ने रिलीज़ के 14 दिन बाद नई फ़ाइल अपलोड अस्वीकार करना शुरू किया

• PyPI अब प्रकाशन के 14 दिन बाद की रिलीज़ पर नई फ़ाइल अपलोड ब्लॉक करता है, ताकि टोकन या डिप्लॉयमेंट वर्कफ़्लो से समझौता होने पर भी स्थिर पुरानी रिलीज़ दूषित न हो
• अब तक वास्तविक दुरुपयोग का कोई मामला सामने नहीं आया है, लेकिन इस संभावना से हमलावर अनजान थे, इसके अलावा हमले को रोकने के लिए कोई तकनीकी बाधा नहीं थी
• शीर्ष 15,000 पैकेजों की जाँच में पाया गया कि रिलीज़ के 14 दिन बाद Python 3.14 के लिए cp314 wheel जोड़ने वाले प्रोजेक्ट सिर्फ 56 थे
• जो प्रोजेक्ट पुरानी रिलीज़ में नए Python version का support जोड़ते थे, उन्हें अब अगला version जारी करना होगा, और PyCon US 2026 Packaging Summit में भी इसे स्वीकार्य तरीका माना गया
• अभी ऐसा कोई API नहीं है जो रिलीज़ के open/closed status को परिभाषित या जाँच सके, इसलिए इस व्यवहार पर निर्भर नहीं होना चाहिए; आगे PEP 694 का Upload 2.0 API और Staged Previews इससे जुड़ी semantics तय करेंगे

---

पुरानी रिलीज़ को बंद करने की वजह

• PyPI का बदलाव पुरानी और स्थिर रिलीज़ में नई फ़ाइल अपलोड करने का रास्ता बंद करता है
  • इससे यह रोका जा सकेगा कि किसी प्रोजेक्ट का publishing token या workflow compromise होने पर पुरानी रिलीज़ का सिर्फ़ कुछ हिस्सा malicious files से बदल दिया जाए
  • यह रिलीज़ के भीतर compromised और uncompromised files के मिश्रण जैसी अस्पष्ट स्थिति को रोकता है और PyPI admins की cleanup मेहनत भी कम करता है
• इस पर चर्चा PEP 740 Digital Attestations के काम के दौरान जनवरी 2024 में शुरू हुई थी और मार्च 2026 में फिर शुरू हुई
  • इसका ट्रिगर LiteLLM और Telnyx supply chain compromise था, जिसका कारण दोनों प्रोजेक्ट्स द्वारा इस्तेमाल किए गए Trivy GitHub Action में mutable reference था
• कुछ प्रोजेक्ट पहले से प्रकाशित रिलीज़ में नए Python version support files जोड़ रहे थे, इसलिए शुरुआती चर्चा रुक गई थी
  • बदलाव के असर को समझने के लिए PyPI database में पुरानी रिलीज़ में फ़ाइल जोड़ने वाले प्रोजेक्ट्स की जाँच elapsed days के हिसाब से की गई
  • शीर्ष 15,000 पैकेजों के cp314 wheel को अलग से देखने पर पता चला कि 14 दिन बाद Python 3.14 compatible wheel प्रकाशित करने वाले प्रोजेक्ट सिर्फ 56 थे

लागू करने का फैसला और आगे का API

• PyCon US 2026 Packaging Summit में मोटे तौर पर सहमति बनी कि नए Python version support के लिए अगले version पर जाना अनिवार्य करना स्वीकार्य है
• इस जाँच के डेटा और सहमति के आधार पर Warehouse patch आगे बढ़ाया गया और 8 जुलाई 2026 को merge किया गया
• मौजूदा सीमा को अभी स्थिर interface नहीं माना जा सकता
  • “ऐसी रिलीज़ जो अब नई फ़ाइलें स्वीकार नहीं करती” की परिभाषा अभी तय नहीं है और उसका status जाँचने का API भी नहीं है
  • PEP 694 के Upload 2.0 API और Staged Previews को standardize करने के बाद रिलीज़ को open या closed के रूप में संभालने की semantics तय की जाएगी

[GN⁺]

Lobste.rs की राय

• यह अच्छा बदलाव है, लेकिन हैरानी की बात है कि ऐसी नीति कई सालों से मौजूद नहीं थी
  • सबसे हैरानी की बात तो यह है कि शुरू से PyPI release को बदला जा सकता था