OpenVMS books

[Saifi Khan]

Hi:

Here is a newbie query.

i can't seem to find any of these books

OpenVMS Operating System Concepts, 2nd Edition, David Miller

C/C++ programming on OpenVMS

The one, i found 'The Minimum You Need to Know to be an OpenVMS Application Developer' by Roland Hughes is too steeply priced, it is simply un-affordable :-(

So, currently, i'm reviewing material at Neil Rieck's site
http://www3.sympatico.ca/n.rieck/

Any other pointers/links related to C/C++ programming on OpenVMS ?


warm regards
Saifi.

[Baldrick]

Try the documentation ?

Freely available and online and probably the best source of information, from
various locations.

This operating system also has HELP which is useful too.

Welcome to VMS I hope you enjoy your journey.

Baldrick

[Henry Crun]

Look for the OpenVMS documentation online
e.g. http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/6489/6489PRO.HTML
or the C manuals at
http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/index.html
or try to find an OpenMS documentation CD from which you can download the whole
six-foot set to a (hack,spit) wintel PC

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html

[John Reagan]

On Thursday, July 20, 2017 at 12:12:32 PM UTC-4, Saifi Khan wrote:

>
> Any other pointers/links related to C/C++ programming on OpenVMS ?
>
>
> warm regards
> Saifi.

Are you on Alpha or Itanium?

The C compiler on both is technically C99 but the RTLs are missing a few things.

The C++ compiler on Itanium is C++98-ish. The C++ compiler on Alpha is even older.

Keep this in mind if you cut-n-paste examples online to try on OpenVMS.

[Saifi Khan]

Hi john:

With Mark's help, i could get an account on decus.org

Guess i'm logged onto an OpenVMS Alpha V8.3

The compiler information is as follows,

$ cc /ver
HP C V7.3-010 on OpenVMS Alpha V8.3

My host machine is an AMD64 ASUS laptop running Arch Linux.

I have ssh'd to decus.org and no "cut-n-paste", as i'd like to read through the code and type it out myself, errors and all. :-)

Could you elaborate, what you mean by "RTLs are missing a few things." ?

i understand a bit of glibc and libc stuff, so i should be able to follow you.


warm regards
Saifi.

[Saifi Khan]

On Thursday, July 20, 2017 at 10:15:05 PM UTC+5:30, Henry Crun wrote:
> >
> Look for the OpenVMS documentation online
> e.g. http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/6489/6489PRO.HTML
> or the C manuals at
> http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/index.html
> or try to find an OpenMS documentation CD from which you can download the whole
> six-foot set to a (hack,spit) wintel PC
>

Hi Henry:

Thanks a bunch for the links. Very helpful.

i've just written my first hello world C program.

The PDF files are quite detailed. This is unlike any documentation i have seen so far !


warm regards
Saifi.

[Saifi Khan]

On Thursday, July 20, 2017 at 9:57:23 PM UTC+5:30, Baldrick wrote:
>
> Try the documentation ?
>
> Freely available and online and probably the best source of information, from
> various locations.
>
> This operating system also has HELP which is useful too.
>
> Welcome to VMS I hope you enjoy your journey.
>
> Baldrick

Thanks Baldrick.

The HELP command you mentioned was an eye-opener.

I am used to 'man' pages with sections on FreeBSD / Arch Linux.

So, this required a bit of adjustment in the way i seek help.

Thanks and i have just begun my journey and i have some specific goals that i'd like to accomplish whhen it comes to OpenVMS.


warm regards
Saifi.

[Camiel Vanderhoeven]

I also would check out the code examples at eight-cubed.com.

[John Reagan]

The obvious stuff is:

- The C99 header "stdint.h" is missing
- The C99 header "fenv.h" is missing
- Various C99 required macros that should be in "inttypes.h" are missing (for example, PRIi32)
- The C99 required "printf/scanf" conversion specifier "F" is missing.
- The C99 required "printf/scanf" argument types "hh","t","j", and "z" are missing

[Craig A. Berry]

Some of what should be in math.h is in float.h or missing entirely.

Some of the locale stuff is outdated. E.g., isprint() should not return
true in the C/POSIX locale for upper ASCII characters because the
C/POSIX locale does not include anything above 127.

Lots of things work differently or have limited functionality, such
pipe() and select(). These sorts of things may or may not be standards
compliance issues but have a big impact on porting code.

A lot of the things you might want are available but not the default,
such as IEEE math on Alpha, large file support, preserving filename
case, and so on. There are a bunch of compile-time and run-time knobs to
turn that enable various things.

Whether you need to worry about any of this stuff depends on what you
are doing. If you are porting a package of any complexity, you'll likely
have to get pretty far into the details.

[Stephen Hoffman]

On 2017-07-20 20:32:12 +0000, John Reagan said:

> On Thursday, July 20, 2017 at 2:08:13 PM UTC-4, Saifi Khan wrote:
>>
>> Could you elaborate, what you mean by "RTLs are missing a few things." ?
>

> The obvious stuff is:
>
> - The C99 header "stdint.h" is missing
> - The C99 header "fenv.h" is missing
> - Various C99 required macros that should be in "inttypes.h" are
> missing (for example, PRIi32)
> - The C99 required "printf/scanf" conversion specifier "F" is missing.
> - The C99 required "printf/scanf" argument types "hh","t","j", and "z"
> are missing

The C run-time library (RTL) is one of a number of RTLs present on OpenVMS.

OpenVMS support for C99 is compiler-only. Put another way, any
header files or C library routines or changes from C99 or later are
missing from the OpenVMS implementation of C. For details, look
around the 'net for discussions of the changes from C90 to C99, and
outside of the changes specific to the compiler and not the include
files and C calls, and you'll have the list of what's not there in C on
OpenVMS. Many of the common C routines found across Unix and Linux
and BSD systems are also missing as distinct from what's part of the C
standards, and this'll be a bigger problem for many applications.
Also missing are many of the common libraries found on Unix, Linux and
BSD, and you'll have to find and install or port those separately
fork()/vfork()/exec() is a topic best avoided. The C socket IP calls
are off in another part of the doc. The current online help for the C
calls is accessible from DCL via the command HELP CRTL. (HELP itself
is rather limited, but that's another discussion.)

Large discussion of the various missing C routines in past postings
here in the comp.os.vms newsgroup; check the Gargle Groups archives for
the newsgroup for details.

Also missing compiler-built-ins for dealing with descriptors — you're
going to need to get familiar with those and with itemlists, when
calling OpenVMS services — and other OpenVMS-isms. Those are handled
via include files, descrip.h or maybe dscdef.h, depending on what
you're doing. (Not by the compiler, as might be expected.
Descriptors are a completely separate means of accessing strings
specific to OpenVMS, and are distinct from the null-terminated C
strings you're likely familiar with.)

The C includes are divided into several hunks: those specific to C, and
those that are specific to OpenVMS. The latter are further split into
those that are stable or documented (and they're in SYS$STARLET_C.TLB)
and those that are less documented or are unstable (SYS$LIB_C.TLB),
If you're working on traditional C code and not using any system
services or kernel calls or OpenVMS RTL calls, you won't need the
latter stuff.

C include files are buried in text libraries, The contents of these
include files are retrieved from TLB files stored in the SYS$LIBRARY:
directory by the compiler. You might find one of the old and
usually-stale header file include reference directories
SYS$SYSROOT:[DECC$LIB...] on a server you're working with, and that can
be useful to look in and to SEARCH through, but it's not maintained by
the C kits (anymore) and it's not used by default by the compiler, so
the contents can be stale.

Eight-cubed.com has been mentioned, and that's a good resource for
examples of system service and RTL calls. Other resources include
digiater.nl and decuslib.com, as well as the OpenVMS archives at
Process software process.com site. Various stuff posted at HPE and at
the HPE Freeware site tends to be stale. SYS$EXAMPLES is a great way
to learn how our ancestors once coded C. The notes conferences — DCL
command is NOTES — available over at decuserve also have some
information, and the porting-related notes conference (porting_to_vms,
IIRC) hosted over there might be interesting to you.

There are other wrinkles.

In short: there's very little documentation available on the
differences from other environments. (The oft-fondly-remembered
OpenVMS documentation hosted at HPE is unfortunately somewhat lacking
in this and other areas, but it's also what is available at your
budget. The VSI folks will likely eventually address parts of this,
both with newer versions of C for x86-64 and with newer documentation
for OpenVMS and layered products.)




--
Pure Personal Opinion | HoffmanLabs LLC

[Arne Vajhøj]

My suggestion will be:

C & C++ language and standard library: pick any 20 year old book and
it should match VMS reasonable OK

C and C++ compilers: HELP should provide you with what you need

POSIX stuff: the process stuff will most likely not work, you need to
be very careful with the file stuff because native VMS file and
directory names are very different from *nix, the rest should
reasonable work as expected

VMS calling convention: read the VMS manual and look at some
examples

VMS specific stuff: read the VMS manuals on, specifically:
* LIB$ reference
* system services reference
* RMS reference
on an "as needed" basis.

Arne

[seasoned_geek]

Electronic versions from Kobo are a bit cheaper and you don't have to pay shipping.

https://www.kobo.com/us/en/ebook/the-minimum-you-need-to-know-to-be-an-openvms-application-developer

One of the reasons I wrote that book is there basically _was_ nothing left out there. If you just wish to read it you can search WorldCat for a library "near" you which has it.

http://www.worldcat.org/title/minimum-you-need-to-know-to-be-an-openvms-application-developer/oclc/748520912&referer=brief_results

Quite a few libraries stock that title and in quite a few countries. When HP handed out a pallet of them at a Technical Boot Camp right after it came out lots of libraries ended up getting copies.

You can try for those other books on WorldCat too.

I do not fill orders for the malignant tumor which will one day end the human race, Amazon.com and I sure as hell do not know where the 12 "new" copies for $59.74 are coming from:

https://www.amazon.com/Minimum-Need-OpenVMS-Application-Developer/dp/1939732018/ref=sr_1_1?ie=UTF8&qid=1500743542&sr=8-1&keywords=The+Minimum+You+Need+to+Know+to+Be+an+OpenVMS+Application+Developer

This book has been heavily pirated in India. I even received an email from someone doing the pirating demanding I send them the entire book in Word format because they were having trouble getting what they took from Google Books properly formatted. I have been told by multiple recruiters that _every_ computer book available on Google Books is available on the street as a physically printed book for under $10. Large corporations purchased high end printers and binders for their campuses and the employees use them to print books they then sell on the street.

Betterworldbooks.com occasionally gets used copies

https://www.betterworldbooks.com/The-Minimum-You-Need-to-Know-to-Be-an-OpenVMS-Application-Developer-id-9780977086603.aspx

Oh! I bet I know where all these "new" copies are coming from suddenly. Bet they have a completely different ISBN as I converted some of those titles for POD via IngramSpark so I could get into Books-a-million. I figured it out when I saw 2017 listed here:

https://www.alibris.com/booksearch?keyword=The+Minimum+You+Need+to+Know+to+Be+an+OpenVMS+Application+Developer&mtype=B&hs.x=23&hs.y=32

That version of the book will be POD (toner) printed. I've never held one in my hands so I don't know the quality.

I really wanna know what genetic misfit came up with $1,172.46 for a book still available from the publisher ON THE SAME SITE which has a list price of $90.

2006 will be an original print via offset press and came with CD in the back. POD version does not come with CD. I do not know about print quality. Contents of the CD are available on the book Web site.

The Barnes & Noble nook version appears to be the cheapest version out there at around $46 (click all available formats.) You don't need to own a nook as they have some free readers. Nook should also be EPUB so unless it has proprietary DRM you should be able to read it via Calibre.

https://www.barnesandnoble.com/w/minimum-you-need-to-know-to-be-an-openvms-application-developer-roland-hughes/1100968909?ean=9781939732019

Keep in mind that isn't just a C++ book. Being the author I am biased, but, others in here should be able to tell you just how much is in there.

[seasoned_geek]

On Thursday, July 20, 2017 at 1:12:28 PM UTC-5, Saifi Khan wrote:
>
> The PDF files are quite detailed. This is unlike any documentation i have seen so far !
>

That would be because Linux and most OpenSource (sans Qt) projects don't _have_ any documentation. They focus on being expert friendly.

[seasoned_geek]

During the VAX 11/730 and 11/750 ear there were self paced tutorials, plural. They came with a spiral bound book and there was a program which ran on the VAX. I "think" the programs could be configured to send process reports to some admin/supervisor. I know you could stop and when you restarted it would bring you back to where you left off. That sounds like nothing now, but it was massive back then.

Sadly the self-paced interactive learning was killed off rather than being maintained. The interactive BASIC environment was also killed off rather than being maintained. About the time both of these things got killed off colleges stopped using DEC machines. Some, myself included, firmly believe it was the killing off of these things which lead to DEC's demise on college campuses. It wasn't just the availability of cheap PCs.

If you are coming from a worthless x86 world you really need to develop a completely different mindset before wading too deeply into the land of real computers with real operating systems. Applications in the worthless x86 world are all developed from "Me & My" point of view. It's mine mine mine mine my own PC and my own software and if you don't know how to use it screw you! If you say it doesn't work, too bad!

In the midrange and mainframe world each application is written knowing there will be dozens, if not thousands of simultaneous users. Most applications require other applications and service other applications all to achieve a "greater good" dictated by the company which owns the computer.

[Colin Butcher]

To assist your journey with a lot of interesting diversions, try the
Digital Technical Journals archive:
http://www.dtjcd.vmsresource.org.uk/

There's also the HPE OpenVMS Technical Journals archive:
http://h41379.www4.hpe.com/openvms/journal/

Welcome to the world of well designed and documented operating systems
and software products that work.

Cheers, Colin.

[Arne Vajhøj]

On 7/22/2017 1:57 PM, seasoned_geek wrote:
> If you are coming from a worthless x86 world you really need to
> develop a completely different mindset before wading too deeply into
> the land of real computers with real operating systems. Applications
> in the worthless x86 world are all developed from "Me & My" point of
> view. It's mine mine mine mine my own PC and my own software and if
> you don't know how to use it screw you! If you say it doesn't work,
> too bad!

In a few years VMS will be part of the x86 world.

:-)

Arne

[seasoned_geek]

They should be porting to IBM's Quantum and ignoring the obsolete x86 world. INTEL is laying off people in droves. They won't be around much longer. The ARM and MMX processors are replacing x86 in most things.

Quantum is the next big thing. Ironically, since IBM is doing it, COBOL will be one of the first compilers for it. Even more ironically COBOL is more suited to Quantum than C/C++ or any 3GL which supported native booleans. COBOL had 88 levels in seemingly limitless quantity. The language was/is already suited for "shades of true" Quantum computing.

Nothing against those working on the port, but, I honestly hope it never makes it to x86. They will end up bringing in a bunch of bug ridden OpenSource code to make it work and then OpenVMS will be just as shitty an OS as everything else on x86. We already went through this when the Itanic port lowered the quality on Alpha. But the Itanic was a chip so bad HP had to kill off the Alpha when it had at least another 10 years of continuous improvements left just to force a market for it.

OpenVMS was banned from Black Hat conferences until it started getting OpenSource added to it, then it was welcomed with open arms AND it started getting breached.

Those legendary multi-decade uptimes VMS is famous for came in large part because of the hardware. Even if you somehow manage to get real clustering to work on x86 you will never get worthless commodity hardware to last 5 years in a flat out production environment. Spinning up a new instance in a VM like Hypervisor et-al does nothing for all of the users and transactions which died with the board. DECdtm and ACMS could provide guaranteed delivery and guaranteed execution because in those rare instances the grid failed along with your UPS, the OS re-start cleaned up the journaling automatically and transactions picked up from their last successful point. Today's x86 world is all up in arms about the billions of dollars left in shopping carts annually. They seem to think it is a consumer issue but in truth it is a worthless platform issue. When your blade/rack/whatever $40 CPU in a $5000 package died and a new instance was spun up everything was lost for the old instance. Faced with having to start over, customer went to different site. It's not a customer issue.

[VAXman-]

In article <8eaf7b38-b1ee-4f5a...@googlegroups.com>, seasoned_geek <rol...@logikalsolutions.com> writes:

>On Saturday, July 22, 2017 at 4:12:16 PM UTC-5, Arne Vajh=C3=B8j wrote:
>> On 7/22/2017 1:57 PM, seasoned_geek wrote:
>> > If you are coming from a worthless x86 world you really need to
>> > develop a completely different mindset before wading too deeply into
>> > the land of real computers with real operating systems. Applications
>> > in the worthless x86 world are all developed from "Me & My" point of
>> > view. It's mine mine mine mine my own PC and my own software and if
>> > you don't know how to use it screw you! If you say it doesn't work,
>> > too bad!

>>=20

>> In a few years VMS will be part of the x86 world.

>>=20
>> :-)
>>=20
>> Arne
>
>They should be porting to IBM's Quantum and ignoring the obsolete x86 world=
>.. INTEL is laying off people in droves. They won't be around much longer. T=

>he ARM and MMX processors are replacing x86 in most things.
>

>Quantum is the next big thing. Ironically, since IBM is doing it, COBOL wil=
>l be one of the first compilers for it. Even more ironically COBOL is more =
>suited to Quantum than C/C++ or any 3GL which supported native booleans. CO=
>BOL had 88 levels in seemingly limitless quantity. The language was/is alre=

>ady suited for "shades of true" Quantum computing.
>

>Nothing against those working on the port, but, I honestly hope it never ma=
>kes it to x86. They will end up bringing in a bunch of bug ridden OpenSourc=
>e code to make it work and then OpenVMS will be just as shitty an OS as eve=
>rything else on x86. We already went through this when the Itanic port lowe=
>red the quality on Alpha. But the Itanic was a chip so bad HP had to kill o=
>ff the Alpha when it had at least another 10 years of continuous improvemen=

>ts left just to force a market for it.
>

>OpenVMS was banned from Black Hat conferences until it started getting Open=
>Source added to it, then it was welcomed with open arms AND it started gett=
>ing breached.
>
>Those legendary multi-decade uptimes VMS is famous for came in large part b=
>ecause of the hardware. Even if you somehow manage to get real clustering t=
>o work on x86 you will never get worthless commodity hardware to last 5 yea=
>rs in a flat out production environment. Spinning up a new instance in a VM=
> like Hypervisor et-al does nothing for all of the users and transactions w=
>hich died with the board. DECdtm and ACMS could provide guaranteed delivery=
> and guaranteed execution because in those rare instances the grid failed a=
>long with your UPS, the OS re-start cleaned up the journaling automatically=
> and transactions picked up from their last successful point. Today's x86 w=
>orld is all up in arms about the billions of dollars left in shopping carts=
> annually. They seem to think it is a consumer issue but in truth it is a w=
>orthless platform issue. When your blade/rack/whatever $40 CPU in a $5000 p=
>ackage died and a new instance was spun up everything was lost for the old =
>instance. Faced with having to start over, customer went to different site.=

> It's not a customer issue.

Over the years, I've purchased several x86 laptops for Linux. Back In 2012, I
purchased an HP Envy 17. It was quite a pricey upper end x86. It just failed
catastrophically yesterday. To put that in perspective, my 2002 PowerBook 17
and 2009 MacBook Pro 17 are still functioning. I don't think it's the x86 at
fault here since the MBP is intel based. However, the commodity marketspace
of the x86 has made many of the offering based around it cheap -- not just in
price. ;) The Envy, for example, had a plastic frame part in a stress point
at the hinge. Not even a month into owning it, a screw stripped out from it.
The touted "beats" audio in it was awful. The whole thing buzzed like an old
rear deck speaker in a late model car. However, despite those hardware kinks,
it was one of the better environments I've ever gotten Linux running upon. I
don't have any real-world experience with x86 servers but I do have clients
that seem to be replacing them all too often while OpenVMS running hardware
just keeps on going like the Energizer Bunny.

Just my $0.02. Does anybody have any pointers to a low-cost x86 laptop? 17"
preferred. I may ??? have found another Envy (used) but you never know.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[johnwa...@yahoo.co.uk]

HP's Envy products are consumer-focused products aren't they?
Maybe a bit like Compaq Presario (once bought, never repeated).

Over the years, I've been happy with business-class HPQ laptops,
but the the prices when new are silly, so I've usually bought
refurb (well, after the DEC HiNote Ultra I inherited) e.g.
Compaq Armada E500, through to the HP Elitebook 6930 (2008?)
I'm using right now (from the days of Windows Vista, now running
OpenSuse and Windows 7 Pro 64).

Being business-class kit it generally comes Linux-ready, and in
some cases (eg Suse) Linux-certified.

I'm in the process of migrating to another refurb, this time an
HP 8460p (2012ish) but it has the trendy modern 'chicklet' (dead
rat?) keyboard which I've not used before and I'm finding it
very mixed (polite word) although it seems OK in other respects.

There are various resolutions and screen sizes available for
various apparently similar model numbers so care is needed when
selecting and purchasing.

There were/are HP Mobile Workstation variants of some EliteBooks
(eg 8460w was the worksstation version of the usual 8460p). Some
of these come with 16"/17" screen options, although it's not
something I've looked at in detail.

Might not suit what you need but it's suited me for years :)

[Paul Sture]

On 2017-07-23, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>
> Over the years, I've purchased several x86 laptops for Linux. Back In 2012, I
> purchased an HP Envy 17. It was quite a pricey upper end x86. It just failed
> catastrophically yesterday. To put that in perspective, my 2002 PowerBook 17
> and 2009 MacBook Pro 17 are still functioning. I don't think it's the x86 at
> fault here since the MBP is intel based. However, the commodity marketspace
> of the x86 has made many of the offering based around it cheap -- not just in
> price. ;) The Envy, for example, had a plastic frame part in a stress point
> at the hinge. Not even a month into owning it, a screw stripped out from it.

IIRC you told us how expensive replacement parts were for the Envy. It looks
like HP apply ink pricing policies for those.

> The touted "beats" audio in it was awful. The whole thing buzzed like an old
> rear deck speaker in a late model car.

Oh, the memories of those buzzing speakers back in the 60s...

My worst PC audio purchase was a pair of Sony "PC Speakers". Absolutely
rubbish when compared to the speakers which came with a cheapish JVC CD
Player/Radio combo (which I'd bought for kitchen use). That ended up
being a replacement for the Sony speakers.

> However, despite those hardware kinks, it was one of the better
> environments I've ever gotten Linux running upon. I don't have any
> real-world experience with x86 servers but I do have clients that
> seem to be replacing them all too often while OpenVMS running
> hardware just keeps on going like the Energizer Bunny.
>
> Just my $0.02. Does anybody have any pointers to a low-cost x86 laptop? 17"
> preferred. I may ??? have found another Envy (used) but you never know.

A quick search on "linux laptop" brought up a range of laptops at
system76:

<https://system76.com/laptops>

mentioned in this article from 2014
<https://www.howtogeek.com/185286/how-to-buy-a-laptop-for-linux/>

My takeaway from that article is to do your research at the time of
buying; last year's information may not only be out of date, but not
work any more.

--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.

[Craig A. Berry]

For a review of that and a review of one of its competitors, see:

<https://arstechnica.com/gadgets/2016/11/system76-oryx-pro-review-linux-in-a-laptop-has-never-been-better/>

<https://arstechnica.com/gadgets/2017/06/the-beefy-dell-precision-7520-de-can-out-muscle-a-growing-linux-laptop-field/>

[seasoned_geek]

>
> Just my $0.02. Does anybody have any pointers to a low-cost x86 laptop? 17"
> preferred. I may ??? have found another Envy (used) but you never know.

I'm typing this on an HP 355 G2 I picked up at Egg Head a few years ago. I don't play sound on it so do not know about that. Battery life is atrocious. I also had to install my own RAM and replace the HD with an SSD just to get it sized correctly. Of course it is better because it is AMD.

Seems like the malignant tumor which will one day end the human race is about the only place to find them now.

https://www.amazon.com/HP-K4K27UT-ABA-15-6-Inch-A8-6410/dp/B00P2D3J62

Wow! They want more for a used one than I paid for this one new! Just over $300 when I bought it new.

Can we find the engineering titan who decided to put touch pads in front of the space bar where people like to wrest their wrists while typing and sterilize the entire family tree?

While it is far too small for your size requirements, the best I've ever owned for durability and batter life is my Acer Aspire One 722.

https://www.cnet.com/products/acer-aspire-one-722/specs/

I haven't measured battery life since I boosted it to 8Gig of RAM and put an SSD in it but it used to reliably last 10 hours writing books and typing emails.

Back when I didn't care what I paid for a laptop _and_ they were the only brand with a numeric keypad on the right, I used to only buy Pro-star.

http://www.pro-star.com/INDEX.PHP?r=product/index&filter=15

Some of the most bullet proof laptops I've ever owned and they had really great keyboards. This 355 G2 makes my fingers sore after a few hours. Nothing-but-air chicklets are made for people who never learned to move their fingers.

There are days I miss my 35lb singer sewing machine with its 9" tube type monitor. sigh...

[seasoned_geek]

I would like to see System-76 do more business. They need to up the volume enough to drop their prices. They used to only pre-load Ubuntu though and Ubuntu has been buggering things royal since they introduced Unity.

Little fear though. Ubuntu will be dropping Linux soon. Microsoft will be taking over and rebadging Ubuntu as Windows whatever (already experimenting with Windows 10 running Ubuntu in places). Microsoft has already abandoned Windows Mobile/phone announcing EOL date without announcing a migration path. Cannonical never got their (*&)(*& to work on a phone but Microsoft believes they can.

Google is soon to drop Android and there will be massive rejoicing.

Both Google and Cannonical have their own forks of Fuchsia going on. Google is pushing hard to make this be what replaces the Android train wreck. Both companies are banking that _they_ can make Fuchsia be the one OS to rule them all from phone to tablet to 2-in-1.

There are kernel design flaws in Linux which Linus and crew refuse to address and it is becoming a total nightmare, especially for Nvidia users. Requiring the kernel to be recompiled and linked to the video driver, bad bad bad bad. Many kernel updates cause boxes running those to gag. Especially since the kernel is now trying to make use of available CUDA cores.

Sigh

Oh. This 355 G2 is running KDE Neon. Windows long since removed. Actually removed days after the machine arrived.

[VAXman-]

In article <20b7fcdb-6098-4908...@googlegroups.com>, seasoned_geek <rol...@logikalsolutions.com> writes:
>>=20
>> Just my $0.02. Does anybody have any pointers to a low-cost x86 laptop? =

> 17"
>> preferred. I may ??? have found another Envy (used) but you never know.
>

>I'm typing this on an HP 355 G2 I picked up at Egg Head a few years ago. I =
>don't play sound on it so do not know about that. Battery life is atrocious=
>.. I also had to install my own RAM and replace the HD with an SSD just to g=

>et it sized correctly. Of course it is better because it is AMD.
>

>Seems like the malignant tumor which will one day end the human race is abo=

>ut the only place to find them now.
>
>https://www.amazon.com/HP-K4K27UT-ABA-15-6-Inch-A8-6410/dp/B00P2D3J62
>

>Wow! They want more for a used one than I paid for this one new! Just over =

>$300 when I bought it new.
>

>Can we find the engineering titan who decided to put touch pads in front of=
> the space bar where people like to wrest their wrists while typing and ste=

>rilize the entire family tree?
>

>While it is far too small for your size requirements, the best I've ever ow=

>ned for durability and batter life is my Acer Aspire One 722.
>
>https://www.cnet.com/products/acer-aspire-one-722/specs/
>

>I haven't measured battery life since I boosted it to 8Gig of RAM and put a=
>n SSD in it but it used to reliably last 10 hours writing books and typing =
>emails.
>
>Back when I didn't care what I paid for a laptop _and_ they were the only b=
>rand with a numeric keypad on the right, I used to only buy Pro-star.
>
>http://www.pro-star.com/INDEX.PHP?r=3Dproduct/index&filter=3D15
>
>Some of the most bullet proof laptops I've ever owned and they had really g=
>reat keyboards. This 355 G2 makes my fingers sore after a few hours. Nothin=
>g-but-air chicklets are made for people who never learned to move their fin=
>gers.
>
>There are days I miss my 35lb singer sewing machine with its 9" tube type m=
>onitor. sigh...

I didn't have the battery in my Envy. The battery life on it was just as, if
not more, atrocious that yours I wager. I have one sitting on my pile that's
swelled to about 1/5 inches from what should be aabout .5 inch. The Envy was
used primarily at my desk and occasionally at a rocket launch site to run an
OpenRocket simulation. The car I have has 115Vac outlet, so again the battery
is not an issue.

Anyway, I've found a similar Envy on eBay dirt cheap. All I will need to do
when I get it is removed its defective WEENDOZE infested drive and install my
two drives (Linux and vtAlpha-OpenVMS).

[Simon Clubley]

On 2017-07-22, seasoned_geek <rol...@logikalsolutions.com> wrote:
>
> OpenVMS was banned from Black Hat conferences until it started getting
> OpenSource added to it, then it was welcomed with open arms AND it started
> getting breached.
>

Bollocks.

The total system compromise breach was in SMG which is pure VMS and
was a straight forward buffer overflow. Its exploit was made a lot
easier due to the VMS design which meant the security researchers
didn't even have to mess around with loading shellcode onto the stack.

The finger compromise on UCX 5.x was caused by not specifying a format
string (IIRC) as the first argument. The UCX 5.x stack came from another
DEC OS and that code should never have passed peer review.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[seasoned_geek]

Double Bollocks

https://www.sans.org/reading-room/whitepapers/infosec/primer-openvms-vms-security-604

====
In mid February 2002, news quickly became widespread regarding vulnerabilities that
existed in the SNMP protocol.
According to the CERT Advisory CA-2002-03
“Vulnerabilities in the decoding and subsequent processing of SNMP messages by both
managers and agents may result in denial-of-service conditions, format string vulnerabilities,
and buffer overflows. Some vulnerabilities do not require the SNMP message to use the
correct SNMP community string.”
According to Compaq’s statement in response to this multi-vendor advisory, the SNMP agent
for VMS TCP/IP is impacted.
====

There are more from the years when OpenSource started getting rolled in. I just don't feel like wasting the time.

Don't forget to look up ShellShock.

[Stephen Hoffman]

On 2017-07-25 15:45:37 +0000, seasoned_geek said:

> In mid February 2002, news quickly became widespread regarding
> vulnerabilities that existed in the SNMP protocol.

OpenVMS is still using SNMPv2. No more need be discussed about that
entire area, pending its replacement with support for SNMPv3
(presumably) part of VSI IP.

[Arne Vajhøj]

On 7/25/2017 11:45 AM, seasoned_geek wrote:
> On Monday, July 24, 2017 at 9:17:31 PM UTC-5, Simon Clubley wrote:
>> On 2017-07-22, seasoned_geek <rol...@logikalsolutions.com> wrote:
>>>
>>> OpenVMS was banned from Black Hat conferences until it started getting
>>> OpenSource added to it, then it was welcomed with open arms AND it started
>>> getting breached.
>>>
>>
>> Bollocks.
>>
>> The total system compromise breach was in SMG which is pure VMS and
>> was a straight forward buffer overflow. Its exploit was made a lot
>> easier due to the VMS design which meant the security researchers
>> didn't even have to mess around with loading shellcode onto the stack.
>>
>> The finger compromise on UCX 5.x was caused by not specifying a format
>> string (IIRC) as the first argument. The UCX 5.x stack came from another
>> DEC OS and that code should never have passed peer review.

> Double Bollocks
>
> https://www.sans.org/reading-room/whitepapers/infosec/primer-openvms-vms-security-604

I don't think that story dispute the SMG or UCX issue.

So no double bollocks.

> ====
> In mid February 2002, news quickly became widespread regarding vulnerabilities that
> existed in the SNMP protocol.
> According to the CERT Advisory CA-2002-03
> “Vulnerabilities in the decoding and subsequent processing of SNMP messages by both
> managers and agents may result in denial-of-service conditions, format string vulnerabilities,
> and buffer overflows. Some vulnerabilities do not require the SNMP message to use the
> correct SNMP community string.”
> According to Compaq’s statement in response to this multi-vendor advisory, the SNMP agent
> for VMS TCP/IP is impacted.
> ====
>
> There are more from the years when OpenSource started getting rolled in. I just don't feel like wasting the time.

Where is the open source????

VMS TCP/IP is not open source.

And nowhere does it state that DEC/Compaq had used any open source in
their SNMP implementation.

They may have, but it does not say so.

Arne

[Simon Clubley]

On 2017-07-25, seasoned_geek <rol...@logikalsolutions.com> wrote:
>
> https://www.sans.org/reading-room/whitepapers/infosec/primer-openvms-vms-security-604
>

According to the footer line in the document, it was written in 2002
which was 6 years before the 2008 DEFCON revelations about VMS
vulnerabilities.

As soon as some security researchers spent the time to find out
a little _something_ about VMS internals, they discovered pure VMS
vulnerabilities (ie: SMG) which the earlier researchers had missed.

The low figures could simply mean that to date no-one has been motiviated
enough recently to learn enough about VMS internals in order to be able
to probe it for vulnerabilities using modern probing techniques.

[seasoned_geek]

On Tuesday, July 25, 2017 at 12:50:50 PM UTC-5, Arne Vajhøj wrote:
>
> So no double bollocks.
>

Yes, double bollocks, you just can't follow a conversation.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: July 25, 2017 2:20 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] OpenVMS books
>
> On 2017-07-25, seasoned_geek <rol...@logikalsolutions.com> wrote:
> >
> > https://www.sans.org/reading-room/whitepapers/infosec/primer-
> openvms-vms-security-604
> >
>
> According to the footer line in the document, it was written in 2002
> which was 6 years before the 2008 DEFCON revelations about VMS
> vulnerabilities.
>
> As soon as some security researchers spent the time to find out
> a little _something_ about VMS internals, they discovered pure VMS
> vulnerabilities (ie: SMG) which the earlier researchers had missed.
>
> The low figures could simply mean that to date no-one has been
> motiviated
> enough recently to learn enough about VMS internals in order to be
able
> to probe it for vulnerabilities using modern probing techniques.
>

Or.. since we doing the "lets do some pure 100% speculating", the
alternate speculating might be that the security researchers tried to
hack recent (not 15+ year old UCX bugs) versions of OpenVMS and they
gave up trying.

Since neither of us know which scenario is true, then either one of us
could be right.

Especially when the value of security bugs that can crack a platform
that runs stock exchanges, banks, lotteries, nuclear stations, power
utilities would likely go for a very high price in the bad guy world.

Btw - while the finger bug was something that needed fixing, one should
remember that the service is disabled by default and I have never known
any OpenVMS system that even uses finger. It was/is a service that came
from the UNIX based code that was ported to OpenVMS as UCX.

Question - does anyone here have the finger service enabled on their
OpenVMS system?

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Simon Clubley]

On 2017-07-29, Kerry Main <kemain...@gmail.com> wrote:
>
> Or.. since we doing the "lets do some pure 100% speculating", the
> alternate speculating might be that the security researchers tried to
> hack recent (not 15+ year old UCX bugs) versions of OpenVMS and they
> gave up trying.
>
> Since neither of us know which scenario is true, then either one of us
> could be right.
>

The DCL bug I found recently appears to have laid dormant within VMS
for at least a couple of decades until I decided on a whim to fuzz
the DCL recall buffer one Sunday.

I may have just got lucky but it only took me several minutes to
crash DCL. Finding the cause of the crash took a lot longer however
due to my limited free time at the moment and especially since my
initial assumption about the cause of the crash was wrong. :-)

My point is: How many other bugs are just waiting to be discovered
in VMS and will the next one turn out to be a security vulnerability ?

> Especially when the value of security bugs that can crack a platform
> that runs stock exchanges, banks, lotteries, nuclear stations, power
> utilities would likely go for a very high price in the bad guy world.
>

And it doesn't help matters when certain portions of the VMS community
sticks its head in the sand and tries to claim the issues affecting
other operating systems do not apply to VMS.

And given that list of _very_ high value targets above, VSI should be
gearing up to detect and stop nation state attacks against VMS and the
VSI VMS development infrastructure just like some other vendors do with
their own critical infrastructure products.

Instead at the moment, we have a vendor that can't even be bothered to
put on its website the security reporting mechanism Clair says he had
people write towards the end of last year.

> Btw - while the finger bug was something that needed fixing, one should
> remember that the service is disabled by default and I have never known
> any OpenVMS system that even uses finger. It was/is a service that came
> from the UNIX based code that was ported to OpenVMS as UCX.
>

That's not the point. The point is that the code should never have
passed peer review.

[Arne Vajhøj]

On 7/30/2017 4:37 PM, Simon Clubley wrote:
> On 2017-07-29, Kerry Main <kemain...@gmail.com> wrote:
> And it doesn't help matters when certain portions of the VMS community
> sticks its head in the sand and tries to claim the issues affecting
> other operating systems do not apply to VMS.

It is even worse.

There are some that actually use the lack of security bug fixes as
"proof" that VMS is more secure.

>> Btw - while the finger bug was something that needed fixing, one should
>> remember that the service is disabled by default and I have never known
>> any OpenVMS system that even uses finger. It was/is a service that came
>> from the UNIX based code that was ported to OpenVMS as UCX.
>>
>
> That's not the point. The point is that the code should never have
> passed peer review.

Nobody should expect code review to find all problems.

Just like static code analysis, unit tests, real test etc.
does not find all problems either.

But when combined they find a large portion of bugs.

Still some get through.

Which is why a vulnerability reporting mechanism and
an effective patch delivery mechanism are needed.

Arne

[David Froble]

Simon Clubley wrote:
> On 2017-07-29, Kerry Main <kemain...@gmail.com> wrote:
>> Or.. since we doing the "lets do some pure 100% speculating", the
>> alternate speculating might be that the security researchers tried to
>> hack recent (not 15+ year old UCX bugs) versions of OpenVMS and they
>> gave up trying.
>>
>> Since neither of us know which scenario is true, then either one of us
>> could be right.
>>
>
> The DCL bug I found recently appears to have laid dormant within VMS
> for at least a couple of decades until I decided on a whim to fuzz
> the DCL recall buffer one Sunday.

I'm sure there are many things that could cause problems. However, during
normal usage, how often will someone attempt to flood the recall buffer with
nulls? I'm not defending the lack of some sanity checking. But it didn't seem
to be a security issue.

If all you want to do is crash the computer, just pull the plug ...

See how easy that was?

I learned long ago that if while taking specs for something, and you hear the
words "that never happens", count on that being one of the first things that
bites you. So, the lesson should be, vet all input data, completely. Not
always done.

> I may have just got lucky but it only took me several minutes to
> crash DCL. Finding the cause of the crash took a lot longer however
> due to my limited free time at the moment and especially since my
> initial assumption about the cause of the crash was wrong. :-)
>
> My point is: How many other bugs are just waiting to be discovered
> in VMS and will the next one turn out to be a security vulnerability ?

I'm going to predict that most won't be security issues. Some will.

>> Especially when the value of security bugs that can crack a platform
>> that runs stock exchanges, banks, lotteries, nuclear stations, power
>> utilities would likely go for a very high price in the bad guy world.
>>
>
> And it doesn't help matters when certain portions of the VMS community
> sticks its head in the sand and tries to claim the issues affecting
> other operating systems do not apply to VMS.

I think those people are few.

> And given that list of _very_ high value targets above, VSI should be
> gearing up to detect and stop nation state attacks against VMS and the
> VSI VMS development infrastructure just like some other vendors do with
> their own critical infrastructure products.

So, they need to install surface to air missiles?

> Instead at the moment, we have a vendor that can't even be bothered to
> put on its website the security reporting mechanism Clair says he had
> people write towards the end of last year.

That's really bugging you, huh?

>> Btw - while the finger bug was something that needed fixing, one should
>> remember that the service is disabled by default and I have never known
>> any OpenVMS system that even uses finger. It was/is a service that came
>> from the UNIX based code that was ported to OpenVMS as UCX.
>>
>
> That's not the point. The point is that the code should never have
> passed peer review.

That wasn't really a VMS issue, other than the mistake of adopting *ix junk.

[Bob Koehler]

In article <olm89k$ql5$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>
> If all you want to do is crash the computer, just pull the plug ...
>
> See how easy that was?

No. That option went away with laptops. Unless the battery is bad.

You have to be able to remove the baterry, which isn't always
trivial.

[David Froble]

Well, in that case, a hammer might work.

Or, just take away the charger. Time delayed crash.

[Stephen Hoffman]

On 2017-07-30 00:48:38 +0000, Kerry Main said:

>>
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
>> Simon Clubley via Info-vax
>> Sent: July 25, 2017 2:20 PM
>> To: info...@rbnsn.com
>> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: Re: [Info-vax] OpenVMS books
>>

>> As soon as some security researchers spent the time to find out a
>> little _something_ about VMS internals, they discovered pure VMS
>> vulnerabilities (ie: SMG) which the earlier researchers had missed.
>>
>> The low figures could simply mean that to date no-one has been
>> motiviated enough recently to learn enough about VMS internals in order
>> to be able to probe it for vulnerabilities using modern probing
>> techniques.
>
> Or.. since we doing the "lets do some pure 100% speculating", the
> alternate speculating might be that the security researchers tried to
> hack recent (not 15+ year old UCX bugs) versions of OpenVMS and they
> gave up trying

I have accrued a list of several hundred CVEs that I suspect or that I
know apply to OpenVMS and various LPs. I track security
notifications as part of helping me understand attacks and to help
customers manage their servers. (A number of these CVEs were acquired
from lists of Linux CVEs that have been occasionally referenced here in
comp.os.vms, too.)

But for many of these sites, there's little point in the effort when
the operating system still offers and many folks are still using
telnet, FTP and DECnet with OpenVMS, too.

VSI is moving forward on some of the security issues that have been
reported here, and VSI IP will certainly address a number of CVEs,
though there are other issues discussed here that are more involved and
far more complex to resolve. Downside is that this security treadmill
doesn't ever end. As one popular comment goes: "servers are 'secured'
like lawns are 'mowed'".

VSI clearly has a whole lot on their plans and their development
schedules, too. Security is one part of that plan and those
schedules, but there's other fundamental work that is necessary for
OpenVMS and not the least of which is the x86-64 port. In the
interim, some of the security work can continue to be deferred by
informing folks to isolate certain traffic on private networks for
OpenVMS servers or other similar remediations, though that sort of
server and network isolation is increasingly difficult to sustain.

[Simon Clubley]

On 2017-07-30, David Froble <da...@tsoft-inc.com> wrote:

> Simon Clubley wrote:
>>
>> The DCL bug I found recently appears to have laid dormant within VMS
>> for at least a couple of decades until I decided on a whim to fuzz
>> the DCL recall buffer one Sunday.
>
> I'm sure there are many things that could cause problems. However, during
> normal usage, how often will someone attempt to flood the recall buffer with
> nulls? I'm not defending the lack of some sanity checking. But it didn't seem
> to be a security issue.
>

_This_ time it wasn't a security issue. What about next time ?

>> And given that list of _very_ high value targets above, VSI should be
>> gearing up to detect and stop nation state attacks against VMS and the
>> VSI VMS development infrastructure just like some other vendors do with
>> their own critical infrastructure products.
>
> So, they need to install surface to air missiles?
>

The very fact you make that comment means you don't understand the
issues involved.

For a really simple example, have VSI considered the possibility of
a Quantum Insert attack against their development infrastructure ?

I would remind you of what happened to some Belgium telecommunications
employees who were reading Slashdot. (It doesn't have to be Slashdot
BTW, it could be a genuine work related website.)

>> Instead at the moment, we have a vendor that can't even be bothered to
>> put on its website the security reporting mechanism Clair says he had
>> people write towards the end of last year.
>
> That's really bugging you, huh?
>

Yes, and for reasons which should be very obvious to anyone who even
vaguely understands the current security environment and the standard
practices in that environment.

For example, VSI management are making these grandiose claims about VMS
on their website by comparing VMS to Linux and other operating systems
but then VSI doesn't even implement the same security reporting
infrastructure as those other operating systems.

That comes across as showing a lack of understanding that the security
environment of today, and what is expected by an OS vendor operating
today, is very different from the 1990s. This is especially true when
VSI can't even be bothered to put on their website something as simple
as a secure reporting mechanism even when Clair has apparently done the
work for them.

>>
>> That's not the point. The point is that the code should never have
>> passed peer review.
>
> That wasn't really a VMS issue, other than the mistake of adopting *ix junk.

If I understood the problem report correctly, the code was of the
general form (with either printf or another string function):

printf(untrusted_string);

If true, that should have been caught instantly during code review.

The CVE summary is at: http://www.cvedetails.com/cve/CVE-2008-3940/

BTW, while looking for the above CVE, I also came across this one which
I had forgotten about:

http://www.cvedetails.com/cve/CVE-2008-3946/

[David Froble]

Simon Clubley wrote:
> On 2017-07-30, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> The DCL bug I found recently appears to have laid dormant within VMS
>>> for at least a couple of decades until I decided on a whim to fuzz
>>> the DCL recall buffer one Sunday.
>> I'm sure there are many things that could cause problems. However, during
>> normal usage, how often will someone attempt to flood the recall buffer with
>> nulls? I'm not defending the lack of some sanity checking. But it didn't seem
>> to be a security issue.
>>
>
> _This_ time it wasn't a security issue. What about next time ?
>
>>> And given that list of _very_ high value targets above, VSI should be
>>> gearing up to detect and stop nation state attacks against VMS and the
>>> VSI VMS development infrastructure just like some other vendors do with
>>> their own critical infrastructure products.
>> So, they need to install surface to air missiles?
>>
>
> The very fact you make that comment means you don't understand the
> issues involved.

No, it means I have a wicked sense of humor ....

> For a really simple example, have VSI considered the possibility of
> a Quantum Insert attack against their development infrastructure ?
>
> I would remind you of what happened to some Belgium telecommunications
> employees who were reading Slashdot. (It doesn't have to be Slashdot
> BTW, it could be a genuine work related website.)
>
>>> Instead at the moment, we have a vendor that can't even be bothered to
>>> put on its website the security reporting mechanism Clair says he had
>>> people write towards the end of last year.
>> That's really bugging you, huh?
>>
>
> Yes, and for reasons which should be very obvious to anyone who even
> vaguely understands the current security environment and the standard
> practices in that environment.

When the x86 port and such is done, then perhaps your insistence will be more
appropriate.

> For example, VSI management are making these grandiose claims about VMS
> on their website by comparing VMS to Linux and other operating systems
> but then VSI doesn't even implement the same security reporting
> infrastructure as those other operating systems.
>
> That comes across as showing a lack of understanding that the security
> environment of today, and what is expected by an OS vendor operating
> today, is very different from the 1990s. This is especially true when
> VSI can't even be bothered to put on their website something as simple
> as a secure reporting mechanism even when Clair has apparently done the
> work for them.
>
>>> That's not the point. The point is that the code should never have
>>> passed peer review.
>> That wasn't really a VMS issue, other than the mistake of adopting *ix junk.
>
> If I understood the problem report correctly, the code was of the
> general form (with either printf or another string function):
>
> printf(untrusted_string);
>
> If true, that should have been caught instantly during code review.
>
> The CVE summary is at: http://www.cvedetails.com/cve/CVE-2008-3940/
>
> BTW, while looking for the above CVE, I also came across this one which
> I had forgotten about:
>
> http://www.cvedetails.com/cve/CVE-2008-3946/
>
> Simon.
>

I don't disagree with much of what you write, not just now. However, I feel
your priorities may be a bit skewed, at least for now. The x86 port isn't
everything, it's the ONLY thing. (Credit to Vince Lombardi)

Another thing is, it seems that you feel that security is the job of the vendor.
Perhaps, as far as sorta secure code goes. But the buck stops with the end
user, who must define their vulnerabilities, and see that they are protected.

[Simon Clubley]

On 2017-07-31, David Froble <da...@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>>
>> Yes, and for reasons which should be very obvious to anyone who even
>> vaguely understands the current security environment and the standard
>> practices in that environment.
>
> When the x86 port and such is done, then perhaps your insistence will be more
> appropriate.
>

[snip]

> I don't disagree with much of what you write, not just now. However, I feel
> your priorities may be a bit skewed, at least for now. The x86 port isn't
> everything, it's the ONLY thing. (Credit to Vince Lombardi)
>

Tell me David, do you think the x86 code is suddenly going to come into
existence 24 hours before the product is released ?

No, that code is being written today in 2017, in the security environment
that exists today, and, in addition to any newly introduced vulnerabilities,
the same vulnerabilities currently present in VMS will also be present in
that new code as well.

VSI doesn't need to start worrying about working in today's security
environment 24 hours before the finished product is shipped. They needed
to start worrying before the first new line of code for that new product
was written.

> Another thing is, it seems that you feel that security is the job of the vendor.
> Perhaps, as far as sorta secure code goes. But the buck stops with the end
> user, who must define their vulnerabilities, and see that they are protected.

And those same end users and others have the right to expect the vendor
to conform to current security standards, including being able to report
security issues to the vendor using a secure and trusted path.

[David Froble]

Simon Clubley wrote:

> Tell me David, do you think the x86 code is suddenly going to come into
> existence 24 hours before the product is released ?

It's my impression that Clair understands project creep very well, and has
decided to port what exists, where possible, without any changes. This is most
likely the only way the project will be completed.

A while back I sent him a study on what I thought would be a rather easy, and
proper, method to incorporate numeric range locking in the DLM. I don't expect
to see such until after the port is completed, and VSI contemplates new work.
Little things such as this would cause project creep, and once you start that,
it seems to never end.

Your security issues fit into this category. I'm sure that some are being
addressed, but, that list will most likely be short and non-expandable, until
VMS is running on x86.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: July 30, 2017 4:37 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>

First - all security holes need to be identified and fixed.

Having stated this, remember:
- this service is off by default
- is seldom, if ever, turned on in OpenVMS by any Customer
- is in the order of 20 year old third party code

Lets ask a similar question about Linux (or Windows) today -

Why does Red Hat have to publish 20-30 Linux security fixes each and
EVERY month?

Should not these many, many monthly security issues not have been found
with "peer review"?

<https://www.redhat.com/archives/enterprise-watch-list>
(click on thread for each month and add them up your self)

Note - this RH list is now disabled - likely because it was getting
embarrassing.
<https://www.redhat.com/mailman/listinfo/enterprise-watch-list>

The same question could be asked about all of the many monthly Windows
server security issues.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: July 30, 2017 4:37 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>

> Subject: [Info-vax] VMS security, was: Re: OpenVMS books
>

That other platform security issues MAY not impact OpenVMS is a fact.

Different architecture, different security mechanisms, some different
code implemented in porting, lots of difference between OpenVMS and
Windows / Linux. A system wide priv escalation issue on Linux may simply
abort on OpenVMS with a process access error.

Course, this is not to say that other platform / app security issues
will NOT impact OpenVMS. This is obviously NOT the case.

The point is that just because a security issue exists in Windows/Linux
does not automatically mean it applies to OpenVMS and/or even if it
does, whether the impact will be the same.

Yes, and I do agree that all security issues that do impact OpenVMS need
to be fixed.

[snip..]

[Steven Schweda]

> Why does Red Hat have to publish 20-30 Linux security fixes
> each and EVERY month?

Perhaps because they're looking for such problems, and
fixing them.

> The same question could be asked about all of the many
> monthly Windows server security issues.

Perhaps because they're looking for such problems, and
fixing them.

https://groups.google.com/d/msg/comp.os.vms/4j13FA005S0/6Rduc3RQBgAJ

> Yes, and I do agree that all security issues that do impact
> OpenVMS need to be fixed.

And yet, vendors which do exactly that for their products
seem to earn your scorn for doing so. It's a puzzlement.

[Scott Dorsey]

Steven Schweda <sms.an...@gmail.com> wrote:
>> Why does Red Hat have to publish 20-30 Linux security fixes
>> each and EVERY month?
>
> Perhaps because they're looking for such problems, and
>fixing them.

That's a lot of it.

Some of it is because Red Hat comes with everything, and when you ship
everything, you have to provide fixes for everything. The Red Hat kit
isn't just the OS, it also includes most applications anyone would ever
want.

And some of it because some of those security fixes, if you look carefully,
turn out not really to be fixes at all but attempts to add additional
functionality.

The nice thing is that if you run a Red Hat system and tailor off the
packages you don't need, likely you will not have to deal with more than
one or two actual security fixes a year. If you install everything, though,
you'll have to patch everything. If you install javascript libraries, you'll
be patching them weekly.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of

> Steven Schweda via Info-vax
> Sent: August 5, 2017 1:13 PM
> To: info...@rbnsn.com
> Cc: Steven Schweda <sms.an...@gmail.com>
> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>
> > Why does Red Hat have to publish 20-30 Linux security fixes
> > each and EVERY month?
>
> Perhaps because they're looking for such problems, and
> fixing them.
>

The point I was making was in response to Simon's criticism of a 20+
year old security issue on OpenVMS (finger is off by default and not
used by 99% of OpenVMS Customers) that this issue should have been found
with a proper peer review.

So, following the same train of logic, why are these 20-30 security
Linux fixes per month not found by peer review before each new Linux
update is released?

At what point do you begin to ask "in the mad and very competitive rush
to release new functionality, are the Linux release updates not getting
proper peer review?"

[and yes, I would ask the same thing about Windows as well]

[snip...]

[Simon Clubley]

On 2017-08-06, Kerry Main <kemain...@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
>> Steven Schweda via Info-vax
>> Sent: August 5, 2017 1:13 PM
>> To: info...@rbnsn.com
>> Cc: Steven Schweda <sms.an...@gmail.com>
>> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>>
>> > Why does Red Hat have to publish 20-30 Linux security fixes
>> > each and EVERY month?
>>
>> Perhaps because they're looking for such problems, and
>> fixing them.
>>
>
> The point I was making was in response to Simon's criticism of a 20+
> year old security issue on OpenVMS (finger is off by default and not
> used by 99% of OpenVMS Customers) that this issue should have been found
> with a proper peer review.
>

I noticed you completely ignored the bit about how I decided to fuzz
DCL one Sunday and then promptly discovered a dormant bug that looks
to be at least 20 years old.

Of course, that doesn't play into your agenda of downplaying any VMS
issues instead of facing them head on and then pushing for changes
which would make VMS more secure.

Hiding the issues only gives the illusion of security. OTOH, tackling
the issues and then asking how can we make things better in the future
provides improved security.

BTW, that bug wasn't exploitable. What about the next bug someone finds ?

[David Froble]

Simon Clubley wrote:
> On 2017-08-06, Kerry Main <kemain...@gmail.com> wrote:
>>> -----Original Message-----
>>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
>>> Steven Schweda via Info-vax
>>> Sent: August 5, 2017 1:13 PM
>>> To: info...@rbnsn.com
>>> Cc: Steven Schweda <sms.an...@gmail.com>
>>> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>>>
>>>> Why does Red Hat have to publish 20-30 Linux security fixes
>>>> each and EVERY month?
>>> Perhaps because they're looking for such problems, and
>>> fixing them.
>>>
>> The point I was making was in response to Simon's criticism of a 20+
>> year old security issue on OpenVMS (finger is off by default and not
>> used by 99% of OpenVMS Customers) that this issue should have been found
>> with a proper peer review.
>>
>
> I noticed you completely ignored the bit about how I decided to fuzz
> DCL one Sunday and then promptly discovered a dormant bug that looks
> to be at least 20 years old.

Don't know how appropriate the term "bug" may be in that case. I guess we can
each define the term in whatever way we desire.

I'm sure there are lots of instances in just about all software where bogus
input can cause unexpected actions. I'm also sure that even you will admit that
stuffing the recall buffer with nulls might be termed bogus input.

What you had there was an untrapped condition.

> Of course, that doesn't play into your agenda of downplaying any VMS
> issues instead of facing them head on and then pushing for changes
> which would make VMS more secure.
>
> Hiding the issues only gives the illusion of security. OTOH, tackling
> the issues and then asking how can we make things better in the future
> provides improved security.
>
> BTW, that bug wasn't exploitable. What about the next bug someone finds ?

Overall, I'm guessing that the VMS software developers produced reasonable code.
Adapting some stuff others have written, such as IP utilities, might be more
chancy. Still it was distributed with VMS, and so the entire product is only as
good as it's weakest point.

[Richard Maher]

While flicking through the channels just the other day I was very
surprised to see Larry King still alive let alone working.

Anyway he had a guy on flogging his book. Now it may not astonish some
to know I have never read a single book cover to cover in my life but
I'd like to hear more aabout this one: -

"The Big Lie"
Exposing the Nazi roots
of the American Left

It's by a bloke called Dinesh D'Souza

[Simon Clubley]

On 2017-08-06, David Froble <da...@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2017-08-06, Kerry Main <kemain...@gmail.com> wrote:
>>> The point I was making was in response to Simon's criticism of a 20+
>>> year old security issue on OpenVMS (finger is off by default and not
>>> used by 99% of OpenVMS Customers) that this issue should have been found
>>> with a proper peer review.
>>>
>>
>> I noticed you completely ignored the bit about how I decided to fuzz
>> DCL one Sunday and then promptly discovered a dormant bug that looks
>> to be at least 20 years old.
>
> Don't know how appropriate the term "bug" may be in that case. I guess we can
> each define the term in whatever way we desire.
>

DCL lost control of the situation and crashed. That makes it a bug.

> I'm sure there are lots of instances in just about all software where bogus
> input can cause unexpected actions.
>

There's a section in the Ada 95 Quality and Style Guide which sums up
my attitude here perfectly:

|The statement that "it can never happen" is not an acceptable programming
|approach. You must assume it can happen and be in control when it does. You
|should provide defensive code routines for the "cannot get here" conditions.

See:

http://www.adaic.org/resources/add_content/docs/95style/html/sec_5/5-8-3.html

> I'm also sure that even you will admit that
> stuffing the recall buffer with nulls might be termed bogus input.
>

And that's exactly the point. When looking for security issues, one of
the things you try is to generate various inputs that a program would
normally never see.

Large numbers of security issues have been found by doing exactly this.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of

> Simon Clubley via Info-vax
> Sent: August 6, 2017 5:37 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>

Bad or crazy inputs to program can easily crash a process or result in
access violation or whatever errors .

The same is true for when programming with punch cards.

> Of course, that doesn't play into your agenda of downplaying any VMS
> issues instead of facing them head on and then pushing for changes
> which would make VMS more secure.
>

You are making things up.

My "agenda" has always been that OpenVMS does need security
improvements. No platform is 100% secure.

I just do not subscribe to the "sky is falling" philosophy.

> Hiding the issues only gives the illusion of security. OTOH, tackling
> the issues and then asking how can we make things better in the future
> provides improved security.
>
> BTW, that bug wasn't exploitable. What about the next bug someone
> finds ?
>
> Simon.
>

Then it will be identified and fixed.

VSI has stated they know OpenVMS needs security improvements.
Enhancements to OpenVMS security are in the roadmap, so these will help.


Knowing the folks involved as well as the Eng culture, I am very
comfortable believing any OpenVMS security issue that is identified will
be fixed.

Just as I am comfortable knowing that the commodity OS's will continue
to release their 20-30 security issues that they have been doing each
and every month for the last few years. There is no reason to believe
that this large number of monthly security patches trend is not going to
continue every month into the future.

Having stated this, no platform is 100% secure, so I fully expect there
will be future security issues that will need to be resolved in OpenVMS.
I do not think anyone here on c.o.v. would state otherwise.

[Stephen Hoffman]

On 2017-08-07 12:22:30 +0000, Kerry Main said:

> Bad or crazy inputs to program can easily crash a process or result in
> access violation or whatever errors .
>
> The same is true for when programming with punch cards.

Alas, we are not in the same environment as when punched cards were used.

Bugs in input sanitization and input validation are very common security bugs.

Code that tosses an access violation is always interesting to an
attacker, whether as a denial-of-service or as the foundation for an
exploit. I'm aware of OpenVMS access violations that were
exploitable, too.

> Then it will be identified and fixed.

For some vulnerabilities, probably. But not for some years for other
identified vulnerabilities, and that's at the earliest. Some of the
security problems in OpenVMS security are rather more entrenched and
remediation and testing and app and customer migrations will be
involved, and some will involve multi-year migrations to more secure
configurations. Getting SCS authenticated and operating over DTLS
and/or via TLS/SCTP (RFC 3436) will be a fair change to OpenVMS and to
clustering, for instance. (Securing the current SCS over UDP/IP
(IPCI) implementation; IP addresses can be spoofed.) Removing DECnet,
ftp and telnet harder to get at, or removing those. Dragging the
security implementation forward from the ad-hoc certificate
implementation and the long-deprecated CDMA bits. Keeping the ported
components current doesn't ever end, and will be speeding up, too.
Haven't gone digging for the latest OpenSSL patches, but it appears
that 1.0.2g is apparently current from HPE, 1.0.2l (L) is current from
OpenSSL.org....

All things that haven't been fixed, and that'll take a while to fix.
But the x86-64 port and the profits must come first and foremost, and
must be both stable and increasing, of course.

BTW, on the subject of down-revision ports... Debian is prototyping
the blocking of TLS prior to 1.2. That'll make interoperation with
OpenVMS and other down-revision configurations more interesting, if
that change makes it into the released versions.

ps: if any vendor markets their software product as "the most secure
operating system on the planet", then it's expected that some folks are
going to be skeptical of the claims, and others will look into the
details of security implementation. Some folks will report those bugs
to the vendor, some will sit on them, and some will exploit them.
Because we're not in the era of punched cards. But for those folks
still using those punched cards, do validate everything being read.

[Stephen Hoffman]

On 2017-08-05 14:30:17 +0000, Kerry Main said:

> Lets ask a similar question about Linux (or Windows) today -
>
> Why does Red Hat have to publish 20-30 Linux security fixes each and
> EVERY month?
>
> Should not these many, many monthly security issues not have been found
> with "peer review"?

Yes, Linux gets a number of bugs found, but then Linux also sees far
more widespread use than OpenVMS, what those bug reports are
encompassing is a whole lot larger and more complex than OpenVMS is,
and yes, Linux definitely gets a whole lot more code review than does
OpenVMS. Some of those same security bugs eventually get fixed in
OpenVMS, too.

If OpenVMS were of the scale of Linux and with a sizable fraction of
the Linux user base, there'd be more bugs and more bugs found, too.
As many as Linux gets? No sé. I also don't know the metrics for the
code base, and VSI is probably only just getting a grasp of that sort
of data. As for bug counts, it takes just one that gets found and
exploited to ruin our day.

But then we're also counting CVEs again, and neither VSI nor HPE
development have seemingly subscribed to that mechanism. We've
previously identified public security fixes with no associated CVEs,
for instance.

[Stephen Hoffman]

On 2017-08-07 15:02:00 +0000, Stephen Hoffman said:

> Yes, Linux gets a number of bugs found, but then Linux also sees far
> more widespread use than OpenVMS, what those bug reports are
> encompassing is a whole lot larger and more complex than OpenVMS is,
> and yes, Linux definitely gets a whole lot more code review than does
> OpenVMS. Some of those same security bugs eventually get fixed in
> OpenVMS, too.

Just bumped into this one today, amid the collection of Linux bug reports...

Apache HTTP Server CVE-2017-7679 Buffer Overflow Vulnerability

"In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_mime
can read one byte past the end of a buffer when sending a malicious
Content-Type response header."

OpenVMS CSWS/SWS/Apache is 2.4-12.

This treadmill doesn't end, which hopefully eventually means better
patch-management tools and better patch notification management.

[Simon Clubley]

On 2017-08-07, Kerry Main <kemain...@gmail.com> wrote:
>
> Bad or crazy inputs to program can easily crash a process or result in
> access violation or whatever errors .
>

Stephen has already answered this one.

>
> Knowing the folks involved as well as the Eng culture, I am very
> comfortable believing any OpenVMS security issue that is identified will
> be fixed.
>

It's now approximately a full year since I started raising the idea that
VSI _really_ needs a secure security reporting mechanism on their website,
just like every other OS vendor out there.

Perhaps someone attending this year's Bootcamp could ask the VSI management
approximately what year they will get around to placing Clair's security
reporting mechanism on the VSI website.

Might also be a good idea to ask at the same time if VSI are set up to
analyze problem reports and produce tested patches within the 60 day
or so embargo period which the responsible disclosure protocols
typically use.

[Bob Koehler]

In article <mailman.3.1502022728.2...@rbnsn.com>, "Kerry Main" <kemain...@gmail.com> writes:
>
> At what point do you begin to ask "in the mad and very competitive rush
> to release new functionality, are the Linux release updates not getting
> proper peer review?"
>
> [and yes, I would ask the same thing about Windows as well]

You don't ave to ask. The answer is known to be "NO".

[Richard Maher]

I've ordered 3 of the second release!
http://www.bbc.com/news/world-us-canada-40848372

You just can't make this shit up :-)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of

Rather than getting better tools to collect the cows and bring them back
after they have left the barn, at some future point, perhaps someone
will ask "maybe its time we found a better way to secure the barn BEFORE
the cows get out?"

Lets face it - when something as massive and has as many different
contributors from many different backgrounds and cultures as Linux, one
has to ask how all of this is being "peer reviewed" before it leaves the
shop.

Btw - CVE-2017-7679 - from Apache web site-

Reported to security team - 15th November 2015
Issue public - 19th June 2017
Update Released - 19th June 2017

Not exactly the quickest turnaround.

[Arne Vajhøj]

On 8/7/2017 8:22 AM, Kerry Main wrote:
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
>> Simon Clubley via Info-vax

>> I noticed you completely ignored the bit about how I decided to fuzz
>> DCL one Sunday and then promptly discovered a dormant bug that looks
>> to be at least 20 years old.
>
> Bad or crazy inputs to program can easily crash a process or result in
> access violation or whatever errors.

Only if the program has a bug.

Correct programs will inform the user about the bad input and
not crash.

> VSI has stated they know OpenVMS needs security improvements.
> Enhancements to OpenVMS security are in the roadmap, so these will help.
>
>
> Knowing the folks involved as well as the Eng culture, I am very
> comfortable believing any OpenVMS security issue that is identified will
> be fixed.
>
> Just as I am comfortable knowing that the commodity OS's will continue
> to release their 20-30 security issues that they have been doing each
> and every month for the last few years. There is no reason to believe
> that this large number of monthly security patches trend is not going to
> continue every month into the future.

And until VMS get the same 20-30 security fixes everyone smart will
know that either VMS is missing a lot of functionality or VMS is
getting fewer of its bugs fixed (aka is less secure) than the
competition.

Neither are good sales points.

Arne

[Stephen Hoffman]

On 2017-08-08 01:09:21 +0000, Kerry Main said:

>>
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
>> Stephen Hoffman via Info-vax
>> Sent: August 7, 2017 12:17 PM
>> To: info...@rbnsn.com
>> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
>> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>>
>>

>> OpenVMS CSWS/SWS/Apache is 2.4-12.
>>
>> This treadmill doesn't end, which hopefully eventually means better
>> patch-management tools and better patch notification management.
>
> Rather than getting better tools to collect the cows and bring them
> back after they have left the barn, at some future point, perhaps
> someone will ask "maybe its time we found a better way to secure the
> barn BEFORE the cows get out?"

Yes, there is. I'd certainly like perfection, but there's been little
evidence of improving trends in vulnerabilities, and exploits are only
going to circulate more quickly. The inclusion of new dependent
packages is likely to increase, and updates and patches for many
existing dependencies aren't likely to slow. I don't see OpenVMS
being at all unique here either, particularly as OpenVMS becomes more
widely used as VSI and I and most folks here would prefer it. Which
then means taking design and technical steps to detect, avoid, contain
and isolate vulnerabilities. This includes compiler features and
static analysis tools to spot latent issues, fuzzing tools, reworking
and replacing and deprecating difficult and problematic interfaces, and
run-time features intended to make exploitation more difficult. To
review older designs and older source code for correctness in the
current and expected environment. And to patch much more easily and
quickly, and potentially establishing coordinated disclosure policies
and other updates. To rework and to harden apps, too.

Or we can attempt to stay aboard the ever-faster treadmill of the
current software security approach, of course.

> Lets face it - when something as massive and has as many different
> contributors from many different backgrounds and cultures as Linux, one
> has to ask how all of this is being "peer reviewed" before it leaves
> the shop.

Ayup. Linux, BSD and other platforms are implementing various
security to attempt to isolate and to contain potential breaches, too.

> Btw - CVE-2017-7679 - from Apache web site-
>
> Reported to security team - 15th November 2015
> Issue public - 19th June 2017
> Update Released - 19th June 2017
>
> Not exactly the quickest turnaround.

Ayup. "Not exactly the quickest turnaround", as you've put it. VSI
Apache is based on Apache 2.4.12, and that was released on 29-Jan-2015.
The HPE Apache 2.2-1 release is based on ~2.0.65 and dates from
July, 2013.

I've not noticed that HPE and VSI have particularly updated Apache CVEs
or other packages to mention OpenVMS either, but then that does help
make your CVE-count comparisons look better.

But then I'd prefer that OpenVMS be marketed with better recognition
around the current and the near-term-future operating system market.
Top hit on Google for "the most secure operating system on the planet"
is VSI, and the use of what I consider to be absurd and detrimental
quotes — and the similarly absurd comparisons of CVE counts, for that
matter — certainly aren't helping the perception of the OpenVMS
platform among other folks. I'd prefer not to see the OpenVMS
marketing efforts backfire. To avoid making unforced errors. This
particularly as VSI works to move beyond the installed base, and as VSI
OpenVMS and OpenVMS users inexorably become subjects of vulnerability
research as port becomes more widely known and the platform becomes
more interesting to wholly new-to-OpenVMS folks.

The VSI folks certainly have to be extremely selective about what they
do work on, and they have massive piles of very challenging design and
development work ahead of them. This while providing clear paths for
existing customers to move forward to newer OpenVMS capabilities and
versions and to improved security, and to avoid the costs and the
effort involved with replacing or with porting existing apps to other
platforms. VSI has fodder for some good messages here for continuing
to reinvigorate and expand the installed base, too.

[johnwa...@yahoo.co.uk]

VMS *is* undeniably missing a lot of functionality which is
taken for granted in the commodity OSes.

How much of that functionality is important to VMS users
(past, present, and potential)?

Another way of describing VMS's not-implemented functionality
is that VMS has a reduced attack surface. Having a "reduced
attack surface" is surely a good sales point, right?

How many of Linux's CVEs describe stuff that few realistic
users would ever need, stuff which could readily be
configured out on Linux, but which is frequently left in
ready and waiting to be exploited in vulnerable setups
(recent example: CVE-2017-2636, involving the HDLC line
discipline in the tty driver).

Is having an HDLC protocol driver a good sales point?
Is having a vulnerable and exploitable HDLC protocol
driver a good sales point?

Is having a defective by design software setup as a
core component of almost every IoT widget on the market
a good sales point?

There's room for a bit of engineering common sense in
this picture as well as the "my CVE count is bigger
than your CVE count" discussions. Whether it'll happen
is a different matter.

[johnwa...@yahoo.co.uk]

"Engineering common sense" includes (obviously) things
like careful design of code so that unexpected input
does not cause unexpected behaviour - which was Arne's
first point in the post to which I was replying, and
which I meant to (but forgot to) acknowledge explicitly.

Apologies. Mistakes always happen, the trick is to stop
them having much of an impact :)

[Stephen Hoffman]

On 2017-08-08 09:04:22 +0000, johnwa...@yahoo.co.uk said:

> VMS *is* undeniably missing a lot of functionality which is taken for
> granted in the commodity OSes.

Ayup.

> How much of that functionality is important to VMS users(past, present,
> and potential)?

To the folks planning to stay on OpenVMS, either some of the changes,
or comparatively little of it. Among the folks I'm dealing with, the
areas of interest tend to be around interoperation, and around data
security.

To the folks that have already decided to port off of OpenVMS?
They're either going, or they're gone. For various reasons.

To the folks that might port apps onto OpenVMS, or might port apps back
to OpenVMS, or that are writing wholly new apps targeting OpenVMS?
That's the sort of expansion that VSI wants.

> Is having a defective by design software setup as acore component of

> almost every IoT widget on the marketa good sales point?

Good enough and cheap enough to sell in volume wins more than a few markets.

The middle parts of many markets has gotten... thin.

As for IoT widgets and security? By present standards, I view the
OpenVMS installation and setup and management and patch process and
distributed security implementation as being un- or under-designed, and
the user interface somewhere between difficult and defective. Sure,
an established installed environment can be great and entirely stable,
but getting there takes far more knowledge and far more skill than it
really should. Than is competitive. (Yes, that statement goes
against interest.)

> There's room for a bit of engineering common sense inthis picture as

> well as the "my CVE count is biggerthan your CVE count" discussions.

There are areas where OpenVMS is still reasonably feature-competitive.
Most of the areas where OpenVMS was outright better than competitive
products have either faded due to changes and improvements in other
packages, or because the areas or the approaches are less interesting
to customers. There are some areas of OpenVMS that are particularly
problematic, and VSI is already working diligently to address a number
of those. Beyond this work — and as your other reply to Arne's
comments — there's a whole lot of work around isolating the problems
that are inevitable; access violations, making successful exploits of
vulnerabilities more difficult, contending with application and server
failures, patch deployments, crash uploads, logging, etc. Around
updating OpenVMS for 2022 and 2027. That's likely involving scheduling
and containers and sandboxes and LDAP and a whole lot more work, once
the x86-64 port is out and stable.

> Whether it'll happen is a different matter.

No sé. But all discussions of CVEs and counts aside, at the end of
every quarter VSI has to sell enough licenses and support contracts to
matter. BTW, anybody reading here that hasn't already started
looking at upgrading to V8.4-2L1/V8.4-2L2, go get yourself some quotes.

[Robert A. Brooks]

On 8/8/2017 11:58 AM, Stephen Hoffman wrote:

> No sé. But all discussions of CVEs and counts aside, at the end of
> every quarter VSI has to sell enough licenses and support contracts
> to matter. BTW, anybody reading here that hasn't already started
> looking at upgrading to V8.4-2L1/V8.4-2L2, go get yourself some
> quotes.

Our operators are standing by, waiting to serve you :-)

--

-- Rob

[David Froble]

Stephen Hoffman wrote:
> On 2017-08-08 01:09:21 +0000, Kerry Main said:
>
>>>
>>> -----Original Message-----
>>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
>>> Stephen Hoffman via Info-vax
>>> Sent: August 7, 2017 12:17 PM
>>> To: info...@rbnsn.com
>>> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
>>> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>>>
>>>
>>> OpenVMS CSWS/SWS/Apache is 2.4-12.
>>>
>>> This treadmill doesn't end, which hopefully eventually means better
>>> patch-management tools and better patch notification management.
>>
>> Rather than getting better tools to collect the cows and bring them
>> back after they have left the barn, at some future point, perhaps
>> someone will ask "maybe its time we found a better way to secure the
>> barn BEFORE the cows get out?"
>
> Yes, there is. I'd certainly like perfection, but there's been little
> evidence of improving trends in vulnerabilities, and exploits are only
> going to circulate more quickly. The inclusion of new dependent
> packages is likely to increase, and updates and patches for many
> existing dependencies aren't likely to slow.

Perhaps here is an area to re-visit. Too much dependence on some of the open
source utilities, and the ensuing exposure, might be counter-productive. Yes,
it makes soem things quicker to implement. But at what cost?

I don't really have much of a choice with TCP/IP and SSL. If VSI can improve
these tools, then I'll be in rather good shape. But I don't use a web server
(yet), gsoap, and such. Because of this, I'm not vulnerable to security issues
in such.

I produce my own programs for socket communications. Codis has it's own
protocol for the data used in the services offered. If we don't like the data
coming in, the connection is aborted. Even if the incoming data is in a valid
format, all that can be done is what the services offer, and, without a valid
customer record, which are not set up over the network, nothing is going to
happen. Even if a valid order goes through, nothing happens without valid
credit card data.

There are two sides to the issues, but, with our own protocols, it's my thinking
that we're less vulnerable to security issues.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of Arne
> Vajhøj via Info-vax
> Sent: August 7, 2017 10:22 PM
> To: info...@rbnsn.com
> Cc: Arne Vajhøj <ar...@vajhoej.dk>
> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>

Think about what you are saying .. "until OpenVMS gets (degrades?) to
the point where it has 20-30 security fixes required each and every
month like the commodity OS's, then the public will not view OpenVMS as
a viable OS.."

Or perhaps "the more security patches released each and every month, the
better the OS..."

Really?

So, the Linux and Windows of the world are free to release heavily
bloated code (huge numbers of developers from different cultures and
different views of the future) with all sorts of functionality (and
security issues) that many in the OpenVMS world may not even want.

Reminds me of Oracle where the saying is often heard "80% of their
Customers only use 20% of the available functionality". This is a key
reason for many reducing costs by moving to alternative solutions.

The future is not in bloated code with all sorts of security issues that
need to be constantly patched on a continual basis, but rather well
engineered code that is part of a well architected overall solution that
gets only occasional security issues (recognizing no platform is 100%
secure).

[Arne Vajhøj]

On 8/8/2017 9:32 PM, Kerry Main wrote:
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of Arne
>> Vajhøj via Info-vax

>>> Just as I am comfortable knowing that the commodity OS's will
>> continue
>>> to release their 20-30 security issues that they have been doing each
>>> and every month for the last few years. There is no reason to believe
>>> that this large number of monthly security patches trend is not going to
>>> continue every month into the future.
>>
>> And until VMS get the same 20-30 security fixes everyone smart will
>> know that either VMS is missing a lot of functionality or VMS is
>> getting fewer of its bugs fixed (aka is less secure) than the
>> competition.
>>
>> Neither are good sales points.
>

> Think about what you are saying .. "until OpenVMS gets (degrades?) to
> the point where it has 20-30 security fixes required each and every
> month like the commodity OS's, then the public will not view OpenVMS as
> a viable OS.."
>
> Or perhaps "the more security patches released each and every month, the
> better the OS..."
>
> Really?

Yes. Really.

If VMS:
* had all the software that Linux has an release fixes for
* released fixes for all bugs found
then VMS having fewer bugs than Linux would be an indication
of quality.

But neither is true.

You can take the Linux list and go through it and see how much
is available for VMS. Only a small fraction.

And I think Hoff has already explained that a lot of unfixed bugs
in VMS exists.

Arne

[Arne Vajhøj]

On 8/8/2017 9:32 PM, Kerry Main wrote:

> So, the Linux and Windows of the world are free to release heavily
> bloated code (huge numbers of developers from different cultures and
> different views of the future) with all sorts of functionality (and
> security issues) that many in the OpenVMS world may not even want.
>
> Reminds me of Oracle where the saying is often heard "80% of their
> Customers only use 20% of the available functionality". This is a key
> reason for many reducing costs by moving to alternative solutions.
>
> The future is not in bloated code with all sorts of security issues that
> need to be constantly patched on a continual basis, but rather well
> engineered code that is part of a well architected overall solution that
> gets only occasional security issues (recognizing no platform is 100%
> secure).

Maybe VMS customers do not need all that software. They need some
of it. But probably not all.

And that is fine. One size does not fit all. no one say that
all OS should have everything.

But everybody should then just realize that comparing absolute
number of bug fixes is dishonest.

Arne

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of Arne
> Vajhøj via Info-vax

> Sent: August 8, 2017 9:44 PM
> To: info...@rbnsn.com
> Cc: Arne Vajhøj <ar...@vajhoej.dk>
> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>

So, by your logic, the more recalls and/or firmware fixes a car has every year, the better the car quality?

I wonder how this rational would work in any other market?

After all, it must means the Engineers are constantly looking for problems - right?

The quality has nothing to do with the Engineering and culture of the company building the car - right?

> But neither is true.
>
> You can take the Linux list and go through it and see how much
> is available for VMS. Only a small fraction.
>

Of course it would be good to get additional features built into OpenVMS.

However, I would rather see much less functionality if it meant having to release 20-30 security fixes each and every month for OpenVMS.

> And I think Hoff has already explained that a lot of unfixed bugs
> in VMS exists.
>
> Arne
>

Never stated OpenVMS did not need improvements. Undoing 20 years of neglect by its former owners is not something that gets fixed over night.

The fact that so many Customers in critical environments still use OpenVMS is a tribute to the engineering and culture of those that designed and built OpenVMS.

[Arne Vajhøj]

On 8/8/2017 10:05 PM, Kerry Main wrote:
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of Arne
>> Vajhøj via Info-vax

>>> Or perhaps "the more security patches released each and every
>> month, the
>>> better the OS..."
>>>
>>> Really?
>>
>> Yes. Really.
>>
>> If VMS:
>> * had all the software that Linux has an release fixes for
>> * released fixes for all bugs found
>> then VMS having fewer bugs than Linux would be an indication
>> of quality.
>
> So, by your logic, the more recalls and/or firmware fixes a car has
> every year, the better the car quality?

A car where a problem with lane change warning get fixed is better than
a car where it does not get fixed and a car without the feature.

A car that had the feature without the problem would be even
better.

But questionable whether such OS'es or cars exist.

> I wonder how this rational would work in any other market?

Have you heard that people are stopping buying cars due to recalls?

> After all, it must means the Engineers are constantly looking for problems - right?

Old joke:

"If debugging is the process of removing bugs, then programming must be
the process of putting them in. "

:-)

> The quality has nothing to do with the Engineering and culture of the
> company building the car - right?

It has a huge impact in small scale.

Much less in large scale.

Very few companies has only top talent.

And large companies does simply not have the option of going
with only top talent.

For large groups of developers the bell curve rules: some good,
a lot mediocre and some hopeless.

Arne

[David Froble]

Well, yes, that's correct. But, Kerry has his agenda.

[David Froble]

Arne Vajhøj wrote:

> A car where a problem with lane change warning get fixed is better than
> a car where it does not get fixed and a car without the feature.

Perhaps not. A car without the feature cannot cause accidents with false
information. A car with the feature, that gives false information, could be a
very bad thing.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> David Froble via Info-vax
> Sent: August 8, 2017 11:11 PM
> To: info...@rbnsn.com
> Cc: David Froble <da...@tsoft-inc.com>
> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>

Well, no, its not correct. But, I guess we will have to agree to disagree.

Its not about absolute security (not regular bug) numbers, but rather the sheer volume and its impact on stability in med-large shops.

I suspect all those server Operations support types that are forced into patch-n-pray deployment strategies due to the sheer volume of monthly security patches would agree with me. However, I am talking about med-large shops where they have to maintain hundreds+ of server OS's.

Remember - its not the Developers that take any heat when a hack is blamed on an unpatched server, it’s the Operations groups.

However, unless you have spent time in a larger Operations shop, I do understand why this might not be evident.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of Arne
> Vajhøj via Info-vax

> Sent: August 8, 2017 10:20 PM
> To: info...@rbnsn.com
> Cc: Arne Vajhøj <ar...@vajhoej.dk>
> Subject: Re: [Info-vax] VMS security, was: Re: OpenVMS books
>

> On 8/8/2017 10:05 PM, Kerry Main wrote:
> >> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Arne
> >> Vajhøj via Info-vax
> >>> Or perhaps "the more security patches released each and every
> >> month, the
> >>> better the OS..."
> >>>
> >>> Really?
> >>
> >> Yes. Really.
> >>
> >> If VMS:
> >> * had all the software that Linux has an release fixes for
> >> * released fixes for all bugs found
> >> then VMS having fewer bugs than Linux would be an indication
> >> of quality.
> >
> > So, by your logic, the more recalls and/or firmware fixes a car has
> > every year, the better the car quality?
>
> A car where a problem with lane change warning get fixed is better than
> a car where it does not get fixed and a car without the feature.
>
> A car that had the feature without the problem would be even
> better.
>
> But questionable whether such OS'es or cars exist.
>
> > I wonder how this rational would work in any other market?
>
> Have you heard that people are stopping buying cars due to recalls?
>

Ask Toyota if they suffered a huge loss in their reputation after all those recalls they had a few years back.

Ask Volkswagen if they suffered any market share loss after all their quality issues.

> > After all, it must means the Engineers are constantly looking for
> problems - right?
>
> Old joke:
>
> "If debugging is the process of removing bugs, then programming must
> be
> the process of putting them in. "
>
> :-)
>
> > The quality has nothing to do with the Engineering and culture of the
> > company building the car - right?
>
> It has a huge impact in small scale.
>

Agree

> Much less in large scale.
>

Unfortunately, OpenVMS will not be exceeding Windows or Linux in market share anytime soon, so a differentiator is quality software - not quantity.

Quantity without quality is simply a race to the bottom.

[snip..]

[Bob Koehler]

In article <omdrg6$ft4$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
> On 8/8/2017 10:05 PM, Kerry Main wrote:
>
>> I wonder how this rational would work in any other market?
>
> Have you heard that people are stopping buying cars due to recalls?

Yes. In that they buy from other manufacturers that have had fewer
and less important recalls.

[Stephen Hoffman]

Then there's the discussion of CVE counts as fodder for
inevitably-going-to-backfire marketing. Of comparing some small
positive integer values with what amounts to Codd's NULL value as bogus
marketing fodder.

Then there's that zero patches doesn't mean that there are zero
vulnerabilities. Never has. Never will. Same for zero CVEs.

Then there's that any number of patches past zero means that folks have
to evaluate and test and deploy those patches. This in addition to
the on-going efforts of monitoring the local networks and servers and
apps for... oddities.

Then there's that the OpenVMS patch tools and the whole patch process
is most charitably referred to as dated, which is part of why OpenVMS
folks tend to be much more aware of each and every one of those
individual patches, and of the associated patch downloads and
installations and reboots involved. On other platforms, the patch
tools make the whole process simpler, and variously increasingly
(opt-in) automated.

Testing is still an effort and a local option. Whether that effort
might or will vary by the site, or by the specific patches?

Then there's that we're not seeing trends with our patch counts that
will comfort most (any?) of us. These trends irrespective of the
platform. If (when?) OpenVMS becomes more widely used secondary to
the x86-64 port and the acquisition of newer ISVs and newer apps, I
would bet against the OpenVMS patch counts remaining where they've
(bogusly) been, too. Hopefully we also start seeing some VSI
participation in the CVE process and more involved in coordinated
disclosures.

Then there's that we (some of us) are increasingly looking at why those
patches are needed, and whether we can isolate the effects of the
breaches (isolation on other platforms goes well beyond mechanisms such
as processes and privileges), and whether we can reduce the numbers of
newly-created vulnerabilities. Of whether we continue with our
current trend and our current approaches, or if we should make changes
to the existing development processes and tools and platforms and
frameworks.

Yes, I really want to see barrages of CVEs and patches for OpenVMS.
Of catching up. Then of CVEs and coordinated disclosures and patches
issued across Linux, BSD and OpenVMS. Together. That'll definitely
be forward progress.

[Bill Gunshannon]

Last time I looked around here Toyota and VW dealers are still
selling everything that comes in the door.

bill

[Arne Vajhøj]

On 8/9/2017 1:11 PM, Bob Koehler wrote:

What car brands have had a long term drop in sales due to many recalls?

Arne

[Bob Koehler]

Seems Toyota has mostly recovered, but VW is still in recovery mode.
It will be many years before VW can successfully market a diesel in
the US again. VW has clearly lost market share. Yes, they can sell
cars, but thier production rates are down to match.

[Bob Koehler]

Ford, Chevy, and VW all come to mind. They didn't go bankrupt, but
they did see sales reductions. Ford and Chevy have pretty much
long since recovered (American attention span being notoriously short).

[Bill Gunshannon]

Actually, I expect VW to stop selling diesels altogether and
it has nothing to do with the fiasco. Seems Europe has
decided diesels aren't as clean as they thought.

bill

[seasoned_geek]

On Thursday, August 10, 2017 at 8:16:35 AM UTC-5, Bill Gunshannon wrote:

> Actually, I expect VW to stop selling diesels altogether and
> it has nothing to do with the fiasco. Seems Europe has
> decided diesels aren't as clean as they thought.
>

Which would actually have to do with the fiasco <Grin> The EU didn't know just how less-than-clean diesel cars were until then. I've heard reports on NPR that a few EU countries are creating bills to ban the sale of diesel for cars within their borders.

Volvo had an 850 Bi-Fuel years ago which could burn both methane and E85. It actually got better mileage on E85 than lower alcohol blends.

http://www.logikalsolutions.com/wordpress/thank-you-sir-may-i-have-another/ford-management-has-a-fart-between-the-ears/

https://www.media.volvocars.com/global/en-gb/media/photos/6271

Given the current global glut of corn and this year being projected to be an at or above trend line yield, I'm surprised more EU countries aren't pushing for 85 and higher percent alcohol fuels. At least from the emissions and Paris Accord standpoint.