jitpass - كلمات مرور في الوقت المناسب

بيانات اعتماد في الوقت المناسب لجهاز التطوير الخاص بك.

التوثيق · البدء السريع · الأدوات المدعومة · مرجع الأوامر · الأمان

الحالة: خاص بنظام macOS فقط (Apple Silicon)، ولا يزال قيد التطوير.

ما هو jit (في 30 ثانية)

أسرارك موجودة كنص عادي في كل مكان على جهازك: ملفات .env، ~/.aws/credentials، تصديرات ~/.zshrc، رموز .npmrc، إعدادات MCP. أي شيء يعمل باسمك يمكنه قراءتها. أمر curl | sh سيئ، أو npm install مشبوه، أو أحد وكلاء الذكاء الاصطناعي الذين يعملون الآن في محررك بصلاحياتك الكاملة.

jit ينقل كل سر إلى خزنة مشفرة محلية محمية بـ Touch ID، ويعيد كتابة الملفات بحيث تستمر أدواتك في العمل. على القرص يوجد الآن خدعة. القيمة الحقيقية تظهر فقط، في الذاكرة، للعملية المحددة التي طلبتها، بعد مطالبة بيومترية. النتيجة: تفتح مرة واحدة، jit يسأل قبل تسليم بيانات اعتماد لأداة (أو وكيل)، وهناك خدعة على القرص بقية الوقت.

تم الإطلاق بواسطة Code	تم الإطلاق بواسطة claude

ما لا يفعله: لا يجعل حسابًا تم اختراقه بالفعل آمنًا، ولا يحمي سرًا بمجرد وجوده في ذاكرة العملية التي طلبته. الحدود موضحة في صفحة واحدة، في البداية: القيود المتعمدة.

كيف يعمل، ميكانيكيًا

لا امتداد نواة، لا برنامج تشغيل نظام ملفات، لا FUSE. ثلاث آليات، مختارة بناءً على ما يمكن للأداة فعله:

1. متغيرات البيئة في عملية واحدة، ثم execve. صورة jit الخاصة تُستبدل بأمرك، لذا تعيش القيمة في تلك العملية الواحدة ويختفي jit من الذاكرة.
2. بروتوكول بيانات الاعتماد الأصلي للأداة، حيثما يوجد: AWS credential_process، مساعدات بيانات اعتماد docker و git، إضافات kubectl exec، مساعد بيانات اعتماد Terraform. الأداة تسأل، jit يجيب، لا ملف مشارك.
3. تركيب أنبوب مسمى، للأدوات التي يمكنها قراءة ملف فقط.

التركيب هو FIFO من POSIX، يُنشأ بـ mkfifo(2) بالوضع 0600. برنامج يستدعي open(".env") يُحجب في النواة حتى يتصل كاتب. خدمة الخلفية هي ذلك الكاتب: يفتح المسار O_WRONLY، مما يحرر القارئ، يكتب البايتات المفكوكة من الذاكرة في مخزن النواة الأنبوبي المؤقت، يغلق، ويعود إلى open(2) للقارئ التالي. لا شيء يلامس القرص. ما يُكتب يُقرر لكل قراءة: خدع لقارئ محيط، قيم حقيقية فقط داخل تشغيل أذنت به.

هوية المتصل تشرح وتدقق، ولا تقرر أبدًا. أسماء العمليات قابلة للتزوير، وقارئ FIFO سريع الإغلاق يمكنه تجنب التعرف تمامًا. الإنسان الذي يجيب على المطالبة هو البوابة؛ اسم العملية يخبرك فقط بماذا تجيب. التفاصيل الكاملة في كيف يعمل و التركيبات الحية.

التثبيت

brew install jitpass/tap/jitpass

هذا هو المسار الموصى به، وبالنسبة لأداة أمنية السبب مهم. الإصدارات موقعة بمعرف مطور Apple ومصدقة من Apple. Homebrew يعزل ما ينزله، لذا Gatekeeper يفحص الثنائي مقابل تذكرة التصديق قبل السماح له بالتشغيل. للتحقق من ذلك بنفسك بدلاً من تصديق كلامنا، شغّل jit doctor: سطر jit فيه يبلغ signed CZC6BH93GJ، نفس الفحص الذي يشغله jit upgrade قبل أن يثبت أي شيء.

curl -sL https://dl.jitpass.com/jitpass/jit/releases/latest/download/jitpass_darwin_arm64.tar.gz | tar -xz jit
shasum -a 256 jit   # قارن مع checksums.txt في صفحة الإصدار
codesign -dv --verify --verbose=2 ./jit   # توقع: Developer ID، TeamIdentifier=CZC6BH93GJ
sudo mv jit /usr/local/bin/

خاص بـ Apple Silicon فقط. على Mac بمعالج Intel، ابنِ من المصدر بـ go install github.com/jitpass/jit/cmd/jit@latest.

اختر مسارًا واحدًا. إذا ثبّت من الحزمة المضغوطة سابقًا وتنتقل إلى Homebrew، أزل النسخة القديمة بعد brew install (sudo rm /usr/local/bin/jit)؛ وإلا فسيكون هناك نسختان من jit على PATH تتحدثان بشكل منفصل، و jit doctor سيشير إلى ذلك.

الترقية: brew upgrade jitpass، أو jit upgrade: تحديث ذاتي موثق (توقيع Developer-ID والمجموع الاختباري كلاهما يُفحص قبل التبديل، يعيد تشغيل الخدمة). في كلتا الحالتين خزنتك لا تُمس.

Homebrew يثبت إكمال الصدفة مع الثنائي، لذا jit <TAB> يكمل الأوامر الفرعية، والأعلام، ومسارات الخزنة، وأسماء الأدوات القابلة للتغليف مباشرة. إذا ثبّت من الحزمة المضغوطة أو من المصدر، أضفه بنفسك:

echo 'source <(jit completion zsh)' >> ~/.zshrc && exec zsh

في كلتا الحالتين، jit doctor يخبرك إذا كان الإكمال لا يصل إلى صدفك.

كيف تستخدمه فعليًا

jit scan                            # للقراءة فقط. لا يغير أي ملف يفحصه، لا يطبع أي قيمة حقيقية.
jit vault init                      # أنشئ الخزنة (المفتاح الرئيسي في سلسلة مفاتيح تسجيل الدخول)
jit migrate --dry-run               # معاينة خطة الإصلاح الكاملة على مستوى الجهاز
jit migrate                         # طبّقها: يعرض الخطة، يسأل [y/N]، Touch ID واحد
jit migrate ~/code/myapp            # أو أصلح مشروعًا واحدًا فقط
jit run -- npm run dev              # شغّل أداتك؛ القيم الحقيقية تُحقن في تلك العملية فقط

jit scan بدون مسار يمسح دليل منزلك بالكامل، لذا امنحه لحظة على دليل كبير. للتوجه مباشرة إلى مكان واحد، وجّهه إلى مسار: jit scan ~/.aws.

يوميًا هو غالبًا jit run -- <cmd>. لـ CLIs التي تحمل رمز تسجيل الدخول الخاص بها (gh، glab، stripe، والمزيد) تقوم بـ jit wrap gh مرة واحدة ثم تواصل كتابة gh كالمعتاد إلى الأبد.

لست متأكدًا مما إذا كان شيء يحتاج jit wrap، أو jit migrate، أو لا شيء؟ لست مضطرًا للمعرفة. jit scan يقسم كل ما يجده إلى ما سيحميه jit (أمر واحد - بما في ذلك التغليفات) وما يمكنك إصلاحه فقط، و jit migrate المجرد يشغل تلك الخطة بأكملها:

$ jit scan
  أسرارك: 7 — 0 محمية بواسطة jit (0%)
  ▱▱▱▱▱▱▱▱▱▱  إلى 100%: أمر واحد +71% · سران فقط يمكنك إصلاحهما +29%

  سيحمي jit هذه — 5 أسرار في 4 ملفات، 0% → 71%
      → jit migrate
        ~/.zshrc            STRIPE_API_KEY, DB_PASSWORD
        ~/.config/gh/hosts.yml  رمز GitHub CLI · يغلف gh
        ...

  يمكنك فقط حماية هذه — سران، 71% → 100%

    [دوّر، ثم احذف كل نسخة]
    ! كلمة مرور قاعدة بيانات إنتاجية في ملفين
      → دوّرها الآن، ثم احذف كل نسخة

(jit scan --full لا يزال يعطي الجرد الكلاسيكي حسب الفئة مع الخطورات، بما في ذلك قسم رموز CLI القابلة للتغليف.)

أدواتك اليومية

هاجر ببيانات الاعتماد مرة واحدة، ثم استمر في استخدام الأداة بالطريقة التي اعتدت عليها دائمًا.

# AWS (و Terraform، وكل AWS SDK)
jit migrate ~/.aws/credentials       # المفاتيح تنتقل إلى الخزنة؛ لا ملف نص عادي متبقٍ
aws s3 ls                            # يُحل من الخزنة عند الطلب. لا بادئة، لا علم.
terraform apply                      # نفس البيانات، نفس الأمر

# بيانات اعتماد GCP الافتراضية للتطبيق (بيانات اعتماد على مستوى الجهاز)
jit migrate ~/.config/gcloud/application_default_credentials.json
terraform apply                      # موفر google يقرأ ADC؛ يعمل بعد مطالبة Touch ID

# Docker / docker-compose
jit migrate ~/.docker/config.json    # تسجيلات الدخول للسجلات تنتقل إلى الخزنة
jit run -- docker compose up         # jit يحقنها لهذا التشغيل
docker login ghcr.io                 # لا يزال يعمل؛ المساعد يخزن في الخزنة

# تصديرات الصدفة التي كانت في ~/.zshrc
jit migrate ~/.zshrc                 # يترك خطافًا من سطر واحد؛ الأصداف الجديدة لديها المتغيرات فقط
./deploy.sh                          # السكربتات التي تقرأ تلك المتغيرات تعمل دون تغيير

# رموز كتبتها مرة في المطالبة، الآن في سجل الصدفة الخاص بك
jit migrate ~/.zsh_history           # كل واحد ينتقل إلى الخزنة؛ أوامرك تبقى، الأسرار لا
jit guard history                    # وامنع تسجيل التالي تمامًا (zsh)
                                     # (`jit migrate` المجرد يعرض هذا أيضًا، في الخطة التي يطلب تأكيدها)

# CLI يحمل رمزه الخاص (gh، stripe، glab)
jit wrap gh                          # مرة واحدة
gh pr list                           # الرمز يُحقن لكل استدعاء، إلى الأبد

في المرة الأولى التي تصل فيها كل أداة إلى بيانات اعتماد حقيقية، jit يسأل مرة واحدة ويتذكر إجابتك حتى تُقفل الخزنة. انظر لحظتا Touch ID لكيفية ترتيب ذلك فوق فتح الخزنة، وما يفعله --trust، وكيفية إيقاف المطالبات لكل أداة.

لماذا تحتاج بعض الأدوات إلى إعداد بينما تأخذ أخرى jit run؟ قاعدة واحدة: هل يمكن للأداة أن تسأل jit عن السر بنفسها؟ AWS (عبر credential_process)، وصدفتك عند تسجيل الدخول، وتسجيلات دخول سجل docker (عبر مساعد بيانات اعتماد) كلها يمكنها ذلك، لذا لا تكتب شيئًا إضافيًا. الأدوات التي تقرأ ملفًا فقط في وقت التشغيل (docker compose، SDKs عادية) لا يمكنها السؤال، لذا jit run يسلمها القيمة.

ملفات بيانات الاعتماد العامة على مستوى الجهاز (GCP ADC، sops، npm، netrc) تعمل بنفس الطريقة اليومية: شغّل أداتك ووافق على المطالبة لكل عملية. أضف jit run --with <name> فقط عندما تريدها صريحة: للسكربتات و CI حيث لا توجد مطالبة للإجابة، أو عندما تريد بوابة صلبة لا يمكن لإعداد المشروع نفسه الوصول إليها أبدًا. الأدوات المدعومة يسرد بالضبط ما تكتبه لكل أداة، وكيف تُسلم كل واحدة.

لحظتا Touch ID، وليس واحدة

jit يطلب بصمة إصبعك في لحظتين مختلفتين، يقومان بمهمتين مختلفتين:

1. فتح خزنتك. في المرة الأولى التي تستخدم فيها jit بعد قفله، Touch ID واحد يفتح الخزنة للجلسة بأكملها (5 دقائق من النشاط، ثم يُقفل مرة أخرى؛ ولا أبدًا أطول من 8 ساعات، مهما كنت مشغولًا). تفتح مرة واحدة، وليس مرة لكل أمر.
2. تسليم بيانات اعتماد لأداة. فوق ذلك، في المرة الأولى التي تصل فيها أداة معينة إلى بيانات اعتماد حقيقية، jit يسأل قبل تسليمها ويسمي ما يسأل. هذا ما يمنع برنامجًا لم تشغله من استخدام مفاتيحك بهدوء بينما الخزنة مفتوحة.

$ aws s3 ls
  Touch ID  ->  افتح خزنتك              # بوابة 1: تفتح الخزنة لمدة 5 دقائق
  Touch ID  ->  aws يريد بيانات اعتماد aws الخاصة بك   # بوابة 2: هذه الأداة، هذه البيانات
  ...دلاؤك...

$ aws s3 cp ./file s3://bucket/   # نفس الأداة، نفس الجلسة: لا مطالبة

$ terraform apply
  Touch ID  ->  terraform يريد بيانات اعتماد aws الخاصة بك   # أداة مختلفة: تسأل بنفسها

البوابة 2 هي ما يبقي الخزنة المفتوحة من كونها فوضى عارمة: حتى بعد استخدامك aws بنفسك، npm install مشبوه يصل لتلك المفاتيح نفسها لا يزال يطلق مطالبة تسميه، لذا يمكنك قول لا.

لا تريد البوابة الثانية؟ أوقفها؛ قفل الخزنة يبقى (إيقافها نفسها يتطلب Touch ID، لأنها تعيد فتح النافذة التي تغلقها):

jit service consent off   # الأدوات تُحل بصمت بينما الخزنة مفتوحة
jit service consent on    # اسأل لكل أداة مرة أخرى (الافتراضي)

تبدأ شيئًا يحتاج عدة بيانات اعتماد في وقت واحد؟ jit run --trust -- terraform apply يوافق على أدوات ذلك التشغيل بأكمله في إيماءة واحدة. التفاصيل الكاملة: الموافقة لكل عملية.

تغادر لوحة المفاتيح؟ jit grant

كلتا البوابتين تفترضان وجود إنسان للإجابة. وكيل ذكاء اصطناعي يعمل طوال الليل، بناء طويل، وظيفة مجدولة: الشاشة تُقفل، الجلسة تنقطع، والتشغيل يتعطل على مطالبة لن يراها أحد. منحة عملية تنقل قرارك إلى وقت أبكر بدلاً من إزالته - Touch ID واحد، يُمنح بينما لا تزال هناك، يسمي بالضبط ما توقعه:

$ jit grant --process claude --profile jamf --for 8h
  Touch ID  ->  اسمح لـ claude تحت iTerm2 باستخدام سرين (jamf) دون مراقبة لمدة 8 ساعات
✓ مُنحت g-7f3a2c81   claude -> jamf   حتى 17:42
  └ تغطي claude تحت iTerm2: 1 يعمل الآن، أي يبدأ قبل 17:42

للساعات الثماني القادمة، كل claude تحت الطرفية التي كتبت فيها ذلك (وما يطلقه) يحصل على تلك الأسرار دون مطالبات - عبر قفل الشاشة وكل شيء، بما في ذلك الجلسات التي تبدأها لاحقًا: تبويب جديد، claude التالي، سكربت يعمل في الساعة 3 صباحًا. إنها طرفيتك التي تُسمى، وليس اسمًا يُوثق: برنامج يسمي نفسه claude في مكان آخر على الجهاز لا ينحدر من تلك الشجرة ولا يرث شيئًا. المنحة تنتهي عند موعدها النهائي، عندما تغلق تلك الطرفية، أو اللحظة التي تكتب فيها jit grant revoke (التي لا تتطلب بصمة إصبع - إزالة الوصول دائمًا مجانية). تريد عملية واحدة محددة بدلاً من ذلك، تختفي عند خروجها؟ --pid. كل منحة تصل في سجل التدقيق كحدث خاص بها، لذا في الصباح التالي يمكنك قراءة بالضبط ما لمسه وكيلك بينما كنت نائمًا. التفاصيل الكاملة: منح العمليات.

وكلاء الذكاء الاصطناعي وخوادم MCP

الوكيل في محررك يعمل باسمك، بصلاحياتك، ويقرأ الملفات لك طوال اليوم. هذا هو الغرض الكامل منه، وهو أيضًا لماذا .env نص عادي في مستودعك أصبح الآن خطرًا مختلفًا جدًا عما كان قبل عامين. jit يعامل الوكلاء كمواطنين من الدرجة الأولى، على أربع جبهات:

jit migrate ~/.claude.json           # إعدادات خادم MCP: المفاتيح تنتقل إلى الخزنة،
                                     # كل خادم الآن يُطلق عبر `jit run`
jit wrap claude                      # CLIs الذكاء الاصطناعي نفسها: claude، codex، gemini،
                                     # cursor-agent، copilot، cline، opencode، kiro-cli
jit grant --process claude --profile myapp --for 8h
                                     # اتركه يعمل طوال الليل دون مطالبة لا يجيبها أحد
jit audit --parent claude            # اقرأ بالضبط ما لمسه بينما كنت نائمًا

• المطالبة تسمي الوكيل. مع الموافقة لكل عملية مفعلة (الافتراضي)، في المرة الأولى التي تصل فيها أداة إلى بيانات اعتماد حقيقية تحصل على Touch ID يقول أي برنامج يسأل. هذا ما تظهره لقطتا الشاشة في أعلى هذه الصفحة: نفس السر المطلوب بواسطة VS Code و بواسطة claude، كل منهما مسمى. وكيل يقرأ ~/.aws/credentials بهدوء هو مطالبة، وليس نجاحًا صامتًا.
• خوادم MCP تُطلق عبر jit run. إعداد MCP مهاجر يحمل مسارات خزنة، وليس مفاتيح، لذا ملف الإعداد نفسه آمن لوجوده على القرص وآمن لتسليمه للوكيل الذي يقرأه.
• الخدعة هي ما يحصل عليه القراءة غير المصرح بها. وكيل يبحث في مستودعك عن .env ويقرأه باردًا يحصل على قيم بديلة، والقراءة تُسجل.
• jit audit --parent claude يعرض كل سر استخدمه وكيل، وكل مطالبة أطلقها، وكل واحدة رفضتها.

المزيد في أدوات MCP / الذكاء الاصطناعي و الموافقة لكل عملية.

سجل التدقيق: ماذا حدث، ومن فعله

كل أمر jit وكل فتح يصل في سجل دائم تقرأه بـ jit audit، الأحدث أولاً، سطر key=value واحد لكل حدث، لذا يمكن البحث فيه مثل سجل خدمة حقيقي. وسيطات الأوامر مقنعة، لذا السجل يثبت أن أمرًا شُغل دون تخزين السر الذي حمله أبدًا.

$ jit audit --since 1h
time=2026-07-24 10:15:04 level=info kind=cmd status=ok dur=312ms cmd="jit migrate ~/.aws/credentials" user=meni parent=claude
time=2026-07-24 10:16:22 level=info kind=use op="read a secret" cmd="aws s3 ls" parent=claude secrets=aws/default
time=2026-07-24 10:31:09 level=warn kind=unlock status=denied method=touchid-or-passcode cmd="node postinstall.js" parent=npm secrets=aws/default

السطر الأوسط هو القصة التي وُجد jit ليرويها: aws/default قُرئ بواسطة aws s3 ls، أُطلق بواسطة claude. الأخير هو مطالبة رفضتها: node postinstall.js تحت npm يصل لتلك المفاتيح نفسها، رُفض. jit يسجل أيضًا ما رفضته الخدمة عند مقبسها (عملية يقول النواة إنها ليست لك، تتحسس الوكيل) كـ kind=error.

ضيقه بأعلام بدلاً من grep: --kind، --status ok|failed|denied، --since/--until (عمر مثل 2h/3d أو تاريخ)، --parent claude، --secret aws، --user، --grep <regexp>. أضف --follow (-f) لتدفق أحداث جديدة مباشرة مثل tail -f، أو --format json لتفريغ قابل للتحليل آليًا. كلا الجزأين ملفات دائمة بجانب الخزنة، لذا يجيب عن الأسبوع الماضي بسهولة مثل الساعة الأخيرة.

ما يدعمه

ملفات .env، تصديرات الصدفة، AWS و Terraform، kubeconfig، تسجيلات دخول سجل Docker، GCP ADC، رموز .npmrc / .netrc، إعدادات خادم MCP، ملفات رموز عارية، بيانات اعتماد مسجلة في سجل الصدفة الخاص بك، CLIs قابلة للتغليف (gh، stripe، vercel، …)، و CLIs SSO التي تصك بيانات اعتماد عند تسجيل الدخول (clisso). في كل حالة يبقى الملف يعمل والقيمة الحقيقية تأتي من الخزنة عند الطلب.

الكتالوج الكامل، مجمعًا حسب بالضبط ما تكتبه لكل أداة، هو الأدوات المدعومة: يتتبع الكود مع إضافة الأدوات أو إزالتها. أي شيء غير مدرج يمكن تغليفه مع jit wrap add.

تبقي أسرارك بالفعل في 1Password؟ مع تثبيت CLI الخاص به، jit migrate يربط بدلاً من النسخ: قيمة موجودة بالفعل في 1Password تُخزن كمرجع op:// الخاص بها، لذا يبقى 1Password نظام السجل و jit يسلم القيمة في الوقت المناسب عبر كل آلية أعلاه (jit vault link يفعل نفس الشيء لسر واحد يدويًا).

هل يمكنني التراجع؟ دائمًا.

jit لا يدمر بيانات اعتماد أبدًا. الهجرة تنقل القيمة إلى الخزنة و تترك خطافًا يعمل حيث كانت (.env خدعة، سطر eval "$(jit export)" في إعداد صدفك، credential_process = jit … في ~/.aws/config، أو غطاء PATH)، لذا أدواتك تستمر في حلها عند الطلب. بيانات الاعتماد لا تزال موجودة، مشفرة فقط بدلاً من كونها نصًا عاديًا.

وكل تغيير قابل للعكس. قبل لمس ملف، jit ينسخه احتياطيًا مشفرًا في الخزنة، لذا jit migrate undo يعيده بايتًا ببايت:

jit migrate ~/code/myapp        # طبّق الإصلاح، Touch ID واحد
# غيرت رأيك، أو شيء انكسر؟
jit migrate undo ~/code/myapp   # كل ملف تم لمسه يُستعاد، بايتًا ببايت

تعلم المزيد

التوثيق موجود تحت docs/، منظمًا حسب المهمة:

• البدء السريع: الإعداد، الهجرة، التعايش مع الإصلاح، خطوة بخطوة
• كيف يعمل: الخزنة، الخدمة، التركيبات، والأغطية في صفحة واحدة
• الأسئلة الشائعة: أسئلة المطورين والأمان، مجاب عنها بصراحة
• الموافقة لكل عملية: ماذا تفعل المطالبات لكل أداة، وكيف تضبطها أو توقفها
• منح العمليات: وافق مسبقًا على أداة تعمل للعمل دون مراقبة لنافذة محدودة وقابلة للإلغاء ومدققة
• سجل التدقيق: اقرأ كل أمر وفتح ورفض، قابل للتصفية والمتابعة
• مرجع الأوامر: كل أمر وعلم، مولّد من CLI
• بنية الأمان: نموذج التهديد والحدود الصادقة
• CONTRIBUTING.md: إعداد البناء/الاختبار؛ التوقيع عبر DCO (git commit -s)، لا CLA

الترخيص

رخصة PolyForm Perimeter 1.0.0 - مجانية للاستخدام الشخصي والداخلي للشركات فقط.