similar to: bugtraq re: remote client address restriction circumvention

When we were porting OpenSSH on SX, we had similar problem. And when we did #undef HAVE_B64_NTOP in config.h, we faced linking problem as b64_pton() multiply defined, in base64.c and in libc.a. So we modified configure to check both the functions b64_pton() and b64_ntop(). But we gave priority to native function if available. Following are the diffs of three files we changed 1. configure (line

if i want to learn more about implementing a /dev/urandom, where would be a good place to start? thanks, wendy -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154

simon- any luck with that GSS-API patch for 3.6.1? ben/markus/whoever - will this ever be added to source? thanks, wendy -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154

do_pre_login() in session.c is used (in do_exec_pty()) before it's declared, which is causing some problems for me. please move it up a couple hundred lines in the file. patch included for 0807 snapshot. thanks, wendy % diff -u session.c.orig session.c.mod --- session.c.orig Tue Aug 7 13:11:51 2001 +++ session.c.mod Tue Aug 7 16:21:07 2001 @@ -397,6 +397,34 @@ } }

anyone who can help me understand- one of my developers reimported openssh snapshot from 0722 into cvs. he sent me the following email about an error he believes is in the snapshot i'm not a cvs-knowledgeable person, so i'm not all that clear on this, but should *.in files be in .cvsignore? i tried checking a later snapshot, but 0722 seems to be the latest one. .cvsignore is dated jun

we are encouraging the use of protocol 2 over protocol 1, correct? but ssh's default is that protocol 1 is tried first, then protocol 2. this can be overridden in the ssh_config file and by command line options, of course, but shouldn't we set the default to be what we want users to use? thanks, wendy -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com,

i have a site that needs to increase the socket buffer size. this is something i really don't know much about, myself. they need to increase it to at least 300k to get decent performance (specifically for scp). what is the current default & are there any known ramifications to increasing it? thanks, wendy -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com,

is anyone running, or advocating running openssh in combination with dce? what would be the concerns? on first glance, i'd say they shouldn't be run together, but i don't know enough about dce to be able to definitively state that. thanks, wendy -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154

memset has apparently been fixed in unicos afterall, or else the current code straightened out whatever was going wrong. i'm not sure what happened, but deattack.c changes are no longer necessary. i'm not going to look a gift horse in the mouth.... crays run great straight out of the box for 3.5p1 as released. sorry for the long delay in replying. porting my product to our new machine

X-PMC-CI-e-mail-id: 13726 Hi, I have been a successful user of Openssh for some time. I am attaching two articles from BugTraq. Hopefully, they show exactly the security problems reported in the BugTraq mailing list. [Pity that no one seemed to have bothered to contact the mailing list(s) for openssh development.] I am not sure what the right fixes would be. But at least, people need to be

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [This came over BUGTRAQ this morning. Note the call for volunteers vis-a-vis rssh.] - ----- Forwarded message from Jason Wies <jason at xc.net> ----- List-Id: <bugtraq.list-id.securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe at securityfocus.com> To: bugtraq at securityfocus.com Cc: rssh-discuss at

http://bugzilla.mindrot.org/show_bug.cgi?id=367 ------- Additional Comments From wendyp at cray.com 2002-07-23 08:38 ------- Created an attachment (id=134) cray patches ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=859 Summary: getaddrinfo(host, "0", &hints, &res) may take extra cycles Product: Portable OpenSSH Version: 3.8p1 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Miscellaneous

OpenSSH 3.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== - /etc/ssh/ now default

OpenSSH 3.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== - /etc/ssh/ now default

Good afternoon, On Fri, 2017-05-12 at 14:37 +0200, Michael Franzl wrote: > Using latest icecast, let's assume the following hosting scenario. (For the records: this applies to 2.4.x as well as current 2.5.x.) > We have 2 mountpoints which are configured with authentication callbacks: > > /mount1 > /mount2 > > Both mountpoints have configured the same fallback

Recent proftpd security vulnerability release FYI. Ports has latest patched proftpd distribution. -- Jez http://www.munk.nu/ -------------- next part -------------- An embedded message was scrubbed... From: Dave Ahmad <da@securityfocus.com> Subject: ISS Security Brief: ProFTPD ASCII File Remote Compromise Vulnerability (fwd) Date: Tue, 23 Sep 2003 10:25:54 -0600 (MDT) Size: 4588 Url:

Good evening, On Sat, 2017-05-13 at 16:11 +0200, Michael Franzl wrote: > On 05/13/2017 03:12 PM, Philipp Schafft wrote: > > Basically the client structure would need to keep track of which sources > > the client was attached to in form of a stack. This is important as > > there can be fallbacks of fallbacks (and there are valid reasons to > > build something like that).

Using latest icecast, let's assume the following hosting scenario. We have 2 mountpoints which are configured with authentication callbacks: /mount1 /mount2 Both mountpoints have configured the same fallback stream, mounted at '/fallback'. Both have fallback-override enabled, so they both can move listeners back from the fallback when they come online. Suppose that both mounts are

On 05/13/2017 03:12 PM, Philipp Schafft wrote: > Basically the client structure would need to keep track of which sources > the client was attached to in form of a stack. This is important as > there can be fallbacks of fallbacks (and there are valid reasons to > build something like that). A pure 'original mount' thing may result in > unexpected behavior. That being even