nsDS5ReplicaTransportInfo: should accept StartTLS as an option

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49109

• Created at 2017-01-31 11:16:35 by firstyear (@Firstyear)
• Closed at 2018-04-18 17:02:32 as fixed
• Assigned to spichugi (@droideck)

---

nsDS5ReplicaTransportInfo SSL vs TLS is not really clear, given that most libraries now support TLS as the default "SSL".

We should make this clear in nsDS5ReplicaTransportInfo by allowing:

ldaps -> SSL
StartTLS -> TLS

Options. So that it's really clear what you are asking for when you configure it.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-02-11 23:02:46

Metadata Update from @Firstyear:

• Issue set to the milestone: 1.3.7 backlog

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-05-08 01:47:46

Metadata Update from @Firstyear:

• Issue close_status updated to: None
• Issue tagged with: Easyfix

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-07-05 17:58:10

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-03-11 10:42:23

Metadata Update from @droideck:

• Issue assigned to droideck

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-03-12 17:43:49

It is not difficult to fix and I've already started to go through the code and check the places with SSL and StartTLS.

But I think we need to discuss how we want to proceed here.

We have two options, at least:

1. Change 'SSL' to 'ldaps' and 'TLS' to 'StartTLS' directly. And then during the instance upgrade, we will take care of it (changing config values to the new ones in the existing instances)
2. Add 'ldaps' and 'StartTLS' but don't remove 'SSL' and 'TLS' for now. We can deprecate them in the later versions.

I think the second options is smoother.
But if we have the upgrade mechanism and we have some exact policy for the cases like this - we should follow it.

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-03-12 17:43:50

Metadata Update from @droideck:

• Custom field reviewstatus adjusted to None

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2018-03-12 17:51:55

I prefer option two. We should be backwards compatible with older versions of DS. We should not have an upgrade script to change the existing agreements because if the customer needs to downgrade it will break those repl agmts.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2018-03-13 00:57:49

@mreynolds389 We have a lot of things that fail on downgrade. TBH I think it's a bit of a high expectation to expect that downgrade will work when we add config parameters, add plugins, change defaults and more. Some things are easier than others to manage, but downgrades are an extreme case, and in a downgrade case you ALWAYS should be restoring your dse.ldif from a backup.

So I think that I would support option 2, with the migration to change the values, but I'd rather them be clearer. Right now we have a protocol AND a uri scheme. I think it would be better as:

• ldaps
• ldap+starttls
• ldap

As the options. These clearly communicate what we are doing.

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-04-18 17:02:21

e306a2d..ea033b6 master -> origin/master

[389-ds-bot]

Comment from spichugi (@droideck) at 2018-04-18 17:02:33

Metadata Update from @droideck:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)