<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks for various replies. <br>
    As far as I can see: <br>
    <br>
    1) The checksum issue, limited to 256sums, is a file size issue; as
    I said, I got around this by using a different app, but it would
    constitute a major limitation or bug. <br>
    <br>
    2) I will try the command line as you have suggested, running "gpg
    -v". <br>
    <br>
    3) I will also try trusting the Tails key using my own key; still,
    Gpg4Win does offer the ability to " completely trust" a key without
    using your own, and even when this is the case, the key fails to
    appear in Kleopatra's trusted field, also an apparent bug. If the
    trusted field only admits keys when signed with your own, this
    should be made clear. <br>
    <br>
    4) This still fails to account for the unidentified string (short
    and post-key-imported long), unmatched to anything on the Tails
    site, the real issue. Can anyone account for this string (<i>
      0xBA2C222F44AC00ED9899389398FEC6BC752A3DB6)? <br>
    </i><br>
    Cheers<br>
    <br>
    On 25/05/2015 00:39, David Kronlid wrote:<br>
    <span style="white-space: pre;">><br>
      > LSmok3, I just realized that your email address wasn't
      included any longer in the discussion on the mailing list, so in
      case you aren't subscribing to the list i resend my email with you
      as a recipient too.<br>
      > /David<br>
      ><br>
      > Den 24 maj 2015 23:47 skrev "David Kronlid"
      <<a class="moz-txt-link-abbreviated" href="mailto:david@kronlid.net">david@kronlid.net</a> <a class="moz-txt-link-rfc2396E" href="mailto:david@kronlid.net"><mailto:david@kronlid.net></a>>:<br>
      > ><br>
      > > I think the main problem here is that "Lsmoke3" didn't
      understand that he needs to create his own key and use it to
      create trust in other keys that he has downloaded from the
      Internet. The other problems with sha256 and command-line are just
      the backup plans that didn't work either. If there is a bug at all
      it might be with sha256 I've never tried it so I don't know, but I
      don't think the command-line or setting the trust level of keys
      aren't bugs at all, just user errors from a beginner.<br>
      > ><br>
      > > Lsmoke3, you really only need to use the gui kleopatra
      and never need to use the command line for verifying a download.
      But you also need to create or import your own gpg keys to set
      trust in other keys you download from the Internet or get from
      friends.<br>
      > ><br>
      > > Gpg4win/gnupg doesn't make it very easy for beginners as
      they have created a WOT system that doesn't create much trust at
      all but instead registers people's connections to each other for
      all eternity on the web, and have added a feature where you have
      to sign the trust level of downloaded keys with your own key,
      making it difficult for beginners. So it's not very user friendly
      and that's the problem, it's not a bug to have a difficult
      environment to use it's just not as user friendly as people expect
      a software to be. Especially if the only thing they want to do is
      to very that a download isn't corrupted or comes from the wrong
      source. That thing could be much easier, and it was easier before.
      It's the new "features" that are causing the problems in this case
      I think together with a user who doesn't want to spend hours
      learning how to verify a download through Gpg4win.<br>
      > ><br>
      > > So removing some unnecessary features or making them
      optional/removable in the installation and later in the settings
      would be a good thing for beginners when using gpg4win. And later
      if people really want to use their own keys to set a trust level
      of a key they just downloaded from the same website they
      downloaded the iso-file from, then fine let them add that feature
      later.<br>
      > ><br>
      > > But honestly, if the website is hacked/replaced the
      hackers/ISP/Country probably will have changed both the public
      key, signature file and the iso file so that people downloading
      both would just create trust in the fake gpg public key anyway.
      But that's a whole other problem which gpg can't solve as there's
      no verified database of public keys, so the hacker/ISP/country can
      just change both the iso file, pgp signature file and the key who
      created it all at once. So that's a more difficult problem to
      solve.<br>
      > ><br>
      > > Den 24 maj 2015 17:45 skrev "Juan Miguel Navarro
      Martínez" <<a class="moz-txt-link-abbreviated" href="mailto:juanmi.3000@gmail.com">juanmi.3000@gmail.com</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:juanmi.3000@gmail.com"><mailto:juanmi.3000@gmail.com></a>>:<br>
      > >></span><br>
    <blockquote type="cite">Daniel Kahn Gillmor:<br>
      > b) kleopatra can't generate or verify sha256 digests:<br>
      <br>
      >> L:<br>
      >>> Additionally, Gpg4Win proved unable to generate or
      verify<br>
      >>> sha256sum hashes (technically a textfile output
      anyway),<br>
      >>> repeatedly producing an error citing an inability to
      name the<br>
      >>> output file; I ultimately turned to another
      application for<br>
      >>> Unicode verification.<br>
      >><br>
      >> Kleopatra's sha256 checksum is either bugged or very
      strict. I<br>
      >> could conclude that you can't create checksum files from
      a file<br>
      >> or files which exceeds in total around 2.3 GiB of size
      and<br>
      >> bigger. And you can't verify checksums from a file which
      is not<br>
      >> named sha256sum.txt and the contents of the files aren't
      like:<br>
      <br>
      > to be honest, i can only get kleopatra to produce sha1
      checksums,<br>
      > and when i try to get kleopatra to verify a sha1 checksum,
      it's<br>
      > very clear to me as a user what is happening, or what was
      actually<br>
      > verified.<br>
      <br>
      <br>
      You can select between md5sum, sha1sum or sha256sum in Settings
      ><br>
      Configure Kleopatra > Crypto Operations > File Operations.<br>
      <br>
      ## Creating a checksum file issue ##<br>
      If I try to make a sha256sum file of Linuxmint 17.1 ISO file[1] or<br>
      from multiple files of 2.01 GiB in total size [2], I can both
      create<br>
      the file and both verify correctly. [4][5]<br>
      <br>
      It is when I use a big file, in this example FreeBSD 10.1 64-bit
      ISO<br>
      (2,40 GiB) [6] or if I add another file in the bulk operation one<br>
      (added Tails ISO in this case)[7] when I get this exact error
      everytime:<br>
      <br>
      "Failed to move file C:/Users/Juanmi/Documents/ISOs/sha256sum.txt
      to<br>
      its final destination, sha256sum.txt: Error during rename."<br>
      <br>
      ## Verifying issue ##<br>
      As you saw before [1][4], the verification works but if you change
      the<br>
      checksums file name to something different you get this error:<br>
      <br>
      "Cannot find checksums file for file<br>
C:\Users\Juanmi\Documents\ISOs\linuxmint-17.1-cinnamon-32bit.iso.sha256"<br>
      <br>
      It gives a different one if you rename it to md5sum.txt or<br>
      sha1sum.txt, as if it's expecting md5 and sha1 checksums instead
      of<br>
      analyzing its contents and determine what kind of checksum is it:<br>
      <br>
      "Error while running C:/Program Files (x86)/GNU/GnuPG/sha1sum.exe:<br>
      sha1sum: error parsing
      `C:/Users/Juanmi/Documents/ISOs/sha1sum.txt':<br>
      invalid line"<br>
      <br>
      [1]:
      <a class="moz-txt-link-freetext" href="https://img.bi/#/pYpuENn!aFlNIA-oEisQAiudUQBqn7YAWfQzoQ_XDRUA-LnT">https://img.bi/#/pYpuENn!aFlNIA-oEisQAiudUQBqn7YAWfQzoQ_XDRUA-LnT</a><br>
      [2]:
      <a class="moz-txt-link-freetext" href="https://img.bi/#/927gE9N!Y4qEJgp7oMVgA06nRQQHTZdwUN72ngrcFkTwrnQM">https://img.bi/#/927gE9N!Y4qEJgp7oMVgA06nRQQHTZdwUN72ngrcFkTwrnQM</a><br>
      [3]:
      <a class="moz-txt-link-freetext" href="https://img.bi/#/p4Ft9ed!xdSDbQAn5qNAkk5CRgeWJ1kAaJ2UfAq5v47wQ4nQ">https://img.bi/#/p4Ft9ed!xdSDbQAn5qNAkk5CRgeWJ1kAaJ2UfAq5v47wQ4nQ</a><br>
      [4]:
      <a class="moz-txt-link-freetext" href="https://img.bi/#/Dnz4awQ!nuwlFQ7xzrHQq_B83wiIeoRQMjwwfwlAD4fQa8vH">https://img.bi/#/Dnz4awQ!nuwlFQ7xzrHQq_B83wiIeoRQMjwwfwlAD4fQa8vH</a><br>
      [5]:
      <a class="moz-txt-link-freetext" href="https://img.bi/#/qB3pPOF!W2T9MwZgXR0Ai3plGAc5h9rQe6nAZQl_JuogwuWS">https://img.bi/#/qB3pPOF!W2T9MwZgXR0Ai3plGAc5h9rQe6nAZQl_JuogwuWS</a><br>
      [6]:
      <a class="moz-txt-link-freetext" href="https://img.bi/#/z0BRTFA!dm5acAqZffVgrAffNgqiBzrAM07AYQiglgNAUqzY">https://img.bi/#/z0BRTFA!dm5acAqZffVgrAffNgqiBzrAM07AYQiglgNAUqzY</a><br>
      [7]:
      <a class="moz-txt-link-freetext" href="https://img.bi/#/de8nTc2!6e7QQQPevjuga8u-WQutjOZQNmUi7gnLOrBQwonp">https://img.bi/#/de8nTc2!6e7QQQPevjuga8u-WQutjOZQNmUi7gnLOrBQwonp</a><br>
      <br>
    </blockquote>
    <span style="white-space: pre;">> >>
      _______________________________________________<br>
      > >> Gpg4win-users-en mailing list<br>
      > >> <a class="moz-txt-link-abbreviated" href="mailto:Gpg4win-users-en@wald.intevation.org">Gpg4win-users-en@wald.intevation.org</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:Gpg4win-users-en@wald.intevation.org"><mailto:Gpg4win-users-en@wald.intevation.org></a><br>
      > >>
<a class="moz-txt-link-freetext" href="https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en">https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en</a><br>
      ></span><br>
    <br>
    <br>
  </body>
</html>