These are great news. Thank you!
Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.
Thank you for the information.
For the record, I put the link to the email submitted:
Wed, Sep 22
Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:
Sorry about that, I forgot to add GCC. I updated the original post with the needed information.
Sorry, I don't know which software has version 12.0.0 and which git master this is. In case this is stock libksba, please tell us at least the last commit id. Note that we in general do not support arbitrary versions from the repos but only released versions .
I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?
Tue, Sep 21
That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:
That does indeed not look like something which could introduce a regression.
I misunderstood as if we need to update libtool from upstream.
macOS has low priority for us and I do not want to risk any regression.
About merging our local changes.
We have our own changes for ltmain.sh and libtool.m4.
And update from automake 1.16:
It's better to update the set of files from libtool:
build-aux/ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 m4/ltversion.m4 m4/lt~obsolete.m4
Our libtool was 2.4.2 + Debian patches + our local changes.
Debian patches are:
Sat, Sep 4
This works for me:
Mon, Aug 30
Aug 18 2021
I added some asserts. However I doubt that it can be hit by LibKSBA. I also fixed a real bug related to VALTYPE_BOOL - but that is also not used in Libksba.
Jun 10 2021
May 26 2021
Another solution to make life easier for gpgme users encountering this stuff would be if gpgme itself knows which uid is a DN and which is not, it could populate the gpgme_user_id_t.address field with content of the 1.2.840.1135220.127.116.11 DN component. (or maybe gpgme_user_id_t.email, or both? as a user of gpgme, i don't really understand the difference between these fields)
fwiw, RFC 2253 is obsoleted by rfc 4514 -- which also doesn't have 1.2.840.113518.104.22.168 associated with "EMAIL", but does provide more detailed guidance for implementers of DN-to-string (and string-to-DN, to the extent that this is possible) conversions. Maybe the code should be updated to refer to the non-obsolete specification at least.
We translate only those OIDs from RFC-2253 to have a stable set of names in the libksba interface. If you need anything else, you need to do this yourself. For example gpgsm does this in in parse_dn_part, gpa has the code in format-dn.
I'm reporting this because the above message renders poorly in notmuch -- notmuch gets the user ID from gmime's g_mime_certificate_get_user_id, and gmime populates that field from the uids field of a gpgme_key_t object, and gpgme pulls uid information from gpgsm --with-colons.
Attached is a proposed patch.
Apr 21 2021
Thank you for your confirmation. Closing.
Apr 20 2021
I applied 1,2,3, and 5 in rKfbb1f303198b: Fixes for static analysis reports.
I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?
Apr 14 2021
Apr 6 2021
Nov 23 2020
Released on 2020-11-18