DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:to:subject:references
	:content-type; q=dns; s=default; b=V1WwcokKloyIAjKsUBoIdXp0om/hh
	NgfRFgtoDJ4HT4++PdaETd9IcACqD5lVALAN477cVYRZtAZWlNUA1M6m0J2sXyyd
	Mj6O+Mva7bPkgO4zm7OlLPitqf4W3Ub6Xvs+16wcodMNd3C+jOOZ/9/illC/VRme
	VeNZnrzNzo2Al0=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <5d34afd1.1c69fb81.8cfdd.7f14@mx.google.com>
Date: Sun, 21 Jul 2019 11:32:49 -0700 (PDT)
From: Steven Penny <svnpenn@gmail.com>
To: cygwin@cygwin.com
Subject: Re: cURL dependencies broken
References: <87d0i31eyy.fsf@Rainer.invalid>
Content-Type: text/plain; charset=utf8; format=flowed
User-Agent: Suede Mail/2.8.0 (github.com/cup/suede)

On Sun, 21 Jul 2019 19:20:53, Achim Gratz wrote:
> Or maybe you should do that and lose the attitude?

You are projecting. It was you who flatly refuted my position with no research
at all.

> Just to keep the record straight, you've been originally asking about
> direct dependencies of curl, not transitory ones; so no, I didn't look
> at those.

I never said children only, I think you assumed that. A grandchild is still a
dependency. Perhaps if I had said "direct dependencies" as you did, then it
would be fair to make that assumption.

> What has been obsoleted is actually libopenssl100; and it was
> replaced by compatibility shims in libssl-1.0 for libraries and
> applications that did not yet make the jump to the new API.

Right, so even in that case why is OpenLdap using "libopenssl100" instead of
"libssl1.0"?

> It would all have been fairly obvious if you had looked at the announcement
> mails and the actual library names.

Please do not assume what mails I do and do not look at.

> Your cygcheck output shows that this obsoletion has worked just the way it was
> supposed to.

In the general case yes, this is an elegant solution. However we are not in
the general case, we are talking about a security sensitive package. I think
it would be reasonable to expect that the cascading dependencies should be
updated in tandem in this case. Else you are left with "weakest link" syndrome,
where the end user is getting none of security fixes in regard to cURL with
OpenLdap, or worse they assume they are. It looks like OpenLdap has been able to
use OpenSSL 1.1 for over 2 years now:

- http://openldap.org/lists/openldap-bugs/201704/msg00053.html
- ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release

but maybe it has not been changed because the package is abandoned:

https://cygwin.com/cygwin-pkg-maint

Can we pull OpenLdap out of cURL until this is resolved? Else I can voluteer to
pick up maintenance.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple