Comment 11 for bug 1905790

>> Soo... Given we prefer to stay conservative and not change SSSD crypto
>
> I didn't say that!

I know, I'm not saying that you took a decision on that but I was
speaking in plural form as I recognize what you say in the sense that
indeed there may be cases which we don't think of that we could break.

>> backend fully (to be clear, I would have preferred it to follow
>> upstream, not to provide a solution that will change in next LTS no
>> matter what, and avoid having "frankensteins", but wasn't a strong
>> requirement for me) I've been exploring ways to get only the component
>> we care (p11_child) to use p11-kit and openssl.
>
> This is certainly a valuable angle to look at - thanks!
>
>> Robie, this would be better SRU approach?
>
> I think you misunderstand me. I'm not saying that your upload *has* to
> be narrow. I've not formed an opinion that yet. What I'm saying is that
> whatever size of scope you choose, there must be a regression analysis
> that covers that scope.

I understood this, reason why I thought that, given we have the chance
to make it a narrower scope, then I tried to get that done.

> But the analysis is still necessary and must not be skipped.

Sure, not trying to do that, I'm just saying that I can't over all the
cases myself.

> I appreciate that sometimes it's harder or riskier to narrow the scope,
> so I'm still open to widening the scope - *if* there is an appropriate
> justification *and* full regression analysis of that wider scope
> provided.

Problem is that I'm quite sure we can't cover all the cases in a such
complicated piece of software that may be configured in so many ways.
Thus the reason I thought narrowing the scope was a better idea.