New release of libassuan is expected to make sure it's cleared off.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 27 2022
Jul 26 2022
Jul 22 2022
@gniibe Thanks!
In the repo, for all related software, it's done.
Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.
Jul 18 2022
Thank you.
Jun 9 2022
Backported to GnuPG 2.2.
Jun 8 2022
Applied the changes.
Jun 7 2022
Jun 1 2022
May 27 2022
May 25 2022
Pushed the solution which doesn't require new flag for libassuan.
^-- I withdraw the solution (with error value) above.
May 24 2022
Or, it would be good for client side (in this case, gpg-agent) to specify the flag in the inquiry callback, that is, it's a kind of transient flag for a single transaction.
Revised version with new flag ASSUAN_CLEAR_INQUIRY_DATA.
May 19 2022
For this particular issue of assuan_inquire, if it's needed, the point we should fix is:
May 18 2022
Apr 8 2022
Apr 5 2022
GPGME has its own system hooks to provide a (different) solution for portability (Windows and POSIX).
Apr 1 2022
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
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:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html
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:
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:
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/link_all_deplibs.patch
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/netbsdelf.patch
Aug 13 2021
Jun 8 2021
Applied and pushed.
Apr 16 2021
(sorry, about my former comment, I only now realized that you did just that already in your original patch)
Updated:
diff --git a/configure.ac b/configure.ac index 53a343b..f496729 100644 --- a/configure.ac +++ b/configure.ac @@ -82,6 +82,7 @@ AC_PROG_AWK AC_CHECK_TOOL(AR, ar, :) AC_USE_SYSTEM_EXTENSIONS
I guess the strcasecmp (nl_langinfo (CODESET), "UTF-8") results in some overhead, so if we do that what about kicking in only if a truncation is really to happen.
Sorry, I was wrong. It seems that GNU C library has a feature to avoid bad truncation.
Mar 22 2021
Jan 2 2021
Hi there, this change is very useful on the Homebrew project's upcoming ARM port. The Mac package manager's base library prefix will change from the existing presumed defaults to prevent backwards-incompatibility, making pkg-config compatibility somewhat more important.
Nov 16 2020
Oct 23 2020
Sep 3 2020
To implement this it would be best to have an gpg_strerror variant which does not call dgettext.
re 1: Correct utf-8 truncation would be quite some work. In this case the message is in the Assuan interface is a debugging aid. Translation is not necessary so we can try to disable it.
Aug 17 2020
No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.
Aug 14 2020
-std=c99 is probably the reason that the tests fail.
Please try with out supplied CFLAGS or change them from
Jul 29 2020
We have had this in the past but it led to subtle build and, worse, runtime problems. Thus the decision to provide architecture dependent files and have configure complain for wrong files. Right, you sometimes get false warnings for non-matching cpu-vendor-os strings but I consider this less severe than the old problem.
Jul 16 2020
This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem
Mar 12 2020
Feb 18 2020
With the fix of T4623, this bug is now fixed.
Dec 6 2019
Aug 20 2019
Well, gpg-error is special. For other libraries, adding -I and -L is enough and good.
Fixed in master.
Thank you. I only tested a configuration where installation of libassuan has same prefix as libgpg-error. That's the reason why this bug exists.
Aug 19 2019
Jul 18 2019
Thanks.
Merged (with line break in the Makefile.am and formatting of commit message.
Jul 17 2019
I don't know why dkg-fix-T4641 is not showing up here on the assuan git repo.
I've just pushed rA45f01593d4ce794ae3562359aee2ff80c97e368e to the dkg-fix-T4641 branch that resolves this.
Jul 15 2019
Jul 1 2019
As I said we do this with all GnuPG components. Pinentry is a bit of exception because it is an external package.
I have also had bug reports which later turned out that a wrong pinentry was used; I prefer to know eactly which pinentry is used. Regarding your concrete problem I suggested to add a note with the full name of the pinentry or to change the error message to something better understandable.
So this is a defense against an adversary capable of creating a pinentry-wrapper somewhere in $PATH, but not capable of modifying gpg-agent.conf? It sounds to me like this is a defense against a very unusually-constrained attacker, at the expense of regular, common bug reports and user confusion.
GnuPG invokes its components always with their absolute file name. We want to mitigate attacks where malware creates a pinentry wrapper somewhere in an improper set PATH.
Jun 27 2019
Mar 27 2019
gpg4win 3.1.6 is released which contains this fix.
Feb 25 2019
Feb 19 2019
Feb 11 2019
Released 2.5.3 today: