- User Since
- Mar 27 2017, 4:49 PM (94 w, 2 d)
Dec 5 2018
One more semantic question about how folks think Context.decrypt(verify=True) should work: if the decrypted thing has no signature at all, should the function succeed without throwing an exception? it currently does, but the returned verify_result has its signatures member set to the empty list.
@aheinecke thanks for the merge of my other branch! sadly, that branch does *not* address this issue yet. It doesn't even test for it. :( I can work on trying to fix it (and test it) if there's a consensus that we want this particular change in behavior.
note that the branch also updates the test suite to make sure the verify=False case is tested.
I've just pushed a branch dkg/fix-T4271 , currently at ac8d7238dbf165950c9844e5cb41da8eb4d37bc0 that resolves this problem.
Dec 1 2018
Nov 27 2018
please add a unit to the test suite to make sure something like this doesn't happen in the future!
Nov 22 2018
i'd be happy to help you set up your own x86 32-bit guest VM for testing
if you like, even if you're running on x86_64 hardware. they're cheap
and easy to run, and have a delightfully small memory footprint :P just
let me know!
Nov 18 2018
hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with:
Nov 14 2018
i don't see any active use of it in all of debian: https://codesearch.debian.net/search?q=gpg-zip
Nov 8 2018
I don't think this answered my question -- i'm asking how adding --no-keyring affects gpgme_op_decrypt_verify -- it seems like verification would fail if no keyring is used, no?
I'm fine with this change, but i do note that some people expect --decrypt to mean "decrypt and verify, if possible". In particular, gpg(1) says about --decrypt:
Oct 29 2018
i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.
I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.
Oct 25 2018
Oct 24 2018
Oct 19 2018
Oct 18 2018
what does "not only on Jan 19, 2038" mean here?
the error i'd seen earlier after reverting the change was an error due to running t-callbacks.py on its own, without the rest of the test suite framework. running it within the test suite framework (with the change reverted), it passes without a problem. I've uploaded 1.12.0-4 to debian with a patch to t-callbacks.py. I can apply it upstream, if you want me to.
The error might have to do with rM46da79e3de99a7b65748994921d6aab73b9974e7 which looks like it might run afoul of 32-bit time_t (Y2K38 problem?).
here's me running just the specific test:
If the swig interface isn't robust, can we replace it with something that will be more robust? Or do we need to wrap it with hand-crafted error checks that describe the API's constraints? It's pretty bad form to segfault python.
When parms is malformed but not NULL, then the error appears to be a bug in the python bindings in _wrap_gpgme_release. maybe something is going wrong because of the "cannot allocate memory" error? in particular:
To deal with passing None correctly, it looks to me like the problem is inside get_parameter() in src/genkey.c -- there ought to be a check for parms being NULL, and then returning either GPG_ERR_INV_VALUE or something else. otherwise, the segfault happens inside strstr.
It the first error (first param = None) is a segfault in versions 1.11.1-2 (debian unstable i386) and 1.8.0-3+b2 (debian stretch amd64).
Oct 17 2018
what's the status on this? i'd love to be able to build binaries for both python3.6 and 3.7 for debian. as it stands right now, the python3.7 continuous integration test for debian is failing.
Oct 12 2018
Oct 9 2018
What are the next steps here? i confess i'm a little tired of doing regular checkins on this issue, and i'm sure other people are tired of me nagging. What can we do to move this along?
Oct 8 2018
what does "back signature's usage tool" mean? can we make an addition to the test suite that ensures that bad signatures will be rejected?
Oct 7 2018
ok, feel free to close this ticket then. It's disappointing that there
seems to be no sane, simple, private multi-channel communication
mechanism avaiable cross-platform that GnuPG can rely on.
Sep 28 2018
This was additionally reported as https://bugs.debian.org/909755 -- it would be great to get a clear statement from the GnuPG project about handling the curated keyring use case.
Sep 23 2018
i note that my patch doesn't include an addition to the test suite, which it probably should, though i'm not fluent in gpgscm. if someone could update it to include a test, i'd appreciate that, and would probably learn from the commit. I imagine the test would do something like:
I tried to push commit 07c19981da0607dc442fadc4079b1d71fbef8f83 to branch dkg/passphrase-env on playfair, but i got this complaint:
Sep 12 2018
sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.
if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:
yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.
Sep 7 2018
Sep 5 2018
well, i tried to push, anyway, but it looks like playfair is rejecting my pushes:
@werner -- yes, i am asking for a change that is specific to the way that gcrypt interacts with the Linux kernel. The minor patch i've proposed only affects a codeblock within #if defined(__linux__), so i don't believe it would have an effect on other Unices. I hope that people working with other kernels will propose any necessary fixes for them.
Aug 23 2018
@aheinecke thanks for the followup!
Aug 2 2018
This bug report has been around for several months now. it has a simple patch, a clear explanation, a report of running code, and examples of problems it solves.
Jul 22 2018
I've now run the proposed patch on a GNU/Linux system where the kernel's RNG is initialized but /proc/sys/kernel/random/entropy_avail shows numbers below 100, and i can confirm that 3072-bit RSA key generation takes roughly 0.8 seconds: 20 sequential default --quick-keygen operations (each creating two secret keys) took ~32s.
Here is another example of users doing sketchy things to try to "fix" this process:
Here is an example of the kinds of UI/UX mystery that users face while this decision is unresolved:
Jul 14 2018
We do have a history of extending the API, no?
Jul 12 2018
About how the keys are actually stored on disk:
Jul 2 2018
Jun 19 2018
could i get feedback on this ticket? a simple, clean patch is available, and i don't understand what is blocking it.
Jun 18 2018
Jun 14 2018
i'm having trouble just assembling the two signatures over the subkey with 2.2.8 in a single homedir. in particular, when i try to do the following with a new, clean test GNUPGHOME, then i see only one signature on the subkeys afterward:
thanks, that works for me. I look forward to seeing the patches :)
can you let me know what you're planning so i can plan my work on enigmail?
Jun 13 2018
thus far every packet type has been a three-letter string, right? I'm looking at "Field 1" in doc/DETAILS. adding a 4-letter packet type seems like it could be trouble if someone has done the dumb thing of assuming the field is fixed-length.
can i get a confirmation that the options you're considering for --with-colons --show-keys when confronted with a revocation certificate will be either:
Jun 12 2018
By "dummy pub line" I think you're proposing output that looks something like this instead of just the rev: line.:
Revocation certificates consist of *only* the revocation packet, right? Claiming that the revocation cert contains more than the revocation packet (when it doesn't) seems more troubling from an API perspective than just telling people to expect a single rev: line if they are looking at a revocation certificate.
thanks for looking into this so quickly. where is your patch? i don't see it on the master branch yet.
ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.
I've just pushed e037657edaf0b3ee9d2e30f6fe3edf6879976472 on the fix-T4019 branch