openssh @9.3p1_1 Nearly all client programs crash with Segmentation Fault.

[snowflake (Dave Evans)]

The crash is immediate. It is affecting keychain.

Attempting to put ssh-agent into diagnostic mode with

ssh-agent -dD

results in an immediate crash.

I will attach the Diagnostic Report

[snowflake (Dave Evans)]

Diagnostic Report

[elventear (Pepe Barbe)]

ssh also crashes for me. Is this related to the recent update to OpenSSL ​here and ​here?

[elventear (Pepe Barbe)]

I just rolled back openssh but kept the OpenSSL updates and the crash is gone.

[snowflake (Dave Evans)]

Tested on Ventura x86_64 = both ssh and ssh-agent crash.

On El Capitan both are OK

[elventear (Pepe Barbe)]

I am on 13.4 x86_64 also.

[snowflake (Dave Evans)]

Replying to elventear:

I am on 13.4 x86_64 also.

All the ssh-* client programs crash except ssh-keyscan

[snowflake (Dave Evans)]

Almost a full house: sftp and scp crash as well

[elventear (Pepe Barbe)]

Building from source generates a client that crashes. Tried downgrading OpenSSL and rebuilding from source and it crashed also. Wondering if its a compiler problem?

[snowflake (Dave Evans)]

Replying to elventear:

Building from source generates a client that crashes. Tried downgrading OpenSSL and rebuilding from source and it crashed also. Wondering if its a compiler problem?

Implicit declaration perhaps? They potentially break compilations on newer macOS

[elventear (Pepe Barbe)]

Rebuilt 9.3p1_1+fido2+kerberos5+ldns+xauth from source forcing gcc to be the compiler and the crashes are gone.

[artkiver (グレェ)]

Thanks for reporting this!

As elventear speculated, I think this is related to the PR ​https://github.com/macports/macports-ports/pull/18879 which neverpanic merged with a revision increment to cause OpenSSH to rebuild relative to OpenSSL yesterday.

I attempted to reassign it for the time though I thought Trac had a way to CC people on issues, I am not seeing that option presently. Unfortunately, it seems as if I do not have sufficient permissions to reassign the ticket either.

Locally:

% ssh -V
OpenSSH_9.3p1, LibreSSL 3.8.0

% ssh-agent -dD
usage: ssh-agent [-c | -s] [-Dd] [-a bind_address] [-E fingerprint_hash]
                 [-O option] [-P allowed_providers] [-t life]
       ssh-agent [-a bind_address] [-E fingerprint_hash] [-O option]
                 [-P allowed_providers] [-t life] command [arg ...]
       ssh-agent [-c | -s] -k

 % ssh-keygen 
Generating public/private rsa key pair.
^C

So, speculatively, if building against libressl or libressl-devel I am guessing OpenSSH is still OK and this is more related to the TLS library choice?

However, the compiler workaround is also fascinating, at least locally I am typically using llvm-devel or llvm-16 on my laptops so I am thinking that may be another potential alternative to test if gcc isn't desired?

I had been testing some things related to a different issue (specifically for the kerberos5 variant which is presently broken with LibreSSL mentioned in this: ​https://trac.macports.org/ticket/67442#comment:11) and had planned to add a "conflicts libressl" to that variant after getting a response from the individual who had filed it, though I have had half a mind to augment the Portfile similar to the modifications made to rpki-client to attempt to auto-detect which TLS library may already be installed and default to LibreSSL if none had previously been used (which is more in alignment with what macOS ships as well as the upstream non -portable branch of OpenSSH); but just because my present setups can't replicate these errors, doesn't mean there may not be some other ways to address it!

Unfortunately, I probably won't have much opportunity to look at this again until tomorrow, but I wanted to at least reply with some preliminary perspective and hopefully Clemens may be able to provide some additional insights!

[elventear (Pepe Barbe)]

Replying to artkiver:

As elventear speculated, I think this is related to the PR ​https://github.com/macports/macports-ports/pull/18879 which neverpanic merged with a revision increment to cause OpenSSH to rebuild relative to OpenSSL yesterday.

I did roll back openssl11 and openssl3 to a version pre-​PR and tried to build from source and that also generated a crashing client. That is why I speculated that it could be the compiler.

[neverpanic (Clemens Lang)]

Could somebody start this in lldb and generate a backtrace? That would maybe help us pinpoint where the issue is.

[neverpanic (Clemens Lang)]

Okay, this is weird. I can reproduce this with openssh @9.2p1_1 built from source, openssh @9.3p1_1 built from source against OpenSSL 3.1.1, but not openssh @9.2p1_1 downloaded from the buildbots when used with OpenSSL 3.1.1.

If I revert to OpenSSL 3.1.0 and rebuild openssl @9.3p1_1 from source, that also crashes.

This makes me think the problem isn't OpenSSL, but the recompilation. Maybe actually an issue with the generated binary?

The backtrace looks like something very early, potentially while loading the binary or its libraries. The backtrace is in the ssh binary, though, so this is very likely not related to OpenSSL:

:) cllang@cllang-mac:/opt/dports/net/openssh$ lldb /opt/local/bin/ssh
(lldb) target create "/opt/local/bin/ssh"
Current executable set to '/opt/local/bin/ssh' (x86_64).
(lldb) run -V
Process 49916 launched: '/opt/local/bin/ssh' (x86_64)
Process 49916 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007ff8027dda82 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 194
libsystem_platform.dylib`:
->  0x7ff8027dda82 <+194>: movb   (%rsi,%r8), %cl
    0x7ff8027dda86 <+198>: movb   %cl, (%rdi,%r8)
    0x7ff8027dda8a <+202>: subq   $0x1, %rdx
    0x7ff8027dda8e <+206>: je     0x7ff8027ddaa4            ; <+228>
Target 0: (ssh) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007ff8027dda82 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 194
    frame #1: 0x000000010006ec66 ssh`___lldb_unnamed_symbol1199 + 36
    frame #2: 0x0000000100004470 ssh`___lldb_unnamed_symbol412 + 368
    frame #3: 0x00007ff80245941f dyld`start + 1903

[neverpanic (Clemens Lang)]

The latest versions compiled with macports clang 15 work.

[hexadecagram ({16/7})]

If I git switch -d 3aac0fe~ and build with clang 15, I have an ssh that does not crash.

[snowflake (Dave Evans)]

The latest version of openssh compiled with macports-clang-devel and macports-clang-14 also work.

clang-mp-14 --version    
clang version 14.0.6
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-14/bin

clang-mp-devel --version
clang version 17.0.0
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-devel/bin

Here's Apple clang:
clang --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Here is mpstats show
"os": {
    "macports_version": "2.8.99",
    "osx_version": "13",
    "os_arch": "i386",
    "os_platform": "darwin",
    "build_arch": "x86_64",
    "cxx_stdlib": "libc++",
    "gcc_version": "none",
    "xcode_version": "14.2",
    "clt_version": "14.3.0.0.1.1679647830"
  },

and sw_vers
sw_vers
ProductName:		macOS
ProductVersion:		13.4
BuildVersion:		22F66

[snowflake (Dave Evans)]

I build ssh with debugging symbols with Apple Clang 14 and got this:

Process 87087 launched: '/opt/local/var/macports/build/_Users_davidevans_macports_sources_github.com_macports_macports-ports_net_openssh/openssh/work/openssh-9.3p1/ssh' (x86_64)
Process 87087 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007ff819b39a82 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 194
libsystem_platform.dylib`:
->  0x7ff819b39a82 <+194>: movb   (%rsi,%r8), %cl
    0x7ff819b39a86 <+198>: movb   %cl, (%rdi,%r8)
    0x7ff819b39a8a <+202>: subq   $0x1, %rdx
    0x7ff819b39a8e <+206>: je     0x7ff819b39aa4            ; <+228>
Target 0: (ssh) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007ff819b39a82 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 194
    frame #1: 0x000000010006daf6 ssh`pwcopy(pw=0x0000600003308020) at misc.c:462:18 [opt]
    frame #2: 0x0000000100003300 ssh`main(ac=<unavailable>, av=0x0000600000008010) at ssh.c:678:7 [opt]
    frame #3: 0x00007ff8197b541f dyld`start + 1903
(lldb) up
warning: ssh was compiled with optimization - stepping may behave oddly; variables may not be available.
frame #1: 0x000000010006daf6 ssh`pwcopy(pw=0x0000600003308020) at misc.c:462:18 [opt]
   459 	{
   460 		struct passwd *copy = xcalloc(1, sizeof(*copy));
   461 	
-> 462 		copy->pw_name = xstrdup(pw->pw_name);
   463 		copy->pw_passwd = xstrdup(pw->pw_passwd == NULL ? "*" : pw->pw_passwd);
   464 	#ifdef HAVE_STRUCT_PASSWD_PW_GECOS
   465 		copy->pw_gecos = xstrdup(pw->pw_gecos);
(lldb) 

[neverpanic (Clemens Lang)]

So essentially pw->pw_name (or the allocated buffer, but as I understand xmalloc, that would have caused exit(1) to be called) is NULL in ​https://github.com/openssh/openssh-portable/blob/V_9_3/misc.c#L457-L462 when called from ​https://github.com/openssh/openssh-portable/blob/V_9_3/ssh.c#L671-L678, which means that getpwuid() would have returned a struct with a NULL member, but only when compiled with Apple clang.

That seems unlikely. I also can't reproduce it with a minimal example:

:) cllang@cllang-mac:~$ cat test.c
#include <pwd.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <uuid/uuid.h>

int main(int argc, char *argv[]) {
	struct passwd *pw = getpwuid(getuid());
	fprintf(stderr, "pw->pw_name = %s\n", pw->pw_name);
}
:) cllang@cllang-mac:~$ clang -std=c99 -Wall -Werror -pedantic -o test test.c
:) cllang@cllang-mac:~$ ./test
pw->pw_name = cllang

[snowflake (Dave Evans)]

It could be an optimisation problem.

The source code looks perfectly reasonable to me.

I turned optimisation off with cflags and cppflags set to -g -O0 in the portfile and built using Apple clang. Testing in the build directory with ./ssh did not crash and showed the usual help message. ./ssh-agent also worked.

I don't have an explanation as to why it has all worked up to now.

[snowflake (Dave Evans)]

On Ventura 13.4, installing the latest Xcode did not solve the problem.

File: Xcode_14.3.1_Release_Candidate.xip

Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[neverpanic (Clemens Lang)]

The buildbot didn't build this update (potentially with an older Xcode installed on the buildbots) because the delivery of the GitHub webhook to the build servers failed. I've re-delivered them now, and the build is running at ​https://build.macports.org/builders/ports-13_x86_64-watcher/builds/7777. If we're lucky, this will produce binaries that work, and everybody can install those for now (but that doesn't solve the original problem, which seems to be compiler-related).

[snowflake (Dave Evans)]

Tbe buildbot is producing broken binaries with the seg fault.

/opt/local/bin/ssh is dated 1 June 15:38 UTC. I was not working on my computer at that time.

[neverpanic (Clemens Lang)]

I can confirm that the binaries produced by the buildbot crash. At this point, I think we should blacklist Apple clang, at least on Ventura.

[hexadecagram ({16/7})]

Replying to snowflake:

On Ventura 13.4, installing the latest Xcode did not solve the problem.

File: Xcode_14.3.1_Release_Candidate.xip

Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I have a second machine and after a fresh port selfupdate, sync, and upgrade -u outdated, I attempted to build the same commit that I mentioned here: ​https://trac.macports.org/ticket/67539?replyto=22#comment:16

This time around, I forgot to port select --set clang mp-clang-15 before attempting the build (or port select --set llvm to anything but none for that matter). So I am running Apple clang 14.0.3, with --version producing the same as quoted above and xcodebuild -version producing:

Xcode 14.3
Build version 14E222a

Under this configuration, port build produced an ssh binary which does not segfault.

[neverpanic (Clemens Lang)]

Replying to hexadecagram:

I have a second machine and after a fresh port selfupdate, sync, and upgrade -u outdated, I attempted to build the same commit that I mentioned here: ​https://trac.macports.org/ticket/67539?replyto=22#comment:16

This time around, I forgot to port select --set clang mp-clang-15 before attempting the build (or port select --set llvm to anything but none for that matter). So I am running Apple clang 14.0.3, with --version producing the same as quoted above and xcodebuild -version producing:

port select --set clang mp-clang-15 does not affect which compiler MacPorts uses to build ports. The port select mechanism is solely for your convenience as user.

Xcode 14.3
Build version 14E222a

Under this configuration, port build produced an ssh binary which does not segfault.

Interesting. I have the same clang version, but Xcode version says

Xcode 14.3
Build version 14E222b

and I get broken versions. It is possible that the build version of Xcode makes the difference here?

[elventear (Pepe Barbe)]

For me xcodebuild -version returns:

  Xcode 14.3
  Build version 14E222b

[elventear (Pepe Barbe)]

I got a new release today.

Xcode 14.3.1
Build version 14E300c

[artkiver (グレェ)]

I'm grateful Clemens was at least able to narrow this down to perhaps the build bots'? Especially since I don't have any privileges within that part of MacPorts. I haven't been able to reproduce it locally either.

For reference, here is my output of xcodebuild -version:

Xcode 14.3
Build version 14E222b

I did see an Xcode command line tools update yesterday, but I couldn't say whether that may be related.

This does have me wondering if this was perhaps related to the issues encountered in this issue as well: ​https://trac.macports.org/ticket/67442

[snowflake (Dave Evans)]

@artkiver Are you on arm(M1, M2)? All my crashes relate to x86_64. I'm not setting any openssh variants.

Test1: - Crashes
Command Line Tools version: 14.3.1.0.1.1683849156
    This was updated yesterday or Thursday.
clang --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Test 2: - crashes
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
  Target: x86_64-apple-darwin22.5.0
  Thread model: posix
  InstalledDir: 
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
xcodebuild -version
  Xcode 14.3.1 (installed from Release Candidate)
  Build version 14E300b

[artkiver (グレェ)]

As referenced in ​https://trac.macports.org/ticket/67442 I am not experiencing segfaults on Intel or Apple Silicon, either with LibreSSL (my preference) or with OpenSSL.

Replying to snowflake:

@artkiver Are you on arm(M1, M2)? All my crashes relate to x86_64. I'm not setting any openssh variants.

Test1: - Crashes
Command Line Tools version: 14.3.1.0.1.1683849156
    This was updated yesterday or Thursday.
clang --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Test 2: - crashes
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
  Target: x86_64-apple-darwin22.5.0
  Thread model: posix
  InstalledDir: 
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
xcodebuild -version
  Xcode 14.3.1 (installed from Release Candidate)
  Build version 14E300b

[piru (Harry Sintonen)]

This issue is caused by Xcode clang being affected by ​https://github.com/llvm/llvm-project/issues/57692

Some more details in ​https://infosec.exchange/@harrysintonen/110508989501024969

[artkiver (グレェ)]

Ah wow, good catch! I doubt I would have noticed that.

So, it seems to me that @neverpanic's suggestion to blacklist Apple's clang/xcode is probably the correct way to handle this?

Do we know which version is providing the buggy version is to avoid? I noticed Apple issued an XCode update since this issue was opened, since that update I have the following output:

%xcodebuild -version 
Xcode 14.3.1
Build version 14E300c

Replying to piru:

This issue is caused by Xcode clang being affected by ​https://github.com/llvm/llvm-project/issues/57692

Some more details in ​https://infosec.exchange/@harrysintonen/110508989501024969

[piru (Harry Sintonen)]

Do we know which version is providing the buggy version is to avoid?

At least the following versions are affected:

Xcode 14.3
Build version 14E222b
Xcode 14.3.1
Build version 14E300c

I suppose one way to handle this would be to avoid use of -fzero-call-used-regs=all if buggy clang versions are detected. However, this is not great as you'd lose the anti-ROPchain-gadget protection zero-call-used-regs provides.

[piru (Harry Sintonen)]

While at it I also developed a quick runtime test. It's a bit crude but works.

#include <string.h>
#include <stdlib.h>

__attribute__((noinline)) void *mymalloc(size_t l)
{
        return malloc(l);
}

__attribute__((noinline)) int dummy(void *a, const void *b, size_t c)
{
        return !a || !b || !c;
}

__attribute__((noinline)) int test(char *s)
{
        size_t l = strlen(s) + 1;
        void *p = mymalloc(l);
        return dummy(p, s, l);
}

int main(void)
{
        return test("a");
}

To test:

clang --target=x86_64-apple-darwin-macho -fzero-call-used-regs=all -O1 -o x x.c && ./x && echo "clang ok"

It depends highly on specifics of the clang internals, such as register allocation etc. So it is not guaranteed to work in every situation. However, at worst it will report false negative, i.e. not detect a buggy clang.

[piru (Harry Sintonen)]

Finally, a friend pointed out a much simpler way to test this (which doesn't involve code execution):

(echo "int dummy() { return 0; }" | clang --target=x86_64-apple-darwin-macho -fzero-call-used-regs=all -O1 -x c -S -o - - | grep -q "xor.*r14") || echo "clang ok"

[danielluke (Daniel J. Luke)]

If the 'best' version of fixing this is going to take some time, could we please require macports clang so that people with affected systems can get a working port in the interim?

[artkiver (グレェ)]

I share your concerns.

Admittedly, I am not sure if it is quite so straight forward to require MacPorts' clang?

Currently the Portfile already has the following:

 compiler.blacklist-append   *gcc*     cc {clang < 421}

Meanwhile, reading ​https://trac.macports.org/wiki/UsingTheRightCompiler we could potentially use the compiler.whitelist to specify preferred compilers; however, piru's stipulation that the following versions of XCode are impacted, I haven't been able to replicate locally (presumably because this is only for Intel systems running Ventura? Whereas the only Intel systems I have at present are too old to be running that officially, and are using llvm16 or llvm-devel from MacPorts).

So the thought of blacklisting:

Xcode 14.3
Build version 14E222b
Xcode 14.3.1
Build version 14E300c

Wouldn't necessarily be a correct fix for Apple Silicon users either as far as I can discern?

Moreover, those versions do not seem to correspond to the sorts of parameters expected by ​https://github.com/macports/macports-base/blob/master/src/port1.0/portconfigure.tcl#L758 so the Xcode and Build versions, would need to be related to something which would be correctly parsed there first before I can meaningfully update the Portfile by expanding the blacklist.

The code snippet @piru provided as a heuristic makes me wonder if it would be able to utilize it similarly inspired by something I stumbled across here when trying to research others encountering issues which required compiler blacklisting: ​https://lists.macports.org/pipermail/macports-users/2017-March/043018.html (and the corresponding commit referenced therein: ​https://github.com/macports/macports-ports/commit/6fb35a1f2843454f08ef5027dfe0e3db59016d99 )

My apologies as I have not had much time to look into this more deeply. Moreover, I do not have sufficient resources to have even been able to replicate the issue, so attempting to test a potential fix from my vantage is somewhat problematic.

I've asked for an extra set of eyeballs on IRC as well, but it doesn't seem as if any human is presently active on there other than, so for the last half hour since my inquiry, it's just been mplog messages.

I'll forward this to the email list next and see if others have suggestions for how to move forward. There's a reason this Portfile is "openmaintainer" after all, I mostly just put myself down as I had been submitting PRs to update OpenSSH in alignment with upstream releases since 8.9p1 and had noticed no one else was really doing much to keep it spruced up.

In the interim, it seems as if the users impacted by this are a limited subset, and thankfully there are known workarounds such as using llvm/clang from MacPorts, though I concur: it would be preferable to have such things in the Portfile.

If anyone who has a system which is impacted by this, can try testing some of the suggestions and submitting a PR, that would be more than welcome.

Replying to danielluke:

If the 'best' version of fixing this is going to take some time, could we please require macports clang so that people with affected systems can get a working port in the interim?

[ryandesign (Ryan Carsten Schmidt)]

Since we apparently now have a test program to see if clang is broken in this way, I recommend someone install various versions of the ​Xcode command line tools, figure out the earliest broken version (clang -v), then add that to compiler.blacklist, along with increasing revision. If the blacklist addition need only apply to Apple Silicon or Intel systems, enclose the addition in a platform darwin arm or platform darwin i386 block, respectively.

[ryandesign (Ryan Carsten Schmidt)]

Or if we go by the llvm bug report which states that clang 15 is affected, then, according to ​Wikipedia, only Xcode 14.3 and 14.3.1 are based on clang 15, and the correct compiler.blacklist addition would be {clang >= 1403 < 1500}.

[artkiver (グレェ)]

Portfile rev2 with compiler.blacklist suggestions from ryandesign comment 43.

[artkiver (グレェ)]

Those both seem as if they are viable strategies. I've modified the Portfile slightly using the suggestions from comment 43.

It passed lint --nitpick OK, but I don't have an impacted system to test on currently, so if any of the individuals who reported and encountered the issue could try that Portfile to see if it rectifies the issue, it would be appreciated.

Thank you!

🙏

Replying to ryandesign:

Or if we go by the llvm bug report which states that clang 15 is affected, then, according to ​Wikipedia, only Xcode 14.3 and 14.3.1 are based on clang 15, and the correct compiler.blacklist addition would be {clang >= 1403 < 1500}.

[danielluke (Daniel J. Luke)]

Replying to artkiver:

Those both seem as if they are viable strategies. I've modified the Portfile slightly using the suggestions from comment 43.

It passed lint --nitpick OK, but I don't have an impacted system to test on currently, so if any of the individuals who reported and encountered the issue could try that Portfile to see if it rectifies the issue, it would be appreciated.

You put the additional blacklist inside of an if for os.major <= 11 so it doesn't get added on my 13.4 intel test box. I think you want something like:

+        } elseif {(${os.major} >= 13 && ${configure.build_arch} eq "x86_64")} {
+            compiler.blacklist-append   {clang >= 1403 < 1500}

I'm doing a build now with that and it's using clang-mp-15

[danielluke (Daniel J. Luke)]

Replying to danielluke:

I'm doing a build now with that and it's using clang-mp-15

That build finished and the clients I've tried all run fine.

[bK4gYuRo]

I can confirm that patch from ​https://trac.macports.org/ticket/67539#comment:45 worked fine on 13.4 intel box.

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_openssh/openssh/work/openssh-9.3p1/ssh -V
OpenSSH_9.3p1, LibreSSL 3.7.3

[artkiver (グレェ)]

Further modified Portfile with danielluke's suggestions for improvement.

[artkiver (グレェ)]

Thank you for the testing and reporting back! I have attached another Portfile with @danielluke's suggestions for improvement. If you could look that over and test that as well and let me know if it is working as intended then I'll prep a PR.

Additionally, I opened a RADAR with Apple so that they're aware of the buggy versions of llvm/clang they've been shipping with XCode so hopefully that will be rectified by them moving forward as well.

Thanks again to everyone involved in assisting in remediating this! I totally went down a wrong path thinking @neverpanic's OpenSSL revision may have been partially responsible, but that was clearly a red herring and doubtlessly wasted some time and energy in diagnosis.

Replying to SpikeLightfoot:

[danielluke (Daniel J. Luke)]

Replying to artkiver:

Thank you for the testing and reporting back! I have attached another Portfile with @danielluke's suggestions for improvement. If you could look that over and test that as well and let me know if it is working as intended then I'll prep a PR.

I suspect you want some WS for indentation on line 131, but I just ran a build with your updated Portfile and it looks good to me. (also, thanks for filing the bug report with Apple!)

[artkiver (グレェ)]

Ah, good recommendation. White space added!

More importantly though was word that the build you ran was OK!

I submitted a PR here:

​https://github.com/macports/macports-ports/pull/19061

The build bots/CI looks as if the checks ran OK. Hopefully this remediates the problems reported for now?

Thank you to everyone involved in for your patience, helpful research and suggestions and testing in this!

Replying to danielluke:

Replying to artkiver:

Thank you for the testing and reporting back! I have attached another Portfile with @danielluke's suggestions for improvement. If you could look that over and test that as well and let me know if it is working as intended then I'll prep a PR.

I suspect you want some WS for indentation on line 131, but I just ran a build with your updated Portfile and it looks good to me. (also, thanks for filing the bug report with Apple!)

[artkiver (グレェ)]

In a120a75a2a08eb553dfc6606771d3803c6c3bebd/macports-ports (master):

openssh: update compiler.blacklist-append to avoid segfault. (​https://github.com/macports/macports-ports/pull/19061)

• closes #67539
  • closes #67442

[snowflake (Dave Evans)]

+        } elseif {(${os.major} >= 13 && ${configure.build_arch} eq "x86_64")} {
+            compiler.blacklist-append   {clang >= 1403 < 1500}

Surely os.major is the Darwin version, according to section 5.2 of the Macports Guide, so the comparison should be with 22 for Ventura. As it happens it all works regardless.

[catap (Kirill A. Korinsky)]

Shall we blacklist clang-15 globaly because it may introduce a lot of issues?

Thus, the fix for this issue includes reverting tests: ​https://github.com/llvm/llvm-project/commit/b4309800e9dc53a84222a6b57c8615d4a3084988

So, behaviour was "expected"

[danielluke (Daniel J. Luke)]

Replying to snowflake:

Surely os.major is the Darwin version, according to section 5.2 of the Macports Guide, so the comparison should be with 22 for Ventura. As it happens it all works regardless.

That's right, we should probably fix this so we don't unnecessarily pull in mp-clang for systems that don't need it.

[artkiver (グレェ)]

So, to make sure I am understanding you correctly, you want the Portfile to instead have:

  } elseif {(${os.major} >= 22 && ${configure.build_arch} eq "x86_64")} {
+            compiler.blacklist-append   {clang >= 1403 < 1500}

I may be mistaken, but os.platform is where specifiers such as Darwin are in use? Though since to this commit, maybe we can use both? ​https://github.com/macports/macports-base/commit/3d9856bce89f46efd130ee52d02115582594ecaa So something along the lines of:

 } elseif {(${os.platforms {darwin any >= 22}  && ${configure.build_arch} eq "x86_64")} {
+            compiler.blacklist-append   {clang >= 1403 < 1500}

I am not sure if I got that right, I am more just writing it illustratively to see if I am understanding the requested change correctly.

Replying to danielluke:

Replying to snowflake:

Surely os.major is the Darwin version, according to section 5.2 of the Macports Guide, so the comparison should be with 22 for Ventura. As it happens it all works regardless.

That's right, we should probably fix this so we don't unnecessarily pull in mp-clang for systems that don't need it.

[danielluke (Daniel J. Luke)]

Replying to artkiver:

I may be mistaken, but os.platform is where specifiers such as Darwin are in use? Though since to this commit, maybe we can use both?

This if/elseif is inside a platform macosx block, so it's only executed on macosx hosts.

[danielluke (Daniel J. Luke)]

Replying to danielluke:

This if/elseif is inside a platform macosx block, so it's only executed on macosx hosts.

I've gone ahead and updated the os.major comparison to >=22 after verifying that it still picks mp-clang on my 13.4 box.

[artkiver (グレェ)]

constrain the compilers_blacklist with more granularity

[artkiver (グレェ)]

Thank you for testing that!

I've attached a Portfile with the requested change; if it looks good, I'll submit another PR.

Replying to danielluke:

Replying to danielluke:

This if/elseif is inside a platform macosx block, so it's only executed on macosx hosts.

I've gone ahead and updated the os.major comparison to >=22 after verifying that it still picks mp-clang on my 13.4 box.

[danielluke (Daniel J. Luke)]

Replying to artkiver:

Thank you for testing that!

I've attached a Portfile with the requested change; if it looks good, I'll submit another PR.

I already committed the change.

[artkiver (グレェ)]

Just for informational purposes, the issue I opened with Apple received the following feedback earlier today:

"Apple Jun 26, 2023 at 2:45 PM Please know that this is already fixed in Xcode 15 by an open source change: ​https://reviews.llvm.org/D133946 ."

XCode 15 is presently in beta, but it's good to know I guess?