<p>बुराई डेटा के साथ संख्यात्मक लोड फ़ंक्शन कमांड निष्पादन का कारण होगा</p>

संस्करण <= 1.16.0, ने काम किया

हाँ, यही कारण है कि np.load(allow_pickle=True) जोड़ा गया था, अब मुझे लगता है कि हम False डिफ़ॉल्ट करने के लिए स्विच करने के लिए एक कदम बना सकते हैं और एक अच्छा पठनीय संदेश देते हैं " allow_pickle="True" यदि आप इस फाइल पर भरोसा रखें ”।

मैं मानता हूं कि यह बेहतर डिफ़ॉल्ट होगा, इसलिए मैं उस पदावनति को आगे बढ़ाने के लिए तैयार हूं, भले ही यह दुर्भाग्य से थोड़ा शोर है जैसे कि उन सभी वैज्ञानिकों के लिए सिर्फ लैब में कुछ डेटा साझा करना (या सिर्फ खुद को बचाने / पुनः लोड करना)।

तो अप्रैल 2015 में allow_pickle जोड़ा गया था, इसलिए ऐसा प्रतीत होता है कि 1.10 के बाद से अस्तित्व में होना चाहिए था। इसलिए मुझे लगता है कि यह कदम अब और अधिक यथार्थवादी हो गया है, क्योंकि मुझे संदेह है कि 1.17 का उपयोग करने / समर्थन करने वाले कई लोग अभी भी 1.10 का समर्थन करेंगे (काग्रेस का समर्थन करने या इसे समर्थन नहीं करने के दर्द को दूर करना)। हालांकि फिलहाल यह कम से कम अभी भी संस्करण 1 में 1.8 का समर्थन करता है।

ऐसा लगता है कि यह लंबे समय तक रहेगा

मेरा सुझाव है कि यदि आप एक सुचारु परिवर्तन चाहते हैं तो एक डिप्रेसेशन चेतावनी लॉगिंग करें और एक तारीख दें।

@Plazmaz बेशक, मैं एक VisibleDeprecationWarning के साथ जाऊंगा, अगर हम चाहते हैं कि आकस्मिक उपयोगकर्ता इसे करना बंद कर दें। फिर एक या दो रिलीज के बाद पदावनत करें। बात यह है कि अगर आपको करना है और आसपास के कुछ पुराने संस्करणों में मौजूद नहीं है तो काम करना कष्टप्रद है। क्योंकि तब आपको चेतावनी से बचने और दोनों का समर्थन करने के लिए if np.__version__ > ...: use kwarg else do not use kwarg करना होगा।

वैसे भी, मुझे लगता है कि एक अच्छा मौका है जब आप इसे 1.17 में प्राप्त कर सकते हैं। इसलिए यदि आप एक पीआर खुला महसूस करते हैं, लेकिन हम मेलिंग सूची को देखने के लिए चाहते हैं कि कोई शिकायत करे।

नमस्ते, फेडोरा सुन्न RPM अनुचर। डिस्ट्रो पैकेजिंग में इसे कम करने का एक अच्छा तरीका क्या है?

मैं एक अच्छा तरीका नहीं जानता। चिंता के स्तर के आधार पर, मैं बहुत जल्द एक चेतावनी जोड़ना चाहूंगा, ताकि यह 1.17 में निश्चित रूप से हो। यदि कोई बहुत चिंतित है, तो हम इसे वापस करने या तेज चलने पर चर्चा कर सकते हैं, लेकिन यह बहुत कुछ इस बात पर निर्भर करेगा कि डाउनस्ट्रीम इस पर निर्भर करता है या नहीं।

मैं इस पर काम कर रहा हूं।

cc @jeanqasaur re: सुरक्षा / भेद्यता विशेषज्ञता

नमस्ते, फेडोरा सुन्न RPM अनुचर। डिस्ट्रो पैकेजिंग में इसे कम करने का एक अच्छा तरीका क्या है?

@ लिम्बुरघेर : पायथन में निर्मित सटीक कार्यक्षमता के बारे में फेडोरा क्या करता है? यह स्पष्ट नहीं है कि यह एक ऐसी चीज है जिसे कम करने की आवश्यकता है।

जबकि मैं डिफ़ॉल्ट को बदलने का विरोध नहीं कर रहा हूँ, यह एक भेद्यता घोषित करना गलत लगता है। यह प्रलेखित और डिज़ाइन के रूप में काम कर रहा है।

दुर्भाग्य से नियम यह है कि एक बार एक सीवीई नंबर सौंपा जाने के बाद, यह कोई मायने नहीं रखता है कि कोई बग है या नहीं, डिस्ट्रोस को अपने ग्राहकों को साबित करने के लिए कुछ करने की कोशिश करनी होगी कि वे मूल्य प्रदान कर रहे हैं। यह सुनिश्चित नहीं है कि यहां क्या होगा, लेकिन कंपनियां और ऑप्स लोग हमेशा कमजोरियों की चल रही बाढ़ का प्रबंधन करने के लिए संघर्ष कर रहे हैं, और ऐसा करने के लिए वे जो उपकरण उपयोग करते हैं, उनके पास अति सूक्ष्म अंतर संचार के लिए बहुत जगह नहीं है, इसलिए यह दबाव है जाता है। हालांकि हमारे पास ग्राहक नहीं हैं, इसलिए हमें जरूरी नहीं है कि हम इसे खुद ही ध्यान में रखें।

हम save और load दौरान बता सकते हैं कि कोई विशेष फ़ाइल अचार का उपयोग करती है या नहीं, है ना? शायद दोनों मामलों में allow_pickle=False प्रवास करना अच्छा है, एक मध्यवर्ती अवधि के साथ जहां हम कुछ प्रकार के अपव्यय चेतावनी जारी करते हैं बिल्कुल उन मामलों में जहां save या load वास्तव में आवश्यकता होती है अचार और allow_pickle का उपयोग करने के लिए निर्दिष्ट नहीं किया गया था।

@ eric-wieser stdlib अचार से अंतर यह है कि load / save वास्तव में अचार का उपयोग करने से बच सकते हैं (जैसे आदिम प्रकार के सरल सरणियों); अचार को केवल अधिक विदेशी मामलों में उपयोग किया जाता है जैसे ऑब्जेक्ट सरणियां या IIRC कुछ जटिल dtypes। यह उन लोगों के लिए संभव बनाता है जो ज्यादातर सुरक्षित मामले का उपयोग करने से चूक जाते हैं कि असुरक्षित मामला मौजूद है, अगर वे डॉक्स को पर्याप्त रूप से नहीं पढ़ते हैं। और वैसे भी, यह देखते हुए कि हमारे पास "सुरक्षित मोड" और "असुरक्षित मोड" दोनों हैं, डिफ़ॉल्ट होने के लिए "सुरक्षित मोड" के लिए बेहतर है। Stdlib अचार OTOH के लिए, यह हमेशा 100% असुरक्षित 100% समय होता है, इसलिए चूक के बारे में चिंता करने का कोई मतलब नहीं है।

ईमानदारी से, अगर यह प्रलेखित है, जानबूझकर कार्यक्षमता है, तो मैं अच्छे विवेक में BZ को बंद कर सकता हूं, खासकर यदि सुरक्षित डिफ़ॉल्ट है। मुझे नहीं पता कि हम पायथन की कार्यक्षमता को कैसे संभालते हैं। मैं देखूंगा।

कल्पना की मेरी परीक्षा से, मुझे नहीं लगता कि हम उस संबंध में कुछ भी ऊपर से बदल सकते हैं।

क्या सीवीई विवादित रहा है? यह परिदृश्य बनाए रखने के लिए स्पष्ट हो सकता है।

सीवीई बड़े पैमाने पर फर्जी प्रतीत होता है। वह numpy.load मनमाना कोड निष्पादित कर सकता है जो अच्छी तरह से जाना जाता है और प्रलेखित है, और यह क्रमबद्ध पाइथन ऑब्जेक्ट सरणियों को लोड करने के लिए आवश्यक है। उपयोगकर्ता इस लाइब्रेरी फ़ंक्शन में allow_pickle=False पास करके लोडिंग ऑब्जेक्ट सरणियों को मना कर सकता है।

यह बेहतर होता यदि डिफ़ॉल्ट ऑब्जेक्ट सरणियों को केवल स्पष्ट रूप से पूछे जाने पर लोड किया जाता, लेकिन यह वैसा ही है जैसा कि ऐतिहासिक कारणों से है। संक्रमण का सुझाव पहले भी दिया जा चुका है, और ऊपर चर्चा इस बात को लेकर है कि इसे कैसे बनाया जाए जो अनियंत्रित रूप से पिछड़ी अनुकूलता को न तोड़ें।

हालांकि, पायथन अचार के रूप में numpy.load का लापरवाह उपयोग, हालांकि बहाव के अनुप्रयोगों में कमजोरियों को जन्म दे सकता है।

वह numpy.load मनमाना कोड निष्पादित कर सकता है जो अच्छी तरह से जाना जाता है और प्रलेखित है, और यह क्रमबद्ध पाइथन ऑब्जेक्ट सरणियों को लोड करने के लिए आवश्यक है।

मैं केवल यह कहूंगा कि यह प्रलेखित है। मैं कुछ वर्षों के लिए numpy का उपयोग कर रहा हूं, और जब मैं numpy.save / numpy.load लगातार उपयोगकर्ता नहीं हूं, तो यह मेरे लिए बिल्कुल भी स्पष्ट नहीं था कि numpy.load pickle रूप में एक ही भेद्यता से ग्रस्त है। बेशक मुझे नहीं पता था कि numpy.load pickle हुड के तहत उपयोग हो सकता है (मैं केवल सुन्न-देशी सरणियों का उपयोग करता हूं और कभी भी इसे एक विचार नहीं दिया, बिल्कुल @njsmith उल्लेख किया है)।

तथ्य यह है कि pickle कमजोर है, अच्छी तरह से जाना जाता है, और इसके प्रलेखन में शीर्ष कहने पर एक बड़ी लाल चेतावनी है

चेतावनी : pickle मॉड्यूल गलत या दुर्भावनापूर्ण रूप से निर्मित डेटा के खिलाफ सुरक्षित नहीं है। एक अविश्वसनीय या बिना स्रोत के प्राप्त डेटा को कभी भी अनपिक नहीं करें।

इसकी तुलना में, numpy.load के डॉक्स अपने allow_pickle कीवर्ड के विवरण में एक तरफ के रूप में पूरे सुरक्षा पहलू का उल्लेख करते हैं:

allow_pickle: _bool, वैकल्पिक_
Npy फ़ाइलों में संग्रहीत मसालेदार ऑब्जेक्ट सरणियों को लोड करने की अनुमति दें। अचार को बंद करने के कारणों में सुरक्षा शामिल है, क्योंकि अचार लोड करने वाले डेटा को मनमाना कोड निष्पादित किया जा सकता है। यदि अचार को बंद कर दिया जाता है, तो लोडिंग ऑब्जेक्ट सरणियाँ विफल हो जाएंगी। डिफ़ॉल्ट: सच है

अगर हम numpy.load के प्रलेखन में बिग रेड वार्निंग डाल सकते हैं तो मुझे इससे नफरत नहीं होगी, कम से कम allow_pickle=False डिफ़ॉल्ट होने तक। जब तक वह परिवर्तन numpy.load देखकर न हो जाए, तब तक किसी के दिमाग में उसी लाल झंडे को उठाना चाहिए, जो pickle.load बढ़े।

प्रलेखन पीआर numpy.load लिए स्वागत करते हैं

अब दस्तावेज़ीकरण में अचार के बारे में चेतावनी है

दुर्भाग्य से नियम यह है कि एक बार एक सीवीई नंबर सौंपा जाने के बाद, यह कोई मायने नहीं रखता है कि कोई बग है या नहीं, डिस्ट्रोस को अपने ग्राहकों को साबित करने के लिए _something_ करने की कोशिश करनी होगी कि वे मूल्य प्रदान कर रहे हैं। यह सुनिश्चित नहीं है कि यहां क्या होगा, लेकिन कंपनियां और ऑप्स लोग हमेशा कमजोरियों की चल रही बाढ़ का प्रबंधन करने के लिए संघर्ष कर रहे हैं, और ऐसा करने के लिए वे जो उपकरण उपयोग करते हैं, उनके पास अति सूक्ष्म अंतर संचार के लिए बहुत जगह नहीं है, इसलिए यह दबाव है जाता है।

@njsmith यह इतना बुरा नहीं numpy.load डिफॉल्ट को allow_pickle से False कर देंगे, जो वास्तव में पूरी तरह से बेवकूफ विचार नहीं है।

एकमात्र जोखिम जो मैं देख रहा हूं, वह कोई भी परियोजना है जो स्पष्ट रूप से सेट नहीं करता है allow_pickle टूट जाएगा।

यह सिर्फ अंत उपयोगकर्ता नहीं कर रहा है परियोजनाओं हम के बारे में चिंता करने की ज़रूरत है - मैं उपलब्ध कराने के नीचे की ओर पुस्तकालयों बारे में चिंतित हूँ mylib.load कि wraps np.load । ये ऑब्जेक्ट सरणियों को लोड करने में विफल होने लगेंगे। उनके साथ तीन चीजों में से एक होगा:

• वे परित्यक्त रहते हैं, और जिस तरह से वे करते थे, उस पर वस्तु सरणियों पर कभी काम नहीं करेंगे। उपयोगकर्ता पाएंगे कि उनके डेटा को बंधक बना लिया गया है, और इसे पुनर्प्राप्त करने के लिए सुन्न को डाउनग्रेड करना होगा।
• उन्होंने पुराने व्यवहार को फिर से शुरू करने के लिए allow_pickle=True सेटिंग फिर से जारी की - जो यह दर्शाता है कि डाउनस्ट्रीम लाइब्रेरियों का कहना है कि उन्हें लगता है कि यह एक हमला वेक्टर नहीं है जिसकी उन्हें परवाह है। यह अभी भी उन्हें एक असंगत रिलीज की लागत
• वे अपने स्वयं के एपीआई में allow_pickle=False को उजागर करेंगे, समस्या को नीचे की ओर धकेलेंगे।

मेरी प्राथमिकता होगी:

• np.save कुछ भी न करें। किसी ऑब्जेक्ट सरणी को सहेजते समय अंत में एक लंबे समय से चल रहे स्क्रिप्ट क्रैश का होना एक भयानक अनुभव है।
• डिफ़ॉल्ट को np.load से None में बदलें। उपयोगकर्ता को True या False स्पष्ट रूप से पास नहीं होने का पता लगाएं, और UserWarning खतरों को समझाते हुए, उन्हें सुरक्षा ( False ) और ऑब्जेक्ट के बीच चयन करने के लिए कहें। सरणी समर्थन ( True )। इस चेतावनी को छोड़ने के बाद यथास्थिति के लिए डिफ़ॉल्ट। यह मेरी समझ है कि यहाँ समस्या जागरूकता की कमी है। सभी मामलों में न तो चुनाव सही है, इसलिए मुझे नहीं लगता कि हमें अचानक बिना किसी चेतावनी के अपने दिमाग को बदल देना चाहिए।

@ एरिक-वेसर अच्छी स्क्रिप्ट दुर्घटना के दर्द के बारे में। मैं डिफ़ॉल्ट रूप से UserWarning देने के लिए तैयार हूं।

सवाल यह है कि हम load में लंबे समय में क्या करना चाहते हैं। मुझे यकीन नहीं है कि मैं सभी को kwarg (चेतावनी को चुप करने के लिए) का उपयोग करने के लिए मजबूर कर रहा हूं, जब सरणी सुरक्षित है। हालाँकि इसमें किसी को अपने डेटा को लॉक करने के खतरे का गुण नहीं है ... OTOH, यदि चेतावनी केवल "असुरक्षित" लोड पर दिखाई देती है, तो बहुत देर हो सकती है। अभी मुझे लगता है कि संक्रमण की अवधि को थोड़ा लंबा करने के लिए मेरी थोड़ी सी प्राथमिकता है।

OTOH, यदि चेतावनी केवल "असुरक्षित" लोड पर दिखाई देती है, तो बहुत देर हो सकती है।

कोई एक:

• लाइब्रेरी / स्क्रिप्ट पहले से मौजूद है और प्रकाशित है - हम जो कुछ भी करते हैं वह पहले से ही बहुत देर हो चुकी है
• पुस्तकालय / लिपि अभी भी विकसित की जा रही है। डेवलपर को सुरक्षित फ़ाइल पर स्थानीय परीक्षण के दौरान चेतावनी देखनी चाहिए, और यह सूचित करने में सक्षम होना चाहिए कि उन्हें कौन सा व्यवहार चाहिए। इस कारण से, हमें चेतावनी को छोड़ देना चाहिए भले ही वह सरणी सुरक्षित हो (और शायद इसे लोड करने से पहले, बस मामले में उनके पास -Werror सेट के बराबर अजगर है)।

हां, मैं निश्चित रूप से पुस्तकालयों के लिए सहमत हूं, लेकिन मुझे लगता है कि बड़ी संख्या में छोटी स्क्रिप्ट के लिए यह थोड़ा कष्टप्रद हो सकता है।

डिफ़ॉल्ट को np.load से None में बदलें। स्पष्ट रूप से True या False True में पास नहीं होने वाले उपयोगकर्ता का पता लगाएं, और UserWarning खतरों को समझाते हुए उन्हें सुरक्षा ( False ) और ऑब्जेक्ट के बीच चयन करने के लिए कहें। सरणी समर्थन ( True )। इस चेतावनी को छोड़ने के बाद यथास्थिति के लिए डिफ़ॉल्ट। यह मेरी समझ है कि यहाँ समस्या जागरूकता की कमी है। सभी मामलों में न तो चुनाव सही है, इसलिए मुझे नहीं लगता कि हमें अचानक बिना किसी चेतावनी के अपने दिमाग को बदल देना चाहिए।

हालांकि यह सुपर कष्टप्रद लगता है। अधिकांश लोग (मेरा मानना ​​है कि) ऑब्जेक्ट सरणियों को सहेज / लोड नहीं करते हैं। और सबसे खराब स्थिति अगर किसी को चेतावनी याद आती है (अंततः) लोड होने पर उनकी स्क्रिप्ट क्रैश हो जाती है, डेटा अभी भी डिस्क पर सुरक्षित है, और वे allow_pickle ध्वज के साथ पुन: प्रयास करते हैं।

क्या यह पहले से ही सुरक्षित रूप से लोड करने की कोशिश करने के लिए सुन्न की ज़िम्मेदारी से परे है और केवल उस मामले में चिल्ला रहा है जो ऑब्जेक्ट सरणियों के कारण विफल रहता है? यह अधिकांश (गैर-ऑब्जेक्टी) उपयोग के मामलों के लिए अतिरिक्त काम को हटा देगा, लेकिन मुझे लगता है कि यह पूरे सुरक्षा मुद्दे की दृश्यता को भी कम करेगा। फिर मुझे लगता है कि "उपयोगकर्ताओं को बहुत जागरूक किया जाना चाहिए" और "उपयोगकर्ताओं को असुविधा नहीं होनी चाहिए" यहां थोड़ा विरोधाभासी प्रयास हैं।

* Change the default in `np.load` to `None`. Detect the user not passing in `True` or `False` explicitly, and emit a `UserWarning` explaining the dangers, asking them to choose between security (`False`) and object array support (`True`). Default to the status quo after emitting this warning. It's my understanding that the problem here is lack of awareness. Neither choice is correct in all cases, so I don't think we should suddenly change our minds about the default without warning.

इस पैच के बारे में क्या?

* Change the default in `np.load` to `None`. Detect the user not passing in `True` or `False` explicitly, and emit a `UserWarning` explaining the dangers, asking them to choose between security (`False`) and object array support (`True`). Default to the status quo after emitting this warning. It's my understanding that the problem here is lack of awareness. Neither choice is correct in all cases, so I don't think we should suddenly change our minds about the default without warning.

इस पैच के बारे में क्या:

--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -265,7 +265,7 @@ class NpzFile(object):
         return self.files.__contains__(key)


-def load(file, mmap_mode=None, allow_pickle=True, fix_imports=True,
+def load(file, mmap_mode=None, allow_pickle=None, fix_imports=True,
          encoding='ASCII'):
     """
     Load arrays or pickled objects from ``.npy``, ``.npz`` or pickled files.
@@ -367,6 +367,16 @@ def load(file, mmap_mode=None, allow_pic
     memmap([4, 5, 6])

     """
+
+    if allow_pickle is None:
+        UserWarning("""
+        numpy.load() run without explicit setting allow_pickle option.
+        If you are not completely certain about security of the pickled
+        data, you are strongly encouraged to set allow_pickle to False,
+        otherwise you can set it to True.
+        """)
+        allow_pickle = False
+
     own_fid = False
     if isinstance(file, basestring):
         fid = open(file, "rb")

मैं अभी भी एक चेतावनी के पक्ष में हूं जब ऑब्जेक्ट डेटा लोड हो रहा है, तो यह थोड़ा "बहुत देर" हो सकता है, लेकिन बहुत कम शोर संक्रमण के लिए बनाता है। बचत करते समय हम एक चेतावनी जोड़ सकते हैं (सिर्फ एक स्थायी चेतावनी)। वहाँ एक खुला पीआरएस है जो मुझे उम्मीद है कि इस तरह से कुछ और में बदल जाएगा। यदि आप इस पर समय बिताना चाहते हैं, तो हम आमतौर पर पीआर के बारे में खुश होते हैं।
यह मुझे लगता है कि यह किसी भी मामले में जल्द ही एक अविकसित चक्र शुरू करने की दिशा में रूपांतरण है, और मुझे लगता है कि ऐसा होगा (लेकिन अगर कोई इसे उठाता है तो यह जल्द ही होगा;))। विलंब का अनुरोध करने का एक छोटा मौका हो सकता है, लेकिन मुझे इसमें संदेह है, और बिना प्रयास किए यह जानना कठिन है।

क्या आप इस मुद्दे को बंद कर सकते हैं क्योंकि इसे https://nvd.nist.gov/vuln/detail/CVE-2019-6446 में संदर्भित किया गया है, जिसके कारण नेक्सस iq अभी भी इस पर विचार करता है कि यह कमजोर है

धन्यवाद @ मंजूनाथ ०।