magic-wormhole: ایک بار کے کوڈ کے ساتھ محفوظ فائل ٹرانسفر

18 فروری، 2026 • 6 min read

السلام علیکم,

آج میں ایک چھوٹے سے CLI ٹول کے بارے میں بتانا چاہتا ہوں جس کی طرف میں سپورٹ اور انسیڈنٹ کی صورتحال میں بار بار واپس آتا ہوں: magic-wormhole۔ یہ ایک ایسا مسئلہ حل کرتا ہے جو عام کمپنیوں میں کسی بھی “enterprise” کہانی سے زیادہ عام ہے: آپ کو کسی کو ایک فائل (یا فولڈر) اسی وقت بھیجنا ہوتا ہے، مگر ای میل کی حد کم ہے، کلاؤڈ لنک پالیسی یا قانونی لحاظ سے حساس ہو سکتا ہے، اور “بس تھوڑی دیر کے لیے ایک پورٹ کھول دیں” آپشن نہیں ہوتا۔

جمعہ، 16:47۔ تقریباً 60 ملازمین والی ایک کمپنی میں فوری مسئلہ ہے: مرکزی فائل سرور سست ہے، یوزرز ٹائم آؤٹس کی شکایت کر رہے ہیں، اور بیرونی IT پرووائیڈر لاگز اور ایک چھوٹے سے کنفیگ ایکسپورٹ کے ساتھ سپورٹ بنڈل مانگ رہا ہے۔ بنڈل تقریباً 900 MB ہے۔ ای میل اسے بلاک کر دیتی ہے، SharePoint کمپلائنس کی وجہ سے منع ہے، اور کوئی ad-hoc FTP کھڑا کرنا 2026 میں ایسی مصیبت ہے جو آپ خود نہیں بنانا چاہتے۔

یہی وہ جگہ ہے جہاں magic-wormhole کام آتا ہے: ایک بار کا کوڈ شیئر کریں، فائل اینڈ ٹو اینڈ انکرپٹڈ ٹرانسفر کریں، بس۔

magic-wormhole کیا ہے؟

magic-wormhole دو کمپیوٹرز کے درمیان ad-hoc فائل ٹرانسفر کے لیے ایک ہلکا ٹول ہے۔ ٹرک “wormhole code” ہے (مثلاً 7-coral-lion): دونوں طرف ایک ہی کوڈ انٹر کریں اور اس سے اینڈ ٹو اینڈ انکرپٹڈ کنکشن بن جاتا ہے۔

اہم بات یہ ہے کہ magic-wormhole کو کیا نہیں چاہیے:

کوئی اکاؤنٹ نہیں
کوئی لاگ اِن پورٹل نہیں
کوئی “کہیں اپلوڈ کریں اور لنک بھیج دیں” نہیں
inbound firewall رولز نہیں

دونوں سائیڈز پر بس wormhole انسٹال ہونا چاہیے اور آؤٹ باؤنڈ انٹرنیٹ دستیاب ہونا چاہیے۔ عملی طور پر: اگر HTTP(S) آؤٹ باؤنڈ چلتا ہے تو عموماً magic-wormhole بھی چل جاتا ہے۔

SMB کی ایک حقیقی مثال

جمعہ والے کیس میں عملی فلو عموماً یوں ہوتا ہے:

سپورٹ بنڈل تیار کریں (لاگز، ایکسپورٹ، چند اسکرین شاٹس)۔
اختیاری: ایک hash نکالیں تاکہ بعد میں کنفرم ہو سکے کہ بالکل یہی فائل پہنچی ہے۔
بنڈل magic-wormhole سے بھیج دیں۔
کوڈ دوسرے چینل سے شیئر کریں (فون کال، الگ چیٹ، یا کوڈ پڑھ کر سنانا)۔

سینڈر سائیڈ پر:

tar -czf support-bundle.tgz ./logs ./config-export
sha256sum support-bundle.tgz
wormhole send support-bundle.tgz

magic-wormhole کوڈ دکھا دے گا۔ رسیور یہ چلائے:

wormhole receive

کوڈ انٹر کریں، ڈاؤن لوڈ شروع ہو جائے گا، پھر hashes ملا لیں۔ حقیقی دنیا میں “فوری” مگر “پھر بھی درست” والا یہ کمبی نیشن بہت سی چھوٹی اور درمیانی کمپنیوں کے لیے انتہائی کارآمد ہے۔

میں اسے پریکٹس میں کیسے استعمال کرتا ہوں

A سے B تک فائل بھیجنا

سینڈر:

wormhole send /path/to/file.zip

ریسیور:

wormhole receive

فائل موجودہ ڈائریکٹری میں آ جائے گی۔ میں اکثر ایک چھوٹا سا فولڈر بنا لیتا ہوں تاکہ Downloads اور Desktop کے بیچ میں کچھ گم نہ ہو:

mkdir -p ~/wormhole-recv && cd ~/wormhole-recv
wormhole receive

ڈائریکٹریز بھیجنا

اگر پورا فولڈر بھیجنا ہو:

wormhole send --dir ./support-bundle/

بیک اینڈ پر کیا ہوتا ہے؟ (مختصر اور بغیر مارکیٹنگ)

اندرونی طور پر magic-wormhole تین کام کرتا ہے جو ورنہ آپ کو خود بنانے پڑتے: peers کو ملاتا ہے، keys کو محفوظ طریقے سے طے کرتا ہے، اور ڈیٹا کو قابلِ اعتماد طریقے سے ٹرانسفر کرتا ہے، چاہے NAT یا firewall تنگ کریں۔

مرحلہ	کیا ہوتا ہے	فائدہ
1. کوڈ	سینڈر ایک مختصر ون ٹائم کوڈ بناتا ہے۔	اسی ٹرانسفر کے لیے shared secret۔
2. Rendezvous	دونوں کلائنٹس ایک rendezvous سرور سے جڑتے ہیں (ڈیفالٹ: پبلک “mailbox”)۔	inbound ports کھولے بغیر peer مل جاتا ہے۔
3. PAKE	کوڈ سے SPAKE2 (PAKE) کے ذریعے مشترکہ key derive ہوتی ہے۔	E2E key بغیر کلاسک key management کے۔
4. Data path	پہلے direct کنکشن کی کوشش، پھر ضرورت ہو تو relay/transit۔	NAT کے پیچھے بھی کام کر جاتا ہے۔
5. E2E transfer	ڈیٹا end-to-end انکرپٹ اور integrity-protected ہوتا ہے۔	relay کو صرف ciphertext نظر آتا ہے۔

اہم نکتہ: rendezvous/relay انفراسٹرکچر ہے، مگر یہ وہ جگہ نہیں جہاں آپ کا ڈیٹا plaintext میں موجود ہوتا ہو۔

سیکیورٹی: طاقتیں، حدود، اور چند اصول

magic-wormhole کی اچھی بات یہ ہے کہ اس کا سیکیورٹی ماڈل کافی “سیدھا” ہے: encryption end-to-end ہے، مگر identity خود بخود نہیں ملتی۔

آپ کو کیا ملتا ہے

End-to-end encryption: content سینڈر اور رسیور کے بیچ محفوظ رہتا ہے، چاہے relay استعمال ہو۔
Short-lived access: کوڈ ایک ٹرانسفر کے لیے ہے، لمبی مدت کا پاس ورڈ نہیں۔
کم attack surface: کوئی سرور harden نہیں کرنا، کوئی user management نہیں، کوئی web UI نہیں۔

کہاں احتیاط ضروری ہے

کوڈ ہی پاس ورڈ ہے۔ جس کے پاس کوڈ ہے وہی “peer” ہے۔ اگر کوڈ اوپن ٹکٹ میں چلا جائے تو مسئلہ ہے۔
ڈیفالٹ میں audit نہیں۔ کچھ کمپنیوں کے لیے یہ فائدہ ہے، کچھ کے لیے deal-breaker۔ اگر DLP، approvals اور traceability چاہیے تو آفیشل چینل استعمال کریں۔
Endpoints ہی حقیقت ہیں۔ اگر سینڈر compromised ہے تو کچھ بھی بھیج سکتا ہے۔ اگر رسیور compromised ہے تو فائل وصول ہوتے ہی risk میں ہے۔

عملی اصول (جو واقعی مدد کرتے ہیں)

کوڈ اسی چینل میں نہ بھیجیں جہاں ٹکٹ لنک یا فائل کا context ہو۔ بہتر: فون کال یا الگ پرائیویٹ چیٹ۔
مان کر چلیں کہ لاگز میں tokens، hostnames یا پرسنل ڈیٹا ہو سکتا ہے۔ صرف ضروری چیزیں بھیجیں۔
حساس artefacts کے لیے hash الگ چینل سے بھیجیں اور وصولی کے بعد verify کریں۔

انسٹالیشن (مختصر اور عملی)

کئی سسٹمز میں یہ package manager سے ایک کمانڈ ہے:

Debian/Ubuntu: sudo apt install magic-wormhole
macOS: brew install magic-wormhole

اگر distro پیکجز پرانے ہوں تو pipx اکثر سب سے صاف آپشن ہے:

pipx install magic-wormhole
pipx ensurepath

اور اگر آپ کو Python بالکل نہیں چاہیے (minimal server، container، rescue environment): wormhole-william ایک compatible Go port ہے جو single binary کی صورت میں ملتا ہے۔

آٹومیشن اور self-hosting

کنٹرولڈ workflows کے لیے magic-wormhole کو script کیا جا سکتا ہے:

CODE="5-alpaca-orbit"
wormhole send --code "$CODE" /path/to/db.dump

ریسیور:

wormhole receive --code "$CODE" --accept-file

یہ convenient ہے، مگر جیسے ہی آپ code کو hard-code کرتے ہیں آپ واپس credential management میں آ جاتے ہیں۔ اگر automate کریں تو proper secret handling اور short lifetimes کے ساتھ کریں۔

اگر آپ rendezvous/relay پر مکمل کنٹرول چاہتے ہیں تو کلائنٹ کو اپنی انفراسٹرکچر کی طرف point کیا جا سکتا ہے، مثلاً:

--relay-url اپنے rendezvous سرور کے لیے
--transit-helper اپنے transit relay کے لیے

نتیجہ

magic-wormhole managed اور policy-driven فائل ٹرانسفر کا متبادل نہیں۔ مگر روزمرہ کے ایک ٹول کے طور پر یہ بہترین ہے: تیز، کم رگڑ والا، اور واضح سیکیورٹی ماڈل کے ساتھ۔

خاص طور پر SMB دنیا میں، جہاں ہر سپورٹ کیس کے لیے approvals کی لمبی قطار بنانے کا نہ وقت ہوتا ہے نہ حوصلہ، “کافی حد تک محفوظ اور فوراً قابلِ استعمال” ٹول اکثر بالکل صحیح ثابت ہوتا ہے۔

ذرائع اور مزید پڑھنے کے لیے

اگلی بار تک، Joe