Dear Michael, On Mon, Feb 25, 2019 at 2:41 AM Michael Richardson <m...@sandelman.ca> wrote:
> > Not sure who Matt quoted, wrote: > >> 2. Can we do something with a bunch of hard-linked non-extendable > >> lists of internal NIDs? > >> > >> For example, providing GOST algorithms always requires a patch to > >> extend 3-5 > >> internal lists. > >> If it could be done dynamically, it will be great. > > Matt then wrote: > > The simplest solution is to submit a PR to add your OIDs to OpenSSL, > > so that no furher out of tree patches are required. > > Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > > Dynamic NIDs don't fit very well into the design, because NIDs are > > expected to be stable compile-time constants. We could perhaps > > reserve a range for "private-use", and "engines" could allocate new > > NIDs in the private space at runtime. The key question is whether > > such NIDs are global or valid only if returned to the same engine > > (provider, ...). If not global, the allocation might be static > > within the engine, and not require any locks. > > Having stubbed my toe on some NID stuff, I must question exposting NIDs. > ruby-openssl used them in a dumb way that meant that adding extensions by > OID > was broken until I removed some code. > > I think that the #define/enum of NIDs should be made internal-only, > available as optimization to internal code only. > Your question then becomes, "are engines internal users", and I'd like the > answer to be no. I think that the openssl 3 changes suggest the same thing. > The engines are _mostly_ external users. But sometimes, providing new algorithms, there appear some parts that should go into the core part. And regulation creates similar problems. All other users can call OBJ_obj2nid() or OBJ_txt2nid() to get a NID, > and we can figure out how to allocate things dynamically if this makes > sense. I don't know which APIs are currently NID-only. AFAIK, no external API, but there are some cases when external API does not cover all. -- SY, Dmitry Belyavsky