Re: [Freedos-user] SSH - unsupported remote protocol version

[Dan Schmidt]

Drat!  Somebody finally caught onto to my evil plan to covertly make Linux
servers insecure!  Foiled again!  You will this one, Tom, but I'll be
back!!  Oh, I'LL BE BACK!!

On Tue, Jan 2, 2018 at 9:03 AM, Tom Ehlert  wrote:

>
> > We did talk at length about it almost exactly a year ago.  The tldr
> > version is that you would need ssh2d386 and you have to have access
> > to modify the ssh config on the server to support older ciphers.
>
> there are GOOD reasons to not allow outdated protocols to be used.
> on what planet have you been living the last years?
>
> > All my attempts to get a decent C coder interested in updating the
> project have failed.
>
> > https://sourceforge.net/p/freedos/mailman/message/35629497/
>
> I'm not surprised
>
> Tom
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] SSH - unsupported remote protocol version

[Tom Ehlert]

> We did talk at length about it almost exactly a year ago.  The tldr
> version is that you would need ssh2d386 and you have to have access
> to modify the ssh config on the server to support older ciphers. 

there are GOOD reasons to not allow outdated protocols to be used.
on what planet have you been living the last years?

> All my attempts to get a decent C coder interested in updating the project 
> have failed. 

> https://sourceforge.net/p/freedos/mailman/message/35629497/

I'm not surprised

Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] SSH - unsupported remote protocol version

[Tom Ehlert]

> On 12/31/2017 10:47 AM, Robert Riebisch wrote:
>> From SSHDOS source code:
>> ###
>>if(remote_major != 1 && remote_minor == 0)
>>   fatal("Unsupported remote protocol version\n");
>> ###

> What a weird check. So version 2.1 would work? Shouldn't the check be

not only a weird and buggy check, this programmer could have given
some more - and helpful - information like


  {
  printf(
 "Unsupported remote protocol version\n"
 " this programm supports only SSL 1.0\n"
 " the remote server requires %u.%u",
  remote_major, remote_minor);

  ...
  }


but he decided otherwise. May he live in peace and empty trash bins for
the rest of his life ...


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] counterproductive UPX usage for loadhigh display /maybe other drivers also/?

[Tom Ehlert]

Hi,

> Hi, I just tried to 'lh display', but it always ends in conventional
> memory (code, codepages are perhaps in XMS):
...

> I myself explain this that the UPX-ed program is probably going to UMB,
> but after its decompression, its resident part will no longer fit there
> for some reason and is placed into conventional memory.

this is right. the .EXE header utility EXEHDR (there are many others)
reports (beyond other stuff) for the UPX'ed file

e:\>exemod y:\temp\BIN\DISPLAY.EXE

   Microsoft (R) EXE File Header Utility  Version 4.02
   y:\temp\BIN\DISPLAY.EXE(hex)   (dec)

   .EXE size (bytes)E433651
>>>Minimum load size (bytes)  1F443  128067
   Minimum allocation (para)   1E627778

after decompressing, minimum load size is much smaller

  e:>upx -d  y:\temp\BIN\DISPLAY.EXE
   Ultimate Packer for eXecutables
  Copyright (C) 1996 - 2017
  UPX 3.93w   Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 29th 
2017

  File size Ratio  Format  Name
    --   ---   ---
  62535 <-  36515.84% dos/exe DISPLAY.EXE

  Unpacked 1 file.

  e:\ntsource\snapshot>exemod y:\temp\BIN\DISPLAY.EXE

  Microsoft (R) EXE File Header Utility  Version 4.02
  y:\temp\BIN\DISPLAY.EXE(hex)   (dec)

  .EXE size (bytes)   F447   62535
>>>   Minimum load size (bytes)   FEF7   65271
  Minimum allocation (para) AD 173



fortunately, after recompressing with the current UPX, the minimum
required load size is only minimally increased, and still load high as
the uncompressed display.exe

 e:\>upx  y:\temp\BIN\DISPLAY.EXE
   Ultimate Packer for eXecutables
  Copyright (C) 1996 - 2017
 UPX 3.93w   Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 
29th 2017

 File size Ratio  Format  Name
   --   ---   ---
 62535 ->  36435.83% dos/exe DISPLAY.EXE

 Packed 1 file.

 e:\>exemod y:\temp\BIN\DISPLAY.EXE

 Microsoft (R) EXE File Header Utility  Version 4.02
 y:\temp\BIN\DISPLAY.EXE(hex)   (dec)

 .EXE size (bytes)E3B3643
>>>  Minimum load size (bytes)   FEFB   65275
 Minimum allocation (para)F0E3854



> What is essential - if so, then this behavior should be IMO mentioned in
> the display documentation (or elsewhere).

wrong. this behaviour should simply be fixed, as the fix is trivial:

   get a recent UPX.
   decompress.
   recompress.
   wait for FreeDOS 2.0 to have this fix published.


some more remarks:

( I didn't look at the sources, so take this with a grain of salt)

12K resident is, even when loaded high, a significant number.
as the compressed .EXE size is just 3,5 K, the executable logic is
most likely ~5 KB size, and the other ~7 KB is buffer space to store font
information.

to move this font buffer to XMS memory shouldn't be a big deal, and
make up ~7 KB more UMB memory.

( in the good old times people would have killed for 7 KB memory :-)

as I have no interest in display.exe, I left this as an exercise to
the reader.


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] SSH - unsupported remote protocol version

[Dan Schmidt]

We did talk at length about it almost exactly a year ago.  The tldr version
is that you would need ssh2d386 and you have to have access to modify the
ssh config on the server to support older ciphers.  All my attempts to get
a decent C coder interested in updating the project have failed.

https://sourceforge.net/p/freedos/mailman/message/35629497/


On Sun, Dec 31, 2017 at 11:57 PM, Rugxulo  wrote:

> Hi,
>
> On Sun, Dec 31, 2017 at 5:27 PM, Jerome Shidel  wrote:
> >
> > Anyhow, I recall seeing a thread earlier discussing something similar.
> At least, I think it was similar.
> > I was not very interested at the time and kinda only skimmed it. But, if
> I remember what I half glimpsed,
> > it involved something about having to add some older protocols to the
> server.  But, I’m probably mis-remembering it.
> >
> > Sorry, I really can’t be much more help than that.
>
> I'm a networking noob overall, but 
>
> Wasn't something like this discussed earlier this year, mainly by
> Ulrich Hansen? A quick search of my email archives shows a few
> messages from him about it.
>
> So maybe wait for him to chime in. (Or email him privately? Or just
> search the mailing list archives for it.)
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user