There is a build failure:

    # ERROR: (int) 'EC_GROUP_cmp(group, group2, NULL) == 0' failed @ test/ectest.c:1826
    # [1] compared to [0]
    not ok 1 - parameter_test

but that also fails on master to not relevant here.

-1 blocker to enable discussion to occur before approval

additional commit pushed, @tmshort please take a look.

Thoughts on this? Netscape cert extensions should really be removed; even the maintainers of NSS think so. :)

I can't remember seeing much of a discussion related to this. It's been a long time since I've seen the netscape extensions, so I can't say that I'd miss much of anything that's removed in this PR.

Considering none of them are critical (as far as I know), and they have been deprecated for a long time (see the docs), I'm not sure I understand the hold.

Not sure that the NS extensions are actually wrong... all they say is that this is a CA cert, and that it can be used in all kinds of contexts: SSL, S/MIME or object signing. In other words, it can be used to verify leaf certificates with all those uses. Or have I misunderstood NS extensions?

That being said, since the PKIX extensions are in place, serving the same purpose, and the key usage marked critical (as it should), the NS extensions really don't serve much of a purpose, except commentary.

You're not quite reading it correctly; the NS extensions say it can sign other specific types of CA's. But you are correct about the critical keyUsage extension. So I think that while @petrovr pointed out an interesting cert, it won't be impacted if this PR is merged.

I think in view of the commit I just pushed, this still needs another review.

Oups, something disappears :

# Number of lines in @def_lines before massaging: 4635
# Number of lines in @nm_lines after massaging: 4629
# Number of lines in @def_lines after massaging: 4631
# The following symbols are missing in libcrypto.so:
#   i2s_ASN1_IA5STRING
#   s2i_ASN1_IA5STRING
not ok 2 - check that there are no missing symbols in libcrypto.so

EXT_IA5STRING macro could be removed too.

These 3 were undocumented, but public interface ...

Should the i2s/s2i_IA5STRING functions be removed?

To answer my question: no, the functions should not be removed. I put them back, but in another file.

Tim put a -1/hold on this three weeks ago. What's the next step?

If someone within the OMC disagrees with the view, then they call a vote to get a formal OMC decision. If no-one in the OMC wants to take it to a vote then it remains blocked.

I disagree that the maintainers of NSS think we should remove this from OpenSSL. They might think they don't currently use it themselves - and they might recommend using PKIX in preference - but that is different from us deciding to remove the code. I think you have missed that context.

And yes I did actually talked to a key NSS person about the distinction between the two contexts.

With @levitte having already approved this, a vote might be desirable.

In this issue we could see clean up of openssl configuration. This part is fine - if extension is not used then exclude from sample configuration.

Another part is to remove support from code even without deprecation period! I know projects where some functionality still exist even if it was deprecated more then 15 years ago.

So what about to mark related "definitions NS_*" x509v3.h as deprecated and in 2028 to remove them?

@t-j-h I also spoke with a couple of "key" RedHat and Mozilla folks and got a different take.

The documentation has marked the extensions as deprecated for more than a decade:

; git blame doc/man5/x509v3_config.pod | grep -i netscape
5dd87981 doc/apps/x509v3_config.pod (Dr. Stephen Henson 2004-11-17 00:55:43 +0000 424) The following extensions are non standard, Netscape specific and largely
19f39703 doc/apps/x509v3_config.pod (Dr. Stephen Henson 2004-11-16 14:09:12 +000

Isn't that long enough?

@richsalz did you ask them if they can guarantee that there are no active users of this capability at all?

That is the right question to be asked for compatibility and matches our context.
And the previous stuff you forwarded in this PR is answering a rather different question.

Anyone making an assertion that they don't exist and you cannot find them in usage anywhere would be wrong - as already noted in a single instance in this PR.

And that capability was not marked as deprecated in the code.
The docs also noted explicitly

Their use in new applications is discouraged.

No I did not ask if they can guarantee, the answer would be as ridiculous as asking if OpenSSL could gaurantee any kind of use.

Yes, the instance was reported, and I commented on it.

This has a hold and two approvals, it seems that the right thing is for the OMC to hold a discussion and vote. If nothing happens in a couple of weeks I'll close the PR and delete the branch.

@richsalz it has one OMC hold, one OMC approval, and one OMC questioning if this should actually be removed (public PR comments). It is being discussed.

@t-j-h we're both right, subsetting different things. One OMC approval, one committer approval and one hold -- those are the "actionable" things. Is this the discussion, or is it happening on the OMC list internally?

I was mistaken, @FdaSilvaYY isn't a committer. Glad the discussion, and eventual resolution I hope, is happening.

For a reason that I ignore , I was able to approve. Sorry for the confusion.
GitHub issue, i suppose, 'cause I remember having the Comment as unique choice enabled, in before days.

May I suggest adding a config option (yes, one more) to disable these old extensions support ?
Else it will take another decade before this removal happens.

For a reason that I ignore , I was able to approve. Sorry for the confusion.

It makes perfect sense that GitHub let's you approve or request changes. Because your opinion (and that of other contributors) is highly appreciated. The only difference is that your vote does not count pro or contra acceptance. If you look closely, you will notice that the check mark of your approval is colored grey, while Richard's check mark is green.

This goes against the stated compatibility plans so I'm closing this. If someone wants to recreate for a future release, feel free to adopt the branch. :)