<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>GPG on iMil.net</title>
    <link>http://imil.net/blog/tags/gpg/</link>
    <description>Recent content in GPG on iMil.net</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 10 Jun 2020 05:36:04 +0200</lastBuildDate>
    <atom:link href="http://imil.net/blog/tags/gpg/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Testing GPG Keys With Docker... and fail</title>
      <link>http://imil.net/blog/posts/2020/testing-gpg-keys-with-docker/</link>
      <pubDate>Wed, 10 Jun 2020 05:36:04 +0200</pubDate>
      <guid>http://imil.net/blog/posts/2020/testing-gpg-keys-with-docker/</guid>
      <description>&lt;p&gt;As a &lt;a href=&#34;https://www.passwordstore.org/&#34;&gt;password-store&lt;/a&gt; user, &lt;a href=&#34;https://gnupg.org/&#34;&gt;GPG&lt;/a&gt; is particularly important and sensitive, I use it for&#xA;pretty much everything authentication / encryption related. Also, about a year ago I got myself&#xA;a pair of &lt;a href=&#34;https://www.yubico.com/products/&#34;&gt;Yubikeys&lt;/a&gt;, and they are now involved in &lt;strong&gt;all&lt;/strong&gt; of the mentioned workflows.&lt;/p&gt;&#xA;&lt;p&gt;Now on the topic, as my keys are a crucial part of my online life, I wanted to make sure I had&#xA;those backuped safely, and moreover, that this backup is usable in an empty environment by simply importing the public and private keys. Among the various possibilities, I thought firing up a basic &lt;a href=&#34;https://www.docker.com/&#34;&gt;docker&lt;/a&gt; container with an interactive shell would be my fastest bet. How wrong I was.&lt;/p&gt;</description>
    </item>
    <item>
      <title>multipart/encrypted et alpine</title>
      <link>http://imil.net/blog/posts/2012/multipartencrypted-et-alpine/</link>
      <pubDate>Tue, 21 Feb 2012 10:48:21 +0000</pubDate>
      <guid>http://imil.net/blog/posts/2012/multipartencrypted-et-alpine/</guid>
      <description>&lt;p&gt;J&amp;rsquo;utilise &lt;a href=&#34;http://www.washington.edu/alpine/&#34;&gt;Alpine&lt;/a&gt; comme client mail depuis hmmm&amp;hellip; 15 ans je pense. J&amp;rsquo;aime bien Alpine. Oh pitié, épargnez-moi le couplet sur sa license, et &lt;a href=&#34;http://www.washington.edu/alpine/overview/legal.html&#34;&gt;renseignez-vous &lt;/a&gt; avant de balancer du &lt;a href=&#34;http://fr.wikipedia.org/wiki/Fear,_uncertainty_and_doubt&#34;&gt;FUD&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;J&amp;rsquo;utilise Alpine donc. Je suis, vous vous en doutez, très satisfait de ce logiciel d&amp;rsquo;une stabilité à toute épreuve qui gère mes boites mail fournies de centaines de milliers de mails (1997 - 2012) comme si elles en contenaient 12. Mais Alpine souffre d&amp;rsquo;un problème millénaire: sa -non- gestion des RFC 2015/3156 i.e. les messages &lt;em&gt;multipart/signed et multipart/encrypted&lt;/em&gt;. En effet, Alpine, comme nombre d&amp;rsquo;autres &lt;a href=&#34;http://en.wikipedia.org/wiki/Mail_user_agent&#34;&gt;MUA&lt;/a&gt; ne respectant pas cette RFC, signe ou chiffre via PGP/GPG dans le corps du message, par le biais d&amp;rsquo;outils tiers tels que &lt;a href=&#34;http://hany.sk/~hany/software/pinepgp/&#34;&gt;pinepgp&lt;/a&gt; ou &lt;a href=&#34;http://dougbarton.us/PGP/ppf/&#34;&gt;pine-pgp-filters&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
