Create a generic number ↔ name and let EVP use it#8878
Create a generic number ↔ name and let EVP use it#8878levitte wants to merge 18 commits intoopenssl:masterfrom
Conversation
|
Arguably, this namemap could be used by the property code... I don't quite understand why |
|
@levitte the reason that I'm not going to object to a merging of the two, so long as the semantics don't also change. |
|
[edit: this whole comment is wrong] There is a slight difference between the properties name ↔ value maps and this. The property maps are known to be indexed sequentially (from By switching the property implementation over, there will be a (small?) space cost but I don't think there will be a noticeable time cost. I believe the simplification to a single name ↔ value map across the library is a beneficial one that outweighs associated the costs. |
|
Merging the two name ↔ value maps in the property code into a single map will allow properties like: "fips=foo, foo=bar" (where foo is not a property name) to be specified and parsed without error. I.e. the reservation of names without a period can be circumvented. |
Uhmmmm, this namemap is indexed monotonically as well, but from one (zero indicates an "undefined" string). A string gets added by pushing it in the stack... |
|
There's one bit that I find highly disturbing, and it's that this namemap is per library context... That would mean duplicating it unnecessarily if we're handling several library contexts within a unit. It's just a string to number cache, essentially, so there's no reason to make the numbers different per context. I could force it to end up in the default library context, but that would mean that there must be one, and the FIPS module currently forbids that... I might have an idea or two on that, btw, but that's the matter of another PR. |
|
I saw the use of Best to stick with the stack and it can directly replace the two property mappings. |
|
Could we have this per context and default to the "default" context if none is directly set? |
|
Properties index from 1 as well. |
We can. Also, this implementation only allows one namemap (per library context), and what you said about keeping property names and values separate makes me think that we need a mechanism to have more than one. This is perfectly viable, but needs an extension of the API. |
|
I re-implemented it to make it possible to create free floating name maps. |
|
Ooooh, this found me an interesting bug... we weren't doing things quite right when there is no pre-existing nid for a name... |
|
This isn't in draft any more |
This avoids using the ASN1_OBJECT database, which is bloated for the purpose of a simple number <-> name database.
We didn't deal very well with names that didn't have pre-defined NIDs, as the NID zero travelled through the full process and resulted in an inaccessible method. By consequence, we need to refactor the method construction callbacks to rely more on algorithm names. We must, however, still store the legacy NID with the method, for the sake of other code that depend on it (for example, CMS).
POD markup is only forbidden in the actual names, while permitted in the description.
…uction
Now that the legacy NID isn't used as a main index for fetched
algorithms, the legacy NID was just transported around unnecessarily.
This is removed, and the legacy NID is simply set by EVP_{API}_fetch()
after the construction process is done.
|
Ping? (btw, in a conversation yesterday, it was suggested that the strings could be bitstrings, i.e. binary data rather than just text... I don't mind the idea, but I also think that could be future development of this map functionality, it doesn't have to happen in this PR) |
|
Doing the close+open thing to kick Appveyor |
|
Merged. 0211740 EVP_FETCH: remove the need to transport the legacy NID through construction |
This can be used as a general name to identity map. Reviewed-by: Paul Dale <[email protected]> (Merged from #8878)
This avoids using the ASN1_OBJECT database, which is bloated for the purpose of a simple number <-> name database. Reviewed-by: Paul Dale <[email protected]> (Merged from #8878)
We didn't deal very well with names that didn't have pre-defined NIDs, as the NID zero travelled through the full process and resulted in an inaccessible method. By consequence, we need to refactor the method construction callbacks to rely more on algorithm names. We must, however, still store the legacy NID with the method, for the sake of other code that depend on it (for example, CMS). Reviewed-by: Paul Dale <[email protected]> (Merged from #8878)
POD markup is only forbidden in the actual names, while permitted in the description. Reviewed-by: Paul Dale <[email protected]> (Merged from #8878)
…uction
Now that the legacy NID isn't used as a main index for fetched
algorithms, the legacy NID was just transported around unnecessarily.
This is removed, and the legacy NID is simply set by EVP_{API}_fetch()
after the construction process is done.
Reviewed-by: Paul Dale <[email protected]>
(Merged from #8878)
4 participants
This creates a generic, per library context number ↔ name map, and has the EVP fetcher use it.
Checklist