I think we can close this as Wontfix since it is our opinion to wont fix this issue. If there should be more prevetion of accidents it would probably be better to have the user type in "DELETE" or "YES". Anything else then another click confirming a popup. Since this will just be clicked away through muscle memory. This came up again in T7211: Kleopatra: configuration option to prohibit deletion of certificate with secret key

Unfortunately there are real world applications which make use of this option in special environments. Thus we can't remove it. I improved the warning in the man page.

I agree. Any automatic use of the embedded filename will be potentially problematic security-wise. The only safe use is probably as a value in an interactive dialog, and even then, only if the user doesn't accept a dangerous value.

The patch supplied here should apply to STABLE-BRANCH-2-4, but it should also be easy enough to backport to STABLE-BRANCH-2-2 and STABLE-BRANCH-1-4. For GnuPG master, i recommend actually removing the option.

Fixed in 2.4.4. Feel free to re-open if you still see problems.

I applied your patch and also fixed another possible problem.

Sorry for the fallout and thank you for taking care of it.

Ah... it fails by make check because it does change the text in tests/basic.c which requires update of hash value.
I'm going to take care of this regressions.

Thank you. All applied and pushed to master.

See rG0988e49c45 which implements time and group but not yet the split thing because we are not shure that is good idea to have this w/o any implementation support.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

In T6388#168750, @gniibe wrote:

Thank you for the bug report.

I see your problem. We need to improve the patch, as we cannot use Bash-only feature in configure.
[...]
That is, prefer possible_libdir1 when not used. Please test this.

Fixed in master and 1.10 branch.

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

Thank you for the bug report.

@gniibe: Would you mind to look at this?

Thanks

Pushed.

Should be OK for mingw.org's MinGW. I cannot test the MinGW64 bits, but I trust that you did.

I encountered this issue of struct stat when compiling for x86_64 of Windows.
I'm considering this patch:

diff --git a/common/sysutils.c b/common/sysutils.c
index c30f9a0ce..bbed309a8 100644
--- a/common/sysutils.c
+++ b/common/sysutils.c
@@ -1237,10 +1237,20 @@ int
 gnupg_stat (const char *name, struct stat *statbuf)
 {
 # ifdef HAVE_W32_SYSTEM
+#  if __MINGW32_MAJOR_VERSION > 3
+    /* mingw.org's MinGW */
+#   define STRUCT_STAT _stat
+#  elif defined(_USE_32BIT_TIME_T)
+    /* MinGW64 for i686 */
+#   define STRUCT_STAT _stat32
+#  else
+    /* MinGW64 for x86_64 */
+#   define STRUCT_STAT _stat64i32
+#  endif
   if (any8bitchar (name))
     {
       wchar_t *wname;
-      struct _stat32 st32;
+      struct STRUCT_STAT st32;
       int ret;

It's in 1.18.0.

The commit is: rMb2f224a471fe: python: Reset passphrase callback correctly..

Thank you for the patch. You are right.

What I found: When the page is served by the server, it omits "charset=utf-8" part. This is the issue.

Thanks for fixing.

Thanks for reporting.

The first thing is a problem of the GNU makeinfo tool. Can't be fixed int the source.

But then again: The three other apostrophes that occur in the text are represented by single quote characters. Maybe sticking to ASCII characters is the better fix after all.

Typographically the apostrophe character ’ is a different character than the single quote character '. So, the correct fix would be to fix the probably wrong encoded apostrophe instead of replacing it by a single quote character.

Please use the feature in 2.3.7 of T5099, instead.

Fixed in 2.3.7.

Thank you. Applied.

Patch applied to master with small changes.

Applied the changes.

Thanks @jukivili , Here is the changelog,

Thanks for updated patch. I'm travelling next week and have time to check it closely only after I'm back. On quick glance, it looks good. What is also needed is the changelog for git commit log.

Thanks @jukivili. I have never thought of interleaving with interger poly1305 operation and that's a good suggestion. Will think about that one.

I meant interleaving integer register based 1xPoly1305 with 8xChacha20 as is done for 4xChacha20 in cipher/chacha20-ppc.c (interleaved so that for each 4xChaCha20 processed, 4 blocks of 1xPoly1305 is executed). Quite often microarchitectures have separate execution units for integer registers and vector registers and then it makes sense to interleave integer-poly1305 with vector-chacha20 as algorithms do not end up competing for same execution resources. Interleaving vector-poly1305 and vector-chacha20 is not likely to give performance increase (and likely to run problems with running out of vector registers).

HI @jukivili , Thanks for the updates. For f14-f31 registers that was my mistake that did not think floating point will be used. Will correct that. For poly1305, it can be used on ARCH_3.0 so checking use_p10 doesn't seem to be necessary but I can include that as well.

Also applied to 1.10.

Applied and pushed.

Problem is that new assembly is using VSX registers vs14-vs31 which overlap with floating-point registers f14-f31. f14-f31 are ABI callee saved, so those need to be stored and restored.

Tested patch with small change so that HWF_PPC_ARCH_3_00 is used instead of HWF_PPC_ARCH_3_10. Building bench-slope with "-O3 -flto" makes bug in new implementation visible. Without new implementations bench-slope is ok (testing with QEMU):

$ tests/bench-slope --disable-hwf ppc-arch_3_00 cipher chacha20
Cipher:
 CHACHA20       |  nanosecs/byte   mebibytes/sec   cycles/byte
     STREAM enc |      2.35 ns/B     405.0 MiB/s         - c/B
     STREAM dec |      2.32 ns/B     410.7 MiB/s         - c/B
   POLY1305 enc |      2.46 ns/B     388.0 MiB/s         - c/B
   POLY1305 dec |      2.34 ns/B     408.1 MiB/s         - c/B
  POLY1305 auth |     0.238 ns/B      4003 MiB/s         - c/B

-O2 problem with bench-slope seems strange. Does problem appear after this patch is applied?

This feature is implemented in different way, by T5099.

In T5975#158113, @werner wrote:

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

The second part is imho not a good idea. Libgcrypt is a building block for all kind of software and there are for sure legitimate reasons to use rsa512 (MCUs, short living keys, etc). Thus I think that the decision on the key size should be done by the software using libgcrypt.

Pushed the change (master and 1.10).

To detect these kinds of bugs, possibly, we can use new GCC option: -ftrivial-auto-var-init=0xFEFEFEFE.
https://gcc.gnu.org/gcc-12/changes.html#uninitialized

The bug was there when it was initially written. It was in 2003, which introduced PC/SC in rG1bcf8ef9dea1: Cleanups, fixes and PC/SC support

I just wrote a blog article about this problem
https://ludovicrousseau.blogspot.com/2022/05/scardlistreaders-and-non-initialized.html

Thanks for opening a ticket.

Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.

Thanks. Should be applied.

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

Pushed the changes for http.c.

Last part is applied. Let me consider how to solve, for other parts.

I guess I don't understand what you mean by "native building". This build was with MinGW, which is as "native" as MinGW64 is.
The reason for the problem is (AFAIU) that MinGW64 went after Microsoft's change in stat due to the 32-bit vs 64-bit time and off_t values issue.s That change breaks backward compatibility in more than one way: programs compiled on some versions of Windows will not run on other versions. mingw.org's MinGW kept the original semantics and symbols, which is why _stat32 exists in the mingw.org's headers, but is not exposed by default.

Turned into a feature request because native building on Windows is not supported.