- rsync मेंटेनेंस ऐसी स्थिति में है जहाँ सुरक्षा रिपोर्टों की बाढ़ और AI के इस्तेमाल पर विवाद एक साथ आ गए हैं, जिससे बेहतर टेस्टिंग, code coverage, multi-platform CI, security scanning और defense-in-depth की ज़रूरत बढ़ गई है
- नया Python test suite पुरानी shell script संरचना की जगह लेता है, लेकिन डिज़ाइन और verification plan की ज़िम्मेदारी मेंटेनर ने खुद संभाली; Claude, Codex और Gemini का इस्तेमाल दोहराए जाने वाले कामों में मदद के लिए किया गया
- 3.4.3 रिलीज़ ने सुरक्षा सुधारों को प्राथमिकता दी, लेकिन कुछ वैध पर असामान्य use cases में regression आया जिन्हें पुराने टेस्ट और manual testing पकड़ नहीं पाए थे
- pytest का इस्तेमाल कई दूसरे प्रोजेक्ट्स में किया गया है, लेकिन rsync test suite की कुछ खास ज़रूरतों के लिए यह उपयुक्त नहीं था, इसलिए अलग तरीका डिज़ाइन किया गया; LLMs को सावधानी से इस्तेमाल करना चाहिए, लेकिन उन्हें उपयोगी टूल माना गया
- आगे की दिशा 3.4.4, जो regressions को कुछ हद तक कम करेगी, और 3.5.0, जिसमें बड़े security changes होंगे, के बीच तय की जा रही है; openrsync नए test suite में 98 में से 85 टेस्ट फेल कर रहा है
सुरक्षा रिपोर्टों की बाढ़ और रक्षा मज़बूत करना
- rsync मेंटेनर हाल में कई open source package developers की तरह सुरक्षा रिपोर्टों की बाढ़ का सामना कर रहे हैं; इनमें से कई रिपोर्टें AI-generated हैं, लेकिन कुछ सावधानीपूर्वक और उच्च-स्तरीय manual analysis भी मौजूद हैं
- रिपोर्टों की बढ़ती संख्या के कारण rsync को अब अधिक सख्त test suite, code coverage analysis, ज़्यादा platforms पर CI testing, जानबूझकर security issue scanning और defense-in-depth तकनीकों की ज़रूरत है
- मेंटेनर रिटायर हो चुके हैं और वे और नौकायन करना चाहते हैं, लेकिन ज़रूरी काम की मात्रा के कारण उन्होंने कई AI tools का इस्तेमाल किया और उन्हें इस फैसले पर पछतावा नहीं है
Python test suite और AI-सहायता प्राप्त काम
- पुराना shell script-आधारित rsync test suite Python में फिर से लिखा गया, और इसकी core design और verification plan की ज़िम्मेदारी मेंटेनर ने सीधे खुद निभाई
- Claude का इस्तेमाल दोहराए जाने वाले कामों के लिए किया गया, जबकि Codex और Gemini cross-checking के लिए इस्तेमाल हुए; यह तरीका सिर्फ इतना नहीं था कि “test suite को Python में बदल दो”
- मेंटेनर ने हर हिस्से की खुद समीक्षा की, इसे ठीक बैठाने में बहुत CI समय लगाया, और बाद में CI wait time कम करने के लिए कई local VMs पर अधिकांश टेस्ट चलाने की ओर बढ़े
- commit history में दिखने वाला
co-authored by claude टैग पूरे software engineering काम का सिर्फ एक हिस्सा ही दिखाता है
LLM बहस, pytest का चयन, और 3.4.3 regression
- यह कि LLM कैसे काम करते हैं, इसे जान लेने से वे बेकार टूल नहीं बन जाते; सावधानी ज़रूर चाहिए, लेकिन मौजूदा software engineering और IT security maintenance माहौल में वे उपयोगी हैं
- rsync 3.4.3 जानबूझकर ऐसा रिलीज़ था जो security issues के fixes को प्राथमिकता देता था, और इस प्रक्रिया में कुछ वैध लेकिन असामान्य use cases बदलावों से प्रभावित हुए
- प्रभावित use cases पुराने rsync test suite और manual testing में शामिल नहीं थे, और GitHub repository के issues और PRs के ज़रिए रिपोर्ट हुई regressions को क्रमवार संभाला जा रहा है
- pytest का इस्तेमाल दूसरे प्रोजेक्ट्स में खूब हुआ है, लेकिन rsync test suite में ज़रूरी कुछ काम pytest से बहुत कठिन लगे, इसलिए अलग testing approach डिज़ाइन की गई
अगली रिलीज़ और security testing का विस्तार
- सुरक्षा रिपोर्टें लगातार आ रही हैं, और इस समय कई CVE-संबंधित काम चल रहे हैं
- system development क्षमता और security knowledge वाले दूसरे developers भी जुड़ गए हैं, जिनमें कुछ वे लोग हैं जो हाल के आक्रोश के कारण सामने आए
- अगला विकल्प कुछ regressions को कम करने वाली 3.4.4 और कहीं बड़े बदलावों वाली 3.5.0 के बीच है; 3.5 rsync के security standards को काफ़ी ऊपर ले जाएगी, लेकिन यह बड़े पैमाने के बदलावों वाली रिलीज़ है
- बड़े बदलावों के सेट को तेज़ी से लागू करने के लिए rsync जैसे software के लिए एक comprehensive test suite ज़रूरी था, और नया test suite rewrite उसी ज़रूरत से निकला काम है
- 3.5 रिलीज़ में security-related issues को कवर करने वाले अतिरिक्त tests शामिल होंगे
openrsync तुलना और code review का अनुरोध
- openrsync को किसी खास platform के लिए package करने की दिशा पर प्रतिक्रिया यह है कि नए rsync test suite को openrsync पर लागू करके देखा जा सकता है
- चलाने का उदाहरण निम्न command है
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- openrsync इस समय 98 में से 85 टेस्ट फेल कर रहा है; कई failures उन features की वजह से हैं जो openrsync में मौजूद नहीं हैं, लेकिन फिर भी इसे अच्छा परिणाम नहीं माना गया
- ज़्यादा आक्रोश व्यक्त करने के बजाय, सार्वजनिक रूप से उपलब्ध code की वास्तविक समीक्षा कर रचनात्मक आलोचना करना बेहतर होगा, ऐसा अनुरोध किया गया है
1 टिप्पणियां
Lobste.rs की राय
उद्धरण को देखें तो ऐसा लगता है कि लेखक नौकायन करना चाहता है, फिर भी प्रोजेक्ट maintenance का दबाव महसूस कर रहा है, और उसे लगा कि LLM इस्तेमाल करके वह दोनों काम कर सकता है
रिटायर होकर नौकायन का आनंद लेते हुए bugs ठीक न करना भी ठीक है, और open source project के bugs ठीक न करना भी ठीक है। बस यह बात सार्वजनिक और पारदर्शी रूप से बता दी जाए तो पर्याप्त है। पुराने ढंग से कहें तो “patches welcome” काफ़ी है। खासकर तब, जब भरपूर संसाधन वाली कंपनियाँ उस project पर निर्भर हों
अच्छा होता अगर और ज़्यादा maintainers और developers open source maintenance में LLM की “मदद” लेने के दबाव के बिना रिटायरमेंट और नौकायन का आनंद ले पाते। फिर भी अगर वह rsync project में LLM का प्रयोग करना चाहता है, तो वह उसका चुनाव है। दूसरे लोग, जिनमें मैं भी शामिल हूँ, सहमत न हों तब भी यही बात लागू होती है
वजह चाहे जो भी हो, open source developers को परेशान करने वाले लोग शायद यह भूल जाते हैं कि मुफ्त open source software कोई product नहीं बल्कि एक उपहार है
बाहर से सिर्फ़ देख रहे लोगों को पसंद न आए तो वे fork कर सकते हैं। Andrew उस project में अपनी पसंद के तरीके से काम कर सकता है, और हमारी टिप्पणियाँ व राय कोई अनिवार्य चीज़ नहीं हैं
उम्मीद की बात यह है कि लंबे समय में rsync maintenance संभालने वाला कोई और भी सामने आ सकता है। Tridge पहले भी एक नए maintainer को जिम्मेदारी सौंप चुका है
मैंने OpenJS Foundation की उस प्रस्तुति पर LWN में लिखा था जिसमें बताया गया था कि कैसे उसने कुछ projects को funding और transition support देकर single-maintainer व्यवस्था से team maintenance की ओर बढ़ने में मदद की, और वह आज प्रकाशित होने वाला है। rsync जैसे projects को इस तरह के support की कहीं ज़्यादा ज़रूरत है
security issues में दबाव बहुत होता है, उन पर नज़रें ज़्यादा रहती हैं, और वे अक्सर उस मूल हिस्से से अलग होते हैं जिसमें maintainer की सच में रुचि होती है
maintenance में बहुत ज़िम्मेदारी होती है और सब कुछ आनंददायक नहीं होता, लेकिन जब free open source maintainers ऐसे काम भी करते हैं तो उसके लिए आभार महसूस होता है। लगता है ऐसे लोग बहुत ज़्यादा नहीं हैं
हो सकता है कि LLM की मदद के बिना किसी खास लक्ष्य तक पहुँचने की लागत बहुत ज़्यादा हो, जबकि LLM की मदद से वही लागत उचित हो जाए
सकारात्मक रूप से देखें तो इसका मतलब है कि healthy work-life balance बनाए रखने की कोशिश कर रहा कोई open source maintainer LLM से अपना workload घटाकर अपने लक्ष्य ज़्यादा आसानी से हासिल कर सकता है
चुना गया उद्धरण सिर्फ़ शुरुआती हिस्से का एक अंश है, और यह लेख साफ़ तौर पर सोच-समझकर और बारीक संदर्भ के साथ लिखा गया है, न कि सिर्फ़ बुनियादी open source maintenance पर
और भी अजीब बात यह है कि उद्धरण से ठीक पहले का संदर्भ छोड़ दिया गया। वहाँ कहा गया था कि reports तेज़ी से बढ़ने के कारण rsync की रक्षा-रेखा काफ़ी ऊँची करनी पड़ी, और कहीं अधिक thorough test suite, code coverage analysis, ज़्यादा platforms पर CI testing, security issues की खोज, और defense-in-depth तकनीकें जोड़ने की ज़रूरत पड़ी
इस मामले में लेखक रिटायर हो चुका है, लेकिन दूसरे open source projects में नौकरी या अन्य काम करने वाले लोग भी ऐसी ही काम की बढ़ोतरी में फँस सकते हैं। सच कहूँ तो इस comment को इतना ज़्यादा upvote मिलना हैरान करता है, और यह सद्भावना से लिखा हुआ नहीं लगता। कम से कम सिर्फ़ शीर्षक देखकर दौड़कर की गई टिप्पणी से मुश्किल से ही बेहतर, काफ़ी लापरवाह प्रतिक्रिया जैसा लगता है
मेरा इरादा harassment का बचाव या समर्थन करने का नहीं है, लेकिन इस defense में वजह गायब है
बात यह बताई गई है कि लेखक ने vibe coding के लिए design किया, बने हुए code की समीक्षा की, code और chatbot दोनों में निपुण था, vibe coding को सावधानी से संभाला, और security व feature regressions के बीच संतुलन बनाने की कोशिश की। यह सुनने में ठीक लगता है, लेकिन वास्तव में regressions हुए, और लेखक उनकी वजह तक भी नहीं पहुँच पाया
उसने कहा कि “AI tools साधारण कामों में अच्छे होते हैं, इसलिए मैंने ऐसे काम उन्हें दिए”, लेकिन ऐसा नहीं है। chatbots वास्तव में लिखने में कमज़ोर हैं। यही मूल बात है, और लगता है कि लेखक इसे पहचान भी नहीं पा रहा
अच्छा होगा अगर यह पता चल सके कि हाल में संख्या सचमुच बढ़ी है या नहीं। regressions अपने-आप में कोई दुर्लभ बात नहीं हैं, और हो सकता है लोग Andrew पर हमला करने का बहाना ढूँढ़ रहे हों
लेखक ने माना कि rsync 3.4.3 release में कुछ use cases में regressions थे, और समझाया कि उस release में जानबूझकर security issue fixes को ज़्यादा वज़न दिया गया था, और कुछ वैध लेकिन असामान्य use cases इस बदलाव की चपेट में आ गए
वे मामले मौजूदा rsync test suite या उसके खुद किए गए manual tests में शामिल नहीं थे, और उसने कहा कि वह अभी regressions को संभाल रहा है तथा GitHub repository में issue या PR के रूप में रिपोर्ट करने वालों का धन्यवाद करता है। उसने यह भी कहा कि अगर आपका use case प्रभावित हुआ है तो वह माफ़ी चाहता है, और अगर आप security risk उठाने को तैयार हैं तो पुराना release इस्तेमाल कर सकते हैं
“पिछले कुछ महीनों में software engineering की दुनिया नाटकीय रूप से बदल गई है”, “IT security और report flood के बीच software maintain करने की दुनिया पिछले कुछ हफ्तों में पूरी तरह बदल गई है” जैसी बातें मैं पिछले लगभग आधे साल से बार-बार सुन रहा हूँ, और अब थक चुका हूँ
अगर इस report flood की वजह LLM है, तो उसका हल भी LLM में ढूँढना अविश्वसनीय रूप से गलत दिशा जैसा लगता है
फिर भी, अभी किसी popular चीज़ को maintain करना भयावह होगा—यह बात तुरंत मान सकता हूँ। शायद उसके लिए सीमित computing time को और निचोड़ने के बजाय पीछे हटकर सचमुच की retirement का आनंद लेना ही बेहतर हो
अगर यह सचमुच उतना उपयोगी tool है जितना लोग दावा करते हैं, उसका उपयोग अपने आप बोलना चाहिए
फिर भी, Tridgell जैसे व्यक्ति की बात सुनने लायक है। और security reports की “बाढ़” को गंभीरता से लेना चाहिए। किसने या किस चीज़ ने उसे ढूँढा, इससे फर्क नहीं पड़ता; security issue, security issue ही होता है। इसलिए यह लेख रोज़ दिखने वाले उबाऊ हमलों से अलग महसूस होता है
आखिरकार हम LLM पर बढ़ती निर्भरता वाली downward spiral में फँस सकते हैं
यह गलत दिशा क्यों है? क्या आपका मतलब है कि किसी के पास भी LLM न हो तो बेहतर होगा?
LLM-assisted development का नतीजा ज़रूरी नहीं कि हमेशा “कचरा output” ही हो
यह लेख लिखा गया और साझा किया गया, इसके लिए आभारी हूँ। खासकर यह बात ध्यान खींचती है कि वह 3.4.4 से कुछ regressions कम करने और कहीं बड़े बदलावों वाले 3.5.0 पर जाने के बीच सोच रहा है
अगर लेखक यह पढ़ रहा हो, तो यहाँ 3.4.4 ही सही रास्ता लगता है। जब पिछली release में regression रहा हो, तब सीधे बड़े 3.5.0 पर जाना बहुत लोगों को लापरवाह लगेगा। अगर लोगों को फर्क अधिक आसानी से समझाया जाए, तो चिंता कम होगी
जहाँ उसने कहा कि नए test suite की मुख्य संरचना पर master में खुले तौर पर पहले काम करना चाहता था, लेकिन उससे गुस्सा भड़क गया, इसलिए शायद वह बुरा विचार था—उस हिस्से पर, मुझे नहीं लगता कि transparency कम करने से धारणा या प्रतिक्रिया बेहतर होगी। ज़्यादा से ज़्यादा, इससे बड़ा backlash बस बाद के लिए टलेगा
openrsync पर नया rsync test suite चलाने को कहना उचित नहीं है। samba rsync protocol 32 पर है, जबकि openrsync protocol 27 पर है, और वह feature completeness का दावा भी नहीं करता
Medium और Cloudflare—यह तो भयानक संयोजन है, जिन्हें साथ नहीं आना चाहिए
https://archive.is/qbyVA
open source maintenance ऐसा काम है जिसके लिए शायद ही कभी सराहना मिलती है। Tridge test suite के technical debt को ठीक करने और LLM द्वारा पकड़ी गई CVE की बाढ़ का जिम्मेदारी से जवाब देने की कोशिश कर रहा था, लेकिन लगता है Hyrum's Law ने उसे आ घेरा। 3.4.4 की योजना फिलहाल कम बुरा विकल्प लगती है, और शायद अंततः उसी पर आगे बढ़ना चाहिए
इस मुद्दे पर मेरी राय दोनों तरफ जाती है। एक तरफ, मुझे लगता है कि security तभी सुनिश्चित की जा सकती है जब इंसान खुद code लिखे
क्योंकि code लिखते समय आप उसी code के बारे में सोचते रहते हैं और errors को जल्दी पकड़ लेते हैं। मैं code review करने की तुलना में खुद लिखते समय कहीं बेहतर लिखता हूँ। review के दौरान बहुत सी चीज़ें बस निकल जाती हैं, क्योंकि मैंने हर line पर सावधानी से विचार नहीं किया होता
दूसरी तरफ, harassment स्वीकार्य नहीं है — यह बुनियादी तथ्य अलग है — लेकिन Andrew को अपने free time में अपने project को अपनी मर्ज़ी से चलाने का अधिकार है। अगर वह LLM इस्तेमाल करना चाहता है, तो मैं सहमत नहीं हूँ, लेकिन वह उसका project है और यह उसका विवेकाधिकार है। अगर मुझे यह पसंद नहीं है, तो मुझे अपने backup को restic या borgbackup पर ले जाना चाहिए, या rsync को fork करना चाहिए
स्पष्ट कर दूँ कि मैं vibe coding के अपने-आप में खिलाफ नहीं हूँ। कंपनी में हमें इसे आधा-ज़बरदस्ती इस्तेमाल कराया जा रहा है, और आजकल मेरे काम का बड़ा हिस्सा जो उबाऊ और नया न लगने वाला glue code लिखना है, उसके लिए यह ठीक-ठाक है। बस मैं इसे अपने free time में इस्तेमाल नहीं करता
rsyncकोई बहुत उपयुक्त समाधान भी नहीं हैक्योंकि यह file content के corrupt हो जाने पर restore करने में मदद नहीं करता। restic जैसे tools इससे कहीं बेहतर हैं, और file के पुराने versions भी संभालकर रखते हैं ताकि ऐसे मामलों को संभाला जा सके। वे deletions को भी track करते हैं, इसलिए यह भी पता चलता है कि कौन-सी files अब relevant नहीं रहीं
मुझे application security का अनुभव है, मैं कुछ exploits चुन सकता हूँ, और review में भी उन्हें पकड़ सकता हूँ। लेकिन मैं मौजूदा top LLMs जितना अच्छा नहीं हूँ, जो “और pathological cases ढूँढो” जैसी iteration चला सकते हैं
ऐसे popular software में मैंने अपने code, इस्तेमाल की गई libraries, और alternative implementations की issues बिना बहुत मेहनत के ढूँढ ली हैं। इंसान जितना समय और जिद लगा सकता है, उसकी तुलना ही नहीं होती
पूरे organization में issues को prevent, detect, और respond करने के लिए security software व्यापक रूप से तैनात होता है। हर क्षेत्र में हमेशा gaps होते हैं और हमेशा कुछ न कुछ काम बाकी होता है। organization यह जानते हुए भी कि वह perfect नहीं हो सकता, security posture में सुधार को, बिल्कुल सुधार न होने से बेहतर मान सकता है। LLM जो trade-off देता है, वह भी उसी का हिस्सा है
यह trade-off context पर निर्भर करता है, लेकिन बहुत कम ही ऐसा होता है कि निष्कर्ष “सारा code हाथ से ही लिखा जाना चाहिए” निकले
यह rsync जैसे servers पर भी लागू होता है। जैसा लेखक कहता है, इसे और robust और resilient बनाने के लिए बड़े refactoring की ज़रूरत हो सकती है। अगर LLM की मदद से privilege separation की दिशा में refactor करके trusted code base को छोटा किया जा सकता है, तो उसके दायरे के बाहर के कुछ bugs स्वीकार किए जा सकते हैं
मुझे rsync का specific context नहीं पता, लेकिन मेरा मानना है कि ऐसे projects के सीमित resources के भीतर लेखक project और users के लिए सबसे अच्छा निर्णय लेने की कोशिश कर रहा है
बदले में rclone में parallelism है, इसलिए यह उपलब्ध network bandwidth का कहीं बेहतर इस्तेमाल करता है
इससे इस बात की एक ऊपरी सीमा मिलती है कि समस्याएँ कितनी गंभीर हो सकती हैं
निचली सीमा वे bugs और vulnerabilities हैं जिन्हें मैं ढूँढ सकता हूँ, कोई दूसरा ढूँढ सकता है, या कुछ और — जैसे LLM — ढूँढ सकता है
ऐसे क्षेत्र में जहाँ कोई इंसान अपने ही लिखे C code की, जैसे rsync की, review कर रहा हो, उसे अच्छी स्थिति कहना मुश्किल है। मेरा Andrew को दोष देने का बिल्कुल इरादा नहीं है
मैं उस retired maintainer के प्रति सहानुभूति रखता हूँ जो sailing करना चाहता है, लेकिन मुझे नहीं लगता कि वह context मूल रूप से कुछ बदलता है
Tridgell हम पर किसी भी काम का कर्ज़दार नहीं है, और उसे retire होकर sailing करने की पूरी आज़ादी है। अगर वह यही करना चाहता है, तो मैं उसके लिए शुभकामनाएँ देता हूँ। मैं उसकी जिम्मेदारी की भावना को समझ सकता हूँ, लेकिन अगर मैंने पंक्तियों के बीच सही पढ़ा है, तो वह इसे कुछ हद तक बोझ की तरह महसूस करता है
लेकिन rsync critical software है, और जो व्यक्ति इसका maintenance करना चाहता है, उसे एक निश्चित quality bar बनाए रखना चाहिए। अगर maintainer का काम उस bar तक नहीं पहुँचता, तो वह एक गलती है। इसका मतलब यह नहीं कि उसे harass किया जाए। किसी चीज़ को गलती कहना यह नहीं कहता कि वह व्यक्ति बुरा है या उसके प्रति सहानुभूति नहीं रखी जा सकती
इसलिए सवाल यह है कि AI coding tools द्वारा किया गया काम उस मानक पर खरा उतरता है या नहीं। मानक roughly यह है: “क्या इस quality के साथ काम हो जाना, काम न होने से बेहतर है?” अगर यह software को बेहतर बनाता है, तो जारी रहना चाहिए; अगर यह उसे बदतर बनाता है, तो रुक जाना चाहिए। मैं यह दावा नहीं करता कि यह कोई चतुर परिभाषा है, लेकिन मुझे यह सही परिभाषा लगती है
हमें Tridgell से अतिरिक्त काम की माँग करने का अधिकार नहीं है, लेकिन अगर यह सच है, तो यह कहने की गुंजाइश है कि “यह users की स्थिति को बदतर बनाता है”
सच कहूँ तो इस काम का मूल्यांकन कैसे किया जाए, इस पर मेरी राय पूरी तरह से तय नहीं है। regression हुआ था, और Tridgell ने उसे edge case बताया, लेकिन और context के बिना मैं नहीं जानता कि उस edge-case regression के प्रभाव की तुलना संभावित security issue fix की value से कैसे की जाए
कुछ लोगों को “WITHOUT ANY WARRANTY” याद आ सकता है, लेकिन वह clause यहाँ अप्रासंगिक है। वह legal liability का disclaimer है, craftsmanship पर गर्व या अपना सर्वोत्तम करने की गैर-कानूनी अपेक्षा का disclaimer नहीं। यह comment भी “WITHOUT ANY WARRANTY” के साथ दिया जा रहा है, लेकिन अगर मैं गलती करूँ, तो मेरी आलोचना होना स्वाभाविक है
लेखक ने इसे critical software नहीं बनाया। अगर आप या कोई और इसे इस्तेमाल करता है, तो जिम्मेदारी user की है। अगर software उम्मीद के मुताबिक काम नहीं करता, तो उसे fork कीजिए या उसका alternative अपनाइए। जो नहीं किया जा सकता, वह यह है कि उस व्यक्ति को आपकी मर्ज़ी के हिसाब से चलने के लिए मजबूर किया जाए
जिन लोगों ने original regression report मिस कर दी थी, उनके लिए context: https://github.com/RsyncProject/rsync/issues/929
issue report mastodon post के screenshot पर आधारित है, और उसके बाद करीब 300 से ज़्यादा बहस वाले comments आ चुके हैं
समझाने की ज़रूरत नहीं, बस जैसे करते आ रहे थे वैसे ही करते रहो। जिन्हें नापसंद है, वे नापसंद करते ही रहेंगे
लोगों ने assembly लिखना बंद किया तभी से वे नापसंद करने लगे थे, और आगे भी नहीं रुकेंगे