Hello Peter,
On Mar 20, 2011, at 12:24 PM, Peter Marschall wrote:
> Please find attached a few patches to src/libopensc/card-openpgp.c
Before I go on testing with CryptoStick (OpenPGP v2.0) could you explain what
happens with the overall behavior of OpenSC after your patches? Do you get
"further" with the card/token? Any other comments?
> * 0001-OpenPGP-fix-top-level-DOs-according-to-spec.patch
> align the list of top-level data objects with the spec
Are these changes between v1.1/2.0 or just mistakes? I don't think that the
v1.0/1.1 support is that relevant in near future, but it would be nice if the
code tried to explicitly maintain changes needed to support both 2.0 and 1.1
cards.
I'm not sure if v2.0 is backwards compatible with 1.1 and 1.0. If you know more
and have studied both v1.1 and v2.0 specs, please provide pointers and/or
insight.
If you do change something because of spec issues, delete/fix the offending
code, don't comment out. If something breaks, version control should support
recovery, not editor comments. Fiddling the driver to a state where it would
work with 2.0 cards by sacrificing older cards support would be OK as well,
but in that case do add comments ("XXX: hardcoded for v2.0 support" or
something similar).
> * 0002-OpenPGP-add-indication-of-2048-RSA-agorithm-for-Open.patch
> indicate 2048-bit support for version 2.0 cards
In fact, 3072 :) But that would be an interesting stress test for the overall
forward-support of OpenSC and software that use it...
> * 0005-OpenPGP-document-TLV-encoding-use-symbolic-values.patch
> add comments to document the "funny TLV" encoding
It looks similar to sc_asn1_read_tag, are you sure it can not be re-used?
> * 0008-OpenPGP-only-malloc-when-we-need-to.patch
> avoid an unnecessary malloc(0)
malloc is not checked for NULL
> * 0009-OpenPGP-add-some-comments.patch
> a few more comments
Comments are always nice!
I'll give the changes a spin, if you could add some more background information
and updates, it would be easier to fix.
By the way, if you use git you can fork on github [1] to allow the pulling
mechanism over there do some tricks.
[1] http://www.opensc-project.org/opensc/wiki/SubversionRepository
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
