SSL_SHUTDOWN(3SSL)

الاسم
SSL_shutdown, SSL_shutdown_ex - إغلاق اتصال TLS/SSL أو QUIC

موجز
 #include <openssl/ssl.h>

 int SSL_shutdown(SSL *ssl);

 typedef struct ssl_shutdown_ex_args_st {
     uint64_t    quic_error_code;
     const char  *quic_reason;
 } SSL_SHUTDOWN_EX_ARGS;

 __owur int SSL_shutdown_ex(SSL *ssl, uint64_t flags,
                            const SSL_SHUTDOWN_EX_ARGS *args,
                            size_t args_len);

الوصف
SSL_shutdown() يُغلق اتصالاً نشطًا يمثله كائن SSL. ssl يجب ألا يكون NULL.

SSL_shutdown_ex() هي نسخة موسعة من SSL_shutdown(). إذا كان غير NULL، يجب أن يشير args إلى بنية SSL_SHUTDOWN_EX_ARGS ويجب تعيين args_len إلى sizeof(SSL_SHUTDOWN_EX_ARGS). يجب أن تكون بنية SSL_SHUTDOWN_EX_ARGS مُهيأة بالأصفار. إذا كان args هو NULL، يكون السلوك مماثلاً لتمرير بنية SSL_SHUTDOWN_EX_ARGS مُهيأة بالأصفار. حاليًا، جميع المعاملات الموسعة تتعلق بالاستخدام مع QUIC، لذلك تعمل هذه الدالة بشكل مماثل لـ SSL_shutdown() عند عدم استخدامها مع QUIC.

بينما تكون العملية العامة لـ SSL_shutdown() مشتركة بين البروتوكولات، تعتمد الطبيعة الدقيقة لكيفية تنفيذ الإغلاق على البروتوكول الأساسي المستخدم. راجع القسم أدناه المتعلق بكل بروتوكول لمزيد من المعلومات.

بشكل عام، استدعاء SSL_shutdown() في وضع عدم الحظر سيبدأ عملية الإغلاق ويعيد 0 للإشارة إلى أن عملية الإغلاق لم تكتمل بعد. بمجرد اكتمال عملية الإغلاق، ستعيد الاستدعاءات اللاحقة لـ SSL_shutdown() القيمة 1. راجع قسم قيم الإرجاع لمزيد من المعلومات.

لا ينبغي استدعاء SSL_shutdown() إذا حدث خطأ قاتل سابق على اتصال؛ أي إذا أعادت SSL_get_error(3) SSL_ERROR_SYSCALL أو SSL_ERROR_SSL.

اعتبارات خاصة بـ TLS و DTLS
يتم تنفيذ الإغلاق لـ SSL/TLS و DTLS من خلال رسالة تنبيه close_notify الخاصة بـ SSL/TLS/DTLS. تتكون عملية الإغلاق لـ SSL/TLS و DTLS من خطوتين:

•   يُرسل تنبيه إغلاق close_notify إلى النظير.

•   يُستقبل تنبيه إغلاق close_notify من النظير.

يمكن أن تحدث هذه الخطوات بأي ترتيب اعتمادًا على ما إذا كانت عملية إغلاق الاتصال قد بدأت أولاً بواسطة التطبيق المحلي أو بواسطة النظير.

  إغلاق بدأ محليًا
استدعاء SSL_shutdown() على كائن SSL/TLS أو DTLS SSL يبدأ عملية الإغلاق ويجعل OpenSSL يحاول إرسال تنبيه إغلاق close_notify إلى النظير. ثم تُعتبر عملية الإغلاق مكتملة بمجرد أن يستجيب النظير بدوره برسالة تنبيه إغلاق close_notify.

استدعاء SSL_shutdown() يُغلق فقط اتجاه الكتابة للاتصال؛ اتجاه القراءة يُغلق بواسطة النظير. بمجرد استدعاء SSL_shutdown()، لم يعد من الممكن استخدام SSL_write(3)، لكن يمكن استخدام SSL_read(3) حتى يقرر النظير إغلاق الاتصال بدوره. قد يستمر النظير في إرسال البيانات لفترة من الوقت قبل معالجة إشارة الإغلاق للتطبيق المحلي.

لا يؤثر SSL_shutdown() على اتصال شبكة أساسي مثل اتصال TCP، الذي يبقى مفتوحًا.

  إغلاق بدأ عن بُعد
إذا كان النظير هو أول من بدأ عملية الإغلاق بإرسال رسالة تنبيه close_notify، سيتم إخطار التطبيق بهذا كحالة نهاية ملف (EOF) عند استدعاء SSL_read(3) (أي ستفشل SSL_read(3) وستعيد SSL_get_error(3) SSL_ERROR_ZERO_RETURN)، بعد قراءة جميع بيانات التطبيق التي أرسلها النظير قبل بدء الإغلاق. يجب على التطبيق معالجة هذه الحالة باستدعاء SSL_shutdown() للرد بتنبيـه close_notify بدوره، مكملاً عملية الإغلاق، على الرغم من أنه قد يختار كتابة بيانات تطبيق إضافية باستخدام SSL_write(3) قبل القيام بذلك. إذا لم يستدع التطبيق SSL_shutdown() في هذه الحالة، لن يُرسل تنبيه close_notify ولن يكون السلوك متوافقًا تمامًا مع المعايير.

  دورة حياة الإغلاق
بغض النظر عما إذا كان الإغلاق قد بدأ محليًا أو بواسطة النظير، إذا كان BIO الأساسي محظورًا، فإن استدعاء SSL_shutdown() سيعود أولاً بمجرد كتابة رسالة تنبيه close_notify إلى النظير (مع إرجاع 0)، وعند الاستدعاء الثاني واللاحق، بمجرد استلام رسالة مقابلة من النظير (مع إرجاع 1 وإكمال عملية الإغلاق). ستعود استدعاءات SSL_shutdown() مع BIO أساسي محظور أيضًا في حالة حدوث خطأ.

إذا كان BIO الأساسي غير محظور ولم تكتمل عملية الإغلاق بعد (على سبيل المثال، لأن رسالة تنبيه close_notify لم تُستلم بعد من النظير، أو لأن رسالة تنبيه close_notify تحتاج إلى الإرسال ولكنها ستحظر حاليًا)، فإن SSL_shutdown() تُرجع 0 للإشارة إلى أن عملية الإغلاق لا تزال جارية؛ في هذه الحالة، سينتج عن استدعاء SSL_get_error(3) SSL_ERROR_WANT_READ أو SSL_ERROR_WANT_WRITE.

يمكن للتطبيق بعد ذلك اكتشاف اكتمال عملية الإغلاق عن طريق استدعاء SSL_shutdown() مرة أخرى بشكل متكرر حتى تُرجع 1، مما يشير إلى اكتمال عملية الإغلاق (مع إرسال واستلام تنبيه close_notify).

ومع ذلك، الطريقة المفضلة لانتظار اكتمال الإغلاق هي استخدام SSL_read(3) حتى يشير SSL_get_error(3) إلى EOF بإرجاع SSL_ERROR_ZERO_RETURN. يضمن هذا أن أي بيانات وُردت فورًا قبل تنبيه close_notify للنظير لا تزال مُقدمة للتطبيق. كما يضمن معالجة أي رسائل نهائية لطبقة المصافحة وُردت (على سبيل المثال، رسائل إصدار تذاكر جلسة جديدة).

إذا لم يُستخدم هذا النهج، فسيفشل الاستدعاء الثاني لـ SSL_shutdown() (لاكتمال الإغلاق بتأكيد استلام رسالة close_notify للنظير) إذا استُدعي عندما لم يقرأ التطبيق جميع بيانات التطبيق المعلقة التي أرسلها النظير باستخدام SSL_read(3).

عند استدعاء SSL_shutdown()، تُضبط العلامة SSL_SENT_SHUTDOWN بمجرد محاولة إرسال تنبيه close_notify، بغض النظر عما إذا كانت المحاولة ناجحة. تُضبط العلامة SSL_RECEIVED_SHUTDOWN بمجرد استلام تنبيه close_notify، والذي قد يحدث أثناء أي استدعاء يعالج البيانات الواردة من الشبكة، مثل SSL_read(3) أو SSL_shutdown(). يمكن التحقق من هذه العلامات باستخدام SSL_get_shutdown(3).

  الإغلاق السريع
بدلاً من ذلك، من المقبول للتطبيق استدعاء SSL_shutdown() مرة واحدة (بحيث تُرجع 0) ثم إغلاق الاتصال الأساسي دون انتظار رد النظير. يسمح هذا بعملية إغلاق أسرع إذا كان التطبيق لا يرغب في انتظار النظير.

يجب تنفيذ هذا النهج البديل "الإغلاق السريع" فقط إذا كان معروفًا أن النظير لن يرسل المزيد من البيانات، وإلا فهناك خطر تعريض التطبيق لهجوم اقتطاع. توفر عملية SSL_shutdown() الكاملة، التي يرسل فيها كلا الطرفين تنبيهات close_notify وتُعيد SSL_shutdown() القيمة 1، إشارة موثقة تشفيريًا لنهاية الاتصال.

هذا النهج باستدعاء واحد لـ SSL_shutdown() دون انتظار هو أفضل من مجرد استدعاء SSL_free(3) أو SSL_clear(3) لأن استدعاء SSL_shutdown() مسبقًا يجعل جلسة SSL مؤهلة لإعادة الاستخدام لاحقًا ويُعلم النظير بإغلاق الاتصال.

لا يمكن استخدام نهج الإغلاق السريع إلا إذا لم تكن هناك نية لإعادة استخدام الاتصال الأساسي (مثل اتصال TCP) للاتصال اللاحق؛ في هذه الحالة، يجب تنفيذ عملية الإغلاق الكاملة لضمان التزامن.

  التأثيرات على إعادة استخدام الجلسة
يضبط استدعاء SSL_shutdown() العلامة SSL_SENT_SHUTDOWN (انظر SSL_set_shutdown(3))، بغض النظر عما إذا كان إرسال تنبيه close_notify ناجحًا أم لا. يجعل هذا جلسة SSL مؤهلة لإعادة الاستخدام؛ تُعتبر جلسة SSL مغلقة بشكل صحيح ويمكن إعادة استخدامها للاتصالات المستقبلية.

  الإغلاق الصامت
يمكن تعديل SSL_shutdown() لضبط الاتصال على حالة "الإغلاق" دون إرسال رسالة تنبيه close_notify فعليًا؛ انظر SSL_CTX_set_quiet_shutdown(3). عند تمكين "الإغلاق الصامت"، سينجح SSL_shutdown() دائمًا ويُعيد القيمة 1 فورًا.

هذا ليس سلوكًا متوافقًا مع المعايير. يجب أن يُفعل فقط عندما يمكّن بروتوكول التطبيق المستخدم النظير من ضمان استلام جميع البيانات، بحيث لا يحتاج إلى انتظار تنبيه close_notify، وإلا فقد تُقتطع بيانات التطبيق بشكل غير متوقع.

  النظراء غير المتوافقين
هناك تطبيقات SSL/TLS لا ترسل أبدًا رسالة تنبيه close_notify المطلوبة ولكنها تغلق ببساطة النقل الأساسي (مثل اتصال TCP) بدلاً من ذلك. سيؤدي هذا عادةً إلى توليد خطأ.

إذا كانت التوافقية مع هؤلاء النظراء مرغوبة، يمكن ضبط الخيار SSL_OP_IGNORE_UNEXPECTED_EOF. لمزيد من المعلومات، انظر SSL_CTX_set_options(3).

لاحظ أن استخدام هذا الخيار يعني أن حالة نهاية الملف (EOF) لبيانات التطبيق لا تحصل على حماية تعمية، وبالتالي تجعل التطبيق عرضة لهجمات الاقتطاع. لذا، يجب استخدام هذا الخيار فقط بالتزامن مع بروتوكول تطبيق يُشير بشكل لا لبس فيه إلى وقت استلام جميع البيانات.

النهج البديل هو ببساطة تجنب استدعاء SSL_read(3) إذا كان معروفًا أنه لن يتم إرسال المزيد من البيانات. يتطلب هذا بروتوكول تطبيق يُشير بشكل لا لبس فيه إلى وقت إرسال جميع البيانات.

  معالجة تذاكر الجلسة
إذا كان تطبيق العميل يكتب فقط إلى اتصال SSL/TLS أو DTLS ولا يقرأ أبدًا، فقد لا يعالج OpenSSL أبدًا تذاكر جلسة SSL/TLS الجديدة المرسلة من الخادم. وذلك لأن OpenSSL يعالج عادةً رسائل المصافحة المستلمة من نظير أثناء استدعاءات التطبيق لـ SSL_read(3).

لذلك، يُنصح تطبيقات العميل التي تكتب فقط ولا تقرأ ولكنها ترغب في الاستفادة من استئناف الجلسة بتنفيذ إجراء إغلاق كامل عن طريق استدعاء SSL_shutdown() حتى تُرجع 1، كما هو موصوف أعلاه. سيضمن هذا وجود فرصة لاستلام رسائل تذاكر جلسة SSL/TLS ومعالجتها بواسطة OpenSSL.

اعتبارات الإغلاق الخاصة بـ QUIC
عند استخدامه مع كائن SSL لاتصال QUIC، يُبدأ SSL_shutdown() إغلاقًا فوريًا لـ QUIC باستخدام إطارات CONNECTION_CLOSE الخاصة بـ QUIC.

لا يمكن استخدام SSL_shutdown() على كائنات SSL لدفق QUIC. لإنهاء دفق بشكل طبيعي، انظر SSL_stream_conclude(3)؛ لإجراء إنهاء غير طبيعي للدفق، انظر SSL_stream_reset(3).

يمكن للتطبيق استخدام SSL_shutdown_ex() بدلاً من SSL_shutdown() لتوفير معلومات إضافية للنظير حول سبب إغلاق الاتصال. المعلومات التي يمكن توفيرها هي كما يلي:

quic_error_code
    رمز خطأ تطبيق اختياري بطول 62 بت يُرسل إشارة إلى النظير. يجب أن تكون القيمة في النطاق [0, 2**62-1]، وإلا فشل استدعاء SSL_shutdown_ex(). إذا لم يُقدم، يُستخدم رمز خطأ 0 مبدئيًا.

quic_reason
    سلسلة محارف سبب اختيارية منتهية بصفر (UTF-8) تُرسل إشارة إلى النظير. التطبيق مسؤول عن توفير سلسلة محارف UTF-8 صالحة ولن يتحقق OpenSSL من صحتها. إذا لم يُقدم سبب، أو استُخدم SSL_shutdown()، تُستخدم سلسلة محارف بطول صفر كسبب. إذا قُدم، تُنسخ سلسلة محارف السبب وتُخزن داخل كائن SSL لاتصال QUIC ولا تحتاج إلى البقاء مخصصة بعد عودة استدعاء SSL_shutdown_ex(). سلاسل محارف السبب مقيدة بـ MTU للمسار وقد تُقتطع بصمت إذا كانت طويلة جدًا بحيث لا تتناسب مع حزمة QUIC.

    سلاسل محارف السبب مخصصة لأغراض التشخيص البشري فقط، ولا ينبغي استخدامها للإشارات التطبيقية.

تُستخدم وسائط SSL_shutdown_ex() فقط في الاستدعاء الأول لـ SSL_shutdown_ex() (أو SSL_shutdown()) لكائن SSL معين لاتصال QUIC. تُتجاهل هذه الوسائط في الاستدعاءات اللاحقة.

لا تؤثر هذه الدوال على BIO شبكة أساسي أو المورد الذي يمثله؛ على سبيل المثال، ستبقى رسالة UDP المقدمة لاتصال QUIC كـ BIO شبكة مفتوحة.

لاحظ أنه عند استخدام QUIC، يجب على التطبيق استدعاء SSL_shutdown() إذا أراد ضمان استلام النظير لجميع البيانات المنقولة. هذا يختلف عن اتصال TLS/TCP، حيث يكون النقل الموثوق للبيانات المخزنة مؤقتًا مسؤولية نظام التشغيل. إذا استدعى التطبيق SSL_free() على كائن SSL لاتصال QUIC أو خرج قبل إكمال عملية الإغلاق باستخدام SSL_shutdown()، فقد لا يستلم النظير البيانات التي كتبها التطبيق باستخدام SSL_write()، ولكن لم يمكن نقلها بعد، أو التي أُرسلت ولكن فُقدت في الشبكة.

عند استخدام QUIC، يسمح استدعاء SSL_shutdown() بإجراء معالجة أحداث الشبكة الداخلية. من المهم أن تُجرى هذه المعالجة بانتظام، سواء أثناء استخدام الاتصال أو أثناء الإغلاق. إذا كان التطبيق لا يستخدم وضع الخيط المساعد، فيجب على التطبيق الذي يُجري الإغلاق إما ضمان استدعاء SSL_shutdown() بانتظام، أو بدلاً من ذلك ضمان استدعاء SSL_handle_events() بانتظام. انظر openssl-quic(7) و SSL_handle_events(3) لمزيد من المعلومات.

  سلوك تصريف بيانات التطبيق
عند استخدام QUIC، تنتظر SSL_shutdown() أو SSL_shutdown_ex() عادةً حتى يتم تأكيد جميع البيانات المكتوبة في دفق بواسطة تطبيق من قبل النظير. بعبارة أخرى، تنتظر عملية الإغلاق حتى يتم إرسال جميع البيانات المكتوبة بواسطة التطبيق إلى النظير، وحتى يتم تأكيد استلام جميع هذه البيانات من قبل النظير. فقط عند اكتمال هذه العملية يُعتبر الإغلاق مكتملاً.

الاستثناء من ذلك هو التدفقات التي انتهت بطريقة غير طبيعية، على سبيل المثال بسبب إعادة تعيين دفق؛ فقط التدفقات غير المنتهية في وقت استدعاء SSL_shutdown()، أو التي انتهت بطريقة طبيعية، يتم مسح مخازن الإرسال المعلقة بهذه الطريقة.

يمكن تخطي هذا السلوك لمسح التدفقات أثناء عملية الإغلاق بتعيين العلم SSL_SHUTDOWN_FLAG_NO_STREAM_FLUSH في استدعاء لـ SSL_shutdown_ex()؛ في هذه الحالة، قد لا تُنقل البيانات المتبقية في مخازن إرسال الدفق إلى النظير. يمكن استخدام هذا العلم عند حدوث حالة تطبيق غير طبيعية ولم يعد تسليم البيانات المكتوبة إلى التدفقات عبر SSL_write(3) ذا صلة.

  وضع الإغلاق
يجب على التطبيقات مراعاة جوانب كيفية تعامل QUIC مع إغلاق الاتصال. عادةً، يتوقع QUIC استمرار خدمة الاتصال لفترة زمنية كبيرة بعد إغلاقه اسمياً. هذا ضروري لضمان استلام أي إشعار إغلاق اتصال أُرسل إلى النظير بنجاح. ومع ذلك، فإن نتيجة ذلك هي أن عملية إغلاق اتصال QUIC المتوافقة تماماً مع RFC قد تستغرق في حدود الثواني. قد لا يكون هذا مناسباً لبعض التطبيقات، مثل العمليات قصيرة العمر التي تحتاج إلى الخروج فوراً بعد إتمام معاملة طبقة تطبيق.

وبالتالي، هناك وضعان للإغلاق متاحان لمستخدمي كائنات SSL لاتصال QUIC:

وضع الإغلاق المتوافق مع RFC
    هذا هو السلوك المبدئي. قد تستغرق عملية الإغلاق فترة زمنية تصل إلى ثلاثة أضعاف وقت الرحلة ذهاباً وإياباً (RTT) المقدر حالياً للنظير. من الممكن أن تكتمل عملية الإغلاق بشكل أسرع بكثير في بعض الظروف ولكن لا يمكن الاعتماد على ذلك.

    في وضع الحظر، ستعود الدالة بمجرد اكتمال عملية الإغلاق. في وضع عدم الحظر، يجب استدعاء SSL_shutdown_ex() حتى تعود بقيمة 1، مما يشير إلى اكتمال عملية الإغلاق وأن الاتصال مغلق بالكامل الآن.

وضع الإغلاق السريع
    في هذا الوضع، يتم إخطار النظير بإغلاق الاتصال على أساس أفضل جهد بإرسال حزمة QUIC واحدة. إذا فُقدت حزمة QUIC تلك، لن يعلم النظير أن الاتصال قد انتهى حتى انتهاء مهلة الخمول المتفاوض عليها (إن وجدت).

    سيعود هذا عموماً بقيمة 0 عند النجاح، مما يشير إلى أن الاتصال لم يُغلق بالكامل بعد (إلا إذا كان قد أغلق بالفعل، وفي هذه الحالة سيعود بقيمة 1).

إذا تم تحديد SSL_SHUTDOWN_FLAG_RAPID في flags، يتم تنفيذ إغلاق سريع، وإلا يتم تنفيذ إغلاق متوافق مع RFC.

إذا استدعى تطبيق SSL_shutdown_ex() مع SSL_SHUTDOWN_FLAG_RAPID، يمكن للتطبيق لاحقاً تغيير رأيه بشأن تنفيذ إغلاق سريع بإجراء استدعاء لاحق لـ SSL_shutdown_ex() دون تعيين العلم.

  الإغلاق المبدوء من النظير
في بعض الحالات، قد يرغب تطبيق في انتظار إغلاق بدأه النظير بدلاً من تشغيله محلياً. للقيام بذلك، استدع SSL_shutdown_ex() مع تحديد SSL_SHUTDOWN_FLAG_WAIT_PEER في flags. في وضع الحظر، ينتظر هذا حتى يبدأ النظير إغلاقاً أو يصبح الاتصال منتهياً لسبب آخر. في وضع عدم الحظر، يخرج فوراً إما بالنجاح أو الفشل اعتماداً على ما إذا حدث إغلاق.

إذا تم بالفعل تشغيل إغلاق بدأ محلياً أو بدأ الاتصال في الانتهاء لسبب آخر، فإن هذا العلم ليس له تأثير.

يتضمن SSL_SHUTDOWN_FLAG_WAIT_PEER SSL_SHUTDOWN_FLAG_NO_STREAM_FLUSH، حيث لا يمكن مسح بيانات الدفق بعد إغلاق النظير للاتصال. قد تظل بيانات الدفق تُرسل إلى النظير في أي وقت يُقضى في الانتظار قبل إغلاق النظير للاتصال، على الرغم من عدم وجود ضمان لذلك.

  وضع عدم الحظر
تستقر الدالتان SSL_shutdown() و SSL_shutdown_ex() إذا كان الاتصال مُهيأً في الوضع المُعطِّل. يمكن تجاوز هذا بتحديد SSL_SHUTDOWN_FLAG_NO_BLOCK في flags عند استدعاء SSL_shutdown_ex()، مما يجعل الاستدعاء يعمل كما لو كان في الوضع غير المُعطِّل.

القيم المُرجعة
بالنسبة لكل من SSL_shutdown() و SSL_shutdown_ex()، يمكن أن تحدث قيم الإرجاع التالية:

0   عملية الإغلاق جارية ولم تكتمل بعد.

    بالنسبة لـ TLS و DTLS، يعني هذا أنه أُرسل تنبيه close_notify لكن النظير لم يرد بعد بدوره بـ close_notify الخاص به.

    بالنسبة لكائنات SSL لاتصال QUIC، قد أُرسل إطار CONNECTION_CLOSE لكن عملية إغلاق الاتصال لم تكتمل بعد.

    على عكس معظم الدوال الأخرى، لا يشير إرجاع 0 إلى خطأ. لا ينبغي استدعاء SSL_get_error(3)؛ فقد يشير بشكل مضلل إلى خطأ حتى لو لم يحدث أي خطأ.

1   اكتملت عملية الإغلاق بنجاح.

    بالنسبة لـ TLS و DTLS، يعني هذا أنه تم إرسال تنبيه close_notify وتم استلام تنبيه close_notify من النظير.

    بالنسبة لكائنات SSL لاتصال QUIC، يعني هذا أن عملية إغلاق الاتصال قد اكتملت.

<0  لم تنجح عملية الإغلاق. استدعِ SSL_get_error(3) بقيمة الإرجاع ret لمعرفة السبب. يمكن أن يحدث هذا إذا كان هناك إجراء مطلوب لمواصلة العملية لـ BIOs غير مُعطِّلة.

    يمكن أن يحدث هذا أيضًا عندما لا تُقرأ كل البيانات باستخدام SSL_read()، أو إذا استُدعي على كائن SSL لدفق QUIC.

    تُرجع هذه القيمة أيضًا عند الاستدعاء على كائنات SSL لدفق QUIC.

انظر أيضًا
SSL_get_error(3), SSL_connect(3), SSL_accept(3), SSL_set_shutdown(3), SSL_CTX_set_quiet_shutdown(3), SSL_CTX_set_options(3) SSL_clear(3), SSL_free(3), ssl(7), bio(7)

التاريخ
أُضيفت الدالة SSL_shutdown_ex() في OpenSSL 3.2.

حقوق النسخ
حقوق النشر 2000-2023 لمؤلفي مشروع OpenSSL. جميع الحقوق محفوظة.

مرخص بموجب رخصة Apache 2.0 (المشار إليها فيما يلي بـ ”الرخصة“). لا يجوز لك استخدام هذا الملف إلا وفقًا لشروط الرخصة. يمكنك الحصول على نسخة منها في الملف LICENSE الموجود في حزمة التوزيع المصدرية أو على الرابط <https://www.openssl.org/source/license.html>.

ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 (https://www.gnu.org/licenses/gpl-3.0.html) أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.