cURL dependencies broken

cURL dependencies broken

[Steven Penny]

For some reason cURL 7.65.0-1 requires both of these:

    cygcrypto-1.1.dll
    cygcrypto-1.0.0.dll

and confirmed by "setup.ini":

    requires: cygwin libcurl4 libmetalink3 libopenssl100 libssl1.1 zlib0

this raises several questions:

Why are both required?

Why is cURL requiring an old version of OpenSSL? Isn’t that a security risk?

Why is the "requires" line being used? I thought the "depends2" was superseding
it.

Even if "requires" is still valid, why is "libopenssl100" being required by
anything? "setup.ini" says that it is obsolete, twice over:

    @ libopenssl100
    sdesc: "Obsoleted by libssl1.0"


--
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

Re: cURL dependencies broken

[Achim Gratz]

Steven Penny writes:
> For some reason cURL 7.65.0-1 requires both of these:
>
>    cygcrypto-1.1.dll
>    cygcrypto-1.0.0.dll
>
> and confirmed by "setup.ini":

No it doesn't.  The "requires" line is only there for backwards
compatibility and is a join of all versioned dependencies, which are
listed in "depends2".


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
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

Re: cURL dependencies broken

[Steven Penny]

On Sun, 21 Jul 2019 08:54:42, Achim Gratz wrote:
> No it doesn't.  The "requires" line is only there for backwards
> compatibility and is a join of all versioned dependencies, which are
> listed in "depends2".

Here is a culled cygcheck of cURL:

    $ cygcheck curl
    C:\cygwin64\bin\curl.exe
      C:\cygwin64\bin\cygcurl-4.dll
        C:\cygwin64\bin\cygcrypto-1.1.dll
        C:\cygwin64\bin\cygldap-2-4-2.dll
          C:\cygwin64\bin\cygcrypto-1.0.0.dll
          C:\cygwin64\bin\cygssl-1.0.0.dll
        C:\cygwin64\bin\cygssl-1.1.dll

So LibCurl itself is requiring the new version, but LibLdap is requiring old
version. Further, we can prove this with "setup.ini" as well. Look at culled
listing of LibCurl:

    @ libcurl4
    requires: ca-certificates cygwin libbrotlidec1 libopenldap2_4_2
    depends2: ca-certificates, cygwin, libbrotlidec1, libopenldap2_4_2

No matter which on we look at "libopenldap2_4_2" is required. Now, let go one
more step:

    @ libopenldap2_4_2
    requires: cygwin libopenssl100 libsasl2_3
    depends2: cygwin, libopenssl100, libsasl2_3

No matter which one we look at, the twice obsolete SSL is being used. Achim, in
the future, I think it would be helpful for you to check your facts before
posting.


--
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

Re: cURL dependencies broken

[Achim Gratz]

Steven Penny writes:
> No matter which on we look at "libopenldap2_4_2" is required. Now, let go one
> more step:
> 
>    @ libopenldap2_4_2
>    requires: cygwin libopenssl100 libsasl2_3
>    depends2: cygwin, libopenssl100, libsasl2_3
>
> No matter which one we look at, the twice obsolete SSL is being used. Achim, in
> the future, I think it would be helpful for you to check your facts before
> posting.

Or maybe you should do that and lose the attitude?

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.  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.  It would
all have been fairly obvious if you had looked at the announcement mails
and the actual library names.  Your cygcheck output shows that this
obsoletion has worked just the way it was supposed to.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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

Re: cURL dependencies broken

[Steven Penny]

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

Re: cURL dependencies broken

[Jon Turney]

On 21/07/2019 19:32, Steven Penny wrote:
> 
> 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 
> volunteer to pick up maintenance.

Thanks for offering.

If you wish to proceed with that, please post an ITA to the cygwin-apps 
mailing list.


--
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

Re: cURL dependencies broken

[L A Walsh]

On 2019/07/21 05:41, Steven Penny wrote:
> Achim, in
> the future, I think it would be helpful for you to check your facts before
> posting.
>   
====
    Ya Achim, don't you know you have to be perfect to post on the cygwin
list.  None of this "attempt to help" or such, or posting only from
your own knowledge.  You must know ALL THINGS before posting and be
sure that your statements are correct for all time! ...

...*cough*....

Um...If everyone had to check all facts from all areas in all situations,
no one could ever post anything, which is hardly helpful.

Just my 'humble opinion', but that seemed to come off a bit haughty,
no?
Even if I do check my facts, I find myself wrong at times cuz
the facts went and changed when I wasn't looking!  Or...things
changed...

I'll just take it as someone not having had their coffee-update
yet... ;-)
-l


--
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