The original reporter in the gpg4win-forums reports that this does not work reliably. :-/
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 13 2018
Nov 19 2018
Nov 15 2018
Nov 12 2018
Oct 24 2018
Sep 4 2018
Gpg4win-3.1.3 was released.
Aug 31 2018
Aug 30 2018
We have a progress dialog now and only show details on request. I've also fixed a bug that you could trigger learning the keys twice which lead to undefined behavior.
Aug 21 2018
Aug 20 2018
Hi,
Can I ask if there is any update on the issue that I face?
Aug 17 2018
Ok
Thanks for your answer
There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.
Aug 6 2018
Jul 24 2018
I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.
Jul 18 2018
Tester reports that this works now.
I got feedback from the user that had the problem. It's fixed with 2.2.9 which contains your commit afaik.
Jul 17 2018
This was a misunderstanding. Import is possible. The german translation of Kleopatra wrongly indicated an error because it translated "unknown certificates" as "ungültige Zertifikate".
Jul 16 2018
Jul 12 2018
it is not due to windows but due to the use of NTBTLS. I have the same problem here... and found it: We call es_fflush to let ntbtls flush its internal buffers but libgpg-error's estream module does no propagate this explicit flush to the cookie functions of ntbtls. Thus ntbtls gets stuck most of the time. I am not sure when this regression happened but it is pretty obvious.
Jul 11 2018
I have logging to a socket always enabled. That may explain why I don't see that error on Unix.
Jun 25 2018
Jun 19 2018
Hi Werner,
I have performed some experiments on the issue I have and the following are the results:
Jun 8 2018
I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.
Jun 6 2018
Hi Werner,
The issue is the following:
I have 2 certificates in the trusted-certificates folder that is searched by gpgsm (C:\ProgramData\Gnu\etc\gnupg\trusted-certs) which I want to trust. When dirmngr starts, it reads the Windows trusted certifcate store (certlm.msc for both system and user - I don't know the path / location of the windows certificates folder outside certlm) and builds the list of certificates to use. Once this list is read and if any duplicates are found in the trusted-certificate folder, it ignores them - they are already present.
I do not fully understand your problem. Can you please explain it with an example and also state the full file names of the mentioned folders?
May 31 2018
May 14 2018
Do you have any other implementation to test against?
May 8 2018
But why is that the case for OpenPGP Signatures, then? The difference does not make sense to me.
The key receives fully trust and thus we get the "green" flag plus the "expired" flag. In my test with OpenPGP the key was not trysted and thus we did not got only the "expired" flag. At some distant past we agreed on these rules.
gpgsm behaves exactly as gpg and as explain in doc/DETAILS. VALIDSIG is issues even for signatures done by an expired certificate. Let me check whey GPGME claims "green" here while it does not not an expired OpenPGP signature.
Wait. Users should not have the ability in the GUI to mess with the CRL cache. That is internal / private stuff. And something for developers, so this should be removed from the GUI altogether.
I think this issue is important as GPGME should not report "Green" / Everything OK in that case and only have the EXPKEYSIG in details.
May 7 2018
May 4 2018
May 3 2018
This is resolved in my opinion. I've tested with some larger CRL's and it worked on Windows.
May 2 2018
No longer happens when the good old ldapwrapper is used.
Apr 30 2018
The highest priority I see here is for T3953 which I think is a bug that might result in a good signature shown for an expired, but otherwise valid and trusted certificate.
Apr 27 2018
Apr 25 2018
Still happens. There are also "BER" errors that seem random.
Apr 24 2018
Apr 23 2018
See also T2448
Apr 21 2018
This for importing passwords using a somewhat heuristic approach to accommodate for all the weird things other PKCS#12 implementations do. I have not looked into the specs for a decade and thus can't tell you the reason for that limitations. There might have been one back then. In any case PKCS#12 is the most insecure things in the PKCS suite and it is questionable whether this can be called a standard.
Apr 20 2018
Looks ok now in my tests. I still want to test against more CA's with more CLRs (e.g. COMODO and CACert)
Apr 16 2018
I wonder if CACert intentionally sabotages X509 / CMS.
Feb 12 2018
When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.
Jan 31 2018
--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.
it is the decision of the user to use such a certificate.
The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.
Jan 30 2018
Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.
Oct 24 2017
Oct 20 2017
DCO = Developer's Certificate of Origin. See gnupg/doc/HACKING under "** License Policy" .
I am preparing the patch I am using against 2.2.0. What is DCO?
@perske, may I ask you to send a DCO and an possible updated patch against 2.2 to gnupg-devel@ ? I would like to add it to 2.2.2. Sorry for the delays.