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.

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.

Updated by the fix:

f9e49c8 scd: Fix an action after card removal.

Fixed in master.

f9e49c8 scd: Fix an action after card removal.

this also affects version 2.1.15 (latest gpg4win beta) and 1.1.1 (latest gpg4win
stable)

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.

PNGs are noe rejected.

Fixed with commit b5e16b0

Will be a week or so. Had to power off my server due to "flooding" nearby.

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.

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.

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.

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"

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.

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

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/

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.

Fix commited to master with rev 643575f

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.

1: https://bugs.kde.org/show_bug.cgi?id=248058

Done with commit cf37a57.
Note that only the first 2k are inspected.

Fixed in 2.1.13.

Thanks. I apply it to 2.1.

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:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=0f3a069211d8d24a61aa0dc2cc6c4ef04cc4fab7;hp=fa917d2e24b0c98143a079ab4889ad8f69bee446

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!

Can we close this bug? (1.71 has been released)

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.

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.

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..

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:

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?

I see. I just pushed two fixes.

Thanks. Fix released with 2.0.30 and 2.1.12.
We can close this bug after the release of 1.4.21

Fixed in all branches.

Master 2.1: d9f9b3be036747c9f55060aed47896f951bfb853
1.4: d957e4388f72581b1ec801613b5629b5ea3f586d
2.0: eb7806d63df63663170ba86f0673caa34b944c28

For some reason, the commit messages of 1.4 and 2.0 refers
master commit of 2f3e42047d17313eeb38d354048f343158402a8d.
Perhaps, I did in my repo and it was 2f3e420 and apply it to 1.4 and 2.0.
Then, I pushed 1.4, 2.0, and 2.1. and 2.1 was failed because of
non-fast-forward. Then I rebased for 2.1.

Patch applied in dc417bf0c555a7416d0aedde6645fd1087660f92 (Dec 15, 2015)

iirc, we removed the patch from 2.1 due to some problems. We plan to work on it
in 2.3.

Neal, what is the status of this bug?

We still need to check whether has been fixed for 1.4 and 2.0.