<div class="about">
    <center><h2>‫<a href="/about">حول</a> | <a href="/about/news">اﻷخبار</a> | <a href="/about/usage">الاستخدام</a> | اﻷسئلة الشائعة | <a href="/about/stats">اﻹحصاءات</a> | <a href="/about/privacy">حماية البيانات‬</a>
</h2></center>

    <p><strong>يمكنك الاطلاع على تعليمات الاستخدام موجودة في <a href="/about/usage">دليلنا</a>.‏</strong></p>

    <h3 id="sks-pool"><a href="#sks-pool">هل هذا الخادم ضمن تجمُّع خوادم المفاتيح المُتزامِنة ؟</a></h3>

    <p>‫كلا. النموذج الاتحادي لتجمُّع خوادم المفاتيح المُتزامِنة لها عدة مشاكل متعلقة بالمصداقية ومقاومة إساءة الاستخدام والخصوصية وسهولة الاستخدام. قد ننجز شيئا مشابها، لكن لن يكون <span class="brand">keys.openpgp.org</span> أبدا ضمن تجمُّع لخوادم المفاتيح المُتزامِنة.</p>

    <h3 id="federation"><a href="#federation">‫هل keys.openpgp.org خادم اتحادي ؟ أيمكنني المساعدة عبر تشغيل خادمي أيضا ؟</a></h3>

    <p>‫ليس في الوقت الحالي. نحن نخطط لجعل <span class="brand">keys.openpgp.org</span> لا مركزيا في المستقبل. نأمل أن نطور إمكانية الاعتماد على هذه الخدمة عبر العديد من الخوادم التي يتكلف بها أفراد المستقلون.</p>

    <p>لقد اقترح علينا عدة أشخاص مد يد العون لنا، عبر « تشغيل البرنامج الخادم Hagrid في أجهزتهم ». بالرغم من تقديرنا لهم على قبول مساعدتنا، إلا أنه من المحتمل أننا لن نستخدم أبدا نموذجا اتحاديا مثل خادم المفاتيح المُتزامِن، الذي من خلاله يمكن لأي فرد أن يشغِّل خادما يصبح ضمن « تجمُّع ». هذا لسببين :</p>
    <ol>
<li>يتطلب الاتحاد عبر المشاركة إتاحة كل البيانات عموميا. ولهذا الأمر تأثير بالغ على الحياة الخاصة للمستخدمين، لأنه يسمح لأي كان بجلب لائحة لجميع عناوين البريد الإلكتروني.</li>
        <li>لا توافق الخوادم معاييرنا حول الأداء والمصداقية، ونقصد بذلك الخوادم التي يُشغِّلها المسؤولون العاديون كهواية لهم.</li>
    </ol>
<h3 id="non-email-uids"><a href="#non-email-uids">لماذا لا يوجد دعم لهويات أخرى غير العناوين الإلكترونية ؟</a></h3>

    <p>إننا نطلب الموافقة الصريحة لتوزيع معلومات الهوية. إن الهويات التي ليست عناوين إلكترونية، كالصور وعناوين المواقع لا توفر لنا طريقة بسيطة للحصول على تلك الموافقة.</p>

    <p>‫ملاحظة : بعض برامج OpenPGP تنشيء المفاتيح بنسق غير صحيح للعناوين الإلكترونية. لذلك، يُحتمَل ألا يتعرف عليها <span class="brand">keys.openpgp.org</span>.</p>

    <h3 id="verify-multiple"><a href="#verify-multiple">أيمكنني التحقُّق من أكثر من مفتاح لبعض عناوين البريد الإلكتروني ؟</a></h3>

    <p>‫يمكنك ربط عنوان البريد الإلكتروني بمفتاح منفرد فقط. عندما يتم التحقُّق من عنوان ما مع مفتاح جديد، لن يظهر بعد ذلك في أي مفتاح سبق التحقق منه. سوف تُوزَّع مع ذلك <a href="/about">المعلومات غير الكاشفة للهوية</a> لجميع المفاتيح.</p>

    <p>‫هذا يعني أن البحث بواسطة عنوان البريد الإلكتروني لن تعرض إلا مفتاحا منفردا، وليس عدة نتائج موافقة لذلك العنوان. هذا الأمر يزيل كل اختيار غير ممكن من طرف المستخدم (مثلا « ماهو المفتاح الصحيح ؟ »)، كما أنه يجعل العثور على المفتاح بواسطة العنوان الإلكتروني أكثر ملائمة.</p>

    <h3 id="email-protection"><a href="#email-protection">ماذا تفعلون لحماية رسائل التحقُّق الصادرة ؟</a></h3>

    <p>‫إننا نستخدم معيارا عصريا يُطلَق عليه <a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a> مع <a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a>، من طرف EFF، وذلك للتأكد من إرسال رسائل التحقُّق بأمان. هذا الأمر يقي ضد التنصت واعتراض الرسائل أثناء تسليمها.</p>

    <p>‫تعمل آلية MTA-STS فقط إذا كان مزود خدمة بريد مُستلِم الرسالة يدعم ذلك. وإلا، ستُسلَّم الرسائل على النحو المعتاد. يمكنك <a href="https://www.hardenize.com/">تشغيل هذا الفحص</a> للتحقُّق من دعم مزود البريد الإلكتروني لتلك الآلية. إذا يظهر رمز تحقُّق أخضر عن يسار المُدخَلة « MTA-STS »، يُرجى الطلب من مزود خدمة بريدك الإلكتروني تحديث تهيئته.</p>

    <h3 id="third-party-signatures"><a href="#third-party-signatures">هل توزعون « توقيعات الأطراف الأخرى » ؟</a></h3>

    <p>باختصار، كلا.</p>

    <p>‫إن « التوقيع من طرف آخر » هو توقيع على مفتاح بواسطة مفتاح آخر. على العموم، يتم إنشاء ذلك التوقيع عبر ختم مفتاح لشخص ما، والذي يعد حجر أساس « <a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">شبكة الثقة</a> ». ولعدة أسباب، لا تُوزَّع تلك التوقيعات حاليا في <span class="brand">keys.openpgp.org</span>.</p>

    <p>السبب الرئيس لذلك هي <strong>الرسائل المزعجة</strong>. إذ تسمح توقيعات الأطراف الأخرى إرفاق بيانات عشوائية مع المفتاح من أي كان، وهذا الأمر سيفتح الباب لمن له نوايا سيئة من إرفاق العديد من البيانات غير النافعة دون أي قيود، مما يُضخِّم من حجم المفتاح بشكل هائل، إلى درجة تجعل استخدامه غير ممكن. بل الأنكى من ذلك، أنه يمكن أن تتضمن محتوىً قبيحا أو غير قانوني.‏</p>

    <p>‫هناك بعض الأفكار لتجاوز هذا المشكل. وهي مثلا، توزيع تلك التوقيعات مع المُوقِّع بنفسه بدل المُوقَّع له. بالمقابل، يمكننا أن نلزم المُوقَّع له بأن يوقع هو الآخر قبل أي توزيع، وذلك لدعم سير العمل <a href="https://wiki.debian.org/caff" target="_blank">على طريقة الأداة caff</a>. إذا رأينا اهتماما كافيا من المستخدمين بذلك، فنحن على أتم الاستعداد للتعاون مع مشاريع OpenPGP الأخرى لإيجاد حل مناسب.</p>

    <h3 id="no-sign-verified">‫<a href="#no-sign-verified">لماذا لا تُوقَّع المفاتيح بعد التحقُّق منها ؟</a>
</h3>

    <p>‫صُممَت خدمة <span class="brand">keys.openpgp.org</span> لتقوم بتوزيع المفاتيح والعثور عليها، لذلك فهي ليست فعليا هيئة للشهادات. يجب على البرامج التي تود توفير اتصالات مُتحقَّق منها أن تعتمد على نموذجها الخاص للثقة.</p>

    <h3 id="revoked-uids"><a href="#revoked-uids">لماذا لا تُوزَّع الهويات الباطلة كذلك ؟</a></h3>

    <p>إذا وسم مفتاح OpenPGP أحد الهويات بأنها باطلة، فذلك يعني أنه لم تعد تلك الهوية صالحة مع ذلك المفتاح. إذ من الأفضل أيضا توزيع هذه المعلومة على كل برامج OpenPGP التي لها علم سابق بالهوية الجديدة الباطلة.‏</p>
    <p>للأسف، لا توجد طريقة أفضل لتوزيع شهادات إبطال الهوية، بحيث لا تكشف عن الهوية التي قامت بإبطالها.‏</p>
    <p>‫لقد اقُترحَت عدة حلول لتلك المشكلة، تسمح بتوزيع شهادات إبطال الهوية دون الكشف عن الهوية المعنية بذلك. رغم هذا، لم تتم لحد الآن، الصياغة النهائية لأي مواصفات تدعمها برامج OpenPGP. نأمل في المستقبل القريب بوضع حل ملائم لكي يدعمه <span class="brand">keys.openpgp.org</span> في أقرب وقت، قدر الإمكان.</p>

    <h3 id="search-substring"><a href="#search-substring">لماذا لا يمكن البحث بواسطة جزء من العنوان الإلكتروني، مثلا باسم النطاق ؟</a></h3>

    <p>‫بعض خوادم المفاتيح تدعم البحث عنها بواسطة جزء من عنوان البريد الإلكتروني. لا يقتصر الأمر على العثور على المفاتيح، بل يتعداه إلى العناوين أيضا، باستخدام طلب يشبه « مفاتيح بعناوين في gmail نقطة com ». إذ بذلك، ستُعرَض بالفعل كل العناوين المقترنة بتلك المفاتيح في خوادم المفاتيح تلك بشكل عمومي.</p>

    <p>‫لذلك، فإن البحث بعنوان البريد الإلكتروني في <span class="brand">keys.openpgp.org</span> يعرض فقط المفتاح الذي يوافق بالضبط العنوان المبحوث به. بهذه الوسيلة، يمكن للمستخدم المعتاد العثور فقط على المفتاح المرتبط بالعنوان الذي يعرفه، لكنه من جهة أخرى لن يتمكن من إيجاد أي عناوين أخرى جديدة. هكذا، تتم الوقاية من ذوي النوايا السيئة والمحتالين، الذين يسعون للحصول بسهولة على كل عناوين البريد الإلكتروني الموجودة في الخادم.</p>

    <p>‫لقد وضعنا تلك القيود كجزء من <a href="/about/privacy">سياسة خصوصيتنا</a>، مما يعني أنه لن نقوم بتعديلها إلا بعد طلب الموافقة على ذلك من طرف المستخدمين.</p>

    <h3 id="tor"><a href="#tor">هل تدعمون تُورْ ؟</a></h3>

    <p>‫بالطبع ! إذا قمت بتثبيت تُورْ، سيمكنك الوصول بهوية مجهولة إلى <span class="brand">keys.openpgp.org</span> عبر موقع <a href="https://support.torproject.org/fr/onionservices/#onionservices-2" target="_blank">خدمة البصلة</a> التالي : <br><a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>

    <h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">لماذا لا تُعمَّى رسائل التحقُّق الإلكترونية ؟</a></h3>

    هناك عدة أسباب لذلك :‏
    <ol>
<li>الأمر أكثر تعقيدا، لنا وللمستخدمين.‏</li>
        <li>ذلك لا يقي من الهجمات. إذ أن الذي ينوي الاختراق لن يُجديَه نفعا رفع مفتاح لا يمكنه الوصول إليه.‏</li>
        <li>يجب توفر إمكانية الحذف، على الرغم من ضياع المفتاح.‏</li>
        <li>ذلك يتطلب آلية مختلفة (وأكثر تعقيدا) لرفع المفاتيح التي تمكِّن من التوقيع.‏</li>
    </ol>
<h3 id="older-gnupg"><a href="#older-gnupg">
‫لدي مشاكل في تحديث بعض المفاتيح مع GnuPG. هل هناك علة ؟
</a></h3>

    <p>‫يَعُد GnuPG المفاتيح التي لا تحتوي على معلومات الهوية غير صالحة، لذلك يرفض استيرادها.
‫مع ذلك، فإن المفتاح الذي لا يتوفر على <a href="/about">عناوين إلكترونية غير مُتحقَّق منها</a> قد تحتوي على معلومات مهمة.
‫بالذات، هناك إمكانية للتحقق من بطلان المفتاح من عدمه.</p>
    <p>‫في يونيو من عام 2019، أنشأ فريق <span class="brand">keys.openpgp.org</span> تصحيحا يسمح لأداة GnuPG معالجة التحديث من المفاتيح دون الحاجة للمعلومات الشخصية. لقد أُدمِج هذا التصحيح فورا في توزيعات كثيرة لتلك الأداة، بما في ذلك Debian و Fedora و NixOS و GPG Suite لنظام اشتغال مَاكْ.</p>
    <p>‫في مارس من عام 2020، رفض فريق GnuPG ذلك التصحيح، ولن يقبل به لاحقا. ‫هذا الأمر يعني أن <strong>إصدارات GnuPG غير المُصحَّحة لن تتلقى التحديثات من <span class="brand">keys.openpgp.org</span> بالنسبة للمفاتيح التي لم يُتحقَّق من عناوينها الإلكترونية</strong>. يمكنك قراءة هذا القرار حول المشكلة <a href="https://dev.gnupg.org/T4393#133689">T4393</a> في مُتتبِّع علل GnuPG.</p>
    <p>يمكنك التحقق من اﻹصدار المتأثر بذلك باتباع التعليمات التالية.</p>
    <blockquote>
<span style="font-size: larger;">استيراد مفتاح التجربة :‏</span><br><br>
‪$ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import<br>
‪ gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" imported<br>

‪gpg: Total number processed: 1<br>
‪gpg: imported: 1<br><br>
</blockquote>
    <blockquote>
<span style="font-size: larger;">بعد تطبيق التصحيح، سوف يُحدَّث المفتاح إذا عُرف محليا :‏</span><br><br>
‪$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
‪gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" not changed<br>
‪gpg: Total number processed: 1<br>
‪gpg: unchanged: 1<br><br>
</blockquote>
    <blockquote>
<span style="font-size: larger;">من دون تطبيق أي تصحيح، سوف يُرفَض كل مفتاح لا يتوفر على هوية :‏</span><br><br>
‪$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
‪gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID<br>
</blockquote>
</div>
