[Info-vax] FTP FYI

[Kerry Main (C.O.V.)]

> -----Original Message-----
> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Stephen
> Hoffman via Info-vax
> Sent: November-25-20 4:35 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] FTP FYI
> 
> On 2020-11-25 19:55:33 +0000, Dave Froble said:
> 
> > On 11/25/2020 11:24 AM, Stephen Hoffman wrote:
> >> On 2020-11-25 14:46:00 +0000, Dave Froble said:
> >>
> >>> Perhaps we should be a bit more focused on the issue?
> >>>
> >>> From what I was reading, the issue was catching data corruptions,
> >>> not security.  Isn't it sort of silly to introduce security into
> >>> another issue?  A checksum either works, or it doesn't.  If it
> >>> works, doesn't that solve the potential issue?
> >>>
> >>> Or maybe I don't understand the issue ...
> >>
> >> OpenVMS is "the most secure operating system on the planet" 🤣, which
> >> means that vendor and third-party developers have thought about both
> >> non-malicious corruptions and about actively-malicious corruptions,
> >> right?
> >>
> >> Same applies for the default choice for random-number generation: use
> >> a cryptographically secure random number generator, absent very
> >> specific reasons to use a lesser generator. Or a lesser message digest
> hash.
> >>
> >> Or somewhat more succinctly, choose and use and offer and work toward
> >> secure defaults, absent specific reasons not to.
> >>
> >> We are all working toward actually living up to that "the most secure
> >> operating system on the planet" claim, right?
> >
> > Actually, no.
> >
> > Why, because security is so much more than an OS, or any other single
> thing.
> >
> > I find it irritating when security is not the topic, that some feel
> > that they have to introduce it into a topic, where it is not an issue.
> >
> > If it ain't broke, don't fix it ...
> >
> > YMMV
> 
> 
> We should all have bad checksums, bad defaults, bad designs, bad APIs, and
> bad documentation, right?
> 
> telnet, FTP, DECnet, AUTODIN-2 CRC32, MD5, that was good enough for our
> ancestors, so it's good enough for us, right?
> 
> Do I like that we're increasingly forced to choose insecurity or to update our
> app code? No.  I've commented around frameworks to help incrementally
> isolate some of that, as have others.
> 
> But change is the development world that we're increasingly all residing
> within. With the occasional breaking changes and/or source code changes,
> yes.
> 
> And awful defaults and sentiments including "you should have known better
> than to use the defaults" don't help our app development and maintenance
> efforts.
> 
> Put differently... If the data here is important enough, then MD5 and
> AUTODIN-2 CRC32 and ilk are broken.
> 
> And if the data is not important, the defaults should still be reliable and
> robust.
> 

Multinet V5.6 Release Notes:
<http://www.process.com/docs/multinet5_6/MULTINET056_RELEASE_NOTES.txt>

- TLSv1.2 is now the default for FTPS on Alpha and ia64 systems.

>From announcement email:

Highlights in this release include:
- PTPv2 support has been added (Precision Time Protocol)
- SSH 'Suite B' support on Alpha and I64, which adds support for more modern key exchanges, certificates, etc.
- Numerous bug fixes for SSH2 and SFTP
- OpenSSL 1.0.2T on Alpha and I64
- Performance enhancements and bug fixes for the MultiNet kernel
- NTP updated to 4.2.18p15 from ntp.org
- NAMED updated to BIND 9.11.21 from isc.org
- FTP support for TLSv1.2 and bug fixes
- NFSv3 improvements and bug fixes
- UCXDRIVER and UCX_LIBRARY_EMULATION bug fixes

Kerry


-- 
This email has been checked for viruses by AVG.
https://www.avg.com