- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 20 2018
Feb 19 2018
Note that there is no standard for this. In particular the encoding of filenames with special characters are different in almost all implementations. I tried to find a common ground for our implementation.
Just to be clear I think this issue is valid and we should add more checksum tools in the future. But I would want them to use libgcrypt and confirm to the standard *sum command line arguments like -c.
On saturday I could observe the problem with a fresh Windows 10 Home edition.
The problem seems to have to do with the locking of the TOFU database.
Feb 18 2018
Feb 17 2018
Feb 16 2018
This handles the problem, thanks.
Kleopatra can still be used without UI Server connectivity. But this might point to a bigger issue.
Hi Werner,
This is a MUA thing. Do you ask whether we plan to add it to GpgOL?
See T3796
Sorry, we won't do this any time soon. We may even shut the Bitcoin thing down. I was too troublesome from a bookkeeping POV.
My first GUI Idea does not work. From the Ribbon I don't see a way to find the currently used account. I could only look at all accounts that are configured and check the WKS publishing state for all of them.
Still trying to pinpoint the bug, but I am afraid I am stuck.
The error of testQuickUID is strange. In the test, it adds a UID and checks number of UIDs (3 + 1 = 4).
It is not reproducible for me (Debian with Qt 5.9.2, NetBSD 7.0.2 with Qt 5.5.1), gnupg 2.2.x from the repo.
Feb 15 2018
FYI this is still unfixed.
I think it'd be valuable to run another round of fuzzing tests, but this should be fixed before, otherwise it'll just be hit all the time and may hide other bugs.
Please see the original file (hello.txt), CFB-encrypted to two passwords (hello.txt.cfb), and AEAD-encrypted (hello.txt.aead).
Passwords used are '1' and '2'.
(automake should flag non-portable Makefile features - after all it is there to avoid gmake features)
Does this patch help? My artificial test confirmed that this does the Right Thing.
Thank you very much! This is working quite well now.
Yes, that is correct.
This is coming along nicely. It might take longer then with Kleopatra if the key is large (as the new resolver does a full keylisting on every start) but that should be OK and we have plans to optimize that anyway.
In my tests this is resolved with the commits mentioned here.
I guess that you are running on 32-bit architecture where the function keybox_get_keyblock uses 32-bit signed size_t for image_off and image_len.
Thanks for your report. I'm going to fix the messages.
I believe that all BSD Makefile issues has been fixed (except python-tar-gz distribution thing for maintainer).
Please test again.
I located the problem. It's Makefile portability issue and it is fixed in: rMb5ec21b9baf0: tests: Makefile portability., rMba6e610baa13: tests: More Makefile portability., and rM3224d7f0ea83: tests: Fix previous commit
It was not your final invocation of "make check" (GNU or BSD), but the one before ("make all" by BSD make) which imported keys for tests.
The "export" directive doesn't work on BSD.
Feb 14 2018
That's weird, I can reproduce it with a fresh pull from dev.gnupg.org (I can't clone it because it keeps giving me an error like "no rule to make target audit-events.h) by configuring with CFLAGS set to -fsantize=address -ldl and LDFLAGS set to -lasan. I added the -ldl because of a linking error with symbol dlsym (only when -fsantize=address is present). It more specifically complains about a READ access of size 1 and heap-buffer-overflow on address 0xb30037b0. It also mentions that this address is a wild pointer. The call tree looks as follows:
iobuf_temp_with_content
keybox_get_keyblock
keydb_get_keyblock
do_export_stream
do_export
export_pubkeys
main