Furthermore, it create conflicts with LDAP and some RFCs that define
"UID" as a lable for the attribute type userId (which we haven't even
defined here).
The next question is if we should update objects.txt with the added
stuff from the main trunk.
could be done automagically, much like the numbering in libeay.num and
ssleay.num. The solution works as follows:
- New object identifiers are inserted in objects.txt, following the
syntax given in objects.README.
- objects.pl is used to process obj_mac.num and create a new
obj_mac.h.
- obj_dat.pl is used to create a new obj_dat.h, using the data in
obj_mac.h.
This is currently kind of a hack, and the perl code in objects.pl
isn't very elegant, but it works as I intended. The simplest way to
check that it worked correctly is to look in obj_dat.h and check the
array nid_objs and make sure the objects haven't moved around (this is
important!). Additions are OK, as well as consistent name changes.
Extend the X509_PURPOSE structure to include shortnames for purposed and default
trust ids.
Still need some extendable trust checking code and integration with the SSL and
S/MIME code.
script, translates function codes better and doesn't need the K&R function
prototypes to work (NB. the K&R prototypes can't be wiped just yet: they are
still needed by the DEF generator...). I also ran the script with the -rewrite
option to update all the header and source files.
objects to objects.h
NOTE: during this integration it will not be possible to compile my PKCS#12
program against OpenSSL because there will be conflicts between the external
functionality and that being added to the core code.
`openssl' and second, the shortcut symlinks for the `openssl <command>' are no
longer created. This way we have a single and consistent command line
interface `openssl <command>', similar to `cvs <command>'.
Notice, the openssl.cnf, openssl.c and progs.pl files were changed after a
repository copy, i.e. they still contain the complete file history.
