Vet – रिमोट shell script को अधिक सुरक्षित तरीके से चलाने का टूल

 (getvet.sh)
10 पॉइंट द्वारा GN⁺ 2025-07-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • vet एक CLI टूल है जो curl | bash शैली में रिमोट install script चलाने को "डाउनलोड → समीक्षा → निष्पादन स्वीकृति" प्रक्रिया में सुरक्षित रूप से बदलता है
  • यह script change history (diff) की जाँच, shellcheck-आधारित lint (static analysis), और direct approval (जाँच के बाद execution) जैसी चरणबद्ध सुरक्षा सुविधाएँ देता है
  • एक ही कमांड (vet https://example.com/install.sh) से रिमोट script चलाने से पहले संभावित जोखिम, छेड़छाड़, टाइपो और कमजोरियों की स्वतः जाँच की जा सकती है
  • installation के लिए भी यह स्वयं "डाउनलोड के बाद समीक्षा" और "curl | sh" दोनों तरीके सपोर्ट करता है, और vet की अपनी install code भी सीधे देखी जा सकती है
  • यह development/operations environment में security risk की रोकथाम और automation/सुविधा दोनों को साथ में हासिल करने वाला एक भरोसेमंद समाधान है

समस्या: बिना सोचे-समझे रिमोट install script चलाना

  • कई open source प्रोजेक्ट और टूल curl -sSL https://example.com/install.sh | bash जैसी रिमोट script installation विधि सुझाते हैं
  • इस तरीके में script से छेड़छाड़, server hack, network error आदि के कारण malicious code execution, partial file execution जैसी गंभीर security risk मौजूद रहती हैं

vet का समाधान: सुरक्षित interactive execution

  • vet रिमोट script execution को नीचे दिए गए 4-स्टेप security process में wrap करता है
    • 1. Fetch: रिमोट script को सुरक्षित रूप से एक अस्थायी location पर डाउनलोड करना
    • 2. Diff & Review: पिछली execution history से तुलना करके change (diff) दिखाना, और नए/बदले हुए code की सीधे नज़र से समीक्षा करना
    • 3. Lint: shellcheck (install होने पर) के जरिए bug, vulnerability और असामान्य pattern का automatic static analysis
    • 4. Confirm: वास्तविक execution से पहले उपयोगकर्ता से अंतिम approval (yes/no) माँगना
  • एकल कमांड: 
    vet https://example.com/install.sh

installation विधि

सुरक्षित अनुशंसित तरीका (डाउनलोड → समीक्षा → निष्पादन)

  • 1. install script डाउनलोड करें:
  • 2. डाउनलोड की गई script के code की स्वयं समीक्षा करें (less, vim आदि से):
    less install_vet.sh
  • 3. समीक्षा के बाद स्वयं चलाएँ:
    sh install_vet.sh

तेज़ installation (trust-आधारित one-liner)

vet की विशेषताएँ और फायदे

  • change detection (diff): पहले चलाई गई script से तुलना करके नए बदले हिस्सों को देखा जा सकता है
  • automatic lint (shellcheck integration): shell script की vulnerability, टाइपो और संदिग्ध code का स्वतः निदान
  • explicit execution approval (Confirm): एक क्लिक/इनपुट से वास्तविक execution को सीधे नियंत्रित किया जा सकता है
  • automatic script save और history management: अक्सर इस्तेमाल होने वाली install scripts को भी सुरक्षित रूप से track किया जा सकता है
  • अंदरूनी तौर पर सुरक्षित installation/update की भी गारंटी

निष्कर्ष

  • vet developers और operators दोनों के लिए ज़रूरी curl | bash का सुरक्षित विकल्प है, जो installation automation और security दोनों को संभव बनाता है
  • "बस ऐसे ही मत चलाइए, vet से verify करके चलाइए!"

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-07-02
Hacker News राय
  • 90% मामलों में, इंस्टॉलर का इस्तेमाल करते समय लोग वास्तव में सॉफ़्टवेयर की विश्वसनीयता को कैसे सत्यापित करते हैं, यह जानने की जिज्ञासा है। कुछ मामलों में कोड पर सिग्नेचर होता है, लेकिन कई बार बिना किसी अतिरिक्त सत्यापन के वही HTTPS सर्वर कोड डाउनलोड करा देता है। अगर कोड compiled रूप में हो, तो क्या लोग diff भी करते हैं, यह भी सवाल है। इंटरनेट से यूँ ही इंस्टॉलर चलाना अच्छा तरीका नहीं है, और अगर operating system के distribution से इंस्टॉल किया जाए तो वहाँ कहीं बेहतर verification व्यवस्था होती है। हालांकि ये तरीके भी भरोसा जोड़ने में बहुत बड़ी मदद नहीं करते
    • vet का उद्देश्य इंस्टॉल स्क्रिप्ट की अपनी सुरक्षा पर फ़ोकस करना है, और इसका ज़ोर इस बात पर है कि इंस्टॉल स्क्रिप्ट को इस तरह बदला न जा सके कि वह checksum verification छोड़ दे या किसी malicious URL से binary डाउनलोड करे। एक हिस्से में यह मज़बूत सुरक्षा देता है, लेकिन पूरी chain की ज़िम्मेदारी नहीं लेता
    • इंस्टॉलर आम तौर पर सिर्फ़ एक बार चलाया जाता है, और पिछली run की तुलना में हुए बदलाव दिखाना कितना उपयोगी है, इस पर सवाल है
    • केवल विश्वसनीय, cryptographically signed, community-managed package list के ज़रिए इंस्टॉल करना चाहिए और ऐसी विधि अपनानी चाहिए जिसका security track record मज़बूत हो। मूल समस्या डाउनलोड स्क्रिप्ट की सुरक्षा कठिन होना नहीं, बल्कि macOS जैसी कुछ communities में इस तरह के hacky install तरीकों को स्वीकार करने की संस्कृति है। भरोसेमंद platforms से अधिक सख़्त अपेक्षाएँ होनी चाहिए। इंटरनेट से मिली shell script पर lint चला देने भर से सुरक्षा बढ़ती है, ऐसा नहीं लगता
  • अगर कोई malicious script में बार-बार # shellcheck disable= pragma डालता रहे तो क्या होगा, यह सवाल है
    • अच्छा point है। हाँ, ऐसा हो सकता है। vet सिर्फ़ ShellCheck पर निर्भर नहीं करता, diff इसका मुख्य हिस्सा है। भले ही linter चुप रहे, diff के ज़रिए संदिग्ध # shellcheck disable= कोड के insertion को पकड़ा जा सकता है। यह बदलाव अपने आप में warning sign है
  • इसमें एक विडंबना महसूस होती है: 
    # जब remote script पर आँख बंद करके भरोसा किया जाता है:
curl -sSL https://example.com/install.sh | bash
    उसके बाद 
    curl -sL https://getvet.sh | sh
    इस तरह चलाना
    • लगता है मैं वह हिस्सा पढ़े बिना आगे बढ़ गया था। vet की खास बात यह है कि वह इस विडंबना को खुद पहचानता है। उपयोगकर्ताओं को vet की install script खुद inspect करने के लिए प्रोत्साहित किया जाता है। vet का लक्ष्य ही वही है। install.sh source सीधे देखा जा सकता है
  • यह सच में बहुत बढ़िया solution लगता है। इस बारे में मैं भी अक्सर सोचता रहा हूँ, और uv जैसी चीज़ों में भी यह सवाल था। लेकिन ज़्यादातर मामलों में लोग code manager पर भरोसा कर लेते हैं, इसलिए व्यावहारिक समझौता कर लेते हैं
    • जानना चाहूँगा कि uv के बारे में आपका क्या विचार है
  • इस चर्चा को देखकर vet के अगले चरण के रूप में private environment support के बारे में सोचने लगा हूँ। Public scripts को verify करना अच्छा है, लेकिन internal GitHub repo या internal server से deployment scripts चलाने की ज़रूरत भी होती है। इस बारे में vet में authentication जोड़ने के लिए feature request खोली है। .netrc support, VET_TOKEN environment variable, और आगे चलकर HashiCorp Vault जैसे secret manager integration भी roadmap में हैं। दिलचस्पी हो तो GitHub issue में राय सुनना चाहूँगा। फ़ीडबैक के लिए धन्यवाद
  • क्या page या readme में इसका काम करता हुआ रूप या demo video दिखाया जा सकता है? यह pager या editor में खुलता है? ShellCheck warnings किस तरह दिखाई जाती हैं?
    • बिल्कुल सही बात है। README में अभी vet कैसे काम करता है, यह तो है, लेकिन वास्तविक उपयोग अनुभव ठीक से नहीं दिखता। मैं page में demo GIF जोड़ने वाला हूँ। आपके सवाल का जवाब: डिफ़ॉल्ट रूप से यह फ़ाइल को pager में खोलता है (less, या अगर bat installed हो तो बेहतर highlighting वाला pager), और गलती से edit न हो जाए इसलिए editor में नहीं खोलता। अगर ShellCheck कोई समस्या पकड़ता है, तो उसे सीधे terminal में रंगीन तरीके से दिखाता है। फिर यह पूछता है कि review जारी रखना है या नहीं, [y/N] के रूप में। उदाहरण: 
      ==> Running ShellCheck analysis...

In /tmp/tmp.XXXXXX line 7:
echo "Processing file: $filename"
           ^-- SC2086: Double quote to prevent globbing and word splitting.

==> WARNING: ShellCheck found potential issues.
[?] Continue with review despite issues? [y/N]
      अच्छे सुझाव के लिए धन्यवाद
  • यह थोड़ा अफ़सोसजनक है कि यह curl | bash pattern की तरह अपने-आप काम नहीं करता। Windows में जब उपयोगकर्ता कुछ install करने की कोशिश करता है, तो वहाँ फ़ाइल अपने-आप scan करने की सुविधा होती है
  • आइडिया बहुत अच्छा है। ऐसे security tools में सबसे बड़ी चुनौती LLM की non-determinism और code के third-party API को भेजे जाने से जुड़ा privacy risk है। vet के ShellCheck पर निर्भर रहने की यही वजह है। ShellCheck deterministic, rule-based, और पूरी तरह offline चलने वाला linter है। वही input मिलने पर हमेशा वही भरोसेमंद output देता है। और ज़्यादा smart analysis के लिए, आगे चलकर vet में तेज़ और local AI चलाने की दिशा उपयोगी हो सकती है। सोचने लायक अच्छी बात है
  • सच में शानदार आइडिया है। एक अतिरिक्त feature के रूप में shell script की सामग्री LLM को भेजकर security के लिहाज़ से संदिग्ध हिस्से पहचानना भी दिलचस्प तरीका हो सकता है
  • Hi HN, मैं vet का डेवलपर हूँ। मुझे हमेशा curl | bash pattern असहज लगा, और लगा कि ऐसा tool होना चाहिए जो script बदलने पर diff दिखाए, shellcheck चलाए, और उपयोगकर्ता से स्पष्ट अनुमति माँगे। इसलिए vet बनाया। installation में भी वही सिद्धांत लागू किए। install script ज़रूर पढ़ें, यही सिफ़ारिश है। फ़ीडबैक का स्वागत है। repo है https://github.com/vet-run/vet
    • यह देखकर अच्छा लगा कि इस तरह की समस्या पर सोचने वाला मैं अकेला नहीं हूँ। मुझे लगता है यह vulnerability attacks के लिए खुला बिंदु है। आपने nvm का उदाहरण दिया, यह दिलचस्प लगा (मैंने पहले nvm में भी ऐसा ही मुद्दा उठाया था)। लेकिन threat model थोड़ा अस्पष्ट लगता है। अगर कोई SSL tampering attacker इतना सक्षम है कि malicious script दे सके, तो वह असली script द्वारा डाउनलोड की जाने वाली binary को भी malicious रूप में बदल सकता है। Cryptographic hash के ज़रिए verification सबके लिए maintain करना कठिन है, लेकिन अंततः यही सबसे भरोसेमंद तरीका है। 1) remote input लाओ और committed hash से compare करो 2) internet-isolated sandbox में चलाओ 3) unverified hash वाले payload की प्राप्ति रोक दो
    • "script बदलने पर diff दिखाना और shellcheck चलाना" क्यों, यह सवाल है। क्या आपने सोचा है कि shellcheck की भूमिका वास्तव में क्या है, और diff कब उपयोगी होगा? "execution से पहले explicit approval" भी बेकार है अगर बदलाव सिर्फ़ indentation बदलने भर का हो। छोटी shell scripts जल्दी पढ़ी जा सकती हैं, लेकिन बड़े installers कई वैध कारणों से कठिन code style में लिखे जाते हैं। समझ नहीं आता vet किस philosophy की बात कर रहा है। वास्तव में vet का तरीका कुछ हद तक उसी pattern जैसा लगता है जिसका इस्तेमाल attackers malware बाँटने में करते हैं (उदाहरण: wget -qO- https://getvet.sh से डाउनलोड करने पर server text/html लौटा रहा है)। मैं तो उल्टा install.sh को सीधे लाने की सलाह दूँगा। फ़ीडबैक के जवाब में, "ऐसे करके देखें" के तौर पर यह bash tip साझा की गई: 
      check () {
  echo "> $BASH_COMMAND" >&2
  echo -n "Allow? (yes/no) " >&2
  select c in yes no
  do
    if [ "$c" = "yes" ]
    then break
    elif [ "$c" = "no" ]
    then return 1
    fi
  done
}

shopt -s extdebug
trap check DEBUG
      इस तरीके में bash जब भी कुछ execute करने की कोशिश करता है, हर बार अनुमति माँगता है। लंबी scripts में यह झंझट भरा हो सकता है, इसलिए जो commands सुरक्षित लगें उनके लिए whitelist रखी जा सकती है, या remember option के साथ इसे customize किया जा सकता है। sudo के मामले में, malware यह चाल चल सकता है कि पहले किसी innocuous command में sudo चलाकर credentials cache में रख ले, और बाद में बिना किसी warning के sudo command फिर चला दे। इसलिए sudo -k से session cache साफ़ करके unknown program चलाना ज़्यादा सुरक्षित है
    • समस्या पहचानकर उसका समाधान बनाने की कोशिश सराहनीय है, लेकिन ShellCheck का मूल काम virus/vulnerability scan करना नहीं है, इसलिए vet की दिशा बहुत प्रभावी होगी, ऐसा नहीं लगता
    • आइडिया अपने आप में अच्छा है। vet उन developers के लिए उपयोगी होगा जिन्हें source code साफ़-साफ़ दिखता है और जो उसे खुद पढ़ सकते हैं। मेरी skill अभी वहाँ तक नहीं है, इसलिए समझ नहीं आता कि मैं अधिकतर users वाली श्रेणी में हूँ या कम users वाली में