Re: OpenSSH 5.1: call for testing - openssh

This is a discussion on Re: OpenSSH 5.1: call for testing - openssh ; On Jul 9 00:18, Damien Miller wrote: > On Mon, 7 Jul 2008, Corinna Vinschen wrote: > > > Other than that: > > > > - session.c, line 427: > > > > #define USE_PIPES > > > > ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: OpenSSH 5.1: call for testing

  1. Re: OpenSSH 5.1: call for testing

    On Jul 9 00:18, Damien Miller wrote:
    > On Mon, 7 Jul 2008, Corinna Vinschen wrote:
    >
    > > Other than that:
    > >
    > > - session.c, line 427:
    > >
    > > #define USE_PIPES
    > >
    > > Is that planned or just left over fomr some test?

    >
    > No, that is planned. We now unconditionally use pipes for communicating
    > with the session subprocesses because they seem to give better semantics
    > for half-closed channels (cf. https://bugzilla.mindrot.org/b/85).


    Ok. Given that USE_PIPES is now only used in sftp.c, wouldn't it
    be easier now to always use pipes, even in sftp.c? That would drop
    the whole test and a bunch of conditional code.

    > > - The following testcases fail on Cygwin 1.5.25:
    > >
    > > - addrmatch.sh tries to run IPv6 tests even though IPv6 is not
    > > available.

    >
    > I'm not sure of a good way to determine at runtime whether IPv6 is
    > available on a platform. Perhaps these tests should be disabled in
    > portable or made non-fatal.


    Ack. Unfortunately `ssh -6' falls silently back to IPv4 instead of
    complaining on platforms not supporting IPv6. Complaining would allow
    to use this as a test.


    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: OpenSSH 5.1: call for testing

    On Jul 17 18:56, Darren Tucker wrote:
    > Corinna Vinschen wrote:
    > > On Jul 17 07:39, Damien Miller wrote:
    > >> On Wed, 16 Jul 2008, Corinna Vinschen wrote:
    > >>
    > >>> Ping?
    > >> This will be post-5.1.

    > >
    > > Too bad. That means that 5.1 will not run on Cygwin 1.7 without local
    > > patch.

    >
    > In that case I think we should put it in now. It affects cygwin only
    > and you're in the best position to know what the impact is.


    Even better, I'm in the position to know how embarrassing it is that I
    haven't provided this patch already years ago.

    pathconf(_PC_POSIX_PERMISSIONS) exists for seven years and has been
    designed for exactly the same purpose as the check_ntsec() function
    in OpenSSH. Oh well...

    > >> This will be post-5.1. Could you file is as a bug so it doesn't get lost?

    > >
    > > Ok, will do.
    > >
    > > What about my question:
    > >
    > >>>> Another question is this: The has_capability function requests Cygwin
    > >>>> version information to figure out if specific features are available.
    > >>>> The newest of the requested capabilities exists since Cygwin 1.5.0,
    > >>>> which has been release in 2003, five years ago. Older versions of
    > >>>> Cygwin are long out of support. That's why I would like to ask, if it
    > >>>> isn't time to drop the whole has_capability() function as well as the
    > >>>> check_nt_auth() function and to remove calling this Cygwin-specific
    > >>>> function throughout OpenSSH. Right now it's called in auth1.c,
    > >>>> auth2-pubkey.c, auth2-passwd.c, auth2-none.c and auth2-kbdint.c.
    > >>>> That's a lot of #ifdef HAVE_CYGWIN which could go away

    > >
    > > Is that also ok for post-5.1?

    >
    > If it removes ifdefs and doesn't break anything other than
    > long-unsupported cygwin then it sounds good to me.


    That's the idea


    Thanks,
    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread