Why not make the name attribute in those local structs const?

Why not make the name attribute in those local structs const?

Can this be done for situations like this in x509_lu.c?

    X509 x509_s;
...

        x509_s.cert_info.subject = (X509_NAME *)name;

BTW, I find the programming pattern in x509_object_idx_cnt(), as well as in the other places where I had to apply the de-constification type cast, pretty awkward:
whole - pretty fat - X509 and X509_CRL structures are allocated on the stack as auto variables and get very sparsely initialized, just to serve as reference objects for cert/CRL comparison.
Directly providing one or two reference values (e.g., subject name or issuer name and serial) to a generalized comparison function would be sufficient.

Looking for a solution that avoids the type casts to non-const,
I first experimented with using direct initializer expressiosn like

    X509_CRL crl_s = { NULL, { 0, }, name, };

but this did not work for two reasons: the compiler cannot handle non-static initialization (with the name parameter), and even if it could, it would (naturally) report the same const conflict.

What would work is to copy the name:

    x509_s.cert_info.subject =X509_NAME_dup(name);

and later free it, but this would be inefficient.

Then I realized that it would be much better to replace the X509_NAME * types of the subject and issuer fields of X509, X509_REQ, X509_CRL, and PKCS7_ISSUER_AND_SERIAL structures by const X509_NAME * (and consequently also for the directoryName field of GENERAL_NAME etc.).
This allows for much more constification of function parameters and is also pretty natural because it resembles const char *.

Doing so I had to introduce just one type cast to non-const in

    X509_NAME_free((X509_NAME *)*xn);

of X509_NAME_set(), which I had to fully constify as

int X509_NAME_set(const X509_NAME **xn, const X509_NAME *name)

I added the following comment there for justification:

/*
 * The use of 'const' for, e.g., the subject and issuer fields of X509 and
 * X509_CRL structures etc. pointed to by *xn, as well as the cast to
 * non-const 'X509_NAME *' in the below call of X509_NAME_free(), should be okay
 * because due to the modification of the pointer value of the field
 * the original pointer value has been invalidated anyway, such that any aliases
 * are not usable any more, neither for reading nor for writing name contents.
 */

I also had to adapt a couple of slightly fishy code sections in crypto/, ssl/, and apps/.

Due to the new constifications I was able to remove again the five casts to non-const that I had introduced yesterday. I also found some new opportunities for little code simplifications, which I did.

I also found and eliminated some casts to non-const that were no longer needed for instance due to my earlier constification of ASN.1 *_dup() functions.

For backwards compatibility, you need to be careful with everything in the public headers. Some const changes will require the applications to also change it to const, which is not something we want to force them to do (at this time.)

@kroeckx, I understand the point regarding backward compatibility.
Yet is there then a chance at all to correct such issues where const would make much sense?

If I revert my improvements regarding const getter responses (and const X509_NAME * fields in structures) then most of the last commit would need to be rolled back.

I actually felt the incompatibilities of constifying X509_NAME * getter results.
These materialize in particular in ssl/ and apps/.
Yet having a look at these it turns out that the changes needed are bearable, and actually contribute to code cleanliness.

I see - thanks for the clarification!

@kroeckx, finally I've found the time to execute all requested changes.
Hope everything is fine/compatible now.

I've just did a quick look at this, and currently don't have any objections. Didn't have time to do a full review.

Thanks nevertheless for your quick scan & response!

This PR contributes to handling the long-standing issue #3742 ("more const").

I've just did a quick look at this, and currently don't have any objections. Didn't have time to do a full review.

@kroeckx, when do you think you'll be able to do a full review?

I've just picked up this stalled PR, rebasing and simplifying it.

@kroeckx, can you resume reviewing this soon, or who else?

I have no idea when I'll find the time to review this

I see. Anyone willing to fill in?

Actually after my recent simplifications the PR consists basically just of a large number of straightforward additions of const (plus some re-formatting where needed).
Where API compatibility (with pre-v.3.0 versions) is an issue it adds const only for function arguments, where it should be harmless.

I've also added a couple of comments why certain constifications cannot be done (at least as long as compatibility is an issue).

Since meanwhile I'm confident that the set of changes done in this PR has stabilized I've updated the documentation accordingly.

Please rebase

Thanks @t8m for taking over the review of this (simplified) PR!
I've rebased it and handled all open issues.

The Travis failure is just a timeout.

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests. Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Please squash the commits and add some descriptive commit message when merging.

Merged, squashing and adding cumulative commit message.
Thanks @kroeckx and @t8m!