I suspect this is because the program itself is only 32 bit, which does not make sense to me why would it be.
Anyways, is there a 64 bit version of gpg4win?
Hi Vicent!
It is possible to have large file support in 32 bit applications.
(As far as I know GnuPG, the crypto engine within gpg4win is only available as 32 bit application, there was no reason the change this.)
This maybe a different limitation.
How did you try to calculate the checksums and on which filesystem?
Best
Bernhard
Maybe sha256sum.exe is not ready for largefiles, the source code is here
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=src/sha1sum.c;hb=HEAD
it depends on how it is build to make FILE be a larger pointer.
Can you check if calling sha256sum.exe directly on your files does not work?
As far as I know GnuPG, the crypto engine within gpg4win is only available as 32 bit application, there was no reason the change this.
Can we do the exact opposite please and ONLY build 64 bit from now on? Besides not needing any LARGE_ADDRESS_AWARE hacks and big FILE pointers and the like. 64 bit processes are also more secure because they have /HIGHENTROPYVA (Support 64-Bit ASLR) enabled by default. /HIGHENTROPYVA (Support 64-Bit ASLR) | Microsoft Learn
Hi Markus,
that is something that you should take to the gnupg-devel mailnglists.
https://lists.gnupg.org/pipermail/gnupg-devel/
to discuss the pros and cons of the different varieties.
(For this discussion thread is about the checksums.)
Personally I do not know the technical details. From what I have understood,
GnuPG (the crypto engine in Gpg4win) supports a great variety of platforms, including
32bits ones. And as long as there is 32 bit support, and platforms, it will need to
deal with the differences.
Best Regards,
Bernhard
Hi Bernhard,
the last mainstream CPUs running on Windows PCs that don’t support x64 were the Pentium 4s 20 years ago. Some rare Atoms were updated later. Still it’s time to move on.
Who builds the executables and libraries that go into gpg4win?
I see there is both a “bin” and a “bin_64” in the installer.
What stops you from building everything as x64?
Does the GnuPG code not compile for 64bit at all?
Regards
Markus
Hi Markus,
it is not about what PC hardware would be able to do. It is about what people run
and other hardware.
I think Windows 7 still could do 32 bit and thus there will be some machines out there, still running it in the world (not everybody can just upgrade). Gpg4win tries to be compatible with many installations. (https://en.wikipedia.org/wiki/Windows_7 says that “As of September 2022, 11% of traditional PCs running Windows are running Windows 7”.)
And then I guess that GnuPG runs on small scale hardware that might still be 32bit only.
(Like most Raspberry Pis still run 32bit last time I’ve looked.)
Given that you need to support 32bit anyway and largefile support there as well, the question is what a 64bit version could offer for the extra maintenance efforts it creates as a variant?
Anyway, gnupg-devel@ is the right place to discuss this question and the details.
Best
Bernhard
Hi Bernhard,
And then I guess that GnuPG runs on small scale hardware that might still be 32bit only. (Like most Raspberry Pis still run 32bit last time I’ve looked.)
Just to make this clear: nothing prevents the upstream gnupg from being compiled for Linux 32 bit on small ARM machines. Yes, 32bit ARM is going away soon too ( Is 32-bits Really Dead? | Hackaday ). But I have nothing against gnupg compiling for 32bit at all for the next 10 years. This has nothing to do with what I am proposing for your PC installer for Windows PCs.
Anyway, gnupg-devel@ is the right place to discuss this question and the details.
Is it really though? I think I don’t have any input for the gnupg source. My input is more about how Gpg4win is built and packaged by this project!
Given that you need to support 32bit anyway and largefile support there as well, the question is what a 64bit version could offer for the extra maintenance efforts it creates as a variant?
The upstream project has to support both, but it doesn’t make sense to me why you are still building 32bit version only for Windows? 32bit on PC is not relevant any more:
- There hasn’t virtually not been any CPU sold that requires 32bit compatibility for 10 years now as per my last emails.
- Ubuntu just links to the 64bit installer on their download page. You have to dig really deep to find the 32bit version. https://ubuntu.com/download/desktop
- Microsoft is dropping 32bit support https://www.bleepingcomputer.com/news/microsoft/rip-microsoft-to-drop-support-for-windows-10-on-32-bit-systems/
- Chrome 32-bit is no longer receiving security updates (or updates of any kind, for that matter). You can’t even properly browse any more on 32 bit!
While yes, Windows 7 still could do 32 bit stop building it for your PC focused installer. That’s just unneccesary maintainance effort for you. And you are depriving anybody using your builds from potential improved ALSR security and potentially more performance (due to double registers for example, or due to the fact that all x64 processors is required to have at least SSE2 support.
Why is there still a 32bit x86 sha256sum.exe in your installer? Get rid of that!
Instead of having mostly 32 bit, have only 64 bit in your installer.
You’re not increasing, you’re reduce your maintainance burden by getting rid of the old cruft and improving what your delivering for users.
Best Regards
Markus
Hi Markus,
we used to discuss Gpg4win development question on
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-devel
but we probably move this to gnupg-devel@ as well. You can try gpg4win-devel@ first,
if you like.
| While yes, Windows 7 still could do 32 bit stop building it for your PC focused installer.
| That’s just unneccesary maintainance effort for you.
If we want to keep compatibility with old systems we have to build a 32bit version
and if we do that, doing only one is less effort.
Of course this is open for discussion to get better numbers of the changing landscape.
| And you are depriving anybody using your builds from potential improved ALSR security and potentially more performance (due to double registers for example, or due to the fact that all x64 processors is required to have at least SSE2 support.
The pros and cons of each technical build option are best discussed on the development mailinglist(s).
Best Regards,
Bernhard
I have to agree that 64bit should be the primary for Windows.
Backwards compatibility can not be more important than modern expected function.
Those who need backwards compatibility can use older versions.
Or compile 32bit themselves.
I’ve compiled my own versions of modern gpg on Ubuntu LTS for years, since I want a newer version than comes pre-packaged.
Hi Kim,
thanks for your view on the matter.
Technically I am not sure that the 32bit version is missing any “modern expected function”.
This is why it needs to be brought up.
Of course it is a potential defect if sha256sum does not do large-files, which is what triggered this discussion. However support for large files can be done with 32 bit binaries,
so this is not the decisive matter. Markus suggested potential ASLR security or performance advantages, those points have to evaluated of course (on the development mailinglist.)
Best Regards
Bernhard
Hello Vincent,
I just tried the sha256sum.exe with a huge file (>8,4 GB) and it worked just fine. Using Gpg4win 4.0.4.
Greetings,
Christoph
Can you please tell us some more details? Which version of Gpg4win are you using? Which file system is the partition using where the file is stored?