Saludos. -------- Forwarded Message -------- Subject: [RFR] wml://security/faq.wml Date: Tue, 16 Aug 2016 17:25:53 -0500 From: Diddier Hilarion <diddierhilarion@gmail.com> To: Debian-es-l10n <debian-l10n-spanish@lists.debian.org> Saludos. On 13/08/16 17:00, Diddier Hilarion wrote: > Saludos. > > -- > Diddier A Hilarion B. > -- Diddier A Hilarion B. -- Diddier A Hilarion B.
#use wml::debian::template title="Preguntas frecuentes sobre la seguridad en Debian" #include "$(ENGLISHDIR)/security/faq.inc" #use wml::debian::translation-check translation="1.94" maintainer="Diddier Hilarion" # $Id: faq.wml,v 1.61 2015/06/08 22:08:06 larjona-guest Exp $ <maketoc> <toc-add-entry name=buthow>He recibido un aviso de seguridad de Debian (DSA) a través de la lista debian-security-announce, como puedo actualizar los paquetes vulnerables </toc-add-entry> <p>R: Como el aviso de seguridad de Debian lo menciona, se deben actualizar los paquetes afectados por dicha vulnerabilidad. Se puede hacer esto actualizando cada paquete en el sistema (después de actualizar la lista de paquetes disponibles usando <tt>apt-get update</tt>) usando <tt>apt-get upgrade</tt> o actualizando el paquete con el error usando <tt>apt-get install <i>paquete</i></tt>. </p> <p> El correo electrónico que anuncia la vulnerabilidad menciona el paquete fuente en el que la vulnerabilidad se encontró. Por lo cual usted debe actualizar todos los paquetes binarios que son generados de ese paquete fuente. Para verificar que paquetes deben ser actualizados, visite <tt>https://packages.debian.org/src:<i>nombre_paquete_fuente</i></tt> y hacer clic en <i>[mostrar ... paquetes binarios]</i> para la distribución en la cual se está haciendo la actualización. </p> <p>Es posible que sea necesario reiniciar un servicio o un proceso. El comando <a href="https://manpages.debian.org/checkrestart"><tt>checkrestart</tt> incluido en el paquete <a href="https://packages.debian.org/debian-goodies">debian-goodies</a> puede indicarle cuales. </p> <toc-add-entry name=signature>¡No se verifica correctamente la firma de sus avisos!</toc-add-entry> <p>R: Casi siempre esto se debe a un problema en su lado. La lista de distribución <a href="https://lists.debian.org/debian-security-announce/">\ debian-security-announce</a> sólo permite el envÃo de mensajes que estén firmados por alguno de los miembros del equipo de seguridad.</p> <p>Lo más normal es que alguna pieza de su software de correo altere ligeramente el mensaje y eso rompa la firma. Asegúrese de que su software no realiza ninguna codificación o decodificación MIME, o conversiones de tabulador/espacio.</p> <p>Algunos programas que suelen causar problemas de este tipo son fetchmail (con la opción mimedecode activada), formail (sólo el de procmail 3.14) y evolution.</p> <toc-add-entry name="handling">¿Cómo se gestiona la seguridad en Debian?</toc-add-entry> <p>R: Una vez que el equipo de seguridad recibe una notificación de un incidente, uno o más miembros lo revisan y consideran si afecta a la versión estable de Debian (es decir, si la versión que allà hay es vulnerable o no). Si ésta versión es vulnerable, se trabaja para arreglar el problema. También se contacta con los encargados del paquete, si es que no se han puesto en contacto todavÃa con el equipo de seguridad. Por último, se prueba la solución y se preparan nuevos paquetes. Después se compilarán para todas las arquitecturas para las que se ofrezca soporte en la versión estable y se publican en el servidor de descargas. Una vez hecho esto, se publica un aviso de seguridad.</p> <toc-add-entry name=oldversion>¿Por qué se molestan en tocar una versión tan antigua de ese paquete?</toc-add-entry> <p>La directriz más importante al hacer un paquete nuevo para que corrija un problema de seguridad es hacer tan pocos cambios como sea posible. Nuestros usuarios y desarrolladores se basan en el comportamiento exacto de una versión una vez que está hecha, asà que cualquier cambio que hagamos puede romper el sistema de alguien. Esto es especialmente cierto en el caso de bibliotecas: nos aseguramos de que no se cambia nunca la API (Interfaz del Programa de la Aplicación) ni la ABI (Interfaz Binario de la Aplicación), por muy pequeño que sea el cambio.</p> <p>Por esto, migrar a una nueva versión, si el autor original tiene una disponible, no es una buena solución; la mejor solución es incorporar los cambios más relevantes (y que introducen el arreglo de seguridad) en la versión disponible. Habitualmente, los desarrolladores originales están dispuestos a ayudar en este trabajo si fuera necesario. Si no es asÃ, el equipo de seguridad de Debian puede prestar su ayuda para hacerlo.</p> <p>En algunos casos, no es posible incorporar una corrección de seguridad en versiones más antiguas porque, por ejemplo, es necesario cambiar o reescribir una gran cantidad de código fuente. Si ésto sucede, puede ser necesario pasar a una versión nueva del autor, pero esto ha de ser coordinado de antemano por el equipo de seguridad.</p> <toc-add-entry name=policy>¿Cuál es la norma que decide que un paquete corregido aparezca en security.debian.org?</toc-add-entry> <p>R: Una vulnerabilidad de seguridad de la distribución estable asegura la aparición de un paquete en security.debian.org. No hay ninguna otra razón. No importa la gravedad de la vulnerabilidad. Normalmente, el equipo de seguridad preparará los paquetes junto con el desarrollador del paquete. Siempre que alguien (de confianza) investigue el problema y envÃe todos los paquetes necesarios compilados al equipo de seguridad, incluso las correcciones a problemas de seguridad más triviales podrán entrar en security.debian.org. Por favor, consulte la información disponible más abajo.</p> <p>Las actualizaciones de seguridad tienen un objetivo: proporcionar una corrección a una vulnerabilidad de seguridad. No son un método para incluir cambios adicionales a la distribución estable sin pasar por el proceso normal de publicación.</p> <toc-add-entry name=version>¡El número de versión de un paquete indica que aún estoy ejecutando una versión vulnerable!</toc-add-entry> <p>R: En lugar de actualizar a una versión más moderna, adaptamos las soluciones a los fallos a la versión que salió en la distribución estable. Hacemos esto para asegurarnos que una versión de la distribución cambia lo menos posible, de manera que las cosas no cambien o fallen de forma inesperada como resultado de una corrección. Puede comprobar si está ejecutando una versión segura de un paquete examinando su registro de cambios (<em>changelog</em>), o comparando su número de versión exacto con el indicado en el Informe de Seguridad de Debian correspondiente.</p> <toc-add-entry name=archismissing>He recibido un aviso, pero parece que no está la compilación para una de las arquitecturas de procesador.</toc-add-entry> <p>R: Generalmente el equipo de seguridad publica un aviso con compilaciones de los paquetes actualizados para todas las arquitecturas que soporta Debian. Sin embargo, algunas arquitecturas son más lentas que otras y puede ocurrir que las compilaciones para la mayorÃa de las arquitecturas estén listas pero algunas aún falten. Estas arquitecturas más pequeñas representan una fracción pequeña de la base de usuarios. Dependiendo de la urgencia del asunto podrÃamos decidir publicar el aviso correspondiente. Las arquitecturas que falten serÃan instaladas tan pronto como estuvieran disponibles, pero no se publicará un nuevo aviso. Por supuesto, nunca publicaremos un aviso en el que las compilaciones para i386 o amd64 no estén presentes.</p> <toc-add-entry name=unstable>¿Cómo se gestiona la seguridad de <tt>inestable</tt>?</toc-add-entry> <p>R: La seguridad en <tt>inestable</tt> la gestionan principalmente los encargados de paquetes, no el equipo de seguridad de Debian. Aunque el equipo de seguridad puede cargar correcciones de seguridad de alta prioridad cuando se sabe que los encargados de los paquetes están inactivos, el soporte para estable siempre tiene prioridad. Si quiere tener un servidor seguro (y estable) le recomendamos encarecidamente que utilice la distribución estable. <toc-add-entry name=testing>¿Cómo se gestiona la seguridad de <tt>testing</tt>?</toc-add-entry> <p>R: La seguridad en «testing» se beneficia de los esfuerzos de seguridad de todo el proyecto para inestable. Sin embargo, hay un retraso mÃnimo de dos dÃas en la migración, y algunas correcciones de seguridad pueden quedar retenidas debido a las transiciones. El equipo de seguridad ayuda a agilizar las transiciones reteniendo actualizaciones importantes de seguridad, pero esto no es siempre posible y pueden ocurrir retrasos. Especialmente en los meses posteriores a la publicación de una nueva versión estable, cuando se cargan en inestable muchas versiones nuevas, las correcciones de seguridad para testing pueden quedar retrasadas. Si quiere tener un servidor seguro (y estable) le recomendamos encarecidamente que utilice la distribución estable. <toc-add-entry name=contrib>¿Cómo se gestiona la seguridad de <tt>contrib</tt> y <tt>non-free</tt>?</toc-add-entry> <p>R: La respuesta corta es que <q>no se gestiona</q>. Contrib y non-free no son partes oficiales de la distribución Debian y no se publican del mismo modo que las versiones oficiales, por tanto no reciben soporte por parte del equipo de seguridad. Algunos paquetes de non-free se distribuyen sin código fuente o con una licencia que no permite la distribución de versiones modificadas. En estos casos no es posible realizar ningún tipo de corrección de seguridad. Si es posible corregir el problema y el responsable del paquete o algún otro proporciona paquetes correctos actualizados, normalmente el equipo de seguridad los procesará y luego publicará el aviso.</p> <toc-add-entry name=sidversionisold>El aviso de seguridad dice que para la versión inestable, el problema está arreglado en la versión 1.2.3-1, pero inestable tiene la 1.2.5-1, ¿qué sucede entonces?</toc-add-entry> <p>R: Intentamos listar la primera versión de «inestable» que arregló el problema. A menudo el encargado ha subido alguna versión nueva mientras tanto. Compare la versión en «inestable» con la versión que le indicamos. Si es la misma o superior, deberÃa estar a salvo de esta vulnerabilidad. Si desea estar seguro, puede verificar el registro de cambios usando <tt>apt-get changelog paquete</tt> y buscando la lÃnea en la que se anuncia la solución al problema. </p> <toc-add-entry name=mirror>¿Por qué no hay réplicas oficiales de security.debian.org?</toc-add-entry> <p>R: En realidad, sà las hay. Hay varias réplicas oficiales, implementadas mediante alias de DNS. El propósito de security.debian.org es ofrecer las actualizaciones de seguridad tan pronto como sea posible.</p> <p>Si recomendáramos el uso de réplicas no oficiales se añadirÃa una complejidad adicional innecesaria y además puede causar frustraciones si las réplicas no se mantiene actualizadas.</p> <toc-add-entry name=missing>He visto el DSA 100 y el DSA 102, ¿qué pasó con el DSA 101?</toc-add-entry> <p>R: Muchos fabricantes (la mayorÃa de GNU/Linux, pero también de derivados de BSD) coordinan los avisos de seguridad para algunos incidentes, y se acuerda un calendario de manera que todos puedan enviar el aviso al mismo tiempo. Se decidió ésto para no discriminar a aquellos que necesiten más tiempo (por ejemplo, cuando un fabricante necesita hacer pasar los paquetes por largas pruebas de calidad o da soporte a varias arquitecturas o distribuciones de paquetes binarios). Nuestro propio equipo de seguridad también prepara los avisos por adelantado. De vez en cuando, aparecen otros problemas de seguridad que deben ser resueltos antes de enviar el aviso que está ya preparado pero <em>aparcado</em>, de ahà el vacÃo temporal entre uno o más números de distintos avisos de seguridad.</p> <toc-add-entry name=contact>¿Cómo puedo ponerme en contacto con el equipo de seguridad?</toc-add-entry> <p>R: La información de seguridad de Debian se puede enviar a security@debian.org o a team@security.debian.org. Los miembros del equipo de seguridad leen correo de ambas direcciones.</p> <p>Si asà lo desea, puede cifrar el correo con la clave de contacto de seguridad de Debian (id. de la clave <a href="http://pgp.surfnet.nl/pks/lookup?op=vindex&search=0x0D59D2B15144766A14D241C66BAF400B05C3E651">\ 0x0D59D2B15144766A14D241C66BAF400B05C3E651</a>). Para obtener las claves PGP/GPG de miembros individuales del equipo, por favor, utilice el servidor de claves <a href="http://keyring.debian.org/">keyring.debian.org</a>.</p> <toc-add-entry name=discover>Creo que he encontrado un problema de seguridad, ¿qué debo hacer?</toc-add-entry> <p>R: Si sabe de un problema de seguridad, bien porque haya ocurrido en uno de sus propios paquetes o en el de algún otro, póngase en contacto con el equipo de seguridad. Si el equipo de seguridad de Debian confirma la vulnerabilidad y otras fuentes se muestran también vulnerables, normalmente también se pone en contacto con esas otras fuentes. Si la vulnerabilidad aún no es pública, el equipo de seguridad intenta coordinar los avisos de seguridad con otras fuentes, para que las distribuciones principales estén sincronizadas.</p> <p>Si la vulnerabilidad ya se conoce públicamente, cerciórese de rellenar un informe del error en el sistema de seguimiento de fallos de Debian, y etiquételo como <q>security</q> (de seguridad).</p> <p>Si es un desarrollador de Debian, <a href="#care">mire más abajo</a>.</p> <toc-add-entry name=care>¿Qué se supone que tengo que hacer si hay un problema de seguridad en algún paquete?</toc-add-entry> <p>R: Si sabe de un problema de seguridad, bien en un paquete suyo o en el de algún otro, póngase en contacto con el equipo de seguridad. Puede hacerlo por correo electrónico a team@security.debian.org. Ellos siguen la pista de los problemas de seguridad, pueden ayudar a los desarrolladores con los problemas de seguridad o incluso arreglar los problemas por sà mismos, y son responsables de enviar los avisos y mantener security.debian.org actualizado.</p> <p>La <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\ Referencia del desarrollador</a> tiene las instrucciones completas sobre qué hacer.</p> <p>Es particularmente importante que no publique nada en ninguna distribución que no sea inestable sin un acuerdo previo con el equipo de seguridad, porque sólo causarÃa confusión y más trabajo.</p> <toc-add-entry name=enofile>He intentado bajar un paquete listado en uno de los avisos de seguridad, pero me ha dado un error de <q>archivo no encontrado</q>.</toc-add-entry> <p>R: Cada vez que se arregla un nuevo error en un paquete más antiguo de security.debian.org, puede ocurrir frecuentemente que el paquete antiguo se elimine al tiempo que se instala el nuevo. Es por esto por lo que aparece el error de <q>archivo no encontrado</q>. No queremos distribuir paquetes con errores de seguridad conocidos más que el tiempo que sea absolutamente necesario.</p> <p>Por favor, use los paquetes anunciados en los últimos avisos de seguridad, y que se distribuyen mediante la lista de correo <a href="https://lists.debian.org/debian-security-announce/"> \ debian-security-announce</a>. Lo mejor es simplemente ejecutar <code>apt-get update</code> antes de actualizar el paquete.</p> <toc-add-entry name=upload>Tengo una corrección a un error, ¿la puedo subir a security.debian.org directamente?</toc-add-entry> <p>R: No, no puede. El archivo de debian.security.org lo mantiene el equipo de seguridad, que tiene que aprobar todos los paquetes. En vez de eso, deberÃa enviar parches o paquetes fuente adecuados al equipo de seguridad, usando <em>Request Tracker</em> (el gestor de solicitudes) o escribiendo a team@security.debian.org. El equipo de seguridad lo revisará y puede subirlo, con o sin modificaciones.</p> <p>La <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\ Referencia del desarrollador</a> tiene instrucciones completas sobre qué hacer.</p> <toc-add-entry name=ppu>Tengo una corrección, ¿puedo publicarla en proposed-updates en su lugar?</toc-add-entry> <p>R: Técnicamente, puede. Sin embargo, no deberÃa, ya que interfiere mucho con el trabajo del equipo de seguridad. Los paquetes de security.debian.org se copian en proposed-updates de forma automática. Si ya hay en el archivo un paquete con el mismo número o mayor, el sistema de archivo rechazará la actualización de seguridad. De esta manera, la distribución estable acabará sin actualizaciones de seguridad para este paquete, a no ser que los paquetes <q>incorrectos</q> del directorio proposed-updates fueran rechazados. Por favor, póngase en contacto con el equipo de seguridad, incluya todos los detalles de la vulnerabilidad y adjunte los ficheros fuente (ficheros dsc y diff.gz) al mensaje.</p> <p>La <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\ Referencia del desarrollador</a> contiene instrucciones completas sobre cómo hacer esto.</p> <toc-add-entry name=SecurityUploadQueue>Estoy casi seguro de que mis paquetes están bien, ¿cómo puedo publicarlos?</toc-add-entry> <p>R: Si está muy seguro de que sus paquetes no rompen nada, de que la versión es la correcta (por ejemplo, mayor que la versión de estable y menor que la versión de testing/inestable), de que no cambió el comportamiento del paquete —salvo el problema de seguridad correspondiente—, de que lo compiló para la distribución adecuada (esto es, <code>oldstable-security</code> o <code>stable-security</code>), de que el paquete contiene el código fuente original si es nuevo en security.debian.org, de que puede confirmar que el parche aplicado a la versión más reciente está limpio y sólo afecta al problema de seguridad correspondiente (compruébelo con <code>interdiff -z</code> y ambos archivos <code>.diff.gz</code> files), de que ha revisado las pruebas al menos tres veces y de que <code>debdiff</code> no muestra ningún cambio, puede publicar los archivos en el directorio incoming <code>ftp://security-master.debian.org/pub/SecurityUploadQueue</code> de security.debian.org directamente. Mande también una notificación con todos los detalles y enlaces a team@security.debian.org.</p> <toc-add-entry name=help>¿Cómo puedo ayudar con la seguridad?</toc-add-entry> <p>R: Por favor, revise cada problema antes de enviarlo a security@debian.org. Podrá acelerar el proceso si es capaz de enviar parches. No nos redireccione simplemente correos de bugtraq, porque ya los recibimos — si puede ofrézcanos información adicional sobre las cosas de las que ya se haya informado en bugtraq. <p>Una buena manera de empezar con el trabajo de seguridad es ayudando en el <q>Debian Security Tracker</q> (<a href="https://security-tracker.debian.org/tracker/data/report">instrucciones</a>).</p> <toc-add-entry name=proposed-updates>¿Cuál es el propósito de proposed-updates?</toc-add-entry> <p>R: Este directorio contiene paquetes que se ha propuesto que entren en la siguiente revisión estable de Debian. Cuando un desarrollador envÃa un paquete para la distribución estable, acaba en el directorio proposed-updates. Como estable implica estabilidad, no se hacen actualizaciones automáticas. El equipo de seguridad enviará los paquetes corregidos mencionados en sus avisos a la estable, y si no, se depositarán antes en proposed-updates. Cada par de meses el Gestor de Versiones Estables (<em>Stable Release Manager</em>) revisa la lista de paquetes en proposed-updates y discute si un paquete debe ir a la distribución estable o no. Entonces se compila en en otra revisión de la estable (por ejemplo, 2.2r3 o 2.2r4). Los paquetes que no se ajuste a esto probablemente también serán rechazados o eliminados de proposed-updates.</p> <p>Tenga en cuenta que los paquetes que suben los desarrolladores (no el equipo de seguridad) al directorio proposed-updates/ no tienen soporte del equipo de seguridad.</p> <toc-add-entry name=composing>¿Quién forma parte del equipo de seguridad?</toc-add-entry> <p>R: El equipo de seguridad está formado en la actualidad de <a href="../intro/organization#security">varios técnicos y secretarios</a>. El propio equipo de seguridad es el que invita a la gente que desee a que se una al grupo.</p> <toc-add-entry name=lifespan>¿Durante cuánto tiempo se proporcionan actualizaciones de seguridad?</toc-add-entry> <p>R: El equipo de seguridad intenta dar soporte a la distribución estable durante aproximadamente un año tras la publicación de la siguiente distribución estable, salvo en el caso de que sea liberada otra distribución durante ese año. No es posible dar soporte a estas tres distribuciones; ya es bastante difÃcil dar soporte a dos de ellas simultáneamente.</p> <toc-add-entry name=check>¿Cómo puedo verificar la integridad de los paquetes?</toc-add-entry> <p>R: Este proceso implica la verificación de la firma del archivo <q>Release</q> con la <a href="https://ftp-master.debian.org/keys.html">\ clave pública</a> que usa el archivo. El archivo <q>Release</q> tiene las sumas de verificación de los archivos <q>Packages</q> y <q>Source</q>. En el <a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\ Manual de seguridad de Debian</a> se encuentran las instrucciones detalladas para comprobar la integridad de los paquetes.</p> <toc-add-entry name=break>¿Qué hacer si un paquete cualquiera se rompe tras una actualización de seguridad?</toc-add-entry> <p>R: Primero deberÃa averiguar por qué se ha roto el paquete y cómo está el fallo relacionado con la actualización de seguridad. Después, póngase en contacto con el equipo de seguridad si el problema es muy grave o con el responsable de la publicación estable si no es tan grave. En este caso estamos hablando de paquetes al azar que se rompen tras la actualización de seguridad de otro paquete. Hable también con el equipo de seguridad si no es capaz de averiguar qué ha ido mal pero tiene un arreglo para el problema. Tenga en cuenta que es posible que éstos le reenvÃen al responsable de la publicación estable.</p> <toc-add-entry name=cvewhat>¿Qué es un identificador CVE?</toc-add-entry> <p>R: El proyecto «Common Vulnerabilities and Exposures» asigna identificadores únicos, llamados identificadores CVE, a vulnerabilidades de seguridad especÃficas, para hacer más fácil la referencia unÃvoca a un asunto especÃfico. Se puede encontrar más información en <a href="http://es.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">\ Wikipedia</a>.</p> <toc-add-entry name=cvedsa>¿Emite Debian un DSA para cada identificador CVE?</toc-add-entry> <p>R: El equipo de seguridad de Debian lleva cuenta de cada identificador CVE emitido, lo conecta al paquete correspondiente de Debian y evalúa su impacto en el contexto de Debian; el hecho es que algo que tenga asignado un identificador CVE no implica necesariamente que el asunto sea una amenaza seria para un sistema Debian. Esta información se registra en el <a href="https://security-tracker.debian.org">Debian Security Tracker</a> y para los asuntos que se consideran serios se emitirá un Aviso de Seguridad de Debian («DSA»).</p> <p>Los asuntos de bajo impacto que no se cualifican para un DSA pueden arreglarse en la siguiente publicación de Debian, en un punto de publicación de las distribuciones estable y oldstable actuales, o se incluyen en un DSA cuando se emite éste para una vulnerabilidad más seria.</p> <toc-add-entry name=cveget>¿Puede Debian asignar identificadores CVE?</toc-add-entry> <p>R: Debian es una autoridad de numeración de CVE y puede asignar identificadores, pero sólo a asuntos que aún no se hayan desclasificado, por polÃtica de CVE. Si usted tiene una vulnerabilidad de seguridad no desclasificada para software en Debian y le gustarÃa obtener un identificador para la misma, contacte con el equipo de seguridad de Debian. Para casos donde a vulnerabilidad ya es pública, recomendamos seguir el procedimiento detallado en el <a href="http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html">\ CÃ?MO solicitar CVE en software libre</a>.</p> <h1>Preguntas frecuentes de seguridad de Debian (obsoletas) </h1> <toc-add-entry name=localremote>¿Qué significa <q>local (remoto)</q>?</toc-add-entry> <p>R: Algunos avisos describen vulnerabilidades que no se pueden identificar con el esquema clásico de aprovechamiento local y remoto. De algunas vulnerabilidades se puede sacar provecho de forma remota, por ejemplo, si no corresponde a un demonio que está leyendo de un puerto de la red. En caso de que se pueda sacar provecho de archivos especiales que se puedan distribuir por la red, aunque el servicio vulnerable no esté conectado permanentemente con la red, denominamos a este tipo de incidencia <q>local (remota)</q>.</p> <p>Estas vulnerabilidades están a medio camino entre las locales y las remotas y suelen referirse a archivos que se pueden distribuir por la red, como adjuntos de correo o descargándolos de una página.</p>
Attachment:
signature.asc
Description: OpenPGP digital signature