मरता हुआ सॉफ्टवेयर: relayd(8) और httpd(8) का लगातार विकास

 (rsadowski.de)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा OpenBSD डेवलपर्स की दिलचस्पी घटने से ठहर गया relayd(8) और httpd(8) डेवलपमेंट, वास्तविक संचालन जरूरतों वाले contributors की भागीदारी से फिर सक्रिय हुआ
  • LLM के coding ज्ञान की जगह लेने के दौर में सीधे C सीखकर चुनौती लेने के फैसले से शुरुआत हुई, और relayd(8) के handmade imsg सिस्टम को modernize किया गया
  • 2024~2026 के tech@ mailing list में पड़े unmerged patches और मौजूदा GitHub mirror के पुराने issues का अधिकांश निपटारा किया गया, और नए contributors के लिए Git mirror और README भी तैयार किए गए
  • relayd(8) ने सुरक्षित imsg API और TLS·request parsing security को मजबूत किया और reload collision को ठीक किया; httpd(8) ने request smuggling defense, custom headers, static file cache control आदि जोड़े
  • दोनों daemons की security·stability·scalability साथ-साथ बेहतर हुई, लेकिन काम के दौरान backlog भी बढ़ा, इसलिए ideas और feedback लगातार लिए जा रहे हैं

दिलचस्पी खो चुके project को फिर से जीवित करने की पृष्ठभूमि

  • OpenBSD 7.8 के प्रमुख बदलावों में जैसा बताया गया था, relayd(8) और httpd(8) का development ठहरा हुआ था
    • कई contributors ने tech@ mailing list पर patches भेजे, लेकिन repository में बहुत कम merge हुए
    • मुख्य कारण यह था कि मौजूदा OpenBSD developers ने इन दोनों daemons में अब रुचि नहीं रखी
  • kirill@ के साथ दोनों daemons को नियमित रूप से इस्तेमाल करने और वास्तविक use cases संभालने के अनुभव के आधार पर सक्रिय development शुरू किया गया
    • जटिल httpd(8)·relayd(8) configurations के साथ OpenBSD customers को support करने की practical demand भी सीधा प्रेरक कारण बनी

LLM युग में C पर लौटने की वजह

  • सबसे बड़ा कारण LLM का उदय था
    • पहले आधुनिक C++ code पेशेवर रूप से लिखा जाता था, लेकिन बाद में solution architecture, platform engineering और team building की ओर जाने से वास्तविक code लगभग लिखना बंद हो गया
    • काम मुख्यतः declarative YAML लिखने और OpenBSD ports(7) के लिए code पढ़ने व porting करने तक सीमित रह गया
  • “coding solved है” जैसे दावों के उलट, यह माना गया कि जब ज्ञान बाहर outsource हो रहा हो, तब उस ज्ञान को खुद हासिल करना और भी महत्वपूर्ण है
  • C++ और Rust कुछ कठिन फैसलों में मदद कर देते हैं, लेकिन C ऐसा नहीं करता — इसी को challenge मानकर relayd(8) और httpd(8) में contribute करने का निर्णय लिया गया

motivation से ज्यादा discipline के सहारे योगदान जारी रहा

  • open source contribution कुछ ही हफ्तों में निराशा पर खत्म हो सकता है, लेकिन शुरुआती तकलीफदेह चरण के बाद लगातार काम कर पाने की स्थिति तक पहुंचा गया
  • शुरुआत में codebase को passive तरीके से पढ़ते हुए कई जगह निराशा हुई
    • कम comments, कुछ खराब design, और जटिल रूप से उलझा हुआ code इसके कारण थे; यह C code की प्रकृति थी या अपने अनुभव की कमी, यह अभी साफ नहीं
  • OpenBSD daemon maintainers से चर्चा के बाद हाथ से बनाए गए imsg message system को modernize करने का फैसला किया गया
    • पहले relayd(8) पर focus किया गया, फिर scope को httpd(8) तक बढ़ाया गया
    • modernization को codebase समझने के साधन के रूप में इस्तेमाल किया गया

unmerged patches और पुराने issues का निपटारा

  • 2024~2026 की tech@ mailing list archives की समीक्षा कर pending patches और issues इकट्ठे किए गए, और माना गया कि उनमें से अधिकांश को handle कर लिया गया है
  • इन दोनों daemons को मूल रूप से Reyk Floeter ने develop किया था, जो अब OpenBSD से retired हैं
  • Reyk द्वारा maintain किए गए relayd GitHub mirror के पुराने issues भी review किए गए
    • सभी issues या तो close हो सकते हैं या fix किए जा सकते हैं, और कुछ अब valid नहीं रहे

नए contributors के लिए Git mirror

  • मौजूदा GitHub mirror से प्रेरणा लेकर, नए और युवा contributors की entry आसान करने और OpenBSD mailing list से बाहर की communities से भी संपर्क बनाने के लिए अलग mirror बनाया गया
  • CVS tree को Git mirror के रूप में इस्तेमाल किया जाता है; development पहले Gothub instance पर किया जाता है और फिर बाकी repositories में sync किया जाता है
  • httpd(8) पर भी यही तरीका लागू किया गया और जरूरी जानकारी के साथ विस्तृत README.md लिखा गया

relayd(8) का modernization और code quality

  • imsg system को अधिक सुरक्षित imsg_get_data, imsg_get_type, imsgbuf_get accessors पर migrate किया गया
  • imsg payload पढ़ने की पूरी प्रक्रिया में उचित error handling जोड़ी गई
  • bgpd के साथ consistency रखने के लिए logging और comments को standardize किया गया
  • HTTP start line handling को dedicated function में अलग कर code organization बेहतर किया गया
  • knfmt format लागू किया गया

relayd(8) में security enhancements

  • default TLS cipher suite को HIGH:!aNULL से secure में बदला गया
  • CA privilege separation (privsep) engine में ECDSA support जोड़ा गया
  • duplicate Content-Length headers को HTTP 400 response के साथ reject किया गया
  • RFC 9112 5.2 के अनुसार parser differences रोकने के लिए obs-fold headers को allow नहीं किया गया
  • process ID की जांच की गई और IMSG_CTL_PROCFD को parent process तक सीमित किया गया
  • sensitive password data हटाने के लिए explicit_bzero का इस्तेमाल किया गया

relayd(8) के bugs और stability improvements

  • crash का कारण बन रही reload race condition को ठीक किया गया
  • X509_dup, config_purge, tls_cfg से जुड़े कई memory leaks हटाए गए
  • NULL checks और bounds checks ठीक किए गए
  • OpenSSL failures के लिए उचित error handling जोड़ी गई
  • TLS failure पर OpenSSL error queue खाली करने के लिए बदलाव किया गया

relayd(8) में जोड़ी गई capabilities

  • MKCALENDAR HTTP method support किया गया
  • कई listeners पर TLS इस्तेमाल करना संभव हुआ
  • name resolution वाली कई addresses support की गईं
  • certificates, keys और OCSP staple के paths explicit रूप से set किए जा सकते हैं
  • HTTP health check requests में User-Agent set किया गया
  • body-less HTTP responses को सही तरीके से handle किया गया

httpd(8) का modernization और code quality

  • proc.c को नए imsg API पर migrate कर relayd(8) के साथ consistency रखी गई
  • भविष्य में configuration options को आसानी से expand करने के लिए token order बदला गया
  • bgpd के साथ consistency रखने के लिए logging को standardize किया गया
  • duplicate code और empty functions हटाए गए
  • knfmt format लागू किया गया
  • built-in features handling को dedicated function में अलग किया गया

httpd(8) में security enhancements

  • default TLS cipher suite को compat से secure में बदला गया
  • request smuggling attacks रोकने के लिए CL.TE request framing reject की गई
  • RFC 9112 5.2 के अनुसार obs-fold headers पर HTTP 400 से response दिया गया
  • Content-Length और Transfer-Encoding headers साथ मौजूद हों तो इसे error माना गया
  • अतिरिक्त protection के लिए boot पर random relinking किया गया
  • process ID की जांच की गई और IMSG_CTL_PROCFD को parent process तक सीमित किया गया
  • response में server identification छिपाने के लिए no banner option जोड़ा गया

httpd(8) के bugs और stability improvements

  • HTTP request की suffix range handling ठीक की गई
  • server_http_time() को GMT time सही तरह से output करने के लिए fix किया गया
  • manual specification के अनुसार timegm(3) की errors check की गईं
  • chunked transfer-encoding इस्तेमाल करने वाली uploads की समस्या हल की गई
  • location के fcgiparams को दो बार भेजे जाने से रोका गया
  • dispatch_parent में उचित error handling जोड़ी गई
  • interrupted responses को bufferevent के जरिए सही तरीके से flush करने के लिए बदलाव किया गया
  • scan-build द्वारा पाए गए unnecessary stores हटाए गए
  • data copy करने से पहले return_uri_len को validate किया गया

httpd(8) की नई capabilities और बाकी काम

  • custom HTTP headers support किए गए
  • बेहतर configuration inheritance के लिए location में gzip-static inherit किया गया
  • अधिक flag options समायोजित करने के लिए server flags को 64-bit integer में expand किया गया
  • static files के लिए cache control जोड़ा गया
  • काम आगे बढ़ने के साथ backlog बढ़ा है, और future development के लिए ideas और feedback लगातार लिए जा रहे हैं

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की राय

  • कस्टम HTTP हेडर का सपोर्ट देखकर अच्छा लगा। पहले यह फीचर नहीं था, इसलिए साधारण कामों के लिए भी httpd इस्तेमाल नहीं कर पाता था, अब सपोर्ट मिलना अच्छी बात है

  • relayd(8) और httpd(8) का डेवलपमेंट ठहर गया था, और कई contributors ने tech@ mailing list पर patches भेजे थे, लेकिन वे repository में लगभग शामिल नहीं हुए। लगता है मुख्य वजह यह थी कि मौजूदा OpenBSD developers की इन daemons में अब दिलचस्पी नहीं रही थी। मेंटेनेंस संभालने के लिए धन्यवाद

  • मैं इन दोनों software का नियमित रूप से उपयोग करता हूँ, इसलिए इन्हें फिर से ठीक से maintain होते देख खुशी हुई। डेवलपमेंट ठहरा हुआ था, यह मुझे बिल्कुल पता नहीं था
    शायद सरल software structure की वजह से बड़े team के बिना भी डेवलपमेंट दोबारा शुरू करके इतने सारे features और fixes शामिल किए जा सके

  • software के नाम के बाद लगे नंबर मुझे काफ़ी समय तक भ्रमित करते रहे, लेकिन बाद में पता चला कि वे manual section numbers हैं
    1 executable programs·shell commands, 2 system calls, 3 library calls, 4 special files, 5 file formats·conventions, 6 games, 7 miscellaneous, 8 system administration commands, और non-standard 9 kernel routines को दर्शाता है

    • man 1 man या छोटा करके man man चलाकर man(1) देख सकते हैं। खास तौर पर SEE ALSO में आने वाले अलग-अलग intro pages उपयोगी हैं

  • सोच रहा हूँ कि क्या ये सुधार OpenBSD 8.0 में शामिल होंगे

  • समझ नहीं आ रहा कि लिंक मूल रूप से पढ़ने योग्य बनाए गए थे या नहीं। Android के Firefox में यह इस तरह दिखता है
    https://imgur.com/a/oTimS9R