Turning this into a feature request: We should create P12 files using AES instead of 3DES
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 25 2023
If we ever add a way to take the password from a file we will for sure hide that in the log files. Ceterum autem censeo tesserae esse delendam.
Aug 23 2023
The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)
No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.
Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.
Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?
It turned out that we need to fix this for use by Kleopatra on Windows.
It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.
That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null
That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null
This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808
Aug 10 2023
Jul 26 2023
From my side this can be closed. In Kleopatra we can maybe check for some more MIME types and then use GPGME_ENCRYPT_NO_COMPRESS but that is unreleated.
Jul 18 2023
I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.
Jul 6 2023
Jul 5 2023
Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.
Jul 4 2023
This was tested by me against the actual sample and the sample is now part of our internal regression test suite.
with the new gpg.exe you gave me for testing it looks good now:
related to T6528
No. Missing mapping in iobuf.
Jul 3 2023
gpgrt version?
I get a failure status, but a different one.
Seems to be an other issue? But wasn't (ec=112) disk full?
And the disk of the Windows VM must have been running full with that file, before the start there were ~2,6 GB free:
Jun 29 2023
Jun 28 2023
Partly done for 2.4. The cram-octet-string stuff is missing, though.
Jun 27 2023
This has long been fixed in 2.4. Given that Libgcrypt has support for PBKDF2 we can back port this.
Jun 26 2023
Jun 23 2023
Jun 22 2023
We had one request to support this back in 2017 but it was closed because the respective CA stopped using this extension. See T2039.
Jun 19 2023
rGb1ecc8353ae3 is just what I meant, so that we can recommend such an option in the future as a workaround until a new update becomes available which supports such an extension.
Nah, the description for that extension is pretty strict and I won't feel comfortable to just ignore it. BTW there is also T6398 (nameConstraints) which needs support. But for debugging a ignore extension makes sense.
For support reasons I would say that it might make sense to also ignore the extensions from "ignore-cert-extension" when checking CRLs?
Jun 16 2023
I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.
Jun 15 2023
And of course we also need to adjust GPGME
We also need PROGRESS lines in gpgsm.
Jun 14 2023
Jun 13 2023
Jun 12 2023
Jun 9 2023
With my fixes I now get this:
Actually two bugs. Easy to test on Unix with a small (e.g. 10MiB partition).
Jun 5 2023
Works in kleopatra; tested with gpg4win-4.2.0-beta339.
May 30 2023
May 26 2023
May 25 2023
May 24 2023
May 23 2023
Kleopatra test case (similar to gpg):
May 19 2023
Fixed in 2.4
May 2 2023
Apr 20 2023
Okay, that was easy to check.
Apr 18 2023
@gniibe, will you be so kind an check the provided patches
gpg --edit-key; keytocard; save
work as expected.
Apr 17 2023
works
Apr 13 2023
gpg_encrypt (engine-gpg.c) passes --output - to gpg, i.e. it reads the result of gpg --encrypt from stdout unless I misread this. Not sure, why this seems to work on Windows. The real problem is probably something completely different.
On Windows we always use --status-fd=1 but with gpg it is not a problem because we use a differenrt fd for output.
Apr 12 2023
Apr 11 2023
The gpgme logs show that gpgtar is called with gpgtar [...] --status-fd 1 [...] --output - [...], i.e. fd 1 is used for status output and for the result output of gpgtar. This cannot work. To me this looks like a flawed implementation of _gpgme_io_pipe() resp. new_fd() in w32-io.c which happily returns 1 as FD on the first call.
Apr 6 2023
I'll add new error codes to gpgrt