Re: OpenSSL version mismatch

[Clemens Lang]

Hi,

On Tue, May 16, 2023 at 09:47:58PM +, Fielding, Eric J (US 329A) via 
macports-users wrote:
> I had a strange error today when I tried to use the “ssh” that is
> installed on my Mac with MacPorts: ‘OpenSSL version mismatch. Built
> against 3080, you have 3010’
> 
> I think I might have installed a port recently without doing the full
> “port selfupdate” and “port upgrade outdated”, so it seems that the
> OpenSSL library was updated but not the “openssh” port. I am running
> the full “port upgrade outdated” now and it is taking a long time, so
> it must have been a while since I last ran the updates. It seems like
> MacPorts should check on the ports that depend on “openSSL” and mark
> those as needing to be updated if it updates the “openssl” port.

This is already the case. [1] updated openssl3 to 3.1.0 and [2] merged
right after it should have triggered a rebuild of openssh immediately
after. I am not sure why this did not happen for you, but not regularly
running 'upgrade outdated' can leave you in this situation. If you
ignore a pending update of the openssh port, there's nothing in
MacPorts' set of tools that would allow us to prevent this situation on
your system.

I recommend you regularly run upgrade outdated to fix issues such as
these.


[1] 
https://github.com/macports/macports-ports/commit/b3cde5bf23f93ea1ebb2010e075bd08e1ca988a9
[2] 
https://github.com/macports/macports-ports/commit/13819785f60e9e79f9fae918f47c9b3aad80d516

-- 
Clemens

p5-net-ssleay dependency on openssl

[Kastus Shchuka]

My "port upgrade outdated" choked today on p5.30-net-ssleay:

$ sudo port upgrade outdated
--->  Computing dependencies for openssl
Error: Can't install openssl because conflicting ports are active: libressl
Error: Problem while installing openssl
Error: Follow https://guide.macports.org/#project.tickets if you believe there 
is a bug.

Debug shows this:

DEBUG: p5.30-net-ssleay 1.920.0_1 exists in the ports tree
DEBUG: p5.30-net-ssleay 1.920.0_0  is the latest installed
DEBUG: p5.30-net-ssleay 1.920.0_0  is active
DEBUG: Merging existing requested variants '' into variants
DEBUG: new fully merged portvariants: 
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/perl/p5-net-ssleay
DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
DEBUG: Re-registering default for configure.universal_args
DEBUG: Sourcing PortGroup perl5 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/perl5-1.0.tcl
DEBUG: Re-registering default for livecheck.version
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Fetching p5.30-net-ssleay-1.920.0_1.darwin_17.x86_64.tbz2 archive size
DEBUG: openssl is *not* installed by MacPorts
DEBUG: Searching for dependency: openssl
DEBUG: Didn't find receipt, going to depspec regex for: openssl
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/openssl
DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
DEBUG: Sourcing PortGroup compiler_wrapper 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_wrapper-1.0.tcl
DEBUG: Sourcing PortGroup openssl 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/openssl-1.0.tcl
DEBUG: openssl: Set OpenSSL Branch dependency 3
DEBUG: openssl: configure_proc set : Configure ''
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Running callback compwrap::configure_envs
DEBUG: Finished running callback compwrap::configure_envs
DEBUG: Running callback openssl::set_openssl_dependency
DEBUG: openssl: Set OpenSSL Branch dependency 3
DEBUG: Finished running callback openssl::set_openssl_dependency
DEBUG: Running callback openssl::check_for_cmake
DEBUG: Finished running callback openssl::check_for_cmake
DEBUG: Running callback openssl::configure_build
DEBUG: Finished running callback openssl::configure_build
DEBUG: Fetching openssl-3_10.darwin_17.x86_64.tbz2 archive size
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: openssl3 3.1.0_3 exists in the ports tree
DEBUG: openssl3 3.1.0_3  is the latest installed
DEBUG: openssl3 3.1.0_3  is active
DEBUG: Merging existing requested variants '' into variants
DEBUG: new fully merged portvariants: 
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/openssl3
DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
DEBUG: Sourcing PortGroup compiler_blacklist_versions 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
DEBUG: Sourcing PortGroup muniversal 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/muniversal-1.0.tcl
DEBUG: Sourcing PortGroup legacysupport 1.1 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/legacysupport-1.1.tcl
DEBUG: legacysupport: Will append MACPORTS_LEGACY_SUPPORT_DISABLED=1 to 
extract.env
DEBUG: legacysupport: Will append MACPORTS_LEGACY_SUPPORT_DISABLED=1 to 
configure.env
DEBUG: 

Re: mac and ssl/openssl

[Riccardo Mottola via macports-users]

Hi Ryan,

Ryan Schmidt wrote:

I tested that 10.13 doesn't have, so GNUMail doesn't compile.

Did Mac switch to a different ssl version and/or changed the location of it? 
with which version?
Do you have experience supporting it?
I'd like to keep GNUMail working on vintage macs, but also support newer ones.

https://web.archive.org/web/20221129062249/http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html



so except of rewriting the code... the solution is to use MacPorts 
openssl and package it inside the app, I see.


Thanks,
Riccardo

Re: mac and ssl/openssl

[Ryan Schmidt]

On Feb 5, 2023, at 16:08, Riccardo Mottola wrote:

> Old versions of macs which I use, like 10.4 up to 10.7 have openssl and ssl.h
> 
> I tested that 10.13 doesn't have, so GNUMail doesn't compile.
> 
> Did Mac switch to a different ssl version and/or changed the location of it? 
> with which version?
> Do you have experience supporting it?
> I'd like to keep GNUMail working on vintage macs, but also support newer ones.

https://web.archive.org/web/20221129062249/http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html

mac and ssl/openssl

[Riccardo Mottola via macports-users]

Hi all!

tangent question for mac development and different MacOS versions.

Old versions of macs which I use, like 10.4 up to 10.7 have openssl and 
ssl.h


I tested that 10.13 doesn't have, so GNUMail doesn't compile.

Did Mac switch to a different ssl version and/or changed the location of 
it? with which version?

Do you have experience supporting it?
I'd like to keep GNUMail working on vintage macs, but also support newer 
ones.


Riccardo

Re: curl and openSSL

[James Secan]

Thanks.  I’ll pass that along to the person from NASA who contacted me.

Jim
> On Apr 13, 2022, at 1:07 AM, Clemens Lang  wrote:
> 
> On Tue, Apr 12, 2022 at 02:16:08PM -0700, James Secan wrote:
>> It’s a US Gov’t site (NASA): cddis.nasa.gov.  I’m accessing data on
>> their Space Geodesy Data archive, pulling files from directory
>> archive/gnss/products/ionex.  I filed an initial complaint with them
>> yesterday before I knew in detail what was going on and had a response
>> asking for more info this morning.  I’ve sent them everything I know,
>> but have heard nothing back.  That was just this morning, so it’s too
>> soon to be getting antsy about a response from them.
> 
> Their server does not include a RFC5746 renegotiation_info extension in
> its ServerHello message. Modern TLS clients such as OpenSSL 3 consider
> this insecure. See https://datatracker.ietf.org/doc/html/rfc5746 for
> more details.
> 
> -- 
> Clemens

Re: curl and openSSL

[Clemens Lang]

On Tue, Apr 12, 2022 at 02:16:08PM -0700, James Secan wrote:
> It’s a US Gov’t site (NASA): cddis.nasa.gov.  I’m accessing data on
> their Space Geodesy Data archive, pulling files from directory
> archive/gnss/products/ionex.  I filed an initial complaint with them
> yesterday before I knew in detail what was going on and had a response
> asking for more info this morning.  I’ve sent them everything I know,
> but have heard nothing back.  That was just this morning, so it’s too
> soon to be getting antsy about a response from them.

Their server does not include a RFC5746 renegotiation_info extension in
its ServerHello message. Modern TLS clients such as OpenSSL 3 consider
this insecure. See https://datatracker.ietf.org/doc/html/rfc5746 for
more details.

-- 
Clemens

Re: curl and openSSL

[James Secan]

It’s a US Gov’t site (NASA): cddis.nasa.gov.  I’m accessing data on their Space 
Geodesy Data archive, pulling files from directory archive/gnss/products/ionex. 
 I filed an initial complaint with them yesterday before I knew in detail what 
was going on and had a response asking for more info this morning.  I’ve sent 
them everything I know, but have heard nothing back.  That was just this 
morning, so it’s too soon to be getting antsy about a response from them.

Jim
> On Apr 12, 2022, at 1:19 PM, Clemens Lang  wrote:
> 
> Hi,
> 
> On Tue, Apr 12, 2022 at 09:17:03AM -0700, James Secan wrote:
>> I switched from using the macOS-supplied curl to MacPorts curl
>> recently, and one of my download scripts which uses curl immediately
>> stopped working.  The error message from curl was:
>> 
>> curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation
>> disabled
>> 
>> From some googling it sounds like this is a problem on the server end
>> and not on my end.  Am I reading this right (I am NOT any kind of
>> expert on SSL)?
> 
> Yes, mostly. Unsafe legacy renegotiation is a mechanism that is
> vulnerable to man in the middle attacks. Can you share which server your
> script was talking to, so I could take a closer look?
> 
> 
>> I’ve switched back to the macOS version of curl for now, but I may try
>> downloading a MacPorts version of curl that doesn’t use openSSL as
>> suggested in a StackExchange post I found.
> 
> This is a message caused by OpenSSL 3.x, so not using OpenSSL will "fix"
> the issue, but leave you vulnerably to the man-in-the-middle vulnerable
> renegotiation.
> 
> -- 
> Clemens

Re: curl and openSSL

[Clemens Lang]

Hi,

On Tue, Apr 12, 2022 at 09:17:03AM -0700, James Secan wrote:
> I switched from using the macOS-supplied curl to MacPorts curl
> recently, and one of my download scripts which uses curl immediately
> stopped working.  The error message from curl was:
> 
> curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation
> disabled
> 
> From some googling it sounds like this is a problem on the server end
> and not on my end.  Am I reading this right (I am NOT any kind of
> expert on SSL)?

Yes, mostly. Unsafe legacy renegotiation is a mechanism that is
vulnerable to man in the middle attacks. Can you share which server your
script was talking to, so I could take a closer look?


> I’ve switched back to the macOS version of curl for now, but I may try
> downloading a MacPorts version of curl that doesn’t use openSSL as
> suggested in a StackExchange post I found.

This is a message caused by OpenSSL 3.x, so not using OpenSSL will "fix"
the issue, but leave you vulnerably to the man-in-the-middle vulnerable
renegotiation.

-- 
Clemens

curl and openSSL

[James Secan]

I switched from using the macOS-supplied curl to MacPorts curl recently, and 
one of my download scripts which uses curl immediately stopped working.  The 
error message from curl was:

curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled

From some googling it sounds like this is a problem on the server end and not 
on my end.  Am I reading this right (I am NOT any kind of expert on SSL)?

I’ve switched back to the macOS version of curl for now, but I may try 
downloading a MacPorts version of curl that doesn’t use openSSL as suggested in 
a StackExchange post I found.

Jim
Seattle, WA

Re: python ports depend on openssl not in index

[Chris Jones]

> On 10 Dec 2021, at 8:07 pm, SeaQuench  wrote:
> 
> Output of selfupdate as requested:
> 
> $ sudo port selfupdate
> --->  Updating MacPorts base sources using rsync
> Error: Error synchronizing MacPorts sources: command execution failed
> Please run `port -v selfupdate' for details.
> Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
> MacPorts sources: command execution failed
> 
> [To be clear, I consider my problem to be resolved, thanks.]

Yes, the above is clear, and I guess the reason behind this thread is you did 
not pay enough attention to it in the first case ;)

Chris
> 
> ‐‐‐ Original Message ‐‐‐
> 
>> On Friday, December 10th, 2021 at 2:21 PM, Chris Jones 
>>  wrote:
>> 
>> Hi,
>> 
>> Yes, the error is expected. What i am asking is if you get any indication or 
>> not that there was an issue when you run without the verbose flag. If not, 
>> then i think thats a bug we should address.
>> 
>> Chris
>> 
>>>> On 10 Dec 2021, at 7:18 pm, SeaQuench seaque...@protonmail.com wrote:
>>> 
>>> I am behind a firewall, so this is the following is predictable:
>>> 
>>> $ sudo port -v selfupdate
>>> 
>>> ---> Updating MacPorts base sources using rsync
>>> 
>>> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
>>> 
>>> rsync error: error in socket IO (code 10) at 
>>> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
>>>  [receiver=2.6.9]
>>> 
>>> Command failed: /usr/bin/rsync -rtzvl --delete-after 
>>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>> 
>>> Exit code: 10
>>> 
>>> Error: Error synchronizing MacPorts sources: command execution failed
>>> 
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
>>>> jon...@hep.phy.cam.ac.uk wrote:
>>>> 
>>>> Just to be clear, are you saying running
>>>> 
>>>>> sudo port selfupdate
>>>> 
>>>> ran without warnings or error, but did not actually update ? If thats the 
>>>> case we should file a bug against base as if the rsync fails it should 
>>>> indicate this to the user ?
>>>> 
>>>> cheers Chris
>>>> 
>>>>>> On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
>>>>> 
>>>>> Ryan is correct; I had been sync'ing my port index successfully, but 
>>>>> MacPorts itself grew stale due to my being unable to run selfupdate. The 
>>>>> MacPorts Migration Guide suggested a manual update (i.e. reinstall) which 
>>>>> I believe got me going again. Thanks guys! ~SeaQuench
>>>>> 
>>>>> ‐‐‐ Original Message ‐‐‐
>>>>> 
>>>>>> On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
>>>>>> ryandes...@macports.org wrote:
>>>>> 
>>>>>> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>>>>>> 
>>>>>>> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>>>>>>> 
>>>>>>>> After downloading and installing the latest MacPorts for Catalina, I 
>>>>>>>> followed the instructions to migrate MacPorts: 
>>>>>>>> https://trac.macports.org/wiki/Migration
>>>>>>>> 
>>>>>>>> Reinstalling the ports went without issue until Step 3e: `sudo 
>>>>>>>> ./restore_ports.tcl myports.txt`
>>>>>>>> 
>>>>>>>> Executing that command resulted in the error I presented initially:
>>>>>>>> 
>>>>>>>> ---> Computing dependencies for python38
>>>>>>>> 
>>>>>>>> Error: Dependency 'openssl3' not found.
>>>>>>>> 
>>>>>>>> ---> Computing dependencies for python39
>>>>>>>> 
>>>>>>>> Error: Dependency 'openssl3' not found.
>>>>>>>> 
>>>>>>>> Is that to be expected on a fresh install (before performing a sync)? 
>>>>>>>> I acknowledge that this outcome may result from the use of git versus 
>>>>>>>> rsync in 

Re: python ports depend on openssl not in index

[SeaQuench via macports-users]

Output of selfupdate as requested:

$ sudo port selfupdate
--->  Updating MacPorts base sources using rsync
Error: Error synchronizing MacPorts sources: command execution failed
Please run `port -v selfupdate' for details.
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
MacPorts sources: command execution failed

[To be clear, I consider my problem to be resolved, thanks.]

‐‐‐ Original Message ‐‐‐

On Friday, December 10th, 2021 at 2:21 PM, Chris Jones 
 wrote:

> Hi,
>
> Yes, the error is expected. What i am asking is if you get any indication or 
> not that there was an issue when you run without the verbose flag. If not, 
> then i think thats a bug we should address.
>
> Chris
>
> > On 10 Dec 2021, at 7:18 pm, SeaQuench seaque...@protonmail.com wrote:
> >
> > I am behind a firewall, so this is the following is predictable:
> >
> > $ sudo port -v selfupdate
> >
> > ---> Updating MacPorts base sources using rsync
> >
> > rsync: failed to connect to rsync.macports.org: Operation timed out (60)
> >
> > rsync error: error in socket IO (code 10) at 
> > /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
> >  [receiver=2.6.9]
> >
> > Command failed: /usr/bin/rsync -rtzvl --delete-after 
> > rsync://rsync.macports.org/macports/release/tarballs/base.tar 
> > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
> >
> > Exit code: 10
> >
> > Error: Error synchronizing MacPorts sources: command execution failed
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > > On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
> > > jon...@hep.phy.cam.ac.uk wrote:
> > >
> > > Just to be clear, are you saying running
> > >
> > > > sudo port selfupdate
> > >
> > > ran without warnings or error, but did not actually update ? If thats the 
> > > case we should file a bug against base as if the rsync fails it should 
> > > indicate this to the user ?
> > >
> > > cheers Chris
> > >
> > > > > On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
> > > >
> > > > Ryan is correct; I had been sync'ing my port index successfully, but 
> > > > MacPorts itself grew stale due to my being unable to run selfupdate. 
> > > > The MacPorts Migration Guide suggested a manual update (i.e. reinstall) 
> > > > which I believe got me going again. Thanks guys! ~SeaQuench
> > > >
> > > > ‐‐‐ Original Message ‐‐‐
> > > >
> > > > > On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
> > > > > ryandes...@macports.org wrote:
> > > >
> > > > > On Dec 10, 2021, at 02:29, Chris Jones wrote:
> > > > >
> > > > > > On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
> > > > > >
> > > > > > > After downloading and installing the latest MacPorts for 
> > > > > > > Catalina, I followed the instructions to migrate MacPorts: 
> > > > > > > https://trac.macports.org/wiki/Migration
> > > > > > >
> > > > > > > Reinstalling the ports went without issue until Step 3e: `sudo 
> > > > > > > ./restore_ports.tcl myports.txt`
> > > > > > >
> > > > > > > Executing that command resulted in the error I presented 
> > > > > > > initially:
> > > > > > >
> > > > > > > ---> Computing dependencies for python38
> > > > > > >
> > > > > > > Error: Dependency 'openssl3' not found.
> > > > > > >
> > > > > > > ---> Computing dependencies for python39
> > > > > > >
> > > > > > > Error: Dependency 'openssl3' not found.
> > > > > > >
> > > > > > > Is that to be expected on a fresh install (before performing a 
> > > > > > > sync)? I acknowledge that this outcome may result from the use of 
> > > > > > > git versus rsync in keeping MacPorts up to date. I am behind a 
> > > > > > > firewall, so i must use git to sync rather than use rsync.
> > > > > > >
> > > > > > > https://trac.macports.org/wiki/howto/SyncingWithGit
> > > > > > >
> > > > > > > If i substitute the command `sudo port -v sync` for the 

Re: python ports depend on openssl not in index

[Chris Jones]

Hi,

Yes, the error is expected. What i am asking is if you get any indication or 
not that there was an issue when you run without the verbose flag. If not, then 
i think thats a bug we should address.

Chris

> On 10 Dec 2021, at 7:18 pm, SeaQuench  wrote:
> 
> I am behind a firewall, so this is the following is predictable:
> 
> $ sudo port -v selfupdate
> --->  Updating MacPorts base sources using rsync
> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
> rsync error: error in socket IO (code 10) at 
> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
>  [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzvl --delete-after 
> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
> Exit code: 10
> Error: Error synchronizing MacPorts sources: command execution failed
> 
> ‐‐‐ Original Message ‐‐‐
> 
>> On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
>>  wrote:
>> 
>> Just to be clear, are you saying running
>> 
>>> sudo port selfupdate
>> 
>> ran without warnings or error, but did not actually update ? If thats the 
>> case we should file a bug against base as if the rsync fails it should 
>> indicate this to the user ?
>> 
>> cheers Chris
>> 
>>>> On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
>>> 
>>> Ryan is correct; I had been sync'ing my port index successfully, but 
>>> MacPorts itself grew stale due to my being unable to run selfupdate. The 
>>> MacPorts Migration Guide suggested a manual update (i.e. reinstall) which I 
>>> believe got me going again. Thanks guys! ~SeaQuench
>>> 
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
>>>> ryandes...@macports.org wrote:
>>> 
>>>> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>>>> 
>>>>> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>>>>> 
>>>>>> After downloading and installing the latest MacPorts for Catalina, I 
>>>>>> followed the instructions to migrate MacPorts: 
>>>>>> https://trac.macports.org/wiki/Migration
>>>>>> 
>>>>>> Reinstalling the ports went without issue until Step 3e: `sudo 
>>>>>> ./restore_ports.tcl myports.txt`
>>>>>> 
>>>>>> Executing that command resulted in the error I presented initially:
>>>>>> 
>>>>>> ---> Computing dependencies for python38
>>>>>> 
>>>>>> Error: Dependency 'openssl3' not found.
>>>>>> 
>>>>>> ---> Computing dependencies for python39
>>>>>> 
>>>>>> Error: Dependency 'openssl3' not found.
>>>>>> 
>>>>>> Is that to be expected on a fresh install (before performing a sync)? I 
>>>>>> acknowledge that this outcome may result from the use of git versus 
>>>>>> rsync in keeping MacPorts up to date. I am behind a firewall, so i must 
>>>>>> use git to sync rather than use rsync.
>>>>>> 
>>>>>> https://trac.macports.org/wiki/howto/SyncingWithGit
>>>>>> 
>>>>>> If i substitute the command `sudo port -v sync` for the command `sudo 
>>>>>> port selfupdate` - as usual - I can now install openssl without error, 
>>>>>> and all dependencies are found after re-executing: `sudo 
>>>>>> ./restore_ports.tcl myports.txt`
>>>>> 
>>>>> We need to see why you are not finding the openssl3 port, as that has 
>>>>> been available for some time.
>>>>> 
>>>>> Please run
>>>>> 
>>>>> sudo port -d sync
>>>>> 
>>>>> And post what you get back to the list
>>>> 
>>>> They already said that after running "sudo port sync", everything is 
>>>> working.
>>>> 
>>>> "sudo port selfupdate" should selfupdate (update MacPorts base) and sync 
>>>> (update ports tree). If updating base failed for some reason, then it 
>>>> might not update the ports tree either. You mentioned being behind a 
>>>> firewall that prevents you from syncing with rsync. selfupdate has no 
>>>> option but to use rsync, so that would be a likely explanation for why 
>>>> selfupdate doesn't work for you, and why you should not use selfupdate and 
>>>> should instead (i) update MacPorts base manually when a new version is 
>>>> available, using an installer from our web site and (ii) sync to update 
>>>> ports.

Re: python ports depend on openssl not in index

[SeaQuench via macports-users]

I am behind a firewall, so this is the following is predictable:

$ sudo port -v selfupdate
--->  Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org: Operation timed out (60)
rsync error: error in socket IO (code 10) at 
/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
 [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzvl --delete-after 
rsync://rsync.macports.org/macports/release/tarballs/base.tar 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
Exit code: 10
Error: Error synchronizing MacPorts sources: command execution failed

‐‐‐ Original Message ‐‐‐

On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
 wrote:

> Just to be clear, are you saying running
>
> > sudo port selfupdate
>
> ran without warnings or error, but did not actually update ? If thats the 
> case we should file a bug against base as if the rsync fails it should 
> indicate this to the user ?
>
> cheers Chris
>
> > On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
> >
> > Ryan is correct; I had been sync'ing my port index successfully, but 
> > MacPorts itself grew stale due to my being unable to run selfupdate. The 
> > MacPorts Migration Guide suggested a manual update (i.e. reinstall) which I 
> > believe got me going again. Thanks guys! ~SeaQuench
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
> > ryandes...@macports.org wrote:
> >
> > > On Dec 10, 2021, at 02:29, Chris Jones wrote:
> > >
> > > > On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
> > > >
> > > > > After downloading and installing the latest MacPorts for Catalina, I 
> > > > > followed the instructions to migrate MacPorts: 
> > > > > https://trac.macports.org/wiki/Migration
> > > > >
> > > > > Reinstalling the ports went without issue until Step 3e: `sudo 
> > > > > ./restore_ports.tcl myports.txt`
> > > > >
> > > > > Executing that command resulted in the error I presented initially:
> > > > >
> > > > > ---> Computing dependencies for python38
> > > > >
> > > > > Error: Dependency 'openssl3' not found.
> > > > >
> > > > > ---> Computing dependencies for python39
> > > > >
> > > > > Error: Dependency 'openssl3' not found.
> > > > >
> > > > > Is that to be expected on a fresh install (before performing a sync)? 
> > > > > I acknowledge that this outcome may result from the use of git versus 
> > > > > rsync in keeping MacPorts up to date. I am behind a firewall, so i 
> > > > > must use git to sync rather than use rsync.
> > > > >
> > > > > https://trac.macports.org/wiki/howto/SyncingWithGit
> > > > >
> > > > > If i substitute the command `sudo port -v sync` for the command `sudo 
> > > > > port selfupdate` - as usual - I can now install openssl without 
> > > > > error, and all dependencies are found after re-executing: `sudo 
> > > > > ./restore_ports.tcl myports.txt`
> > > >
> > > > We need to see why you are not finding the openssl3 port, as that has 
> > > > been available for some time.
> > > >
> > > > Please run
> > > >
> > > > sudo port -d sync
> > > >
> > > > And post what you get back to the list
> > >
> > > They already said that after running "sudo port sync", everything is 
> > > working.
> > >
> > > "sudo port selfupdate" should selfupdate (update MacPorts base) and sync 
> > > (update ports tree). If updating base failed for some reason, then it 
> > > might not update the ports tree either. You mentioned being behind a 
> > > firewall that prevents you from syncing with rsync. selfupdate has no 
> > > option but to use rsync, so that would be a likely explanation for why 
> > > selfupdate doesn't work for you, and why you should not use selfupdate 
> > > and should instead (i) update MacPorts base manually when a new version 
> > > is available, using an installer from our web site and (ii) sync to 
> > > update ports.

Re: python ports depend on openssl not in index

[Christopher Jones]

Just to be clear, are you saying running

> sudo port selfupdate

ran without warnings or error, but did not actually update ? If thats the case 
we should file a bug against base as if the rsync fails it should indicate this 
to the user ?

cheers Chris

> On 10 Dec 2021, at 3:13 pm, SeaQuench  wrote:
>
> Ryan is correct; I had been sync'ing my port index successfully, but MacPorts 
> itself grew stale due to my being unable to run selfupdate. The MacPorts 
> Migration Guide suggested a manual update (i.e. reinstall) which I believe 
> got me going again. Thanks guys! ~SeaQuench
>
> ‐‐‐ Original Message ‐‐‐
>
> On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
>  wrote:
>
>> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>>
>>> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>>>
>>>> After downloading and installing the latest MacPorts for Catalina, I 
>>>> followed the instructions to migrate MacPorts: 
>>>> https://trac.macports.org/wiki/Migration
>>>>
>>>> Reinstalling the ports went without issue until Step 3e: `sudo 
>>>> ./restore_ports.tcl myports.txt`
>>>>
>>>> Executing that command resulted in the error I presented initially:
>>>>
>>>> ---> Computing dependencies for python38
>>>>
>>>> Error: Dependency 'openssl3' not found.
>>>>
>>>> ---> Computing dependencies for python39
>>>>
>>>> Error: Dependency 'openssl3' not found.
>>>>
>>>> Is that to be expected on a fresh install (before performing a sync)? I 
>>>> acknowledge that this outcome may result from the use of git versus rsync 
>>>> in keeping MacPorts up to date. I am behind a firewall, so i must use git 
>>>> to sync rather than use rsync.
>>>>
>>>> https://trac.macports.org/wiki/howto/SyncingWithGit
>>>>
>>>> If i substitute the command `sudo port -v sync` for the command `sudo port 
>>>> selfupdate` - as usual - I can now install openssl without error, and all 
>>>> dependencies are found after re-executing: `sudo ./restore_ports.tcl 
>>>> myports.txt`
>>>
>>> We need to see why you are not finding the openssl3 port, as that has been 
>>> available for some time.
>>>
>>> Please run
>>>
>>> sudo port -d sync
>>>
>>> And post what you get back to the list
>>
>> They already said that after running "sudo port sync", everything is working.
>>
>> "sudo port selfupdate" should selfupdate (update MacPorts base) and sync 
>> (update ports tree). If updating base failed for some reason, then it might 
>> not update the ports tree either. You mentioned being behind a firewall that 
>> prevents you from syncing with rsync. selfupdate has no option but to use 
>> rsync, so that would be a likely explanation for why selfupdate doesn't work 
>> for you, and why you should not use selfupdate and should instead (i) update 
>> MacPorts base manually when a new version is available, using an installer 
>> from our web site and (ii) sync to update ports.



smime.p7s
Description: S/MIME cryptographic signature

Re: python ports depend on openssl not in index

[SeaQuench via macports-users]

Ryan is correct; I had been sync'ing my port index successfully, but MacPorts 
itself grew stale due to my being unable to run selfupdate. The MacPorts 
Migration Guide suggested a manual update (i.e. reinstall) which I believe got 
me going again. Thanks guys! ~SeaQuench

‐‐‐ Original Message ‐‐‐

On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
 wrote:

> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>
> > On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
> >
> > > After downloading and installing the latest MacPorts for Catalina, I 
> > > followed the instructions to migrate MacPorts: 
> > > https://trac.macports.org/wiki/Migration
> > >
> > > Reinstalling the ports went without issue until Step 3e: `sudo 
> > > ./restore_ports.tcl myports.txt`
> > >
> > > Executing that command resulted in the error I presented initially:
> > >
> > > ---> Computing dependencies for python38
> > >
> > > Error: Dependency 'openssl3' not found.
> > >
> > > ---> Computing dependencies for python39
> > >
> > > Error: Dependency 'openssl3' not found.
> > >
> > > Is that to be expected on a fresh install (before performing a sync)? I 
> > > acknowledge that this outcome may result from the use of git versus rsync 
> > > in keeping MacPorts up to date. I am behind a firewall, so i must use git 
> > > to sync rather than use rsync.
> > >
> > > https://trac.macports.org/wiki/howto/SyncingWithGit
> > >
> > > If i substitute the command `sudo port -v sync` for the command `sudo 
> > > port selfupdate` - as usual - I can now install openssl without error, 
> > > and all dependencies are found after re-executing: `sudo 
> > > ./restore_ports.tcl myports.txt`
> >
> > We need to see why you are not finding the openssl3 port, as that has been 
> > available for some time.
> >
> > Please run
> >
> > sudo port -d sync
> >
> > And post what you get back to the list
>
> They already said that after running "sudo port sync", everything is working.
>
> "sudo port selfupdate" should selfupdate (update MacPorts base) and sync 
> (update ports tree). If updating base failed for some reason, then it might 
> not update the ports tree either. You mentioned being behind a firewall that 
> prevents you from syncing with rsync. selfupdate has no option but to use 
> rsync, so that would be a likely explanation for why selfupdate doesn't work 
> for you, and why you should not use selfupdate and should instead (i) update 
> MacPorts base manually when a new version is available, using an installer 
> from our web site and (ii) sync to update ports.

Re: python ports depend on openssl not in index

[Ryan Schmidt]

On Dec 10, 2021, at 02:29, Chris Jones wrote:
> 
> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>> 
>> 
>> After downloading and installing the latest MacPorts for Catalina, I 
>> followed the instructions to migrate MacPorts: 
>> https://trac.macports.org/wiki/Migration
>> Reinstalling the ports went without issue until Step 3e: `sudo 
>> ./restore_ports.tcl myports.txt`
>> Executing that command resulted in the error I presented initially:
>> --->  Computing dependencies for python38
>> Error: Dependency 'openssl3' not found.
>> --->  Computing dependencies for python39
>> Error: Dependency 'openssl3' not found.
>> 
>> Is that to be expected on a fresh install (before performing a sync)? I 
>> acknowledge that this outcome may result from the use of git versus rsync in 
>> keeping MacPorts up to date. I am behind a firewall, so i must use git to 
>> sync rather than use rsync.
>> https://trac.macports.org/wiki/howto/SyncingWithGit
>> If i substitute the command `sudo port -v sync` for the command `sudo port 
>> selfupdate` - as usual - I can now install openssl without error, and all 
>> dependencies are found after re-executing: `sudo ./restore_ports.tcl 
>> myports.txt`
> 
> We need to see why you are not finding the openssl3 port, as that has been 
> available for some time.
> 
> Please run
> 
> sudo port -d sync
> 
> And post what you get back to the list



They already said that after running "sudo port sync", everything is working.

"sudo port selfupdate" should selfupdate (update MacPorts base) and sync 
(update ports tree). If updating base failed for some reason, then it might not 
update the ports tree either. You mentioned being behind a firewall that 
prevents you from syncing with rsync. selfupdate has no option but to use 
rsync, so that would be a likely explanation for why selfupdate doesn't work 
for you, and why you should not use selfupdate and should instead (i) update 
MacPorts base manually when a new version is available, using an installer from 
our web site and (ii) sync to update ports.

Re: python ports depend on openssl not in index

[Chris Jones]

Hi,

Please always remember to reply to the list.

We need to see why you are not finding the openssl3 port, as that has been 
available for some time.

Please run

sudo port -d sync

And post what you get back to the list

Chris

> On 9 Dec 2021, at 10:49 pm, SeaQuench  wrote:
> 
> 
> After downloading and installing the latest MacPorts for Catalina, I followed 
> the instructions to migrate MacPorts: https://trac.macports.org/wiki/Migration
> Reinstalling the ports went without issue until Step 3e: `sudo 
> ./restore_ports.tcl myports.txt`
> Executing that command resulted in the error I presented initially:
> --->  Computing dependencies for python38
> Error: Dependency 'openssl3' not found.
> --->  Computing dependencies for python39
> Error: Dependency 'openssl3' not found.
> 
> Is that to be expected on a fresh install (before performing a sync)? I 
> acknowledge that this outcome may result from the use of git versus rsync in 
> keeping MacPorts up to date. I am behind a firewall, so i must use git to 
> sync rather than use rsync.
> https://trac.macports.org/wiki/howto/SyncingWithGit
> If i substitute the command `sudo port -v sync` for the command `sudo port 
> selfupdate` - as usual - I can now install openssl without error, and all 
> dependencies are found after re-executing: `sudo ./restore_ports.tcl 
> myports.txt`
> 
> Any additional advice welcome. Thanks for the tip on migration, Chris!
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
>> On Thursday, December 9th, 2021 at 2:47 PM, Chris Jones 
>>  wrote:
>> 
>> 
>> 
>> Did you follow the migration guide when moving to a new major os version ?
>> 
>> https://trac.macports.org/wiki/Migration
>> 
>> If not, follow it now, to wipe out your ports and reinstall them correctly 
>> for the new os.
>> 
>> If you did, your ports tree seems to be very out of date. Then try,
>> 
>> > sudo port selfupdate
>> > sudo port sync
>> > sudo port upgrade outdated
>> 
>> Chris
>> 
>>>> On 9 Dec 2021, at 6:53 pm, SeaQuench via macports-users 
>>>>  wrote:
>>> 
>>> 
>>> 
>>> After applying an update to MacOS last August, the python ports are 
>>> reporting a dependency on either openssl11 or openssl3, neither of which 
>>> are to be found in the (local?) index for MacPorts, according to the error 
>>> I have received, copied below. While I am prompted to report a bug, I 
>>> presume I am not in a novel situation. Could someone advise me as to how to 
>>> proceed? I am running MacPorts 2.6.2 on MacOS 10.15.7 with XCode 12.4 
>>> installed.
>>> $ sudo port install python39 
>>> 
>>> 
>>> 
>>> 
>>> Warning: No port openssl3 found in the index. 
>>> ---> Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found. 
>>> Error: Unable to execute port: upgrade openssl failed 
>>> 
>>> 
>>> 
>>> 
>>> $ sudo port install openssl 
>>> 
>>> 
>>> 
>>> 
>>> ---> Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found. 
>>> Error: Follow https://guide.macports.org/#project.tickets to report a bug. 
>>> Error: Processing of port openssl failed
>>> 
>>> 
>>> $ sudo port -n upgrade --force python38
>>> --->  Computing dependencies for python38
>>> --->  Fetching archive for python38
>>> --->  Attempting to fetch 
>>> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2 from 
>>> https://packages.macports.org/python38
>>> --->  Attempting to fetch 
>>> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2.rmd160 from 
>>> https://packages.macports.org/python38
>>> --->  Installing python38 @3.8.12_4+optimizations
>>> --->  Cleaning python38
>>> --->  Computing dependencies for python38
>>> --->  Deactivating python38 @3.8.11_0
>>> --->  Cleaning python38
>>> --->  Activating python38 @3.8.12_4+optimizations
>>> --->  Cleaning python38
>>> --->  Updating database of binaries
>>> --->  Scanning binaries for linking errors
>>> --->  Found 18 broken files, matching files to ports 
>>> --->  Found 4 broken ports, determining rebuild order
>>> You can always run 'port rev-upgrade' again to fix errors.
>>> The following ports will be rebuilt:
>>>  python38 @3.8.12+optimizations
>>>  python39 @3.9.6
>>>  glib2 @2.58.3+x11
>>>  gobject-introspection @1.60.2
>>> Continue? [Y/n]: y
>>> Warning: No port openssl3 found in the index.
>>> --->  Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found.
>>> Error: rev-upgrade failed: Error rebuilding python38
>>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>>> 
>>> 
> 
> 

Re: python ports depend on openssl not in index

[Joshua Root]

SeaQuench wrote:


After applying an update to MacOS last August, the python ports are reporting a 
dependency on either openssl11 or openssl3, neither of which are to be found in 
the (local?) index for MacPorts, according to the error I have received, copied 
below. While I am prompted to report a bug, I presume I am not in a novel 
situation. Could someone advise me as to how to proceed? I am running MacPorts 
2.6.2 on MacOS 10.15.7 with XCode 12.4 installed.
The primary problem here is that you are running MacPorts 2.6.2 
(released in 2019). The current ports are not going to work with an old 
version of base. You need to update to 2.7.1, and the other problems 
will likely be resolved by that.


- Josh

Re: python ports depend on openssl not in index

[Chris Jones]

Did you follow the migration guide when moving to a new major os version ?

https://trac.macports.org/wiki/Migration

If not, follow it now, to wipe out your ports and reinstall them correctly for 
the new os.

If you did, your ports tree seems to be very out of date. Then try,

> sudo port selfupdate
> sudo port sync
> sudo port upgrade outdated

Chris

> On 9 Dec 2021, at 6:53 pm, SeaQuench via macports-users 
>  wrote:
> 
> 
> After applying an update to MacOS last August, the python ports are reporting 
> a dependency on either openssl11 or openssl3, neither of which are to be 
> found in the (local?) index for MacPorts, according to the error I have 
> received, copied below. While I am prompted to report a bug, I presume I am 
> not in a novel situation. Could someone advise me as to how to proceed? I am 
> running MacPorts 2.6.2 on MacOS 10.15.7 with XCode 12.4 installed.
> 
> $ sudo port install python39 
> Warning: No port openssl3 found in the index. 
> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found. 
> Error: Unable to execute port: upgrade openssl failed 
> $ sudo port install openssl 
> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found. 
> Error: Follow https://guide.macports.org/#project.tickets to report a bug. 
> Error: Processing of port openssl failed
> $ sudo port -n upgrade --force python38
> --->  Computing dependencies for python38
> --->  Fetching archive for python38
> --->  Attempting to fetch 
> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2 from 
> https://packages.macports.org/python38
> --->  Attempting to fetch 
> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/python38
> --->  Installing python38 @3.8.12_4+optimizations
> --->  Cleaning python38
> --->  Computing dependencies for python38
> --->  Deactivating python38 @3.8.11_0
> --->  Cleaning python38
> --->  Activating python38 @3.8.12_4+optimizations
> --->  Cleaning python38
> --->  Updating database of binaries
> --->  Scanning binaries for linking errors
> --->  Found 18 broken files, matching files to ports 
> --->  Found 4 broken ports, determining rebuild order
> You can always run 'port rev-upgrade' again to fix errors.
> The following ports will be rebuilt:
>  python38 @3.8.12+optimizations
>  python39 @3.9.6
>  glib2 @2.58.3+x11
>  gobject-introspection @1.60.2
> Continue? [Y/n]: y
> Warning: No port openssl3 found in the index.
> --->  Computing dependencies for openssl
> Error: Dependency 'openssl3' not found.
> Error: rev-upgrade failed: Error rebuilding python38
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> 

python ports depend on openssl not in index

[SeaQuench via macports-users]

After applying an update to MacOS last August, the python ports are reporting a 
dependency on either openssl11 or openssl3, neither of which are to be found in 
the (local?) index for MacPorts, according to the error I have received, copied 
below. While I am prompted to report a bug, I presume I am not in a novel 
situation. Could someone advise me as to how to proceed? I am running MacPorts 
2.6.2 on MacOS 10.15.7 with XCode 12.4 installed.
$ sudo port install python39

> Warning: No port openssl3 found in the index.
> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found.
> Error: Unable to execute port: upgrade openssl failed

$ sudo port install openssl

> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port openssl failed

$ sudo port -n upgrade --force python38

> --->Computing dependencies for python38
> --->Fetching archive for python38
> --->Attempting to fetch python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2 
> from https://packages.macports.org/python38
> --->Attempting to fetch 
> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/python38
> --->Installing python38 @3.8.12_4+optimizations
> --->Cleaning python38
> --->Computing dependencies for python38
> --->Deactivating python38 @3.8.11_0
> --->Cleaning python38
> --->Activating python38 @3.8.12_4+optimizations
> --->Cleaning python38
> --->Updating database of binaries
> --->Scanning binaries for linking errors
> --->Found 18 broken files, matching files to ports
> --->Found 4 broken ports, determining rebuild order
> You can always run 'port rev-upgrade' again to fix errors.
> The following ports will be rebuilt:
> python38 @3.8.12+optimizations
> python39 @3.9.6
> glib2 @2.58.3+x11
> gobject-introspection @1.60.2
> Continue? [Y/n]: y
> Warning: No port openssl3 found in the index.
> --->Computing dependencies for openssl
> Error: Dependency 'openssl3' not found.
> Error: rev-upgrade failed: Error rebuilding python38
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.

Re: Add CA certificates to OpenSSL chain

[Gregory Anders]

On Mon, 29 Mar 2021 20:16 +0200, Clemens Lang wrote:

Install the certsync port instead of curl-ca-bundle. That will generate
/opt/local/share/curl/curl-ca-bundle.crt as an export from your system
trust store, and automatically export your workplace root CAs.


Thanks! This works perfectly and is an even better solution than the one 
I had in mind.


Greg

Re: Add CA certificates to OpenSSL chain

[Clemens Lang]

Hi,

On Mon, Mar 29, 2021 at 09:54:20AM -0600, Gregory Anders wrote:
> Does MacPorts provide a mechanism for adding certificates to the MP
> version of OpenSSL?

No.

> My system keychain contains some certificates used by my work proxy,
> which are (obviously) not in the default CA bundle installed by
> MacPorts. Right now, while I'm connected to my work proxy I cannot
> connect to anything since the CA is not present in the bundle. I
> realize I can just append my CA certificate onto
> /opt/local/share/curl/curl-ca-bundle.crt, but I'm wondering if there's
> a more "official" or "robust" way.

Install the certsync port instead of curl-ca-bundle. That will generate
/opt/local/share/curl/curl-ca-bundle.crt as an export from your system
trust store, and automatically export your workplace root CAs.

Note that you'll have to force-uninstall curl-ca-bundle since many ports
will depend on it. Having certsync installed is a drop-in replacement,
though, and any future installations will have the curl-ca-bundle
dependency fulfilled by certsync instead.


HTH,
Clemens

Add CA certificates to OpenSSL chain

[Gregory Anders]

Hi all,

Does MacPorts provide a mechanism for adding certificates to the MP 
version of OpenSSL?


For example, on a distribution like Ubuntu I can do something like:

cp my-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

There are similar mechanisms for other distros as well.

My system keychain contains some certificates used by my work proxy, 
which are (obviously) not in the default CA bundle installed by 
MacPorts. Right now, while I'm connected to my work proxy I cannot 
connect to anything since the CA is not present in the bundle. I realize 
I can just append my CA certificate onto 
/opt/local/share/curl/curl-ca-bundle.crt, but I'm wondering if there's a 
more "official" or "robust" way.


Thanks,

Greg

Re: dependency on correct openssl?

[Ryan Schmidt]

The developers of vde2 have responded with a fix for most of the issues I 
reported, so now I can go test again and see if anything else is needed before 
we could update the port.


> On Oct 5, 2019, at 14:43, Richard L. Hamilton  wrote:
> 
> No, I'd just run
> port echo rdepends:vde2
> and noticed virtualbox and a couple of related sub-ports in the output.
> 
> Still, I gather one could also use vde2 with some builds of QEMU, for 
> example.  So it presumably still has its uses, esp. since it can apparently 
> optionally apply degrees of network impairment, perhaps useful for testing 
> network stack or network server or client application robustness without 
> expensive test hardware.
> 
> I'm not sure why I have vde2 installed, actually.  I might have been thinking 
> of building something that required it (not necessarily something in 
> MacPorts), but I don't recall what that might be.  I recall having some 
> interest in getting hercules with bridged networking to work (both with the 
> host and out to the internet) even if only WiFi and not Ethernet was in use 
> (ISTR that local to the host didn't work with only WiFi and their 
> implementation of bridging, but I could be misremembering); but hercules 
> doesn't seem to have any need or option for vde2, so that probably wasn't it.
> 
> 
>> On Oct 5, 2019, at 14:39, Ken Cunningham  
>> wrote:
>> 
>> Oh, gosh -- our virtualbox port is so old and out of date I wouldn't even 
>> consider using it.
>> 
>> it should probably be removed, I guess. 
>> 
>> Do you actually have it installed? I am startled if so !
>> 
>> 
>> Ken
>> 
>> 
>> 
>> 
>> On 2019-10-05, at 11:08 AM, Richard L. Hamilton wrote:
>> 
>>> Thank you! From the tickets you filed, it certainly looks like you did a 
>>> thorough job of investigating and reporting the issues.  Hopefully they'll 
>>> get to it reasonably soon, although clearly that's beyond your control.
>>> 
>>> Given that virtualbox depends on it (at least if the vde2 variant is 
>>> enabled), I was surprised that it has such issues left unresolved.  But in
>>> https://www.virtualbox.org/manual/ch06.html#network_vde
>>> I see "At the moment this option requires compilation of Oracle VM 
>>> VirtualBox from sources, as the Oracle packages do not include it."  So I 
>>> guess the folks with commercial resources also just avoided that.
>>> 
>>> Would it be a good idea, until vde2 is working again (not that it would 
>>> help anyone with the virtualbox port already installed), to have it not be 
>>> a default variant for the virtualbox port? (that's how I read [+]vde2 in 
>>> the output of port info virtualbox)
>>> 
>>>> On Oct 5, 2019, at 09:21, Ryan Schmidt  wrote:
>>>> 
>>>> 
>>>> 
>>>> On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:
>>>> 
>>>>> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that 
>>>>> (esp. kdelibs4, which is probably nasty to maintain).
>>>>> 
>>>>> The one I have left that means I can't just "port upgrade outdated" on my 
>>>>> system with the most packages installed, running the current (Mojave) OS, 
>>>>> is vde2; a look at the log file makes it appear quite likely that's also 
>>>>> an openssl changeover related problem.
>>>> 
>>>> I looked into vde2 a few days ago.
>>>> 
>>>> It is not compatible with openssl 1.1, as you found.
>>>> 
>>>> There is a newer version than the one we have in the port available, but 
>>>> it is years old and is also still not openssl 1.1 compatible.
>>>> 
>>>> This has been reported to the developers. Their response was to change 
>>>> their code so that it uses wolfssl instead of openssl. They have not yet 
>>>> released a new version containing this change.
>>>> 
>>>> I tried to update the port to the latest released version and backport the 
>>>> wolfssl change. Just getting that patch to apply required me to backport a 
>>>> number of other changes as well, and I don't think I ended up with a 
>>>> successful build after that either.
>>>> 
>>>> In the process, I noticed a half dozen other problems with their code. I 
>>>> reported these to the developers. I was intending to wait for them to 
>>>> acknowledge and hopefully fix those issues and release a new stable 
>>>> version so that I could then update the port to that version but so far 
>>>> they have not responded to those reports.
>>>> 
>>>> https://github.com/virtualsquare/vde-2/issues
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

Re: dependency on correct openssl?

[Richard L. Hamilton]

No, I'd just run
port echo rdepends:vde2
and noticed virtualbox and a couple of related sub-ports in the output.

Still, I gather one could also use vde2 with some builds of QEMU, for example.  
So it presumably still has its uses, esp. since it can apparently optionally 
apply degrees of network impairment, perhaps useful for testing network stack 
or network server or client application robustness without expensive test 
hardware.

I'm not sure why I have vde2 installed, actually.  I might have been thinking 
of building something that required it (not necessarily something in MacPorts), 
but I don't recall what that might be.  I recall having some interest in 
getting hercules with bridged networking to work (both with the host and out to 
the internet) even if only WiFi and not Ethernet was in use (ISTR that local to 
the host didn't work with only WiFi and their implementation of bridging, but I 
could be misremembering); but hercules doesn't seem to have any need or option 
for vde2, so that probably wasn't it.


> On Oct 5, 2019, at 14:39, Ken Cunningham  
> wrote:
> 
> Oh, gosh -- our virtualbox port is so old and out of date I wouldn't even 
> consider using it.
> 
> it should probably be removed, I guess. 
> 
> Do you actually have it installed? I am startled if so !
> 
> 
> Ken
> 
> 
> 
> 
> On 2019-10-05, at 11:08 AM, Richard L. Hamilton wrote:
> 
>> Thank you! From the tickets you filed, it certainly looks like you did a 
>> thorough job of investigating and reporting the issues.  Hopefully they'll 
>> get to it reasonably soon, although clearly that's beyond your control.
>> 
>> Given that virtualbox depends on it (at least if the vde2 variant is 
>> enabled), I was surprised that it has such issues left unresolved.  But in
>> https://www.virtualbox.org/manual/ch06.html#network_vde 
>> <https://www.virtualbox.org/manual/ch06.html#network_vde>
>> I see "At the moment this option requires compilation of Oracle VM 
>> VirtualBox from sources, as the Oracle packages do not include it."  So I 
>> guess the folks with commercial resources also just avoided that.
>> 
>> Would it be a good idea, until vde2 is working again (not that it would help 
>> anyone with the virtualbox port already installed), to have it not be a 
>> default variant for the virtualbox port? (that's how I read [+]vde2 in the 
>> output of port info virtualbox)
>> 
>>> On Oct 5, 2019, at 09:21, Ryan Schmidt >> <mailto:ryandes...@macports.org>> wrote:
>>> 
>>> 
>>> 
>>> On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:
>>> 
>>>> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
>>>> kdelibs4, which is probably nasty to maintain).
>>>> 
>>>> The one I have left that means I can't just "port upgrade outdated" on my 
>>>> system with the most packages installed, running the current (Mojave) OS, 
>>>> is vde2; a look at the log file makes it appear quite likely that's also 
>>>> an openssl changeover related problem.
>>> 
>>> I looked into vde2 a few days ago.
>>> 
>>> It is not compatible with openssl 1.1, as you found.
>>> 
>>> There is a newer version than the one we have in the port available, but it 
>>> is years old and is also still not openssl 1.1 compatible.
>>> 
>>> This has been reported to the developers. Their response was to change 
>>> their code so that it uses wolfssl instead of openssl. They have not yet 
>>> released a new version containing this change.
>>> 
>>> I tried to update the port to the latest released version and backport the 
>>> wolfssl change. Just getting that patch to apply required me to backport a 
>>> number of other changes as well, and I don't think I ended up with a 
>>> successful build after that either.
>>> 
>>> In the process, I noticed a half dozen other problems with their code. I 
>>> reported these to the developers. I was intending to wait for them to 
>>> acknowledge and hopefully fix those issues and release a new stable version 
>>> so that I could then update the port to that version but so far they have 
>>> not responded to those reports.
>>> 
>>> https://github.com/virtualsquare/vde-2/issues 
>>> <https://github.com/virtualsquare/vde-2/issues>
>>> 
>>> 
>>> 
>> 
> 

Re: dependency on correct openssl?

[Ken Cunningham]

Oh, gosh -- our virtualbox port is so old and out of date I wouldn't even 
consider using it.

it should probably be removed, I guess. 

Do you actually have it installed? I am startled if so !


Ken




On 2019-10-05, at 11:08 AM, Richard L. Hamilton wrote:

> Thank you! From the tickets you filed, it certainly looks like you did a 
> thorough job of investigating and reporting the issues.  Hopefully they'll 
> get to it reasonably soon, although clearly that's beyond your control.
> 
> Given that virtualbox depends on it (at least if the vde2 variant is 
> enabled), I was surprised that it has such issues left unresolved.  But in
> https://www.virtualbox.org/manual/ch06.html#network_vde
> I see "At the moment this option requires compilation of Oracle VM VirtualBox 
> from sources, as the Oracle packages do not include it."  So I guess the 
> folks with commercial resources also just avoided that.
> 
> Would it be a good idea, until vde2 is working again (not that it would help 
> anyone with the virtualbox port already installed), to have it not be a 
> default variant for the virtualbox port? (that's how I read [+]vde2 in the 
> output of port info virtualbox)
> 
>> On Oct 5, 2019, at 09:21, Ryan Schmidt  wrote:
>> 
>> 
>> 
>> On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:
>> 
>>> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
>>> kdelibs4, which is probably nasty to maintain).
>>> 
>>> The one I have left that means I can't just "port upgrade outdated" on my 
>>> system with the most packages installed, running the current (Mojave) OS, 
>>> is vde2; a look at the log file makes it appear quite likely that's also an 
>>> openssl changeover related problem.
>> 
>> I looked into vde2 a few days ago.
>> 
>> It is not compatible with openssl 1.1, as you found.
>> 
>> There is a newer version than the one we have in the port available, but it 
>> is years old and is also still not openssl 1.1 compatible.
>> 
>> This has been reported to the developers. Their response was to change their 
>> code so that it uses wolfssl instead of openssl. They have not yet released 
>> a new version containing this change.
>> 
>> I tried to update the port to the latest released version and backport the 
>> wolfssl change. Just getting that patch to apply required me to backport a 
>> number of other changes as well, and I don't think I ended up with a 
>> successful build after that either.
>> 
>> In the process, I noticed a half dozen other problems with their code. I 
>> reported these to the developers. I was intending to wait for them to 
>> acknowledge and hopefully fix those issues and release a new stable version 
>> so that I could then update the port to that version but so far they have 
>> not responded to those reports.
>> 
>> https://github.com/virtualsquare/vde-2/issues
>> 
>> 
>> 
> 

Re: dependency on correct openssl?

[Richard L. Hamilton]

Thank you! From the tickets you filed, it certainly looks like you did a 
thorough job of investigating and reporting the issues.  Hopefully they'll get 
to it reasonably soon, although clearly that's beyond your control.

Given that virtualbox depends on it (at least if the vde2 variant is enabled), 
I was surprised that it has such issues left unresolved.  But in
https://www.virtualbox.org/manual/ch06.html#network_vde 
<https://www.virtualbox.org/manual/ch06.html#network_vde>
I see "At the moment this option requires compilation of Oracle VM VirtualBox 
from sources, as the Oracle packages do not include it."  So I guess the folks 
with commercial resources also just avoided that.

Would it be a good idea, until vde2 is working again (not that it would help 
anyone with the virtualbox port already installed), to have it not be a default 
variant for the virtualbox port? (that's how I read [+]vde2 in the output of 
port info virtualbox)

> On Oct 5, 2019, at 09:21, Ryan Schmidt  wrote:
> 
> 
> 
> On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:
> 
>> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
>> kdelibs4, which is probably nasty to maintain).
>> 
>> The one I have left that means I can't just "port upgrade outdated" on my 
>> system with the most packages installed, running the current (Mojave) OS, is 
>> vde2; a look at the log file makes it appear quite likely that's also an 
>> openssl changeover related problem.
> 
> I looked into vde2 a few days ago.
> 
> It is not compatible with openssl 1.1, as you found.
> 
> There is a newer version than the one we have in the port available, but it 
> is years old and is also still not openssl 1.1 compatible.
> 
> This has been reported to the developers. Their response was to change their 
> code so that it uses wolfssl instead of openssl. They have not yet released a 
> new version containing this change.
> 
> I tried to update the port to the latest released version and backport the 
> wolfssl change. Just getting that patch to apply required me to backport a 
> number of other changes as well, and I don't think I ended up with a 
> successful build after that either.
> 
> In the process, I noticed a half dozen other problems with their code. I 
> reported these to the developers. I was intending to wait for them to 
> acknowledge and hopefully fix those issues and release a new stable version 
> so that I could then update the port to that version but so far they have not 
> responded to those reports.
> 
> https://github.com/virtualsquare/vde-2/issues
> 
> 
> 

Re: dependency on correct openssl?

[Ryan Schmidt]

On Oct 4, 2019, at 21:41, Richard L. Hamilton wrote:

> I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
> kdelibs4, which is probably nasty to maintain).
> 
> The one I have left that means I can't just "port upgrade outdated" on my 
> system with the most packages installed, running the current (Mojave) OS, is 
> vde2; a look at the log file makes it appear quite likely that's also an 
> openssl changeover related problem.

I looked into vde2 a few days ago.

It is not compatible with openssl 1.1, as you found.

There is a newer version than the one we have in the port available, but it is 
years old and is also still not openssl 1.1 compatible.

This has been reported to the developers. Their response was to change their 
code so that it uses wolfssl instead of openssl. They have not yet released a 
new version containing this change.

I tried to update the port to the latest released version and backport the 
wolfssl change. Just getting that patch to apply required me to backport a 
number of other changes as well, and I don't think I ended up with a successful 
build after that either.

In the process, I noticed a half dozen other problems with their code. I 
reported these to the developers. I was intending to wait for them to 
acknowledge and hopefully fix those issues and release a new stable version so 
that I could then update the port to that version but so far they have not 
responded to those reports.

https://github.com/virtualsquare/vde-2/issues

Re: dependency on correct openssl?

[Richard L. Hamilton]

I see that kdelibs4 and xmms2 are ok now; thanks to whoever did that (esp. 
kdelibs4, which is probably nasty to maintain).

The one I have left that means I can't just "port upgrade outdated" on my 
system with the most packages installed, running the current (Mojave) OS, is 
vde2; a look at the log file makes it appear quite likely that's also an 
openssl changeover related problem.

> On Sep 8, 2019, at 02:55, Ken Cunningham  
> wrote:
> 
> The stragglers are being tweaked as fast as we find them, eg kdelibs4
> 
> <https://trac.macports.org/ticket/58970>
> 
> 
> You can check the git repo, or use ports.macports.org to see how the build is 
> going, or check the tickets to see if yours has been fixed already.
> 
> Feel free to open up some tickets if you find some we haven't come across 
> yet. Watch for dupes, and for ports that have been already fixed in the git 
> history, to keep the volume down.
> 
> It is possible to have your system hold back on the older openssl, but IMHO 
> that would be a mess for you in the end...
> 
> If you have a port you love, and you can find a patch from Free BSD or 
> Archlinux or similar that fixes the build against openssl 1.1.x , feel free 
> to post up a link to the patch and we'll get on it that much faster!
> 
> Best,
> 
> Ken
> 

Re: dependency on correct openssl?

[Bill Cole]

On 8 Sep 2019, at 15:05, Ken Cunningham wrote:

All your points are fair. To be honest, the PR for the openssl upgrade 
was in the PR queue for six months, and it was perceived that all the 
relevant ports that would be affected had been identified and fixed... 
shows you how good we are are guessing that!


MacPorts waited about a year more than other package managers to 
upgrade openssl, so we have lots of patches to use from elsewhere, 
thank goodness.


Yes, I've been living in fear of this day since the release of 1.1.1, 
since I'm not optimistic enough to have been looking forward to it. 
Since my use case is keeping a 1st-gen Core Duo iMac usable as a utility 
server for world-facing services (mail, web, DNS) I was fully 
anticipating a long rebuild cycle full of bumps. I expect that like me, 
most MacPorts users don't have the mental bandwidth to keep an eye on 
slow-moving big projects.


That symlink might stop the rev-upgrade errors, but the symbols in the 
openssl libraries have changed, so you'll be wandering well into the 
land of "unpredictable behaviour" there.


The symlink(s) I made are solely for transition (literally only until 
the terminal leaf ports like Postfix & Apache are rebuilt) but should 
not have significant effects on how other ports that are able to use 
v1.1.1 get built. However, that linkage *should* be entirely safe to 
keep, because I did NOT replace the unversioned .dylib links which point 
to the v1.1.1 libraries. The previous executables explicitly want 
/opt/local/lib/lib{ssl,crypto}.1.0.0.dylib and that is the only problem 
I'm trying to fix. Anything that *can* build with the v1.1.1 libraries 
should be looking for the unversioned names.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)

Re: dependency on correct openssl?

[Ken Cunningham]

All your points are fair. To be honest, the PR for the openssl upgrade was in 
the PR queue for six months, and it was perceived that all the relevant ports 
that would be affected had been identified and fixed... shows you how good we 
are are guessing that!

MacPorts waited about a year more than other package managers to upgrade 
openssl, so we have lots of patches to use from elsewhere, thank goodness.

That symlink might stop the rev-upgrade errors, but the symbols in the openssl 
libraries have changed, so you'll be wandering well into the land of 
"unpredictable behaviour" there. 

Best,

Ken

Re: dependency on correct openssl?

[Bill Cole]

On 8 Sep 2019, at 2:44, Ken Cunningham wrote:


Please have a bit of patience.

MacPorts did a wholesale move to openssl 1.1.1 yesterday.


It would be very helpful to have notice of changes this big. I made the 
mistake of trying an off-schedule 'upgrade outdated' yesterday and ran 
in to a buzzsaw of OpenSSL problems complicated by ongoing churn in the 
devel/* world, blowing out two critical branches of the port 
dependencies of my 10.6.8/libcxx/i386 system which has been compiling as 
fast as it can for over a day now, slowed by the need to manually order 
builds and guess which compiler will actually build which specific 
ports.


We scoped out most of the build failures prior, but there are a few 
that have cropped up.


Yes, they have...


Some of the ones you listed have already been fixed.


A major problem (in effect, not origin) was a typo in the cmake Portfile 
that is now fixed, so anyone hitting that should do another sync or 
selfupdate. Also, for those like myself who don't have a separate build 
environment and need existing operational software built fromMacPorts 
(e.g. Postfix, Apache, BIND, Dovecot, etc. ) to not break in operation, 
it is helpful to do this after updating OpenSSL:


ln -s /opt/local/lib/openssl-1.0/*.1.0.0.dylib /opt/local/lib/

I'm not quite sure why that wasn't done as a part of upgrade, since 
there's always going to be a period of transition where some extant 
software still wants the old version.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)

Re: dependency on correct openssl?

[Ken Cunningham]

The stragglers are being tweaked as fast as we find them, eg kdelibs4

<https://trac.macports.org/ticket/58970>


You can check the git repo, or use ports.macports.org to see how the build is 
going, or check the tickets to see if yours has been fixed already.

Feel free to open up some tickets if you find some we haven't come across yet. 
Watch for dupes, and for ports that have been already fixed in the git history, 
to keep the volume down.

It is possible to have your system hold back on the older openssl, but IMHO 
that would be a mess for you in the end...

If you have a port you love, and you can find a patch from Free BSD or 
Archlinux or similar that fixes the build against openssl 1.1.x , feel free to 
post up a link to the patch and we'll get on it that much faster!

Best,

Ken

Re: dependency on correct openssl?

[Richard L. Hamilton]

No big, except how can I check, short of attempting port rev-upgrade on a 
regular basis, when the fixes are available?

I think kdelibs4 is also one that may want the older 1.0.x.


> On Sep 8, 2019, at 02:44, Ken Cunningham  
> wrote:
> 
> Please have a bit of patience.
> 
> MacPorts did a wholesale move to openssl 1.1.1 yesterday.
> 
> We scoped out most of the build failures prior, but there are a few that have 
> cropped up.
> 
> Some of the ones you listed have already been fixed.
> 
> Best,
> 
> Ken
> 

Re: dependency on correct openssl?

[Ken Cunningham]

Please have a bit of patience.

MacPorts did a wholesale move to openssl 1.1.1 yesterday.

We scoped out most of the build failures prior, but there are a few that have 
cropped up.

Some of the ones you listed have already been fixed.

Best,

Ken

dependency on correct openssl?

[Richard L. Hamilton]

I see the following:

sh-3.2$ port list openssl\*
openssl@1.1.1c devel/openssl
openssl10  @1.0.2s devel/openssl10
openssl11  @1.1.1c devel/openssl11
sh-3.2$ 
sh-3.2$ 
sh-3.2$ port installed openssl\*
The following ports are currently installed:
  openssl @1.0.2s_0
  openssl @1.1.1c_0 (active)
  openssl10 @1.0.2s_0 (active)
sh-3.2$ port select openssl

Apparently sometime recently, plain "openssl" changes from 1.0.x to 1.1.x.  At 
least the following ports may have problems with that - they're the smaller 
number that failed the rev-upgrade test compared to what failed with 1.0.2s_0 
active as openssl.
 elinks @0.11.7
 fetchmail @6.3.26+ssl
 gnome-vfs @2.24.4
 virtuoso-7 @7.2.5
 ipmitool @1.8.15
 xmms2 @0.8DrO_o+python27

They all appear to have dependencies on  openssl rather than explicitly on 
openssl10 or openssl11.

This is definitely not a comprehensive list, it's just the ones I had trouble 
with, all of which have a dependency on openssl.

It seems to me that anything that can work equally well with either can use 
openssl, but anything else should have an explicit dependency on openssl10 or 
openssl11 instead. In particular, anything that cannot yet work with 1.1.x 
should have an explicit dependency on openssl10 rather than openssl.

Does that make sense?

 Aside from those that have to be mutually exclusive, I'd prefer not to have to 
do without some ports to have others.

Re: Is there yet a clean way to upgrade to OpenSSL 1.1.1?

[Daniel J. Luke]

On Apr 18, 2019, at 5:05 PM, Bill Cole 
 wrote:
> Is there some approach that I'm not seeing to build against the new version 
> while leaving services that use the old version (and spawn worker children 
> while running) up and functional?

I think your best bet is to wait for that PR to be merged, and then wait a 
little longer for binaries to be built for all of the other services that you 
have running - then your potential downtime for each service should be pretty 
short.

You could, of course, replicate what the build infrastructure does if you don't 
want to be patient (but it would probably be a better use of your time to help 
out with testing the PR and getting everything ready for it to just be merged).

-- 
Daniel J. Luke

Is there yet a clean way to upgrade to OpenSSL 1.1.1?

[Bill Cole]

It's about time to get everything off the soon-to-be-EOL'd OpenSSL 1.0.2 
and onto 1.1.1, particularly with so-called 'security scanners' scolding 
for lack of TLSv1.3 support. I was happy to see the advent of openssl10 
and openssl11 ports which purport to simplify migration, but it's not 
clear to me how that is true...


I also see https://github.com/macports/macports-ports/pull/3822, which 
is a WIP but it looks like people are testing against it?


Anyway: I have a SnowLeopard machine doing utility server work (Postfix, 
Apache, Dovecot, BIND) which I'd like to update, but it is not clear to 
me how (or even whether) it is possible to build 1.1.1 and use it to 
build all the relevant dependents without taking down services for the 
extended period it will take to build the dependency chain between 
OpenSSL and each of them. On a 2006 1st-gen Core Duo, this is likely to 
be measured in hours of aggregate downtime.


Is there some approach that I'm not seeing to build against the new 
version while leaving services that use the old version (and spawn 
worker children while running) up and functional?


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: openSSL

[Ryan Schmidt]

On Dec 17, 2018, at 06:48, pagani laurentwrote:

> I just upgraded my MacPort install and OpenSSL is 1.0.2q while my VPN 
> application would like to use 1.1.1.
> Is there any chance that v1.1.1 be uploaded to MacPort sometimes soon ? 
> (easier to ask than to do, I know, thanks for all those of you who spend 
> their time making MacPort a useful service)

The request to update openssl to 1.1 is here:

https://trac.macports.org/ticket/52101

The difficulty seems to be that openssl 1.1 has backward-incompatible changes, 
so old software written in the days of openssl 1.0 or earlier might not work. 
We will need to identify which ports fall into that category. Then we can 
either fix all that old software to be openssl 1.1-compatible, or keep an old 
copy of openssl 1.0 around and make all the old software use that.

If we go the latter route, openssl 1.0 would need to install to a different 
location than openssl 1.1, and it's worth considering that we have an existing 
request to have that kind of nonconflicting behavior with openssl and libressl 
and other similar libraries, so perhaps it's worth coming up with a solution 
that works for all of them.

https://trac.macports.org/ticket/54744

openSSL

[pagani laurent via macports-users]

I just upgraded my MacPort install and OpenSSL is 1.0.2q while my VPN 
application would like to use 1.1.1.
Is there any chance that v1.1.1 be uploaded to MacPort sometimes soon ? (easier 
to ask than to do, I know, thanks for all those of you who spend their time 
making MacPort a useful service)

Laurent

"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise Shadok)

Re: OpenSSL 1.1?

[mf2k]

> On Jul 11, 2018, at 12:40 PM, Jim Hu  wrote:
> 
> I saw some old issue tracker items about this… is OpenSSL to 1.1 going to 
> happen anytime soon?
> 
> My campus IT security people keep complaining even though I have 1.02o set to 
> strong ciphers.

The update request ticket is stalled. 

https://trac.macports.org/ticket/52101 <https://trac.macports.org/ticket/52101>


Cheers!
Frank

OpenSSL 1.1?

[Jim Hu]

I saw some old issue tracker items about this… is OpenSSL to 1.1 going to 
happen anytime soon?

My campus IT security people keep complaining even though I have 1.02o set to 
strong ciphers.

Thanks

Re: OpenSSL with option enable-tlsext

[Clemens Lang]

On September 23, 2017 10:16:47 PM GMT+02:00, Bill Christensen 
 wrote:
>That's exactly what I was trying to find out.
>
>For some reason it's not working for me,  and I'm trying to figure out
>why.

Can you explain what you're trying and what outcome you would expect? That 
might allow me to pinpointing what's wrong.

Hi, 
-- 
Clemens Lang

Re: OpenSSL with option enable-tlsext

[Bill Christensen]

On Sat, Sep 23, 2017 at 2:47 PM, Clemens Lang <c...@macports.org> wrote:

> Hi,
>
> On Fri, Sep 22, 2017 at 02:21:13AM +, Bill Christensen wrote:
> > Does OpenSSL install with the enable-tlsext extension, or do I need to
> > do something special to get that to kick in?
>
> If you're asking whether our version of OpenSSL supports Server Name
> Indication, the answer is yes.
>
> --
> Clemens
>

That's exactly what I was trying to find out.

For some reason it's not working for me,  and I'm trying to figure out why.

Would you be willing to help me troubleshoot offlist?

Re: OpenSSL with option enable-tlsext

[Clemens Lang]

Hi,

On Fri, Sep 22, 2017 at 02:21:13AM +, Bill Christensen wrote:
> Does OpenSSL install with the enable-tlsext extension, or do I need to
> do something special to get that to kick in?

If you're asking whether our version of OpenSSL supports Server Name
Indication, the answer is yes.

-- 
Clemens

Re: Trouble upgrading openssl

[mf2k]

> On Mar 8, 2017, at 7:39 AM, Dan D. <dandun...@gmail.com> wrote:
> 
> I have been trying to upgrade openssl because another port upgrade needs
> it.  Each time I try to upgrade opensll I get this:
> 
> Password:--->  Computing dependencies for openssl
> --->  Staging openssl into destroot
> Error: Failed to destroot openssl: error copying 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_openssl/openssl/work/destroot"
>  to 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_openssl/openssl/work/destroot-x86_64/destroot":
>  file already exists
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_openssl/openssl/main.log
> 
> for details.
> 
> I cann't uninstall/install because several ports use it.
> 
> Any ideas?

clean it and try again. 

sudo port clean openssl


Cheers!
Frank