[Info-vax] Device locked by non existing process.

[Stephen Hoffman]

On 2018-05-04 18:41:51 +0000, seasoned_geek said:

> When you have to needlessly shoehorn in transport layer security WITH 
> RETRY and RECONNECT logic, you end up carrying an enormous amount of 
> luggage around.

Most folks are already using IPv4 and IPv6 everywhere, it's the old 
code that's not caught up yet.

As compared with IPsec et al, TLS and DTLS and the whole certificate 
mess exists for a reason.   If everybody is running IPsec-capable 
end-points and the rest and if the links can be pre-defined, then sure, 
point-to-point host-to-trusted-host connections will work.

I'm only rarely working in that world anymore, and the few times I have 
those pre-defined links I also have ad-hoc links around and which means 
that TLS and DTLS might as well be used everywhere.

I'm also finding it less desirable to trust the whole host or to trust 
the whole app for that matter, but that's a trend and a preference 
that's not yet commonly arrived on OpenVMS; containers and sandboxing, 
Intel SGX support, etc.  Within a few years after the x86-64 port is 
available and stable, some OpenVMS folks will begin to realize they 
don't trust some of the hosts they're now running their OpenVMS apps on.

Related:
https://asylo.dev/blog/2018/announcing-asylo.html
https://github.com/intel/intel-sgx-ssl

But again, most of the apps aren't in a world where all end-points are 
known, or where links can be pre-established, or where everybody has 
IPsec-capable end-points.  For those cases that are, bully.  Where the 
links are not pre-defined, TLS and DLTS are what we have.  Which could 
be and should be better of course, whether its an OpenVMS framework 
atop OpenSSL (descriptors, ease of use, etc) or if it's libtls and 
jackets, or otherwise.

> Information from configuration files which should only exist at startup 
> has to be saved within the application and re-used repeatedly.

The OpenVMS implementation of application configuration files is not 
competitive.  The contents and processing of the config files are 
inherently app-specific.

As a specific example of the problem with OpenVMS apps and 
configuration data, may I present...

http://h41379.www4.hpe.com/doc/732final/5763/5763pro_004.html
Mail and DEC notes and AUTHORIZE and a whole pile of other OpenVMS apps, too.

That's far from the only example, and other OpenVMS and LP and ISV and 
customer apps all have their own bespoke designs, and there's the 
endemic use of logical names for purposes exceedingly ill-suited.

Tools such as yaml configuration data stores and serialization, and 
stores such as ldap are our friends now, whether the yaml processing 
and ldap are all running entirely locally and/or app-specific, or if 
ldap is running multi-host.  I'll leave aside discussions of the image 
activator and of app bundles and packaging.

> The vintage of the C compiler does add insult to injury. All of the 
> examples you can find from other platforms use features you don't have. 
> In a recent project I had to thieve many GNU strutil source files and 
> spend a few days getting them to both compile and work in this 
> environment just to have the "basic" string functionality needed for a 
> project.

Yeah, the open-source clang port will help with C support.   Porting 
and then replacing and then retiring the existing C RTL will help, too. 
 Whether it's based on llvm libc or musl libc or otherwise, or some 
newly-constructed environment built from the wreckage of the existing C 
RTL.  And we're long past when it's reasonable that the IP API be 
separately partitioned and installed.  select() has been broken for 
decades.

JR is already aware of various missing string routines.