Rust डेवलपर्स ऑडिट शुरू होने से पहले किसी crate और उसकी dependencies में unsafe code खोजने के लिए cargo-geiger का उपयोग करते हैं।
Rust टीमें cargo-geiger का उपयोग किसी crate और उसके dependency graph में unsafe Rust की गिनती करने के लिए करती हैं, जिससे maintainers को code audits के लिए एक शुरुआती बिंदु मिलता है।

यह project Rust ecosystem के एक तनावपूर्ण हिस्से में स्थित है। Rust memory safety को अपनी core promise के रूप में प्रस्तुत करता है, फिर भी कई उपयोगी crates को operating systems से बात करने, C libraries को call करने, performance tune करने या low-level abstractions बनाने के लिए unsafe blocks की आवश्यकता होती है। Cargo Geiger teams को एक report देता है जिसे वे review time कहाँ खर्च करना है, यह तय करने से पहले देख सकते हैं।
README इस tool को audit input के रूप में प्रस्तुत करती है। Developers Cargo.toml के साथ उसी directory में cargo geiger चलाते हैं, और यह plugin स्थानीय crate तथा उसकी dependencies के लिए statistics report करता है। वह output cargo-crev या safety-dance जैसे tools में review work को feed कर सकता है।
Installation उस Cargo pattern का अनुसरण करती है जिसकी Rust users अपेक्षा करते हैं। Developers cargo install --locked cargo-geiger चला सकते हैं और system OpenSSL library का उपयोग कर सकते हैं, या वे vendored-openssl feature जोड़कर OpenSSL को executable में build कर सकते हैं। Maintainers GitHub releases के माध्यम से prebuilt binaries भी प्रकाशित करते हैं।

Cargo Geiger उन teams के लिए libraries भी expose करता है जो data को अन्य tools के भीतर consume करना चाहती हैं। README में cargo-geiger, cargo-geiger-serde और geiger सूचीबद्ध हैं। पहला unstable API के साथ internals expose करता है। दूसरा serializable report types प्रदान करता है। तीसरा decoupled Cargo components रखता है जिनका उपयोग command-line tool करता है।
Adoption signal उस समस्या से आता है जिसे यह target करता है। Rust teams ने अपने dependency graphs का विस्तार किया है, और maintainers को manual review शुरू करने से पहले risk देखने के तेज़ तरीके चाहिए। एक ही crate दर्जनों packages खींच सकता है। किसी transitive dependency में एक unsafe block, application repository के code से अधिक महत्वपूर्ण हो सकता है, यह इस पर निर्भर करता है कि team उस dependency पर कितना trust रखती है।
Cargo Geiger developers को यह नहीं बताता कि किसी crate में vulnerability है। यह unsafe usage की गिनती करता है। यह अंतर Rust users के लिए महत्वपूर्ण है क्योंकि unsafe एक contract boundary को चिह्नित करता है, न कि एक defect को। अच्छी तरह से reviewed unsafe block एक high-level API की रक्षा कर सकता है। एक लापरवाह safe wrapper फिर भी खराब abstraction के माध्यम से memory unsafety expose कर सकता है।
Counter-argument उसी अंतर से आता है। कुछ maintainers को चिंता है कि unsafe counts उन crates के आसपास stigma पैदा कर सकते हैं जो कठिन systems work संभालते हैं। अधिक unsafe code वाला crate अधिक review का हकदार हो सकता है, लेकिन केवल संख्या गुणवत्ता को rank नहीं कर सकती। Reviewers को अभी भी invariants, FFI boundaries, tests और maintainer practice की जाँच करनी होती है।
Tool तब सबसे अच्छा काम करता है जब teams report को triage map की तरह मानती हैं। आप इसे किसी dependency को अपनाने से पहले, किसी security-sensitive crate को release करने से पहले, या periodic audit के दौरान चला सकते हैं। आप versions की तुलना कर सकते हैं, नए unsafe usage को spot कर सकते हैं और तय कर सकते हैं कि किस dependency को human review मिलना चाहिए।
Cargo Geiger एक परिपक्व Rust security habit को दर्शाता है: पहले मापें, फिर inspect करें। Count बातचीत शुरू करता है, और engineers code पढ़कर उसे पूरा करते हैं।

टिप्पणियाँ
चर्चा में शामिल होने के लिए कृपया लॉग इन करें या रजिस्टर करें