Mon, May 16
Fri, May 13
Mar 25 2022
Mar 22 2022
Thank you. Confirmed and applied.
Dec 8 2021
Nov 10 2021
Also applied to gpgme.
Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.
Nov 3 2021
Oct 13 2021
Oct 12 2021
Bison used to be the de-facto standard yacc ;-)
I think that a simple way is defining a table (string -> token) by ourselves in yylex, not enabling %token-table.
(Then, we don't need to depend on the feature of string with %token, which is not supported by POSIX yacc.)
Oct 11 2021
Thanks for your findings. I recall that I read this in the announcement and cursed about this new tendency in GNU to break long standing APIs.
Looks like yytoknum was removed from Bison in version 3.8: http://git.savannah.gnu.org/cgit/bison.git/commit/?id=1efe31185ff6b0bc22ff527098971bedf1ace5f4
Sep 27 2021
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:
Sep 22 2021
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?
Sep 21 2021
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:
Sep 4 2021
This works for me:
Aug 30 2021
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.1135188.8.131.52 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.1135184.108.40.206 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.