work/markus_montkowski/T7485

work/markus_montkowski/T5681

In version Version VS-Desktop-3.3.0.0 a certificate imported via WKD is correctly shown as level 2 security:

No error message in that case for Gpg4win 4.4.o either

Is not a GpgOL bug.
Full functionality will be possible with GpgOL/WEB.

Well I finally did some more tracing and removeOurAttachments_o is not called when the attachments vanish.

There is a new report where mails are not shown with the following settings:

HKCU\Software\Microsoft\Office\16.0\Outlook\Options\Mail:ReadAsPlain
  ->0<-
HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Mail:ReadAsPlain
  ->1<-

works for VS-Desktop-3.2.94.481-Beta, too

VS-Desktop-3.2.94.481-Beta: works, if no kleopatragroupsrc is found at the new location, the one at the old location is used.
This is only relevant in the case that after the update to this version GpgOL is used without starting Kleopatra in between.
Because when Kleopatra is started it will copy the kleopatragroupsrc from the old location to the new one. After that the config file in the old location is ignored.

Fixed. No backport needed because we use gpg4win-tools master also for VSD 3.3
@werner: gpg4win-tools needs to be updated in gpg4win master.

The file path of the group config file in line
https://dev.gnupg.org/source/g4wt/browse/master/src/resolver/resolver.cpp$171
has to be changed to the one in line
https://dev.gnupg.org/source/kleo/browse/master/src/kleopatraapplication.cpp$355 .
It may be best to add a function returning the default path to libkleo. Or to use the new path by default if no other path is passed to the c'tor of KeyGroupConfig. It's unfortunate that the path is GNUPGHOME/kleopatra/kleopatragroupsrc although the groups are also used by GpgOL and they should likely also be supported/used by KMail.

This was now added as disableAutoPreview (the option was renamed after 26c2fc196bb73d9bd96c91ea7cc12679d925b376 )

Since codesigning for all dlls was added this is fully resolved.

There won't be improvements to PGP/Inline

The status of HTML Mails is noted in T6333 everything else here does no longer apply afaik. Although mailstore has since been known as an incompatible addin.

Forgotten to resolve the issue when fixing it.

I have fixed this as a7349189f3af05822eba4bd17b62482fa2b0747f so I am closing this as a duplicate of T5982 because it is clear to me now that the problem was sending and no receiving such mails and was broken by 9f81ed6561c5f41e50d1a51333c9586a33ed2ef6

I mostly receive HTML only mails from automated mail systems.

Sorry, what I meant by this was just 9316d458d509dd0237a6bb82109c0f48549c3e59 which I added to T6582 instead of this ticket

This was fixed by c0ca4f1b254f6879d719d1a5ed43a51ca9015b93 since the embedded message was not handled it was not extracted / parsed into an Attachment C++ Object which caused this error. I don't want to change the status of tasks which are not assigned to me but i saw it while looking over my open assigned tickets.

I misunderstood the problem. On the receiving side this was already fixed by me in 2019 9a9fe4e7fcad92bfba49ade9a6c44373f170ccd2

Closing since the cause for this was identified.

Maybe its overthinking the problem of attachments with content-id but no reference in the HTML (btw. if mails are shown as plain text all attachments are listed regardless of their content id. ) I guess code like: if filename.endsWith(.png) || filename.endsWith(.jpg) || filename.endsWith(.jpeg) then ignore_cid=false; else ignore_cid = true. Would do the right thing 99% of the time. Core reference: rOd87848059727587be1f660283e0aeb3be16cc382

I assume the problem has been resolved because we never got feedback that the problem persists.

Please ask on the forum or a mailing list for help.

Gpg4win-Beta-70: This works now, the issue can not be reproduced any more like described

This is no longer possible. The sign/encrypt button is disabled and an info box is displayed.

When I last talked about this ticket I had not thought of the fact that we need to have this in some kleowrap wrapper and that currently stdout and stderr are not printed in a process which forwards its call to an already running kleopatra.

I thought about this and any change here has a regression risk and the release is already overdue. If we change this now as a band aid before a release with keyboxd we really need this only for one release.

Backported for VSD 3.3

Fixed.

FWIW, a related task is T7308

Alright, we should do that in any case because two key caches are never a good idea and in particualr not if one of them needs too be reloaded too often. Thus re-using the one in Kleopatra is the proper solution. I recall that we looked at this at a time when we already started to design gpgol2 which would solve the problem anyway. However, at least for vsd we need to keep on using the classic gpgol for quite some more time. Thus the effort to improve the key resolving in gpgol is really justified.

The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.

Something which has high priority but has not been touch can't have a super high priority.

Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.

I see only links to our own pages and to the emailselfdefense - which is a good resource.

Hmm, two years old - I doubt that it makes sense to continue here.

Priority lowered in the light of the the forthcoming gpgol.js

Should definitely work with gpg4win if it works with vsd.

A bit more verbose description would be helpful ...

Closing because POP3 is rarely used and has never been supported.

More than a year old - we can reduce the priority.

Note: The code for this is in the work/mmontkowski branch but has not yet been merged with master. Before we take this bug up again, we need to look closer at the ribbon UI events as remarked by Andre on July 29.

That was resolved with vsd 3.2.0

Fixed together with T6864

Works fine.
For special DOS names only COM/LPT1-9 are supported names like COM12 are not handled.
But that is not really an issue as these names are always prepended with the temp-pathname and c:\tmp\COM12 are valid names.

Getestet, beim normalen wechseln taucht dieses Verhalten so nicht mehr auf. Aber einmalig nach Klick auf weiterleitung dafür neues Ticket T7276