Thanks
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 24 2023
Jan 19 2023
Oct 14 2022
Pushed.
Sep 22 2022
Sep 1 2022
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;
Aug 15 2022
It's in 1.18.0.
Aug 5 2022
The commit is: rMb2f224a471fe: python: Reset passphrase callback correctly..
Thank you for the patch. You are right.
Jul 27 2022
What I found: When the page is served by the server, it omits "charset=utf-8" part. This is the issue.
Jul 26 2022
Thanks for fixing.
Thanks for reporting.
The first thing is a problem of the GNU makeinfo tool. Can't be fixed int the source.
Jul 19 2022
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.
Jul 12 2022
Please use the feature in 2.3.7 of T5099, instead.
Fixed in 2.3.7.
Jul 7 2022
Jun 14 2022
Thank you. Applied.
Jun 13 2022
Jun 12 2022
Patch applied to master with small changes.
Jun 8 2022
Applied the changes.
Jun 7 2022
Jun 3 2022
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.
Jun 2 2022
Thanks @jukivili. I have never thought of interleaving with interger poly1305 operation and that's a good suggestion. Will think about that one.
Jun 1 2022
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.
May 31 2022
Also applied to 1.10.
Applied and pushed.
May 28 2022
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
May 27 2022
-O2 problem with bench-slope seems strange. Does problem appear after this patch is applied?
May 26 2022
May 25 2022
This feature is implemented in different way, by T5099.
May 23 2022
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.
May 19 2022
Pushed the change (master and 1.10).
May 17 2022
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
May 14 2022
I just wrote a blog article about this problem
https://ludovicrousseau.blogspot.com/2022/05/scardlistreaders-and-non-initialized.html
May 13 2022
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.
May 10 2022
Pushed the changes for http.c.
Mar 30 2022
Last part is applied. Let me consider how to solve, for other parts.
Mar 22 2022
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.
Mar 14 2022
Thanks for you patches. Most of them applied cleanly despite that I delayed processing them for half a year.
Mar 2 2022
Feb 14 2022
Feb 10 2022
Dec 21 2021
Ok, I'll add.
Seen. @jukivili can you please add it to the AUTHORS file?
Dec 14 2021
Ok, I have subscribed to the mailing list. I have resent the DCO.
DCO has not appeared on mailing-list. You can this from check list archives, https://lists.gnupg.org/pipermail/gcrypt-devel/2021-December/thread.html
Thanks Jussi, I did not receive the list moderator's email so I am not sure if the it has been posted on gcrypt-devel@gnupg.org. If not, I can resend the DCO. Thanks.
I did some finishing touches on coding style:
Dec 13 2021
Hi Jussi,
Dec 12 2021
Few comments on new patch:
Dec 10 2021
Hi jukivili,
Dec 8 2021
Dec 7 2021
Hi jukivili,
I ran some basic tests and it did show the errors. I am in the process investigating what went wrong. In the meantime, i also included test result that I have used in my testing from bench-slope. In this test, I captured the message with 272 bytes buffer from the original libgcrypt repo and my optimized repo. Note that the bulk version of my code do 8x unrolling and the rest will do 16 bytes. So the first 2 128 bytes ran thru gcry_ppc_aes_gcm_encrypt and the rest of the 16 bytes thru gcm_ctr_encrypt (cipher-gcm.c).
Dec 6 2021
Thanks jukivili for the review.
Dec 4 2021
Thanks, however I didn't see your email on mailing-list. Maybe the email got stuck on the way.
Dec 2 2021
I sent a copy to gcrypt-devel@gnupg.org. Hope this is the right process. Thanks.
Please read doc/HACKING carefully on the process of sending DCO the right way.
Nov 23 2021
Hi Werner, Here is the DCO. Thanks.
FWIW: We need a DCO; see doc/HACKING.
Sep 13 2021
Sep 12 2021
Aug 27 2021
Code for avoiding the COMMON section has been there, because of RISC OS.
I think that it will be easier to enable that for all (but not for RISC OS only).