openssh bugs - Aug 2020 - [Bug 3205] New: Support HPE NonStop Server Port

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

            Bug ID: 3205
           Summary: Support HPE NonStop Server Port
           Product: Portable OpenSSH
           Version: 8.3p1
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Build system
          Assignee: unassigned-bugs at mindrot.org
          Reporter: rsbecker at nexbridge.com

I am working on updating the port for HPE NonStop Itanium and x86 (Big
Endian) platforms. I would like to contribute the changes, once
working, to the main repository for inclusion into the code base.

For reference, I have been maintaining the openssh-portable port for
both platforms through 7.6p1 using OpenSSL 1.0.2. The port for OpenSSL
1.1.1 was just completed and this has enabled me to bring the port up
to date. There are a few changes needed based on configure not handling
some situations but mostly the key difference is that ROOT is 65535 not
0 on this platform. The compiler we have to use is c99 but can upgrade
to c11 or higher in about 3 years when the Itanium platform is
deprecated.

The team I work on is called ITUGLIB and maintain many of the critical
Open Source ports for the platform.

Is this contribution desired?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
Our general policy is that we'll support something as long as someone
is willing to do the work, and that the changes involved don't
compromise support for modern platforms.  It sounds like you're willing
to do the work, so the other question is how invasive the required
changes are.  

Can you share the existing port or the diff against the stock code of
the same vintage?  It doesn't have to be polished, I just want to get a
sense for what's involved.
> x86 (Big Endian)
I didn't know that was even possible.
> The compiler we have to use is c99
right now all of the code (with the exception of some of the
experimental post-quantum stuff not compiled by default) is c89 for
maximum portability so c99 is fine.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

--- Comment #2 from Randall S. Becker <rsbecker at nexbridge.com> ---
We went to c99 because some of the constructs in the regression suite
do not compile with c89. I don't mind going back to c89 but there will
be a larger set of changes.

I'll share a patch listing here once I get this compiling correctly.

Note: the Big-Endian part has worked since 6.x - does not seem to take
any specific mods to get that working.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

--- Comment #3 from Randall S. Becker <rsbecker at nexbridge.com> ---
One thing that has me confused:

cc -c99   -I. -I. -I/usr/local-ssl1.1/include -Wnowarn=262,1252
-I/usr/local-ssl1.1/include -DSSHDIR=\"/usr/local-ssl1.1/etc\"
-D_PATH_SSH_PROGRAM=\"/usr/local-ssl1.1/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local-ssl1.1/libexec/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/usr/local-ssl1.1/libexec/sftp-server\"
-D_PATH_SSH_KEY_SIGN=\"/usr/local-ssl1.1/libexec/ssh-keysign\"
-D_PATH_SSH_PKCS11_HELPER=\"/usr/local-ssl1.1/libexec/ssh-pkcs11-helper\"
-D_PATH_SSH_SK_HELPER=\"/usr/local-ssl1.1/libexec/ssh-sk-helper\"
-D_PATH_SSH_PIDDIR=\"/var/run\"
-D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -fPIC
-shared
-o regress/misc/sk-dummy/sk-dummy.so regress/misc/sk-dummy/sk-dummy.lo
regress/misc/sk-dummy/fatal.lo ed25519.lo hash.lo ge25519.lo fe25519.lo
sc25519.lo verify.lo \
    -L. -Lopenbsd-compat -lopenbsd-compat -L. -Lopenbsd-compat/
-L/usr/local-ssl1.1/lib -L/usr/local-ssl1.1/lib  -lcrypto -lz
c99: error: Invalid input file
extension"regress/misc/sk-dummy/sk-dummy.lo".
c99: error: Invalid input file
extension"regress/misc/sk-dummy/fatal.lo".
c99: error: Invalid input file extension"ed25519.lo".
c99: error: Invalid input file extension"hash.lo".
c99: error: Invalid input file extension"ge25519.lo".
c99: error: Invalid input file extension"fe25519.lo".
c99: error: Invalid input file extension"sc25519.lo".
c99: error: Invalid input file extension"verify.lo".

I'm not sure how to fix this in your build structure.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

--- Comment #4 from Randall S. Becker <rsbecker at nexbridge.com> ---
Created attachment 3443
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3443&action=edit
Git diff for patches associated with the NonStop port

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
(In reply to Randall S. Becker from comment #3)
> One thing that has me confused:
> 
> cc -c99   -I. -I. -I/usr/local-ssl1.1/include -Wnowarn=262,1252
> -I/usr/local-ssl1.1/include -DSSHDIR=\"/usr/local-ssl1.1/etc\"
> -D_PATH_SSH_PROGRAM=\"/usr/local-ssl1.1/bin/ssh\"
> -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local-ssl1.1/libexec/ssh-
> askpass\"
> -D_PATH_SFTP_SERVER=\"/usr/local-ssl1.1/libexec/sftp-server\"
> -D_PATH_SSH_KEY_SIGN=\"/usr/local-ssl1.1/libexec/ssh-keysign\"
> -D_PATH_SSH_PKCS11_HELPER=\"/usr/local-ssl1.1/libexec/ssh-pkcs11-
> helper\"
> -D_PATH_SSH_SK_HELPER=\"/usr/local-ssl1.1/libexec/ssh-sk-helper\"
> -D_PATH_SSH_PIDDIR=\"/var/run\"
> -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -fPIC
> -shared -o regress/misc/sk-dummy/sk-dummy.so
> regress/misc/sk-dummy/sk-dummy.lo regress/misc/sk-dummy/fatal.lo
> ed25519.lo hash.lo ge25519.lo fe25519.lo sc25519.lo verify.lo \
>     -L. -Lopenbsd-compat -lopenbsd-compat -L. -Lopenbsd-compat/
> -L/usr/local-ssl1.1/lib -L/usr/local-ssl1.1/lib  -lcrypto -lz
> c99: error: Invalid input file
> extension"regress/misc/sk-dummy/sk-dummy.lo".
> c99: error: Invalid input file
> extension"regress/misc/sk-dummy/fatal.lo".
> c99: error: Invalid input file extension"ed25519.lo".
> c99: error: Invalid input file extension"hash.lo".
> c99: error: Invalid input file extension"ge25519.lo".
> c99: error: Invalid input file extension"fe25519.lo".
> c99: error: Invalid input file extension"sc25519.lo".
> c99: error: Invalid input file extension"verify.lo".
> 
> I'm not sure how to fix this in your build structure.
these .lo files are identical to their .o counterparts except they were
compiled with -fPIC for linkage into a shared object (.so) for use by
dlopen(3). If your system is not going to use client-side FIDO security
key support, then it's fine to simply skip this (--disable-security-key
at configure time, though possibly we need some makefile surgery too)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

--- Comment #6 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Damien Miller from comment #5)
[...]
> these .lo files are identical to their .o counterparts except they
> were compiled with -fPIC for linkage into a shared object (.so) for
> use by dlopen(3).
There's a similar problem with AIX, which has an, err, interesting
linker.  The traditional solution to this is libtool, but that AFAICT
that'd require overhauling the entire build system.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

--- Comment #7 from Randall S. Becker <rsbecker at nexbridge.com> ---
AFAIK (and have tested) c89,c99 do not support .lo files on input. This
is a gcc extension for -fPIC files. For c89, -fPIC still generates .o
files and accepts PIC .o files on input when building .so DLLs.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
These are just .o files with a different name to distinguish them. Is
c99 refusing the accept them because of the name?

Anyway, I agree with Darren here - turning off FIDO support is the best
way to work around this, unless you really want to be using FIDO keys
in a HPE NonStop ssh client (I'm pretty sure turning this options off
doesn't stop their use on the server side)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

--- Comment #9 from Randall S. Becker <rsbecker at nexbridge.com> ---
As of the most recent version of the operating system (L24.08), the c99
compiler has been upgraded to support .lo, so this can be closed.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3205

Randall S. Becker <rsbecker at nexbridge.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #10 from Randall S. Becker <rsbecker at nexbridge.com> ---
No fix is required. Resolved.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.