<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true">
    <p><br>
    </p>
    <p>Sorry for splitting Peter and Philihp  into two threads. <br>
    </p>
    <p><br>
    </p>
    <p>I have probably put my gpg environment/program in a state it
      cannot come out of. I want to do what cowards do. I want to
      uninstall gpg and start all over again, escaping from the mess I
      put my self into somehow. With the advice you gave me I should do
      better next the time, and hopefully  stay out of trouble. <br>
    </p>
    <p><br>
    </p>
    <p>I have not given anybody any of the IDs yet. And besides, the
      intended application is non interactive and also does not
      communicate anything. It hides everything and itself from ever
      body and ever thing, let alone the keys (or at least that is the
      intention if a manage to keep me out of trouble. I am a ASIC
      hardware guy venturing to do what I should not; obviously.)<br>
    </p>
    <p><br>
    </p>
    <p>How do I ensure I uninstall without leaving any history or state
      that could affect a new install please? Sorry for the head ache I
      am giving you. If I manage to make money and not go bankrupt I
      will remember my friends.</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 7/12/2020 11:01 AM, Ayoub Misherghi
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9757848e-a469-1c8d-a057-620e127158c1@gmail.com">
      <br>
      Thanks. This exposes to me how little I know and it will take me
      time to absorb it. None of this information is in anything I read.
      Nothing comes close. I will not come to grips with it with the
      kind of reading material I have. Can you please suggest some good
      tutorial and reference material preferably free (probably mutually
      exclusive requirements) that will bring me up to your level or
      close to it please.
      <br>
      <br>
      <br>
      The material I come across is just like silly preschool stuff with
      1/4 truth which keeps you ill informed and miss informed and
      throws you off track. They over simplify and drain education out
      of you making you zombie.
      <br>
      <br>
      <br>
      Thanks,
      <br>
      <br>
      <br>
      Ayoub
      <br>
      <br>
      <br>
      On 7/12/2020 9:15 AM, Peter Lebbing wrote:
      <br>
      <blockquote type="cite">On 12/07/2020 17:45, Ayoub Misherghi
        wrote:
        <br>
        <blockquote type="cite">Sorry for going off list and messing
          everybody up. Now I disserve
          <br>
          punishment.
          <br>
        </blockquote>
        Heh :-). It's just that if I reply off-list, it only helps you,
        but if
        <br>
        it is on-list, other people can find it in a search engine when
        they're
        <br>
        facing something similar.
        <br>
        <br>
        On 11/07/2020 21:07, Ayoub Misherghi wrote:
        <br>
        <blockquote type="cite">My current intended usage is in
          non-interactive mode, completely.
          <br>
          I can remove them from the gpg.conf but I would have to issue
          them
          <br>
          every time. My understanding is that non-interactive mode
          requires
          <br>
          those commands.
          <br>
        </blockquote>
        Well, in that case, you should supply --no-batch when you're
        using it
        <br>
        interactively; I'll show why further down.
        <br>
        <br>
        My personal choice would be to have my scripts and programs
        supply the
        <br>
        --batch on invocation rather than put it in the config file,
        because you
        <br>
        only need to write that command invocation in the script once
        (as you're
        <br>
        writing the script), whereas you'll be writing the --no-batch
        every time
        <br>
        you /do/ use it from an interactive shell.
        <br>
        <br>
        <blockquote type="cite">I selected "expert" mode because I am
          using ED2599 incrpytion that is
          <br>
          available only in this mode (I know, I am newbie)
          <br>
        </blockquote>
        You only need the --expert on commands creating or adding keys
        for that.
        <br>
        Once you have the key, you no longer need --expert to just use
        it.
        <br>
        <br>
        <blockquote type="cite">All the config lines I showed are in my
          user config.
          <br>
          A few days ago, my set up, which is still in development
          phase,
          <br>
          worked until my short lived gpg keys expired. I fell in deep
          ***** when
          <br>
          I created new keys. It all worked, with the passphrase-file
          option and
          <br>
          without, before I fell. Can you pull this dumb newbie out?
          <br>
        </blockquote>
        I think the combination that worked might have been
        <br>
        <br>
        --8<---------------cut
        here---------------start------------->8---
        <br>
        pinentry-mode loopback
        <br>
        passphrase-file /home/ayoub/.gnupg/output.png
        <br>
        --8<---------------cut
        here---------------end--------------->8---
        <br>
        <br>
        but once you commented out the passphrase-file entry, GnuPG had
        no way
        <br>
        to get the passphrase. Normally you should use the pinentry (so
        comment
        <br>
        out the pinentry-mode line as well), but you force it to use the
        <br>
        loopback pinentry-mode. gpg _could_ ask for your passphrase that
        way.
        <br>
        But, you also specify --batch. --batch tells GnuPG that the
        human is
        <br>
        currently unavailable and it needn't bother trying to interact
        with it.
        <br>
        So it has no way to get the passphrase and gives up.
        <br>
        <br>
        It will ask you for the passphrase when you comment out --batch,
        but I
        <br>
        recommend also commenting out the --pinentry-mode line so it'll
        just
        <br>
        launch a pinentry like it wants to do.
        <br>
        <br>
        Now about this configuration:
        <br>
        <br>
        --8<---------------cut
        here---------------start------------->8---
        <br>
        pinentry-mode loopback
        <br>
        passphrase-file /home/ayoub/.gnupg/output.png
        <br>
        --8<---------------cut
        here---------------end--------------->8---
        <br>
        <br>
        If this file is stored with the same access conditions as
        <br>
        ~/.gnupg/private-keys-v1.d/, it serves no good purpose. You
        should then
        <br>
        just use a key without a passphrase. With a key without a
        passphrase, an
        <br>
        attacker would just need the file
        <br>
        <br>
        ~/.gnupg/private-keys-v1.d/[...].key
        <br>
        <br>
        and they're good to go. With your passphrase-file, they need two
        files:
        <br>
        <br>
        ~/.gnupg/private-keys-v1.d/[...].key
        <br>
        ~/.gnupg/output.png
        <br>
        <br>
        and once again they're good to go, they have your private key.
        Why would
        <br>
        it be more difficult to get a hold of two files rather than one?
        Just
        <br>
        drop the passphrase, and all your problems magically disappear
        :-).
        <br>
        <br>
        But given its name, I suppose output.png is generated by some
        unlocking
        <br>
        process. Suppose you did it like this before:
        <br>
        <br>
        $ my-unlocker >~/.gnupg/output.png
        <br>
        <br>
        You can actually unlock keys the way GnuPG intends to do that
        with:
        <br>
        <br>
        $ my-unlocker | /usr/lib/gnupg/gpg-preset-passphrase --preset
        <keygrip>
        <br>
        <br>
        You can find the keygrip for your keys with:
        <br>
        <br>
        $ gpg --with-keygrip --list-secret-keys
        <br>
        <br>
        You do need it for every subkey you want to use like this
        separately,
        <br>
        and also, it does not verify whether the passphrase was correct.
        Also,
        <br>
        put
        <br>
        <br>
        allow-preset-passphrase
        <br>
        max-cache-ttl <seconds>
        <br>
        <br>
        in ~/.gnupg/gpg-agent.conf
        <br>
        <br>
        and issue
        <br>
        <br>
        $ gpgconf --kill gpg-agent
        <br>
        <br>
        to reload. <seconds> is how long you want the passphrase
        to stay
        <br>
        available after gpg-preset-passphrase, and it defaults to a mere
        2
        <br>
        hours. You could set it to 4294967295 to specify a lifetime of
        136
        <br>
        years, i.e., infinitely for all practical purposes.
        <br>
        <br>
        Watch out that my-unlocker doesn't leak the passphrase in any
        way. I
        <br>
        thought it was unhelfpul that you can't use the pinentry with
        <br>
        gpg-preset-passphrase and I proposed a hack more than two years
        ago:
        <br>
        <br>
<a class="moz-txt-link-freetext" href="https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059917.html">https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059917.html</a>
        <br>
        <br>
        It's pretty hacky, but it does seem to work.
        <br>
        <br>
        You could actually just unlock your key by using it once when
        you start
        <br>
        up your system, and then use the caching feature to keep it
        available
        <br>
        for non-interactive use for the rest of the time. Then you don't
        use
        <br>
        gpg-preset-passphrase, but put, e.g., this in your
        gpg-agent.conf
        <br>
        <br>
        default-cache-ttl 4294967295
        <br>
        max-cache-ttl 4294967295
        <br>
        <br>
        and unlock your key by doing one decryption:
        <br>
        <br>
        $ echo Open Sesame | gpg -r develop1 -e | gpg -d
        <br>
        <br>
        This will pop up a pinentry for your passphrase, and since you
        set the
        <br>
        cache-ttl to infinity, it will never popup a pinentry again on
        <br>
        decryptions until you restart gpg-agent. It's a pretty good
        workflow
        <br>
        that uses all parts as they were intended.
        <br>
        <br>
        HTH,
        <br>
        <br>
        Peter.
        <br>
        <br>
      </blockquote>
    </blockquote>
  </body>
</html>