Static OpenSSL linking vs. shared object (missing macro -> function definitions)

[jas-]

This very well may not be a bug but a direct omission within the OpenSSL (static) linking.

While attempting to extend functionality of the ursa node module the NETSCAPE_SPKI_b64_decode defined within the x509.h is not within the registered symbols provided by objdump (see ex.1 for output).

Is there a reason for this function to have been omitted? Thanks for any insights. Also I have it available when linking dynamically.

ex. 1
[root@node node-v0.10.7]# objdump -x /usr/local/bin/node | grep NETSCAPE 0000000000a9d660 l O .rodata 0000000000000050 NETSCAPE_CERT_SEQUENCE_seq_tt 0000000000a9d6c0 l O .rodata 0000000000000028 NETSCAPE_CERT_SEQUENCE_aux 0000000000a9e0e0 l O .rodata 0000000000000050 NETSCAPE_SPKAC_seq_tt 0000000000a9e140 l O .rodata 0000000000000078 NETSCAPE_SPKI_seq_tt 00000000006914e0 g F .text 000000000000000a NETSCAPE_SPKAC_free 000000000068f470 g F .text 000000000000000a d2i_NETSCAPE_CERT_SEQUENCE 00000000006914f0 g F .text 000000000000000a NETSCAPE_SPKI_new 0000000000643830 g F .text 000000000000001b PEM_read_NETSCAPE_CERT_SEQUENCE 0000000000691500 g F .text 000000000000000a NETSCAPE_SPKAC_new 0000000000691530 g F .text 000000000000000a d2i_NETSCAPE_SPKI 00000000006431f0 g F .text 000000000000003d PEM_write_NETSCAPE_CERT_SEQUENCE 000000000068f460 g F .text 000000000000000a i2d_NETSCAPE_CERT_SEQUENCE 0000000000a9d620 g O .rodata 0000000000000038 NETSCAPE_CERT_SEQUENCE_it 0000000000a9e060 g O .rodata 0000000000000038 NETSCAPE_SPKAC_it 0000000000666270 g F .text 0000000000000027 NETSCAPE_SPKI_sign 000000000068f450 g F .text 000000000000000a NETSCAPE_CERT_SEQUENCE_new 000000000068f440 g F .text 000000000000000a NETSCAPE_CERT_SEQUENCE_free 00000000006914d0 g F .text 000000000000000a NETSCAPE_SPKI_free 0000000000a9e0a0 g O .rodata 0000000000000038 NETSCAPE_SPKI_it 0000000000691520 g F .text 000000000000000a i2d_NETSCAPE_SPKAC 0000000000691540 g F .text 000000000000000a d2i_NETSCAPE_SPKAC 00000000006663b0 g F .text 0000000000000018 NETSCAPE_SPKI_verify 0000000000691510 g F .text 000000000000000a i2d_NETSCAPE_SPKI 00000000006435f0 g F .text 000000000000003d PEM_write_bio_NETSCAPE_CERT_SEQUENCE 00000000006439b0 g F .text 000000000000001b PEM_read_bio_NETSCAPE_CERT_SEQUENCE

[bnoordhuis]

That's because of #4051 - the binary only exports what node.js itself uses (either directly or indirectly.) We've tried a couple of times to remedy that but it's complicated by build tool limitations and Windows vagaries. I'll see if we can get this fixed in v0.12.

EDIT: And maybe v0.10 - but don't hold your breath.

[jas-]

lol, fair enough. What is the patch submission policy? Or more specifically adding new functionality to the core crypto module? That would force inclusion and remedy the problem (at least with what I am working with).

Thanks.

[bnoordhuis]

We'd only accept the patch if it's something that's broadly useful. I'm not sure if the NETSCAPE_SPKI_*() functions fall into that category - I've never seen SPKI/SPKAC being used in the real world.

[jas-]

Strange that Ruby & Python (and now PHP =P) all have support for this functionality.

In regards to useful, for most developers it may not be. For those of us that would like an automated system for generating certificate signing requests based on a users DN information which can then be forwarded or signed with a CA certificate for SSL/TLS authentication with personal certificates (which the TLS/SSL functionality node.js already provides) it is a good feature.

Besides since the release of the latest w3c HTML5 specifications (which essentially brought back) the old <keygen> element.

Anywho, appreciate the feedback.

[bnoordhuis]

Don't get me wrong, I'm not rejecting it flat out. Feel free to send a pull request our way and we can take it from there. It's just that I can't promise we'll land it.

[jas-]

No worries, thanks.

[jas-]

@bnoordhuis Sorry to bug you again. I have a pull request ready. Which branch should I issue it on (per the guidelines). Thanks!

[isaacs]

@jas- This is new API functionality, so it needs to go on the master branch. Thanks!

[jas-]

Thank you @bnoordhuis & @isaacs