This subproject allows committers to use "g10: <TITLE>" in commit messages.
Apr 20 2018
@nitroalex Perhaps, creating new ticker is better for this topic.
In the current OpenPGP card specification, there is no way for an application (except having a list of card implementation information) to know wich algo and which curve is supported or not.
So, what an application does is try and error.
I don't like this situation, but I don't know how we can modify the specification.
Apr 19 2018
Well, I surely would agree (and this is only a proposal anyway), but my point here is, that OpenPGP Card does not support Curve 25519, so that one *have to* choose between those other two. Considering me a tinfoil hat person, I would rather not choose NIST, as many others wouldn't too.
Apr 13 2018
Neither Brainpool nor NIST curves make any sense unless there is an organizational policy requirement. Thus the --expert requirement is the Right Thing (tm).
Apr 12 2018
works just fine, thx!
Apr 11 2018
Fixed in 2.2.6.
Mar 30 2018
Furthermore, I changed to have an explicit command: key-attr
Mar 29 2018
I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.
Mar 5 2018
This would be a good solution.
This has also the advantage that we could list the possible curves and let the user select them.
So should we revert this patch and replace it by an explicit command to switch the card to ECC?
Feb 16 2018
This handles the problem, thanks.
Feb 15 2018
Does this patch help? My artificial test confirmed that this does the Right Thing.
Yes, that is correct.
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.
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:
Can't replicate this with gcc's address sanitizer. I found a bug in kbxutil, though.
Can you post a bit more info than just line 1275?
Feb 13 2018
Feb 6 2018
Great, thanks for the quick response!
Thanks for testing. I recall that I wanted to update the checking but a phonecall disturbed my hacking sequence; should have used DND.