Zammad: PGP

+1 para compatibilidad con S/MIME

Vale, he cambiado el título. Lo mejor sería, por supuesto, si ofreciera ambas cosas.

Agradecería tener la posibilidad de enviar y recibir correos encriptados X.509.

SÍ, sería muy bueno poder enviar y recibir correos X.509 firmados o encriptados.

Entonces, los correos cifrados X.509 son correos S/MIME. Personalmente, me gustaría más PGP (también porque está más extendido), pero este tema es sobre ambos sistemas. 😃

Agregaría notificaciones cifradas a la lista de deseos; por lo tanto, los usuarios deben poder agregar su clave pública a su perfil.

FYI: existe un buen complemento con dicha funcionalidad para redmine: https://github.com/C3S/redmine_openpgp

Esta gema parece no estar realmente mantenida (última confirmación), pero hay muchas otras . Personalmente, diría que esta joya tiene la confirmación más reciente.

Hoy tuvimos la primera solicitud de un cliente solicitando PGP-Support porque no quería solicitar sus datos bancarios a través de una conexión no cifrada. Por lo tanto +1

+1.
Estamos trabajando con la comunidad de IT SEC y recibimos toneladas de correos cifrados con PGP que no podemos abrir en Zammad, por lo que tenemos que exportar y descifrar, es un flujo de trabajo increíble. +1 por admitir PGP y tal vez S/MIME Mails en Zammad :)

Hoy en día, el cifrado de correo electrónico es imprescindible. El Reglamento General de Protección de Datos (RGPD) exige la Privacidad desde el Diseño y por Defecto y según el estado de la técnica.

Técnicamente, esto podría ser fácil de resolver integrando el motor p≡p (privacidad bastante fácil).

+1
A menudo recibimos correos cifrados. Exportar y descifrar manualmente los boletos encriptados es doloroso, y luego ni siquiera podemos responder a los boletos a través del sistema de boletos.

+1
Sin PGP/GPG no puedo migrar de OTRS a Zammad. Tengo muchos tickets encriptados con gnupg en mi antiguo OTRS.

+1

Nos gustaría que GnuPG firme todos los correos electrónicos de tickets salientes después de un caso muy desagradable de falsificación de nuestro correo electrónico para robar a nuestros clientes.

Tal vez PeP podría integrarse ya que es una solución fácil y útil para el cifrado PGP.

También creo que sería una gran característica enviar correos electrónicos firmados. Esto le daría cierto grado de confianza al destinatario, que la dirección es real y confiable.

El siguiente paso sería cifrar completamente el mensaje.

@martini @monotek estamos pensando en abordar la parte GPG de esto nosotros mismos, internamente. ¿Hay alguna restricción para fusionar esto, si lo hacemos? ¿Alguna funcionalidad que le gustaría ver o requerir?

Hola @luto , ¡suena bien! Las cosas que se requieren para una fusión son:

• Pruebas, preferiblemente RSpec
• Documentación
• Documentación de API de código
• Código QAd a través de nuestra configuración de rubocop y coffeelint

Ya vimos algunas gemas de Ruby que proporcionan una API para el binario gpg CLI. Por lo que recuerdo, ninguno de ellos parecía realmente prometedor. Asegúrese de confiar solo en dependencias mantenidas/de calidad, ya que este es un punto crítico.
Es posible una implementación personalizada, pero tenga en cuenta la extensibilidad y el mantenimiento. No ponga toda la lógica en el módulo, pero cree una clase lib para él. Respetar el principio de responsabilidad única.

La funcionalidad debe incluir todas las variaciones de firma, verificación y cifrado/descifrado de envío y recepción de correos 🤓
El manejo de los mensajes entrantes debe hacerse lo antes posible para que el contenido esté accesible en otros componentes.
El manejo de los mensajes salientes debe realizarse lo más tarde posible para poder acceder al contenido de otros componentes.

Debe haber una buena interfaz de administración para administrar las claves públicas y privadas.

No dude en contactarnos en [email protected] para hacer cualquier pregunta que tenga y obtener nuestro apoyo al respecto. Estamos más que felices de recibir el tuyo 💪 Hagámoslo a la manera de Zammad 🏎

También obtuvimos el primer cliente que requiere dicha comunicación, así que también voto por este. ¿Ya hay algún avance? También me gustaría ayudar a probar una versión beta.

@martinseener afaik esto no está en la hoja de ruta del equipo de Zammad. Actualmente estamos planeando implementar esto por nuestra cuenta. Si desea participar, para que podamos hacerlo más rápido y pueda atender a su cliente, no dude en comunicarse a través de la dirección de correo electrónico en mi perfil de github.

@thorsteneckel Actualmente estoy creando un prototipo de una implementación para recibir correos en dos partes:

1. descifrar el correo en Postmaster::PreFilter : establecer el mensaje descifrado como contenido; tirar el original; almacenar la clave de descifrado utilizada en los metadatos
2. en Postmaster::PostFilter crea un objeto GpgCryptoInfo , adjúntalo a Article ; almacenar información como la clave de descifrado utilizada y el estado de la firma de forma permanente

Un par de preguntas:

• ¿Crees que esto debería implementarse usando esas API de filtro? ¿O debería estar codificado en Channel::EmailParser ?
• ¿Hay suscriptores Postmaster::PreFilter que necesiten acceso al contenido del mensaje descifrado? En este caso, se necesita una implementación codificada o Postmaster::EarlyPreFilter .
• ¿Hay alguna información, excepto la clave utilizada para cifrar/descifrar/firmar/verificar, así como el estado de la firma del correo recibido, que le gustaría que se mantuviera de forma permanente?

Además, una pregunta general: EmailParser o los filtros parecen ser el lugar perfecto para _descifrar_ correos; ¿Se te ocurre un lugar "perfecto" para encriptarlos?

Espero que este número sea el lugar adecuado para hacer preguntas sobre la implementación. Si no es así, indíqueme otro, preferiblemente público, uno :) ¡Gracias!

Hola @luto : actualmente estoy escribiendo mis pensamientos sobre esto. Dado que es un tema bastante grande e importante, lleva algo de tiempo. Intento hacerlo para el final de la semana. Gracias por su comprensión.

Pequeña actualización: se ordenan Postmaster::PreFilter filtros. Actualmente coloqué el mío justo después IdentifySender , por lo que puedo averiguar qué claves gpg probar. Sabiendo eso, los filtros parecen ser el lugar adecuado para descifrar para mí.

@thorsteneckel ¡ Gracias por tomarte el tiempo! Esperando tu redacción. :)

Hola @luto , ¡me alegra escuchar eso! Me gusta tener la coordinación en este tema como lo propusiste. Por lo tanto, será transparente y podremos reutilizar la información compartida para una documentación técnica. Puede hacer referencia a este problema en su rama de trabajo de su bifurcación y se hará referencia aquí. Cree una solicitud de extracción después de completar los cambios. Mientras tanto, revisaré su sucursal y veré los cambios.
Deberíamos mover la funcionalidad S/MIME a un problema separado ya que no la implementaremos ahora.

Con respecto a tus preguntas: Estás totalmente en el camino correcto. Escribiré algunas cosas y responderé a sus preguntas en el camino.

desarrollo general

Según nuestra experiencia, el desarrollo basado en pruebas (con RSpec) funciona mejor para este tipo de tareas. Depende de usted cómo lo aborda, pero definitivamente necesitaremos un conjunto de pruebas completo para la funcionalidad. Por lo tanto, le proporcionaré un ayudante de RSpec para facilitar las pruebas y brindarle apoyo en el camino lo mejor que pueda. Lo agregaré a la rama develop en los próximos días. Debería usar esta sucursal como su base, ya que también es nuestra sucursal de trabajo. Se fusionará con el maestro y reemplazará al estable en el futuro.

Postmaster::Prefiltro

Postmaster::PreFilter s son el lugar correcto. Puede influir en el tiempo de ejecución mediante un prefijo numérico en el nombre del registro del filtro . Los números más bajos se ejecutarán antes .
Para los sistemas ya inicializados , también se necesita una migración que agregue la configuración .
Propondría un nombre algo así como app/models/channel/filter/decrypt.rb , pero al final depende de usted.

Una vez realizado el registro, Zammad ejecutará el filtro para cada correo entrante.

clase de mensaje PGP

Dado que solo implementaremos PGP en este punto, debemos asegurarnos de que no agregaremos obstáculos para agregar S/MIME más adelante. Además, podría ser necesario en el futuro admitir PGP en otros canales además del correo electrónico. Tener esto en mente garantizará que el backend y la API que diseñemos sean fáciles de probar e integrar. Siguiendo mi propuesta (abierta a discusión):

Debería haber una clase llamada PgpMessage ubicada en el archivo lib/pgp_message.rb . Esta clase toma un argumento obligatorio que será (posiblemente) la cadena del mensaje cifrado/el contenido del correo. Ejemplo:

instance = PgpMessage.new(email_content)

La instancia debe proporcionar la siguiente interfaz:

• #firmado?
• #verificado?(firma) # la firma es opcional y puede ser una firma externa de, por ejemplo, un archivo adjunto
• #firma_error
• #encriptado?
• #decribable?
• #descifrado
• #llave
• #error de descifrado
• #cifrar( clave_pública(s) )
• #firmar

interfaz PGP

Para ser honesto, no he encontrado ninguna joya que me guste tener como dependencia. Todos parecen no mantenidos, complejos o necesitan compilación C de extensiones. Podría valer la pena intentarlo si no podemos simplemente acceder a la CLI de PGP. ¿Qué piensas?

Integración de PgpMessage en Postmaster::PreFilter para descifrado

La clase PgpMessage se puede usar en Postmaster::PreFilter para inicializar una instancia y verificar la relevancia del mensaje. Si se trata de un mensaje cifrado con PGP, podemos utilizar los otros métodos para extraer los datos que necesitamos y sobrescribir el contenido de body y attachments en el hash dado mail .
Además, tenemos que almacenar cierta metainformación (como ya indicó) en el artículo que se creará configurando el encabezado x-zammad-article-preferences :

mail[:'x-zammad-article-preferences']['decryption_key'] = instance.key
...

Creo que los siguientes metadatos deberían ser suficientes:

• decryption_key <- clave
• decryption_error <- decryption_error (en caso de existir)
• mensaje_cifrado <- correo['cuerpo']
• signature_status <- verificado?
• signature_error <- signature_error (en caso de existir)

variaciones admitidas de mensajes descifrables

La clase PgpMessage debería poder manejar (¿al menos?) las siguientes combinaciones y variaciones de mensajes PGP entrantes:

• encriptado
• firmado
• encriptado + firmado
• en línea
• adjunto archivo

¿Ya tienes suficientes correos de ejemplo?

Tenemos que tener una lista completa de casos de prueba para cubrir varios casos que puedan ampliarse fácilmente en el futuro.

enviar mensajes encriptados

Dado que Zammad solo admite el envío de correos electrónicos HTML , solo necesitamos cubrir el envío detached correos PGP.

El lugar donde Zammad crea un correo electrónico a partir de atributos determinados es app/models/channel/email_build.rb en el método self.build . Esto debería extenderse para usar la clase PgpMessage para crear una instancia con el atributo body dado y usar los métodos encrypted y signed para crear el cifrado PGP y el contenido del cuerpo firmado y los archivos adjuntos.
Para ello es necesario consultar las claves públicas de las direcciones de correo electrónico de los destinatarios. Aún no está claro cómo los usuarios pueden almacenar su clave (en su perfil). Discutiré esto internamente y te lo haré saber.

Creo que no debería haber opción para enviar correos sin cifrar una vez que se configura PGP y el destinatario lo admite. Necesitamos aclarar esto, pero hasta entonces este debería ser el camino a seguir.

Interfaz de administración

Esto debe aislarse de la funcionalidad principal y se describirá más adelante. Creo que necesitarás nuestro apoyo en esto. Lo discutiré internamente y le haré saber cómo lo abordamos.

Conclusión

Esto debería ser suficiente por ahora y apuntar en la dirección correcta. Probablemente lleguemos a algunos puntos en los que tengamos que realinear y cubrir otros casos, pero dejemos que surjan primero.
Siéntete libre de hacer cualquier pregunta si surge.

Estoy deseando ver y revisar tus cambios 🤓

Gracias por su apoyo 🚀
Thorsten

Para ser honesto, no he encontrado ninguna joya que me guste tener como dependencia. Todos parecen no mantenidos, complejos o necesitan compilación C de extensiones. Podría valer la pena intentarlo si no podemos simplemente acceder a la CLI de PGP. ¿Qué piensas?

La CLI de PGP no es estable y, según GPG, no debe usarse como una API. He tenido éxito usando ruby-gpgme hasta ahora, así que esa es la ruta que me gustaría seguir por ahora. Dado que, hasta donde yo sé, GPG no tiene una API, sino solo bibliotecas de nivel C, no creo que podamos salir adelante sin ninguna extensión de C... excepto por una reimplementación de GPG en Ruby tal vez, pero no conozco ninguno

Gracias por dejarlo claro. Yo no estaba al tanto de eso. Me parece bien entonces. Es un poco preocupante que sus compilaciones estén fallando, pero le echaré un vistazo.

¡Hola! Como se discutió anteriormente, este problema comenzó como una solicitud de la funcionalidad PGP. Más tarde también agregamos S/MIME. Pero dado que ambos se implementan de forma independiente y son tecnologías diferentes, decidimos trasladar el requisito de S/MIME al nuevo número 1961. Siéntase libre de suscribirse allí si está interesado en algún progreso. Las discusiones deben volver a realizarse en la junta comunitaria para evitar ruido en el rastreador de problemas. ¡Gracias!

Por lo tanto, le proporcionaré un ayudante de RSpec para facilitar las pruebas y brindarle apoyo en el camino lo mejor que pueda. Lo agregaré a la rama de desarrollo en los próximos días.

@thorsteneckel ya ha llegado y, en caso afirmativo, ¿dónde está exactamente? :)

@luto - perdón por la demora - aquí está: https://github.com/zammad/zammad/commit/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d

Solo necesita colocar un *filter_filename*_spec.rb en spec/models/channel/filter/ (como se hizo para models/channel/filter/follow_up_merged.rb y agregar , type: :channel_filter después del nombre de su clase de filtro.
Después de eso, tienes dos ayudantes disponibles:

filter_parsed(mail_string) :
https://github.com/zammad/zammad/blob/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d/spec/support/channel_filter.rb#L17 -L27

y filter(parsed_mail_hash) :
https://github.com/zammad/zammad/blob/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d/spec/support/channel_filter.rb#L3 -L13

El parámetro nombrado channel es opcional y no debería ser necesario en su caso.

¡Gracias!
FYI: la rama vive en nuestra bifurcación ahora. siéntase libre de comentar sobre cualquiera de los compromisos a medida que avanzo. Eso debería mantener la revisión final fácil y corta para todos los involucrados :)

Hola @luto , es genial verte trabajar en esto con ese ritmo. Noté que el código no parece haber sido verificado con rubocop. Usamos rubocop y coffeelint para garantizar la guía de estilo de Zammad para ambos tipos de archivos. Incluso hay una configuración de filtro previa a la confirmación disponible si desea realizar las comprobaciones automáticamente. Avísame si puedo darte más información al respecto.

Oh, cosa segura. Instalé el gancho con pre-commit install así como la extensión correspondiente para mi editor . La sangría se corrigió a través filter-branch , por lo que el historial se ve mejor; todos los demás delitos se arreglaron a mano. El policía es mayormente feliz ahora :)

Es posible que observe una con pitonismos en el código. Si bien trato de emular la forma rubí de hacer las cosas lo mejor que puedo, sigo siendo un pitón de oficio;) Por favor, solo señale las cosas, si le parecen al revés. Rubocop atrapó bastantes de ellos :sweat_smile:

¡Bonito! Acabo de notar que hay al menos un tipo de cambios aplicados que no coinciden con nuestra configuración de rubocop: usar unless en lugar de if negativos. Entonces parece que su rubocop está haciendo mucho aquí.

Oh, los pitonismos están bien para mí. Nada de lo que quejarse hasta ahora 🤓

Hola, @luto : solo quería ver el estado actual del desarrollo, pero noté que no había ningún compromiso desde hace 24 días. ¿Hay algo que pueda hacer?

¿Hay algo que pueda hacer?

arreglando nuestros otros proyectos internos :wink: :grin:
No hay bloqueador dentro de los límites de Zammad, solo una falta general de tiempo. El trabajo en esto debería continuar la próxima semana.

@thorsteneckel Me encontré con un inconveniente. Gpg (o al menos gpgme) no distingue entre "el correo electrónico está cifrado, pero no se puede descifrar" y "el correo electrónico está cifrado y todo está bien" en la mayoría de los casos. Ese comportamiento no es compatible con los métodos encrypted? y decryptable? descritos anteriormente. En este momento tengo una serie de trucos para detectar correos cifrados, pero no descifrables, pero no puedo hacer que funcione en todos los casos.

¿Qué opinas sobre no hacer una distinción entre descifrado y cifrado en la interfaz de usuario? Excepto en casos obvios como la falta de un encabezado de mensaje GPG, ofc.

¿Cuándo podemos esperar la implementación e integración en Zammad? ¿La implementación está planificada para una versión específica?

¿Hay noticias?

Tengo la sensación de que aquellos que podrían adelantar el desarrollo de este complemento tienen otras cosas en mente, pero están revisando las respuestas sobre este tema.
Si desea llamar su atención sobre esto, puede escribirles un correo electrónico: [email protected] - Ya lo hice - o enviarles un tweet amistoso @ubernauten

@hatscher perdón por el retraso; como @0xErnie supuso que actualmente tengo otras cosas que hacer, pero esta característica todavía está en nuestro radar. Tenga en cuenta que actualmente estoy trabajando en este solo, no como parte del equipo de Zammad, Inc. y sin ninguna financiación externa. Así que esto puede llevar un tiempo.

En cuanto a los bloqueadores, hay una pregunta para @thorsteneckel abierta aquí, así como una pregunta privada sobre cómo abordaremos el componente de interfaz de usuario de esto. No dude en contactarlo, si desea contribuir para hacer avanzar esto, ¡@hatscher! Sin embargo, el principal bloqueador es mi falta de tiempo.

¡Perdón por la respuesta tardía, especialmente para ti @luto ! No puedo darle a esto el tiempo y la atención que necesita actualmente. Planeo abordar esto en 2 semanas a partir de ahora.

¿Hay noticias? Necesitamos esta función...

@hatscher muchos de nosotros lo necesitamos :) Pero después de todo, todos los que están trabajando en la función (@luto) lo hacen voluntariamente :) Si hay una necesidad comercial real, supongo que donar (ya sea algo de dinero o trabajo) ayudaría a impulsar adelante el progreso. Desafortunadamente no tengo tiempo para contribuir, así que todo lo que me queda es esperanza y paciencia :P

Hablando de contribuciones: ¿Qué tal enviar el estado actual de desarrollo como relaciones públicas para que otros puedan unirse si sienten que pueden contribuir?

Dado el triste estado de las GPG-API tanto en Ruby como en general, podría valer la pena echarle un vistazo a la nueva implementación de GPG rust .

Con un grano de sal:

ENCUADERNACIONES PRÓXIMAMENTE!

¿Hay alguna noticia sobre la integración de PGP y S/MIME? También me gustaría donar una cantidad porque necesito esta función con urgencia.

¿Hay realmente una lista con las características previstas de las próximas versiones?

Hola @hatscher ,
también necesitamos S/MIME y estamos en conversaciones con Zammad sobre los costos. ¿Queremos hablar entre nosotros para que tal vez podamos compartir los costos de integración? Tal vez solo envíeme un correo electrónico (firstname at lastname de).

El correo electrónico está en camino ;-)

Actualmente estamos buscando otras personas que estén dispuestas a financiar esta función (quizás también junto con el cifrado S/MIME como paquete). Por favor, póngase en contacto conmigo si está interesado en mi nombre en lastname .de. Revisaré y veré cuántas personas dispuestas hay para que podamos compartir los costos.

@martinseener Es genial saber que intentó obtener fondos para esta función. ¿Podría compartir el progreso realizado o los problemas que encontró? El soporte de PGP actualmente está tomando o deshaciendo una decisión con respecto a un cambio a Zammad, por lo que agradecería cualquier información.

Lo sentimos, pero en este momento no podemos compartir ninguna información sobre este tema.
Actualizaremos este problema en consecuencia tan pronto como algo se mueva para Zammad-Core.

Mirando su tiempo de respuesta de varios meses y las discusiones previas sobre este tema, llego a la conclusión de que agregar compatibilidad con PGP a Zammad no es una prioridad para usted o no sucederá en absoluto. (Solo resumiéndolo aquí para cualquiera que venga en el futuro y no quiera leer la discusión completa).

Hola @rixx , tienes razón. Actualmente estamos trabajando en tareas basadas en nuestro esquema de prioridad:

1º: soporte / desarrollo personalizado
Estas son las personas que financian Zammad y las funciones que lanzamos. Zammad no estaría aquí hoy sin ellos. Tenerlos realmente significa mucho para nosotros y nos anima a que estemos en el camino correcto.

2do: 80% características/problemas
El tiempo libre que ganamos con el apoyo de nuestros clientes es gastar el 100% en el producto. Es importante para nosotros ser igualmente justos con cualquier usuario de nuestra base de usuarios. Sin embargo, tan pronto como se trata de los detalles, hay más y más decisiones que debemos tomar a favor de una parte sobre la otra. Por lo tanto, solo trabajamos en funciones y problemas que afectan al 80 % de nuestra base de usuarios. De esta manera, podemos asegurarnos de que la mayoría de nuestra base de usuarios se beneficie de los cambios que introducimos.

3º: Interés personal
Aquí en Zammad todo el mundo es libre de dedicar su tiempo a tareas que son de su interés personal. Si echa un segundo vistazo, notará que respondemos a problemas y preguntas que no entran en la categoría de cambios financiados o más relevantes. Esto se debe a que realmente nos preocupamos y disfrutamos ayudar a las personas. Sin embargo, estas son en su mayoría tareas más pequeñas porque el tiempo libre actualmente es muy limitado, desafortunadamente.

Ahora para volver al tema: PGP actualmente no cae en ninguna de las categorías enumeradas anteriormente. Es por eso que tiene razón cuando dice que actualmente no es una alta prioridad para nosotros. Sin embargo, te equivocas cuando dices que PGP no sucederá en absoluto. PGP tiene una prioridad comparativamente alta para nosotros, en realidad está en nuestro borrador interno para la hoja de ruta pública que incluye solo los cambios más relevantes.
Así que el momento de PGP aún no ha llegado, pero seguramente lo hará. Dependiendo del esquema de prioridad, tarde o temprano.
Lo que me falta en su resumen es el hecho de que el desarrollo de PGP en realidad ya se inició como un esfuerzo comunitario de @luto con nuestro apoyo (¡gracias de nuevo @luto !). Desafortunadamente, la prioridad cambió y el cambio actualmente está obsoleto. Sin embargo, ¡todos los que tengan el conocimiento y la capacidad para retomar las cosas y continuar trabajando en ello serán apoyados por nosotros con seguridad!

También hay noticias para cualquier persona interesada en el tema general de la comunicación cifrada: la gran gente de @martinseener en barzahlen.de financió el desarrollo de la comunicación S/MIME (#1961), que pronto comenzará.

Si está interesado en profundizar esta discusión o incluso contribuir, siéntase libre de abrir un hilo o enviarme un mensaje privado a la junta de la comunidad y mantener este tema en el tema.

¿Alguna noticia sobre la "comunicación S/MIME"?

Si tiene que preguntar, al menos use el lugar correcto: https://github.com/zammad/zammad/issues/1961

Lo siento, debido a la falta de comentarios en los últimos meses, limito este problema solo a los colaboradores.
Esto es para reducir el ruido y nos ayuda a concentrarnos en los problemas.

Si tenemos alguna actualización sobre esto, actualizaremos este problema en consecuencia.

Como habrás visto en #1961, hemos agregado compatibilidad con S/MIME y lo lanzaremos con la próxima versión 3.4 de Zammad 🎉 Muchas gracias a @martinseener en barzahlen.de por patrocinarlo y, por lo tanto, hacerlo posible 🙌
Desafortunadamente, todavía no tenemos los recursos necesarios para agregar soporte PGP también. Estábamos pensando en probar algunas cosas, pero aún no hemos tenido la oportunidad. Es por eso que quería darles una breve actualización aquí.
Sin embargo, la integración S/MIME proporciona un "marco" casi completo para manejar el correo seguro y una buena implementación de referencia sobre cómo se deben integrar/construir las cosas. Todavía queda el gran trabajo inicial realizado por @luto en la bifurcación de Uberspace . Si alguien está dispuesto a arriesgarse, estaremos encantados de ayudar con todo lo que podamos. Solo abre un hilo en el foro de la comunidad y mencióname.

Lo mantenemos actualizado a medida que hay nueva información disponible - prometido ✌️