Okay, we can then add the code to dirmngr.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 21 2016
Oct 17 2016
thanks, that seems to have resolved the problem in my tests.
I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.
Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.
Oct 15 2016
Oct 1 2016
If a apply that fix to an unmodified 2.1.15, my problem is solved:
My test case (importing a PKCS#12 file with pinentry-mode=loopback if the agent
has not been started before) now works. Thank you!
If a apply that fix to an unmodified 2.1.15, my problem is solved. Thank you!
Sep 27 2016
gpgme 1.7.0 has been released and thus I consider this bug solved.
Right. It is the cause.
Fixed in: 836b72363168cbb0051fc2356f61788468db211c
Fixed in: 98bc6f480ac973dccce90378dc021a2e24e58704
Sep 19 2016
Sep 14 2016
gpgme 1.7 will have gpgme_op_createkey which takes "default" and
"future-default" as algorithm parameters. There is also a bunch of user
functions to make creating a key easy with gpgme.
Sep 5 2016
OpenPGP has a timestamp granularity of one second and thus you can't distinguish
non-RSA signature from each other if they are donewithin the same second.
Waiting a second is an old trick which is even employed somewhere inside gpg.
Thanks, this works now as expected.
While enabling the checks for signcount in gpgme/lang/qt/tests/t-tofuinfo.cpp
I've noticed though that if I sign and verify the same plaintext twice
immediately after another the signcount is not incremented correctly.
In line 266 of that test. The call to signAndVerify leads to an Assert if you
remove the " World" part of the "Hello World" message.
Alternatively adding a QTest::qWait(1000); before that line also results in a
success.
You can trigger this also by modifing the strings in line 233ff to contain the
same message.
Not really important imo as this is a constructed problem. The main issue here
is resolved for me.
Jochen, can you please find out:
a) Does this still work on GNU/Linux?
b) Did this work with elder Gpg4win version? With binary search you
should find out qickley when this broke.
Sep 3 2016
Updated by the fix:
f9e49c8 scd: Fix an action after card removal.
Fixed in master.
f9e49c8 scd: Fix an action after card removal.
Sep 2 2016
Sep 1 2016
Aug 29 2016
this also affects version 2.1.15 (latest gpg4win beta) and 1.1.1 (latest gpg4win
stable)
Aug 26 2016
Okay, if this transfers line endings because of the textmode read, it will
depend on the contents of the CRL in question. This explains why the defect was
not seen in earlier testing.
And pem does not work for this (I guess and tried on a GNU system).
It is okay that pem does not work, because this is a rarely used function I think.
Aug 25 2016
Aug 18 2016
Aug 10 2016
PNGs are noe rejected.
Aug 9 2016
Fixed with commit b5e16b0
Aug 2 2016
Will be a week or so. Had to power off my server due to "flooding" nearby.
Jul 29 2016
I confirmed that with patched npth, 2.1.14 with
c49c43d7e4229fd9f1bc55e17fa32fdc334dbef6 builds well and "make check" goes
successfully (on AIX 7.1 with gcc 4.8.1).
Please test again when npth 1.3 will be released.
I confirmed on AIX 7.1 with GCC 4.8.1, libgcrypt 1.7.2 builds well. "make
check" goes success with no errors.
I'm closing this again, because the particular problem of typedef has been fixed.
If you have another issue, please open another report.
This particular problem of assertion error, it was fixed in 1.22. So, I close this.
We also have T2378 for a possible change for Solaris/sparc. Please continue
there.
Jul 22 2016
While the detection works now to distinguish between PGP and S/MIME data it
might be more robust if it would do some more sanity checking on the packet.
E.g. PNG Graphics are detected as PGP Signatures because they start with 0x89
But this is not super neccessary as for the use case of file extension support
valid data will be detected correctly.
Jul 20 2016
My problems are resolved. I have not encountered a problem since your last
fixes. Although I sometimes have to reenter pin so I think the errors still
occur occassionally but gnupg recovers.
Thanks.
Jul 16 2016
Since Kleopatra is using data callbacks the total is always 0 so I can't use the
way to calculate percent.
Previously kleopatra used the filesize as total value. This does not work if
total is always 0 and the progress switches based on the current file size. E.g
for a large file the prgress decreases after 1024*1024 bytes have been processed.
I could probably add some weird "if gnupg > 2.1.14 and the file size is >
1024*1024 and the progress is < 1024*1024 expect it to be bytes and otherwise
expect it to be kilobytes." But this is not nice to use API.
My attached patch solves this by giving data callback users the opportunity to
provide GnuPG with the information how much input size it can expect. This makes
total / current workable from the start and everything is fine.
But as we jabbered about you do not like this patch :'-(
Problem not resolved for me as I think the weird handling currently imposed by
GnuPG is definitely not "Easy"
Jul 14 2016
You may want to test 1.7.2 instead.
2.4.3 has been released and I assume that this works now. Feel free to re-open
if it is not the case.
Jul 13 2016
I forgot to apply Daiki's patch. Done now with commit 82b90ee.
I won't work on the other mentioned change now and this commit is actually about
a regression. Thus bumping to testing.
Thanks. Changed with commit 678f606 for 2.4.3
Jul 7 2016
I think that the charset header in the armor is not a good idea. In fact gpg
does not consider it at all. The armor headers are not protected and thus they
should not not chnage the semantics of the encrypted message. There is also no
way to keep this information after removing the armor or to re-create the header
from a binary message.
I consider a new flag for the Literal Data Packet to indicate theat the content
is a MIME message to be better. Standard MIME methods can then be used to
describe the content. Right now we only have an 'u' flag to indicate UTF-8
encoding (which to some interpretation of OpenPGP is anyway the default).
An 'm' flag would make it explicit that the content is MIME encoded and there
would be no more need to derive that info from the context.
I also created a set of examples messages. They are in
gnupg/tests/openpgp/samplemsgs/
Jul 1 2016
Fix for the difference in detection of armored vs. binary detached signatures
was trivial so I've pushed it with rev. 570bf2a
Looks good to me know. I'll start using it in Kleopatra and we will see what
breaks :-)
Have not tested different S/MIME messages yet.
Jun 29 2016
Fix commited to master with rev 643575f
Jun 24 2016
Thanks.
I've created some examples to test it. They are all done with alfa@example.com
test key. Found an issue through that.
-ba (detached ascii armored signature) is detected as PGP-Signed and not as
PGP-Signature.
examples/plain.txt.asc: PGP-signed
A discussion about KMail handling PGP/Inline encodings [1] also makes me wonder
if data_identfiy should also return the output charset of text messages if it is
provided in the Armor Header. Afaik there is currently no API in gpgme to check
this and semantically It would make sense to me to parse this in identify, too.
But this is more of a question wether or not you think it makes sense to do this
directly. I'm not strongly opinionated about this.
Jun 23 2016
Done with commit cf37a57.
Note that only the first 2k are inspected.
Fixed in 2.1.13.
Jun 22 2016
Jun 17 2016
Thanks. I apply it to 2.1.
Jun 16 2016
Awesome, that did the trick!
Many thanks.
Sorry, my near sight. I only fixed cofactor support, in a case where "h" is
provided.
I should have fixed other parts, too. Now, I fixed in master:
It is backported to 1.7 branch too.
libaacs should work with this patch.
Well, I still get a "Missing object" error in libaacs, and I'm not sure how to
fix it. But the patch is in, so I think the bug can be closed.
It seems the problem is around the code here:
http://git.videolan.org/?p=libaacs.git;a=blob;f=src/libaacs/crypto.c;h=4db7641ec8e9af3cdf056562de39a39e3fa0c09b;hb=HEAD#l308
And the error I get when I try to scan a disc with aacs_info is as follows:
crypto.c:587: _aacs_verify: gcry_pk_verify failed. error was: Missing item in object
aacs.c:1502: invalid signature in cached hrl
If you have any hints, I'd be very grateful. Thanks!
Jun 15 2016
Can we close this bug? (1.71 has been released)
Jun 14 2016
Ah, I see. The GUI interface affects the S/MIME algorithm, not the general
one. I don't know why I didn't put that together sooner. Well, I'm glad that
it revealed the minor bug anyway.
Jun 6 2016
7257ea2 switches to none.
There is also a new option --with-subkey-fingerprint which keeps the compact
fingerprint format also for subkeys. The Lead-in text for fingerprints n the
listing is in any case not anymore printed if keyid-format is none.
Jun 2 2016
Ok,
Let me summarize how I understand the workflow is supposed to be:
- Generate a Key with the limited batch keygen.
- After key creation add subkeys as wanted with --quick-addkey
- Add additional UID's with --quick-adduid
I think I can work with that.
For full flexibility T2364 would be nice so that one could create a certify
only key this way and subkeys for everything else.
But yeah thats icing on the cake.
Still does not solve the Problem how to figure out which algrithms with which
parameters / capabilities are supportet but meh, I guess you can't have everything..
May 27 2016
Looks good...I can even build and run it using the ports version if I hand-patch
it after extracting:
[sonicyouth] /usr/ports/security/gnupg# make extract
> License GPLv3 LGPL3 accepted by the user
> Found saved configuration for gnupg-2.1.12
> gnupg-2.1.12 depends on file: /usr/local/sbin/pkg - found
> Fetching all distfiles required by gnupg-2.1.12 for building
> Extracting for gnupg-2.1.12
> SHA256 Checksum OK for gnupg-2.1.12.tar.bz2.
> SHA256 Checksum OK for gnupg-2.1.12.tar.bz2.sig.
[sonicyouth] /usr/ports/security/gnupg# cd work/gnupg-2.1.12/
[sonicyouth] /usr/ports/security/gnupg/work/gnupg-2.1.12# patch <
~ms/Downloads/gnupg-master-
20160527.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
diff --git a/configure.ac b/configure.ac |
index 6458f1a..d90921c 100644 |
--- a/configure.ac |
+++ b/configure.ac |
Patching file configure.ac using Plan A...
Hunk #1 succeeded at 787.
done
[sonicyouth] /usr/ports/security/gnupg/work/gnupg-2.1.12# autoconf
[sonicyouth] /usr/ports/security/gnupg/work/gnupg-2.1.12# cd ../../
[sonicyouth] /usr/ports/security/gnupg# make install
[snip]
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Reader ...........: 1050:0111:X:0
Application ID ...: D2760001240102000006036429670000
Version ..........: 2.0
Manufacturer .....: Yubico
[snip]
No, I'll do a Version check in for the GnuPG Version in Kleo master and I won't
backport any changes to the KDE4 / Gpg4win stable variant.
I'm assigning testing to me, I'll test it by using it in Kleo :-)
Done with commit 6c957c3.
Do we need to backport this?