Additional backend for asn1ate

[vanrein]

Hello kimgr,

Here is a patch that I propose to have added to asn1ate. It uses your carefully designed compiler structure by adding a new backend "asn2quickder" -- and it adds a few extra's that you didn't need to the semantics module.

The target for this backend is the Quick DER parser/generator, https://github.com/vanrein/quick-der for which it generates C header files -- for example, for processing of ASN.1 portions from RFC's, as in https://github.com/vanrein/quick-der/tree/master/rfc The idea being that such include files are installed along with a Quick DER devel-package, making standard ASN.1 structure ready for immediate use.

I know that asn1ate targets Python, and indeed that is something I've considered that for the future too, https://github.com/vanrein/quick-der/blob/master/PYTHON.MD

A last thought I've had is to derive clickable HTML files with ASN.1 structures, https://github.com/vanrein/asn2quickder/issues/1

But first things first... would you be willing to add this extension to asn1ate?

I hope this pleases you as much as your compiler pleased me!

Thanks, -Rick

[kimgr]

Hi Rick,

Thank you! This definitely looks interesting. I'm a little pressed for time (and attention span), but I'll try to take a closer look when I have chance.

Generally, I'm all for including this in asn1ate, but I don't think I'll be able to support it -- I have no idea what Quick DER is or does :-). I should be able to add you as a collaborator if you can take that responsibility.

I'll also have to double-check with my employer if there are any legal complications here (sigh) -- I've developed asn1ate for use internally, and then received permission to open-source it, so I need to understand if your changes need to be donated to Schneider Electric, or if you can retain the rights (which I would prefer).

Also, is there a chance of adding tests? Otherwise changes to parser/sema might break the QuickDER stuff without me noticing.

[kimgr]

I'll also have to double-check with my employer if there are any legal complications here (sigh) -- I've developed asn1ate for use internally, and then received permission to open-source it, so I need to understand if your changes need to be donated to Schneider Electric, or if you can retain the rights (which I would prefer).

After consulting local experts on the matter, this should not be an issue -- we can mark file headers for Quick DER as copyrighted to you, and spell the respective ownership/license details out in the LICENSE.txt file. We can draft something when we're happy with the patch.

[vanrein]

Hi Kim,

Thanks for your nice response! Getting this into asn1ate simplifies some of our packaging woes a little (we intend to add it into Nix, which we're using as our development and package release platform).

I would assume that your work should have an application or two for Quick DER -- as it is so hospitable to embedded environments, which the telecom industry likes to deal with.

Generally, I'm all for including this in asn1ate, but I don't think I'll be able to support it -- I have no idea what Quick DER is or does :-). I should be able to add you as a collaborator if you can take that responsibility.

On the best-effort basis that one may expect of open source code, sure.

I'll also have to double-check with my employer if there are any legal complications here (sigh) -- I've developed asn1ate for use internally, and then received permission to open-source it, so I need to understand if your changes need to be donated to Schneider Electric, or if you can retain the rights (which I would prefer).

Then let me retain the rights, except for the files you wrote and that I extended only slightly. Let me know if you need me to add the headers that I usually forget because I'm more into getting code out than getting the legal ownership of it.

Also, is there a chance of adding tests? Otherwise changes to parser/sema might break the QuickDER stuff without me noticing.

There actually are some tests, but they are part of Quick DER. You would like me to add this to the pull request before accepting, right?

Thanks so far, -Rick

[kimgr]

Sounds good, thanks!

You would like me to add this to the pull request before accepting, right?

Yes, let's iterate on the PR until we're both happy :-)

I have lots of detail-level comments, but at a high level I'm mostly interested in test coverage. Not sure how to test generated C code reliably and portably, but maybe you have something already.

[vanrein]

Hi,

Yes, let's iterate on the PR until we're both happy :-)

OK.

I have lots of detail-level comments, but at a high level I'm mostly interested in test coverage. Not sure how to test generated C code reliably and portably, but maybe you have something already.

What I tend to do is build an include file, then pack and unpack a VeriSign root certificate and check it's the same.

-Rick

[kimgr]

What I tend to do is build an include file, then pack and unpack a VeriSign root certificate and check it's the same.

I guess the challenge is the 'build an include file' step -- there are no native GCC-compatible compilers on Windows. But you if it's a single file, it's relatively easy to abstract out. Let's ignore portability for now, and I can sort it out after the fact, it should be pretty easy.

[kimgr]

I've added a first round of mostly style-oriented comments to make this more consistent with the rest of asn1ate. Once that's fixed up, I'd like to understand the finer points of the sema changes and your new code generator better.

[vanrein]

Sorry for the very slow response; we had a project delivery deadline and decided to initially pack our own branch, and later migrate to yours, for this indirect dependency. I am now processing your suggestions (and Michiel has already taken care of some as well). New or adopted PR is coming up soon.

[kimgr]

Thanks! No worries, I've been busy myself, and haven't had much time to look at this.

[vanrein]

Closing this PR and submitting a new one from another branch