- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 21 2019
Hi,
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 20 2019
Jan 19 2019
Jan 18 2019
Hello, I'm trying to create my key with Cleopatra. It does not work.
At first it looks like it will work. The normal dialogue comes:
F576314: 1.jpg
The following when saving a backup, the following error occurs:
F576316: 2.jpg
When updating the certificates comes the following dialog:
F576319: 3.jpg
Enclosed the log files:
F576313: kleopatra.log.8456
F576312: Cleo-log
F576311: kleopatra.log.7084
Looking forward to help. Many Thanks
Jan 17 2019
BTW, did you manually define -DNDEBUG, or what caused -DNDEBUG?
Reading https://en.wikipedia.org/wiki/Fedora_version_history, I guess that your kernel/glibc doesn't have working mlock.
It may work if running by root, though.
It is fixed in master branch of the repo.
OK, it's a libc with no pthread_rwlock_t.
T4298: 'make check' with uninstalled library, which is building now (even if rpath doesn't work well) handles related issue, which was fixed for libgcrypt-1.9. Since this issue is for other libraries (libgpg-error, specifically), we could do something similar, but, it may be detecting LD_LIBRARY_PATH to fail with "Please remove LD_LIBRARY_PATH".
Applied.
I think Bash 5.0 is in sid, not testing yet. Are you sure it's related to Bash 5.0? Is there any possibility your upgrading some other software causing this?
Jan 16 2019
Rebooting the system makes the issue disappear.
News for 1.34:
Done for libassuan and libksba.
Done for gpgme.
Jan 15 2019
Since today, I cannot send any Signed email. Outlook is crashing.
I guess it is due to the new version of GpgOL I installed.
Done for libgcrypt.
Pushed to master, fixing about return value of getentropy. Tested on FreeBSD 12. Tested on FreeBSD 11 where getentropy is not available.
So the output of this was
Jan 14 2019
All right then, fine by me.
These are hooks so that co-operative thread libraries (like ntph) are able to yield control to the system's thread's implementation.
Sorry for long reply, your change looks ok even though dunno it is meaningful those _gcry_pre_syscall ()/_gcry_post_syscall () surrounding get entropy for example.
You can save as text or html decrypted. And apart save the attachment. You can save as .msg in encrypted form dragging and dropping the message row to the desktop. In Outlook smime native mode you can save as .msg in encrypted mode (could be the key cache decrypts "on the fly"). This option seems disabled in gpgol.
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.
In T4318#121604, @che wrote:Ok, so saving a decrypted message is not possible at the moment, right?
Thanks to the remediation.
Hi Andre,
I give this normal priority to move it out of the "Needs Triage" queue.
I think I understand what is going on here:
@aheinecke the file is gpgolXXX.dat. I never got the winmail.dat (I think).
Thanks for taking care of the action.
@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.
Thanks for reply and clarification, regards danny
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.