I’ve owned a TaoTronic TT-BH22 headphones with noise cancellation for a while ago, and I can tell you that despite being quite cheap have worked perfectly for me. Battery life is fantastic (around 40 hours) and noise cancelling, even if it’s not 100% perfect as the professional ones, is more than acceptable.

However, then I bought those I didn’t realize that they had an integrated microphone, and I think that during the first year of use I left this feature forgotten and unused since my SO didn’t recognized it right away. Sad thing is, it wasn’t until my husband tried them on his laptop and his SO recognized the microphone, that we knew about this.

And even sadder than that? We both use the same SO… so it was time to work around this and figure out why it was working on his laptop and not on mine, so if anyone has encountered an issue like this, here’s a solution that should work with every headphone with a built in microphone just like mine.

All problem was this: Like this headphones have a high fidelity sound  (Hi-Fi)  my system didn’t recognized them as regular headphones and “assumed” they didn’t had a microphone, that was it…

Now it was just time to configure correctly the headphone type, however, KDE’s Bluetooth config app is too simple and doesn’t allow more advanced settings, so I installed blueman, which is Gnome’s Bluetooth settings app and allowed me to configure easily my little gadget without going to the terminal. So lets install blueman as root:

[root@libro ]# dnf -y install blueman

And with this app we can configure our Bluetooth devices better. when we open the app the first thing we see is the list of recent devices.

  • We will locate our headphones on this list and right-click it to see the menu.
  • Will select the option “audio profile” .
  • And finally select the option Headset Head Unit (HSP/HFP).

And that’s it, you should be able to see your microphone between the audio device list and select it.

Now this happy girl can walk around the house while makes herself a coffee in between the million meetings we have now during this pandemic.

Let me know if this worked for you, and specially, which headphones did you configured so I can add them to this list.

  • TaoTronics TT-BH22

This post has a nicer formatting that can be seen at it's original source at tatica.org , so feel free to hit the link and read better version!

When we are creating a book that will be published at Amazon Kindle Store and we want it to be printed as well as digital, we need to have some important considerations when comes to create the cover.

It’s not just about having an attractive cover that encourage readers to buy, but it also has to be functional when comes to content, paper type and even the thickness of the book itself. Anyway, the idea is to have a working cover that won’t ve rejected by the automated verification process that Amazon holds.

When comes to select our book properties, we not just have a wide sizes variety, but also we have to decide is it will be printed on black/white or color. Besides, we will have to choose the thickness and quality of the paper, so we can begin to estimate the size and cost of our book.

For this example, we will assume we are creating a cover for a 6″x 9″ (15.24 x 22.86 cm) book

The most important when comes to create a book cover are the dimensions, since it won’t matter to have a fantastic cover that crops, is unreadable or is misplaced and not aligned correctly. This is why we will use an online service that will help us run the necessary calculus to save time and effort:

Lets asume we have a 100 pages book, and we will use a White paper for color impressions.

This type of paper has a thickness of 0.002347″ (0.00596138cm)

This web allows us to play with several options that include pre-formats to start writing our books, generate the ISBN bar code, but the option we really need is the KDP Cover Template Generator. So click on it

On this form, we will have to fill the data requested on each field just as follows:

  • Width: 6
  • Height: 9
  • Page count: 100
  • Paper type: select white colour
  • OPTIONAL ISBN-13:Leave this in blank
  • OPTIONAL Price Barcode: Just leave this in blank
  • Formats: Select the ones that I put on bold, which are usually already marked
    • PDF
    • PNG
    • IDML (InDesign)
    • SLA (Scribus)
    • ODG (OpenOffice)
  • Your email address : hi@gmail.com
  • Your email address (again): hi@gmail.com
  • Consent to email: Check this last field to consent that you want them to send you an email.

Finally click on the “Email Cover Template” button and this will display a popup with the option to leave a donation. Remember to always leave a tip if you can since this services don’t have funds beyond their own users.

If you can’t make a donation, then simply select the first option that says “No thanks, just email me the template” .

Either you make a donation or not, you will finish the process with this donation page again, but this time with a success message that ask you to check your email and download your guides. Just do so and download either the png or pdf with the desired layout. I’m gonna open it with inkscape to start designing my cover.

We add the image with our layout to inkscape and adjust the size of the canva to the one at the image (the outside). This will allow our design to already include the cut margins or bleeds that always give us a headache.

We will design our cover following the guide lines and respecting the margins, only writing our content on the white parts of the layout. We will include our title, images, description but remember to leave the space for the ISBN since Amazon will add it automatically in case you don’t have one.

It’s important to mention that the section we usually forget is the name at the book mold. Make sure that this text is within the white line at the very center of the layout without touching the red border so it pass the Amazon KDP filters.

To work more comfortably, I set the layout image to a 60% opacity and put it on top of everything, that way I was able to see every element below the layout and move them better. But this is just a personal recommendation.

Once happy with your design, just delete the layout image, export your cover at 300DPI and you will be set to upload it at Amazon KDP.

Let me know if this tutorial was useful and if you created your book cover easily with this tips!


This post has a nicer formatting that can be seen at it's original source at tatica.org , so feel free to hit the link and read better version!

Asegúrate de estar recibiendo regularmente actualizaciones de las llaves

Si no refrescas regularmente tus llaves públicas implica que no recibas a tiempo la información sobre las llaves que han expirado o las revocaciones, lo cual es muy importante.

Si realizas un simple “gpg –refresh-keys”, revelas a cualquiera y al operador de servidor de llaves todo el conjunto de llaves que te interesa refrescar.

Para evitar esto puedes hacer actualizaciones regulares de llaves usando Parcimonie para refrescar tu llavero. Parcimonie es un daemon que refresca lentamente tu llavero desde un servidor de llaves a través de Tor. El propósito es hacer más difícil para un atacante correlacionar las actualizaciones de las llaves con tu llavero. Parcimonie es un paquete que se encuentra en Debian y Ubuntu.

También puedes usar un simple cronjob, como el siguiente para refrescar tus llaves, esto requiere que tu computadora este conectada a la red a la 1am, y potencialmente revela al mundo todas las llaves que estés actualizando en tu llavero.

No uses pgp.mit.edu

El servidor de llaves pgp.mit.edu ha estado sin funcionar adecuadamente por años, especialmente para cierto tipo de actualizaciones de llaves.

Depender específicamente de un único servidor de llaves te hace vulnerable a las posibles fallas de ese servidor de llaves, si el servidor de llaves se queda fuera de la piscina principal por cualquier razón, puede que nunca lleguen las actualizaciones al resto de la piscina. Utilizar la piscina es más robusto que usar un único servidor de llaves.

Considera mejor utilizar sks keyservers pool . En gpg.conf:

keyserver hkp://pool.sks-keyservers.net

La transición a una llave primaria más fuerte

Muchas personas siguen teniendo llaves DSA de 1024-bit. Debes considerar hacer la transición a un algoritmo de función hash más fuerte y de más bits. Ahora se sabe que este tamaño está dentro de lo que Well Funded Organizations pueden llegar a vulnerar. Este algoritmo de función hash ya está también envejeciendo.

Se recomienda hacer una llave 4096bit RSA con el algoritmo de función hash SHA512, realizando un aviso de transición que esté firmado por ambas llaves y hacerlo del conocimiento de todos. Este es un buen documento (EN) que detalla exactamente los pasos para que generes una llave así, asegurándose de obtener al algoritmo de función de digest adecuado.

Considera hacer que tu servidor de llaves por defecto use un servidor de llaves que tenga transporte HKPS

En lugar de un hkp sin cifrado por defecto puedes usar hkps. Esto hace menos evidente tu mapa de relaciones sociales de cualquiera que pueda estar fisgoneando el tráfico de tus datos por la red. Si realizas un gpg –refresh-keys en un servidor de llaves que es sólo hkp, entonces alguien monitoreando tu tráfico vera cada una de las llaves que tienes en tu llavero cuando pidas las actualizaciones de las llaves.

Nota: para poder utilizar el paquete hkps usuarios Debian/Ubuntu necesitarán instalar el paquete gnupg-curl

Puedes usar hkps.pool.sks-keyservers.net como tu servidor de llaves por defecto, este es un servidor piscina que contiene los servidores disponibles que usan hkps. Esta piscina contiene únicamente servidores que han sido certificados por sks-keyservers.net CA. Puede ser usado mediante los siguientes parámetros en gpg.conf:

~/.gnupg/gpg.conf:
 keyserver hkps://hkps.pool.sks-keyservers.net
 keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

Además, hkps:/keys.indymedia.org, hkps://keys.mayfirst.org and hkps://keys.riseup.net ofrecen esto (aunque es recomendable que mejor utilices la piscina).

Finalmente, si optas por designar la piscina como tu servidor de llaves, debes también agregar la siguiente opción:

~/.gnupg/gpg.conf:
 keyserver-options no-honor-keyserver-url

Cuando se genera una llave, los usuarios pueden designar un servidor de llaves específico desde el cual se pueden descargar sus llaves. La opción de arriba va a omitir esa especificación y utilizará la piscina, lo cual es útil porque (1) previene que alguien designe un método inseguro para que podamos bajar su llave y (2) si el servidor designado usa hkps, refrescar las llaves no funcionará porque el ca-cert no va a coincidir y por lo tanto las llaves no se van a refrescar.

Asigna una fecha de vencimiento si no tienes una

Las personas suelen preferir que sus llaves no expiren, pero tú sí debes querer que expiren. ¿Porqué? Porque siempre podrás extender su fecha de vencimiento, aún después de que hayan expirado. Este “vencimiento” es de hecho una válvula de seguridad o un “sistema de seguridad de hombre-muerto” que automáticamente se activará en algún momento. Si tienes acceso a los datos secretos de tus llaves lo puedes desactivar. El objetivo es implementar algo que deshabilite tu llave en caso de que pierdas acceso a ella y que no tengas certificado de revocación.

Asignar una fecha de vencimiento significa que necesitarás extender esa fecha en algún punto del futuro. Es una pequeña tarea que necesitarás recordar hacer.

Puedes pensar que es molesto y que no quieres tener que lidiar con ello, pero de hecho es bueno hacerlo regularmente. Indica a los usuarios que su llave sigue estando activa, y que el propietario de la llave la utiliza. Además, mucha gente no firmará una llave que no tenga fecha de vencimiento.

Para asignar una fecha de vencimiento a tu llave, simplemente necesitas ejecutar:

gpg --edit-key <fingerprint>

Ahora selecciona la sub-llave a la que quieres asignar una fecha de vencimiento (por ejemplo, la primera), o ninguna para asignar el vencimiento en tu llave primaria y luego ejecuta el comando “expire”

gpg> key 1
gpg> expire

Ahora asigna un valor razonable, (por ejemplo, 2 años) guarda la llave y salga:

Key is valid for? (0) 2y
gpg> save

Ahora debes enviar tu llave a los servidores de llaves para publicar este cambio:

gpg --send-key

Agenda un evento en el calendario para recordarte sobre la fecha de vencimiento de tu llave

No lo vas a recordar, así que lo mejor es pedir un recordatorio. Agenda una alerta un mes o más antes de la fecha para que puedas hacer el cambio con algo de tiempo. No quieres tener que apresurarte cuando tengas que manejar tus llaves.

Siempre puedes extender la fecha de expiración (aún cuando la llave ya expiro), así que no necesitas generar una nueva llave cada vez, sólo necesitas extender a fecha de vencimiento para después.

¿Tienes un certificado de revocación?

Si llegas a olvidar tu frase de contraseña o si tu llave privada queda comprometida o la pierdes, la única esperanza que te queda es esperar a que expire la llave (esto no es una buena solución), o activar tu certificado de revocación publicándolo a los servidores de llaves. Al hacer esto notificarás a otros que esta llave ha sido revocada.

Una llave revocada puede seguir utilizándose para verificar firmas anteriores o descifrar datos (si es que sigues teniendo acceso a la llave privada), pero no puede ser usada para cifrar nuevos mensajes para ti.

Para saber como generar y utilizar el certificado haz clic aquí.

Utiliza únicamente tu llave primaria para certificación (y tal vez también firmar). Ten una subllave por separado para cifrar.*

(extra) Ten una subllave por separado para firmar y mantén tu llave primaria completamente fuera de linea.

En este escenario, tu llave primaria es utilizada solo para certificación, lo que no sucede con frecuencia.

No confíes en el ID de la llave

Los IDs de llaves que son cortas, por ejemplo 0x2861A790, son de 32 bits. Hemos visto que son fácilmente falsificadas por otra llave con el mismo ID. Las OpenPGP IDs largas (por ejemplo 0xA1E6148633874A3D) son de 64 bits. Son fáciles para un ataque de colisión (trivially collidable) (EN), lo que es potencialmente un serio problema (EN).

Si quieres tratar con un identificador criptográficamente fuerte para una llave, debes usar la huella digital completa. Nunca debes confiar en la ID corta de la llave.

Probablemente deberías al menos tener:

keyid-format 0xlong y with-fingerprint en las opciones gpg.conf para incrementar el tamaño en el que se muestra el ID de la llave a 64-bit bajo uso regular y para mostrar siempre la huella digital.

Asegúrate de que tu llave es OpenPGPv4

De acuerdo con el RFC4880 Las llaves V3 están ya desaprobadas, contienen 3 vulnerabilidades. Primero, es relativamente fácil construir una llave V3 que tenga el mismo ID que otra llave porque el ID de la llave son simplemente los 64 bits del módulo público. Segundo porque la huella digital de una llave V3 hace las funciones de digest del material de la llave pero no de su extensión, por lo que hay una mayor oportunidad para colisiones de huellas digitales. Tercero, hay puntos débiles en el algoritmo MD5 que hace que los desarrolladores prefieran otros algoritmos. Ver abajo la discusión sobre ID’s de llaves y huellas digitales.

Para determinar si tu llave es una llave V3 puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets |grep version

Las llaves primarias deben ser DSA-2 o RSA de 4096 bits o más. (RSA de preferencia)

Para revisar si estás utilizando DSA-2 o RSA puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 '^:public key packet:$' | grep algo

Si el algoritmo reportado es 1, quiere decir que estas usando RSA. Si es 17 entonces es DSA y necesitarás confirmar que las siguientes revisiones reporten un tamaño de llave mayor a 1024, de otro modo no estás utilizando DSA-2.

Si el algoritmo reportado es 19, estás usando ECDSA, si es 18 es ECC. En ese caso la siguiente comprobación del tamaño de bits de la llave no es un criterio apropiado para este tipo de llaves ya que los tamaños de llave se reducirán significativamente.

Para revisar el tamaño de bits de la llave primaria puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 'public key' | grep 'pkey\[0\]:'

Las auto-firmas no deben usar MD5, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 1,'

Si ves que se genera algún resultado ‘digest algo 1’, entonces tienes algunas auto-firmas que están usando MD5, ya que el algoritmo digest 1 es MD5. Ve el OpenPGP RFC 4880, section 9.4 (EN) que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las auto-firmas no deben usar SHA1, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 2,'

Si obtienes cualquier resultado ‘digest algo 2’ quiere decir que tienes algunas auto-firmas que están utilizando SHA1, ya que el algoritmo digest 2 es SHA1.

Ve el OpenPGP RFC 4880, section 9.4 que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las preferencias del algoritmo digest deben incluir al menos un miembro de la familia SHA-2 con una prioridad más alta que las MD5 y SHA1 juntas

Puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'pref-hash-algos'

e inspeccionar los resultados. El orden de preferencia está basado en cuál número está primero de izquierda a derecha. Si ves un número ‘3’, ‘2’, o ‘1’ antes del ‘11’, ‘10’, ‘9’ u ‘8’, quiere decir que has especificado en tus preferencias preferir un algoritmo digest más débil.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Las llaves primarias deben tener una fecha de vencimiento razonable (no más de 2 años en el futuro) Puedes revisar cuáles son las fechas de vencimiento de tus llaves haciendo lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'key expires after'

Después inspecciona visualmente cuáles son los resultados para confirmarlo, la fecha en la lista será relativa a la creación de la llave lo cual puede ser difícil de interpretar.

Otro modo de revisar el vencimiento es simplemente:

gpg --list-keys <fingerprint>

Lo cual debe mostrar las fechas de creación y vencimiento de la llave primaria y de cada sub-llave asociada. Si no ves nada que mencione “expires” en este resultado, quiere decir entonces que no designaste una fecha de vencimiento apropiadamente.

Para corregirlo:

gpg --edit-key <fingerprint>
 gpg> expire
 ...
 gpg> save

Actualiza tu configuración GPG por defecto

Si estás utilizando GnuPG, asegúrate de tener las configuraciones optimas en gpg.conf, para esto puedes utilizar el siguiente script.

No incluyas un “comentario” en tu ID de usuario

Si crees que necesitas un lugar para un “comentario” en tu OpenPGP User ID piénsalo bien dos veces lee más sobre esto (EN). Probablemente no lo necesites ni lo quieras. Tener un espacio para un comentario dificulta a mucha gente saber qué es lo que están certificando.

Visto en riseup.net.