jayjwa <jayjwa@nowhere.org> wrote:

> OpenSSH 3.9p... I'm surprized it's not in the changelog. Actually,
> it's been out since Aug.17, according to their website. Anyone else
> think that Slack's gotten quite slow about new updates?

Remember, Slackware is a one-man job and the man is entitled to a vacation
now and again. Perhaps he is taking one now (it was not uncommon for him
to do so in the past after a release). If you really need the updates, the
great thing about Slack is you can, shock of shocks, compile them
yourselves.

OpenSSH is particularly easy in this respects. Just copy the slackbuild
script from the source tree over to /tmp, change the file to reflect the
proper OpenSSH version and off you go. Takes all of 5 minutes, if not
less. Whenever I do this on campus, waiting for the source tarball to
download usually takes longer than the actual compile and upgradepkg
process.

On 2004-08-23, Cichlidiot <fishlover@nospam.invalid> wrote:

>> OpenSSH 3.9p... I'm surprized it's not in the changelog. Actually,
>> it's been out since Aug.17, according to their website. Anyone else
>> think that Slack's gotten quite slow about new updates?
>
> Remember, Slackware is a one-man job and the man is entitled to a vacation
> now and again. Perhaps he is taking one now (it was not uncommon for him
> to do so in the past after a release). If you really need the updates, the
> great thing about Slack is you can, shock of shocks, compile them
> yourselves.

I had already done that before my original post. The thing is, once
an app goes to 'self-compile', it stays that way (unless you remove
all of it then start with slackpacks again), with all security,
updates, and notices on you.

BTW, no problems encountered with a source compile of OpenSSH 3.9 on
slack, just remember to set the user, empty dir., and group correctly.
There's of course no rc.sshd script, but you can make one if you need
to. Openssh runs fine from xinetd/inetd with -i switch. I've used key
sizes bigger than the manpage examples for this and it works fine.


--
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

jayjwa <jayjwa@nowhere.org> wrote:
> I had already done that before my original post. The thing is, once
> an app goes to 'self-compile', it stays that way (unless you remove
> all of it then start with slackpacks again), with all security,
> updates, and notices on you.

Not necessarily. If you go the route I stated in my post and make your own
slack package (with makepkg), then you can just removepkg your package and
installpkg the "official" one, or just upgradepkg. If you go a "make
install" route, then there is usually an uninstall Makefile target in most
mature software packages. But really, making your own package is very
simple (particularly if you start with a slackbuild script and modify it
for your needs) and then you can use slack's package tools to go from your
home-compiled version to PV's versions in the future should you so desire.

spammer trash troll delete

Roger Maynard (rm the cordially as always Troll)
is the pathetic loser who sent this spam.

Roger Maynard posting as An Metet wrote:

> NOTE: This message was sent thru a mail2news gateway.
> No effort was made to verify the identity of the sender.
> --------------------------------------------------------
>
> pgp trash troll delete
>
> +Alan Hicks+ <alan@lizella.network> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
>
> > In alt.os.linux.slackware, Petri Kaukasoina dared to utter,
> > > Here is a list of the most important security issues fixed by
this release:
>
> > Interesting. I hadn't heard about any of these other problems in the
> > 2.4.26 kernel.
>
> > > CAN-2004-0495 (Al Viro sparse fixes)
>
> > I find the following information for this "vulnerability".
>
> > o Al Viro sparse fixes: decnet user pointer dereference
> > o Al Viro sparse fixes: mpu401 user pointer dereference
> > o Al Viro sparse fixes: msnd user pointer dereference & assorted
fixes
> > o Al Viro sparse fixes: pss user pointer dereference
> > o Al Viro sparse fixes: aironet
> > o Al Viro sparse fixes: asus_acpi user pointer dereference
>
> > Nothing here really jumps out to me as anything serious. Looks more
> > like code clean-ups to fix issues that might one day be exploited if
> > conditions are right.
>
> > > CAN-2004-0497 (users could modify group ID of arbitrary files
on the system)
>
> > This one certainly looks a little more serious. Missing call to
fsuid()
> > in chown() allows an NFS client to modify the group permissions (and
> > only the group permissions) on the NFS server. Note of course that
the
> > user would have to be a member of the group, so this may be a little
> > more difficult to exploit than first impressions state.
>
> > > CAN-2004-0535 (e1000 minor info leak)
>
> > The only information I can find in the changelog is a credit to
Chris
> > Wright for fixing a "probable security hole".
>
> > > CAN-2004-0685 (backported Conectiva usb sparse fixes)
>
> > I found nothing of note in the Changelog for this.
>
> > > CAN-2004-0415 (file offset pointer handling race)
>
> > Not sure how important this one is for most users. The only specific
> > mention of file offset fixes is in net/atm/br2684.c.
>
> > > CAN-2004-0565 (information leak ia64)
>
> > Of course this is only of interest to a very small minority of users
> > with ia64 machines. With that said there seems to be a lot of
changes
> > in this kernel for that processor. Definately an upgrade you want if
> > you're running ia64.
>
> > Anyone got any corrections or flames for me? Prove me wrong here and
> > I'll assign two BOZO points!
>
> > - --
> > It is better to hear the rebuke of the wise,
> > Than for a man to hear the song of fools.
> > Ecclesiastes 7:5
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.1 (GNU/Linux)
>
> > iD8DBQFBKfdqlKR45I6cfKARAuDOAKCshro9rtoT2B0s0q0UEI hnRslEfgCfQCqS
> > nAQzPx1AaNDMkvAnakBZ1no=
> > =dvkh
> > -----END PGP SIGNATURE-----


--
--
Roger Maynard is a Pathetic loser!
Killfile all posts that end with
"cordially, as always"!