Integration of the ASN.1 parser/encoder in Ruby 2.0.0dev

[nahi]

Deliverable for the GM1 includes this.

The final deliverable for the intermediate report will comprise:
...
- integration of the ASN.1 parser/encoder in Ruby 2.0.0dev,
 replacing the existing OpenSSL::ASN1 module

[emboss]

I proposed this, but as much as I'd like to, I think it's too early to be integrated into Ruby trunk right now. I am quite confident that until Tuesday specs will be stable and pass (except maybe for the Bignum specs regarding krypt-core), but the one blocking issue I currently see preventing this is that we do not yet support the #tagging attribute with Krypt. And we still haven't decided if we really should.

If we wouldn't, I would suggest branching from GM1, integrating a customized version of GM1 to Ruby 2.0.0dev.

What are your thoughts on this? I'm in favor of postponing this until after GM1.

[nahi]

pending. I'd try to run ossl tests with "OpenSSL::ASN1 = Krypt::ASN1" library.

require 'openssl'
require 'krypt-core'
OpenSSL::ASN1 = Krypt::ASN1

You didn't write about the expected result so I thought you'll do compatibility check against 2.0.0dev. Parts would run fine, parts would not. We should find how we should handle (or no need to handle) tagging then.

[nahi]

I created PoC project at https://github.com/nahi/krypt-openssl

bundle install && bundle exec rake should run tests copied from 2.0.0dev but it gives lots of failures at this moment. I'll revisit this once we fixed SEGV of krypt-core.

[emboss]

I had an idea about #tagging:

I don't like it because it is "create from scratch"-only information. When parsing values it will always stay nil, so it's really an encoding directive. In addition tagging == :IMPLICIT doesn't really do anything, too. But I like the convenience it gives you for encoding explicitly tagged values, because wrapping them in an array as the value of an ASN1Data first (which is what you would have to do with krypt) is painful.

So, I thought about it and I had an idea: what if we would make :EXPLICIT another "tag class"? Internally, tag_class == :EXPLICIT would be handled as follows: set the actual tag class to :CONTEXT_SPECIFIC and set an internal explicit flag that is to be recognized when encoding the value. This would nicely handle the "encode-only" aspect and it wouldn't introduce a basically worthless instance variable, don't you think?

This would of course not guarantee one-to-one compatibility with OpenSSL::ASN1 code, but if properly documented, I think we could afford the break for Ruby 2.0.0. I'd like to avoid the 'tagging' attribute for krypt, but I'd also want to avoid having to maintain a branch of krypt as the replacement for OpenSSL::ASN1 in Ruby 2.0. This new approach would IMO be a good compromise for both "worlds" and would allow us to maintain one single code base. What's your take on this?

[nahi]

Would you please add 'EXPLICIT as another tag_class' idea as new issue? It sounds good for compatibility, but perhaps as you think, I don't think we need tagging compatibility with ossl. Let's decide after how template/builder works good instead of old features.

We've (re-)found this issue, that's enough. I'll run krypt-openssl specs Monday.

[emboss]

OK, I opened Issue #13 for this!

[nahi]

I gathered all compatibility issues on running ossl test suite at here; https://github.com/nahi/krypt-openssl/blob/master/lib/krypt-openssl/asn1.rb https://github.com/nahi/krypt-openssl/blob/master/lib/krypt-openssl/x509.rb

@emboss , please find "DIFF"s and check those are intentional or not. Those would findings as a result of "Integration of the ASN.1 parser/encoder in Ruby 2.0.0dev" I think.