[MacPorts] #59397: openssh @8.1_1: fails to build on 10.6: audit-bsm.c:66:10: fatal error: 'bsm/audit_session.h' file not found

[MacPorts]

#59397: openssh @8.1_1: fails to build on 10.6: audit-bsm.c:66:10: fatal error:
'bsm/audit_session.h' file not found
-------------------------+----------------------------------------
  Reporter:  grumpybozo  |      Owner:  Ionic
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.1
Resolution:  fixed       |   Keywords:  snowleopard lion legacy-os
      Port:  openssh     |
-------------------------+----------------------------------------

Comment (by Ionic):

 Replying to [comment:36 iEFdev]:
 > It installed fine. Made a testkey with ssh-keygen and was then about to
 add the key with ssh-add.
 >
 > [...]
 >
 > So, it didn't want to add the key. It just returned the list of options.
 >
 > But the output looks ok, with `-A, -K [-d]` included.

 Whoops, yes, it looks like I missed a few hunks in `ssh-add.c`, especially
 the keychain disabling/enabling bit, so it's always disabled currently.
 The `-A`/`-K` options likewise aren't handled at all.

 Will need to fix that up at some point. My machine just crashed, though,
 so I won't do it right away.

 [[br]]

 > I could ssh/login to a webhost, and push with git, run a backupscript
 (rsync) - so it seems like it can read the keychain anyway.

 That highly depends on where the key is coming from. If it came via ssh-
 agent, then that only tells us that the running ssh-agent either has the
 key already cached or can read the keychain. The running ssh-agent is
 typically the Apple-/system-provided one, though, and not the one
 installed via MacPorts, so this would be testing something completely
 different. If the key came from a file directly, neither an agent nor the
 keychain would have been involved either (maybe minus a passphrase stored
 within the keychain, iff the private key was encrypted).

 [[br]]

 > Notice 1: The man pages… The output is different between, `man ssh-add`
 and if you open it in a separate window (like: `open x-man-page://ssh-
 add`). Both with same date in the bottom (Oct 26, 2019). That was odd, or
 does the man pages use a dynamic date value (todays date)? ...like it's
 loading an old cached one with current date added.

 Hm, I can't tell right now. `man` itself shouldn't be caching anything as
 far as I remember, but I don't know what `open` does with an `x-man-page`
 URL.

 Today's date isn't surprising, because that's when the man page was built.
 So at least that should be normal. It should, theoretically, be different
 tomorrow.

 [[br]]

 > Notice 2: I saw briefly duing the config/build that the process creates
 a folder with a symlink: `../work/include/security`. It looks like a dead
 symlink. When looking at it, it symlinks to `/usr/include/pam`:
 >
 > [...]
 >
 > There's nothing named `*pam*` in `/usr/include`, but there is a
 `/usr/include/security` folder which includes the pam files.
 >
 > Perhaps there are different locations in different OS X/macOS versions?
 >
 > // Don't know if that one is important or not, but thought I should
 mention it (as a notice).

 Good catch. We've been dragging this symlink around for quite some time
 now. According to the Portfile comments, it sounds like PAM stuff was
 located in `/usr/include/pam` on (some?) OS X versions, instead of the
 more-standard `/usr/include/security` directory.

 I can't reproduce that on 10.9 though, and if even 10.7 uses
 `/usr/include/security`, there's probably no sense in keeping that around.
 Not sure about 10.6 and specifically 10.5 and 10.4, though. Apple might
 have moved things to `security` with 10.6 or something like that.

 But, yes, that shouldn't cause any problems.

-- 
Ticket URL: <https://trac.macports.org/ticket/59397#comment:37>
MacPorts <https://www.macports.org/>
Ports system for macOS