I'm curious. So what was it about this particular key and signed text that caused this
to expose this error while others did not?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 2 2017
Here is the output from the program you attached running on OS X Sierra and compiled
with gcc. Is it what you expected?
$ ./a.out
0 => 0; tail = ''; errno = Undefined error: 0 (0)
1 => 1; tail = ''; errno = Undefined error: 0 (0)
=> 0; tail = ''; errno = Invalid argument (22)
Jan 15 2017
I had a chance to run this test against 2.1.17 today as that version has been recently
released via homebrew. The error is essentially the same, but the debug output is
indeed slightly different. Now the debug line numbers are different and there is the
addition of string=''; in the debug output. I didn't notice anything else that looked
significantly different.
/tmp$ gpg2 --verify TrueTimeStamp-certificate-4793.txt
gpg: Signature made Wed Nov 23 23:08:29 2016 PST
gpg: using DSA key 0x6F3B2E6AB748A8F8
gpg: Good signature from "TrueTimeStamp <signing-department@TrueTimeStamp.org>"
[marginal]
gpg: DBG: tofu.c:3068: strtoul failed for TOFU DB data; returned string (string='';
tail=''): Invalid argument
gpg: DBG: tofu.c:3070: strtoul failed for TOFU DB data; returned string (string='';
tail=''): Invalid argument
gpg: signing-department@truetimestamp.org: Verified 1 signature in the past
5 weeks. Encrypted 0 messages.
gpg: Warning: we've only seen one message signed using this key and user id!
gpg: Warning: you have yet to encrypt a message to this key!
gpg: Warning: if you think you've seen more signatures by this key and user
id, then this key might be a forgery! Carefully examine the email address for small variations. If the key is suspect, then use gpg --tofu-policy bad 83289060F40DED088CF246B56F3B2E6AB748A8F8 to mark it as being bad.
gpg: WARNING: This key is not certified with sufficiently trusted signatures!
gpg: It is not certain that the signature belongs to the owner.
Primary key fingerprint: 8328 9060 F40D ED08 8CF2 46B5 6F3B 2E6A B748 A8F8
Dec 10 2016
"Can you please compile gpg with debugging symbols"...
Sorry, I am not currently setup to compile GnuPG and all its dependencies and I'm not
even sure of the details as to how to go about doing so. As I mentioned I am installing
pre-compiled binaries compiled server side by the homebrew project which installs those
binaries.
I would imagine the GnuPG project has an OS X development machine to test/debug on. No?
If you have specific changes you would want me to make to the homebrew recipe I linked
to I can try to do that.
Dec 8 2016
FYI, here is the homebrew formula that is used to compile GnuPG
https://github.com/Homebrew/homebrew-versions/blob/master/gnupg21.rb#L46
Hmmm. So since I filed this bug I happened to do a key transition so I started with a
brand new gnupg dir. So in trying to replicate this again I was starting from scratch.
I imported the key and downloaded the signed file from the gist I sent you. I still see
the same output! This leads me to wonder if there is something different about how the
tofu code compiles when installed on OS X via homebrew?? The gnupg installation didn't
change, but my whole .gnupg dir is new.
$ gpg2 --verify ts.txt
gpg: Signature made Wed Nov 23 23:08:29 2016 PST
gpg: using DSA key 0x6F3B2E6AB748A8F8
gpg: Good signature from "TrueTimeStamp <signing-department@TrueTimeStamp.org>"
[marginal]
gpg: DBG: tofu.c:2772: strtoul failed for DB returned string (tail=): Invalid argument
gpg: DBG: tofu.c:2774: strtoul failed for DB returned string (tail=): Invalid argument
gpg: signing-department@truetimestamp.org: Verified 1 signature in the past
0 seconds, and encrypted 0 messages.
gpg: Warning: we've only seen one message signed using this key and user id!
gpg: Warning: you have yet to encrypt a message to this key!
gpg: Warning: if you think you've seen more signatures by this key and user
id, then this key might be a forgery! Carefully examine the email address for small variations. If the key is suspect, then use gpg --tofu-policy bad 83289060F40DED088CF246B56F3B2E6AB748A8F8 to mark it as being bad.
gpg: WARNING: This key is not certified with sufficiently trusted signatures!
gpg: It is not certain that the signature belongs to the owner.
Primary key fingerprint: 8328 9060 F40D ED08 8CF2 46B5 6F3B 2E6A B748 A8F8
Dec 2 2016
tofu.db sent via encrypted email today.
Nov 24 2016
Nov 19 2016
Jan 18 2016
Werner, there is a typo in your new commit 56275e4392a7b38abe5fdd84fe9d67599cf5e6d1
'defaulte' should be 'default'
+Use @code{name} as the digest algorithm used to mangle the passphrases
+for symmetric encryption. The defaulte is SHA-1.
Also, might it be beneficial to add this change of behavior to either the man page or
to the 'What's changed in 2.1' docs?
Thanks
Jan 11 2016
OK, thanks for the response Werner. Perhaps this bug then is to update the website
docs to reflect what I gather may be big changes to this feature as compared to earlier
gnupg releases.
It seems that everything that can be found here (the best source I have found for using
gnupg w/ DNS) is now outdated and will no longer work:
http://gushi.org/make-dns-cert/HOWTO.html
I wanted to learn more about the new changes but I was only able to find the following
references which I'll document here in case someone else comes across it.
Unfortunately, I won't be able to test out the new method as I don't run my own bind
server and like many of us rely on a DNS provider that doesn't allow me to create the
form of DNS record output by --print-pka-records.
I only found three references to the new '--print-pka-records':
2.1.3 Announce:
https://lists.gnupg.org/pipermail/gnupg-announce/2015q2/000365.html
"* gpg: New option --print-pka-records. Changed the PKA method to use
CERT records and hashed names."
gnupg docs:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html
"--print-pka-records
Modify the output of the list commands to print PKA records suitable to put into DNS
zone files. An ORIGIN line is printed before each record to allow diverting the records
to the corresponding zone file."
And finally an announcement from you in gnupg-devel from last year where you state that
all of the old functionality for PKA has been removed and replaced with something
entirely new (which is just for key 'validation' and not for key installation?):
http://marc.info/?l=gnupg-devel&m=142488047809150&w=2