@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.

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.

Neither Brainpool nor NIST curves make any sense unless there is an organizational policy requirement. Thus the --expert requirement is the Right Thing (tm).

works just fine, thx!

Fixed in 2.2.6.

Furthermore, I changed to have an explicit command: key-attr

I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.

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?

This handles the problem, thanks.

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.

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

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?

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.