- User Since
- Mar 27 2017, 4:49 PM (98 w, 5 d)
Mon, Feb 11
I think we might accept this with low priority. As this is an unusual way to create a key.
Tue, Feb 5
This was fixed.
Mon, Feb 4
I don't see it as a priority right now. We should keep it in mind for T3811 .
I do not think that we should prioritize this right now. I had a talk with Michael and he said that we basically have the trademark because we are currently using it. To really register it and enforce it we would have to hire patent lawyers and that will easily go into 6 figure sums. Which I don't think we need right now. Let's keep it as "GnuPG is in use as a Product of g10cde".
First of all I find PIN a very bad term. "Personal Identification Number" for example for my Gnuk token is confusing. I use a string there,... So let us use PIN only where it really has to be a number. Otherwise it is a Password.
There has been some progress here. At least we no longer use "passphrase" in new code. We still have not yet replaced all old occurances.
Wed, Jan 30
Tue, Jan 29
I've already sent jens a mail this morning.
Interesting. Thanks for reporting this. This happened in the past because images had a "content-id" (so they were marked to be an embedded image) but were not really embedded. I did not have a very good fix then because it is hard for us to detect (easy for Outlook itself though) so there might be more special cases where this happens.
Mon, Jan 28
fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.
That is a very interesting problem that we did not have on our radar.
Fri, Jan 25
But to resolve this bug I also want to remove stuff like "ooooh you should use numbers or something like that" we have that in configuration but our default code is too dumb to be useful (afaik "password" is accepted with 90% quality). We also have a bug for the quality thingy, which I also find important because that is the first contact with our software.
Found it: T3724
No that bug is different. Nowadays you have to solve four dialogs to create a key without a passphrase.
No! That is not what I want with this issue. We should ask once for a passphrase and then shut up.
I know, I helped implementing that. Patrick changed it.
Thu, Jan 24
I want to have this fixed for the next release so prio high.
Oops. Assignee removal was an accident. Sorry for the noise here ;-)
Just as a note: To workaround this you can also place "no-use-tor" into %APPDATA%\gnupg\dirmngr.conf (you might need to create that file) %APPDATA% expands to something like "c:\users\yourname\appdata\roaming"
Thanks you very much for your help! I think we have it. \o/
I see some strangeness:
A TCP Connect: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050
and TCP Send: q4master.idsoftware.com:4862 -> q4master.idsoftware.com:9050
I think that this is the name of the integration tool with the desktop, isn't it?
I was able to reproduce this. I tried it three times with a very large folder and it worked fine. The fourth try though created a corrupted archive and Kleopatra did not show an error either creating or extracting this archive!
Thanks for the confirmation and additional info. In that case I give this high priority as I agree with the potential for data loss.
I'm thinking of how to move this forward.
The problem is that we (the developers) can't reproduce this at all and the debug output does not show anything.
The problem only occurs with the gtk platformtheme.
Wed, Jan 23
Thanks, I don't think that it is a problem for our usecase but the fix is trivial and we should apply it.
Thanks, will be fixed before the next release.
Tue, Jan 22
Have you used a very old version (< 3 ) to create the directory? I know you said that you are currently using Gpg4win-3.1.5 but maybe you have used an older version to create the archive.
In the past we had a problem that Kleopatra would not see the errors from the archive program but that was fixed some time ago. The Archive problem had problems with non ASCII filenames but nowadays it only has problems with full unicode filenames and those errors are shown in Kleopatra.
Mon, Jan 21
- What about the "Group" patches from Stephan Müller? We should give him a response. I'm thinking that they might be good for master.
we have a rare situation where the Home directory of Kleopatras backend ( gnupg ) becomes corrupted. This results in undefined behavior and strange error states from which we do not yet recover.
I don't think the cause of the corruptions is user interference. Users which report that don't even know about the GnuPG home directory in advance. I think we have some kind of rare bug which causes the keyring to break.
Jan 16 2019
Jan 15 2019
Jan 14 2019
I can reproduce it. For me the image is properly attached, I can access the file, but the embedded image does not work. This will be because the content_id is mixed up. I don't know why this happens yet.
I've opened T4322 for the image embedding issue.
I give this normal priority to move it out of the "Needs Triage" queue.
I think I understand what is going on here:
@MThib What is the filename of the .dat with the original message, is it gpgolXXX.dat or winmail.dat and can you confirm that even without an attachment any modifications to the forwared mail are ignored and the mail is sent out as if it was send again?
There appears to be something very fishy when forwarding from the sent mails folder. Even without attachments if I forward and modify the content the original message is sent out and not the modified one.
- First new work week so a bit unorganized.
- Looked into a GpgOL issue regarding clearsigned mails from Microsoft.
- Improved Gpg4win mailvelope integration installation.
- Some more work researching ISHellFolder interaction and adding more COM code to GpgA (just a a project name) in the gpg4win-tools repo.
It is a bit related to T4241 indeed. As we have not yet seen a way to determine if the user actually triggered "save as" or if outlook just wants to save the modifications we can't decide when we should pass the save event and when we should block it.
Thank you for the report. Sadly this is a long standing bug that is still not fixed. We hope to address this in a future version.
Thank you for your detailed report. I agree that this can have serious consequences as it might send out unintended information. I'll look into it with high priority.
Jan 10 2019
Jan 9 2019
@jmrexach Thanks for the reminder, I confused those with other mails I've gotten regarding this issue.