On 1/16/2024 4:23 PM, Lawrence D'Oliveiro wrote:
> On Tue, 16 Jan 2024 13:33:58 -0000 (UTC), Simon Clubley wrote:
>> However, when he is not making some crazy out of touch
>> comments, such as replicating the VMS APIs on Linux work ...
>
> Consider that the entirety of the VMS APIs add up to only a tiny fraction
> of the Windows APIs. Yet an emulation layer for Windows (WINE) has been
> successfully built on Linux, and is actually seeing some production use.

If the expectation is that:

systems running emulated VMS on top of Linux / systems running actual VMS

=

systems running Windows server apps on Wine on Linux / systems running
real Windows Server

then that confirms that there are no business case.

> And this was done with only a fraction of the resources available to VSI.

That would be a pretty big fraction.

According to Github then Wine has 873 contributors. Not all active
every year and definitely not full time.

But compared to VSI VMS engineering team (that excludes management,
sales people, compiler engineering teams and other applications
engineering teams) then the fraction must still be like 5/1 or 10/1.

Arne

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 16 Jan 2024 13:16:29 -0000 (UTC), Simon Clubley wrote:
>
>> The problem with that is that you need to rebuild the kernel everytime
>> there is a kernel security update.
>
>Somebody has to, anyway, for security bugs in the core. Building your own
>kernel really isn’t that big a deal. And remember, it’s your choice
>whether to use an off-the-shelf kernel or not.

Only ONE person has to. It's not like modern Unix and Linux users have to do
a SYSGEN with every kernel patch or every time a device is added or removed.
Modloading is a cool thing.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 16/01/2024 21:20, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 23:37:34 +0000, Chris Townley wrote:
>
>> There are plenty of good engineers at Raspberry
>
> And yet it was none of them that created Raspbian, to begin with.

They don't use raspian any more. They use Debian, but add quite a few
extra bits, and patches for raspberry pi architecture

--
Chris

In article <uo74p9$1lkg8$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/16/2024 4:23 PM, Lawrence D'Oliveiro wrote:
>[snip]
>> And this was done with only a fraction of the resources available to VSI.
>
>That would be a pretty big fraction.
>
>According to Github then Wine has 873 contributors. Not all active
>every year and definitely not full time.
>
>But compared to VSI VMS engineering team (that excludes management,
>sales people, compiler engineering teams and other applications
>engineering teams) then the fraction must still be like 5/1 or 10/1.

Please don't feed the troll.

- Dan C.

On Tue, 16 Jan 2024 23:53:26 +0000, Chris Townley wrote:

> On 16/01/2024 21:20, Lawrence D'Oliveiro wrote:
>
>> On Sun, 7 Jan 2024 23:37:34 +0000, Chris Townley wrote:
>>
>>> There are plenty of good engineers at Raspberry
>>
>> And yet it was none of them that created Raspbian, to begin with.
>
> They don't use raspian any more. They use Debian, but add quite a few
> extra bits, and patches for raspberry pi architecture

That is what “Raspbian” is. As I mentioned before, it’s now called
“Raspberry Pi OS”.

On 2024-01-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
>
>> On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> Nowadays, the whole Internet is built on the concept of running secure
>>> protocols over insecure channels. Those secure protocols can in turn be
>>> channels for older, insecure protocols--this is not rocket science.
>>
>> Things like SSL only protect data in motion. It does nothing to help you
>> if the server software on the receiving end of that SSL connection has a
>> vulnerability within it.
>
> Not sure why that?s relevant to the issue of whether to support DECnet or
> not.

The server software with the vulnerability could be the DECnet stack
running on that server.

BTW, has anyone been able to do a $ show proc/priv against the EVL listener
PID and are you able to post the output ?

I notice that no-one, including Mark yet, has posted this, so I wonder
just how many of you are actually running the DECnet Phase IV stack on
your machines.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:

> On 2024-01-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
>>
>>> On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>> Nowadays, the whole Internet is built on the concept of running
>>>> secure protocols over insecure channels. Those secure protocols can
>>>> in turn be channels for older, insecure protocols--this is not rocket
>>>> science.
>>>
>>> Things like SSL only protect data in motion. It does nothing to help
>>> you if the server software on the receiving end of that SSL connection
>>> has a vulnerability within it.
>>
>> Not sure why that’s relevant to the issue of whether to support DECnet
>> or not.
>
> The server software with the vulnerability could be the DECnet stack
> running on that server.

Any reason why you think DECnet is particularly prone to introducing
security holes, per se?

On 1/17/2024 8:11 AM, Simon Clubley wrote:
> BTW, has anyone been able to do a $ show proc/priv against the EVL listener
> PID and are you able to post the output ?

Full priv on my VMS 8.4-2L2 Alpha and 9.2-1 x86-64.

> I notice that no-one, including Mark yet, has posted this, so I wonder
> just how many of you are actually running the DECnet Phase IV stack on
> your machines.

Among hobbyists I expect most to have DECnet installed - to get
"the real VMS experience". And 20 years ago many would have went
with V, but today I think a lot just go with IV because it is
simpler and does what they need.

For real use there are probably more TCP/IP only among the
newly installed systems while the older systems probably have
either V or IV installed.

Arne

On 1/17/2024 8:11 AM, Simon Clubley wrote:
> On 2024-01-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
>>
>>> On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>> Nowadays, the whole Internet is built on the concept of running secure
>>>> protocols over insecure channels. Those secure protocols can in turn be
>>>> channels for older, insecure protocols--this is not rocket science.
>>>
>>> Things like SSL only protect data in motion. It does nothing to help you
>>> if the server software on the receiving end of that SSL connection has a
>>> vulnerability within it.
>>
>> Not sure why that?s relevant to the issue of whether to support DECnet or
>> not.
>
> The server software with the vulnerability could be the DECnet stack
> running on that server.
>
> BTW, has anyone been able to do a $ show proc/priv against the EVL listener
> PID and are you able to post the output ?
>
> I notice that no-one, including Mark yet, has posted this, so I wonder
> just how many of you are actually running the DECnet Phase IV stack on
> your machines.
>
> Simon.
>

Well, rather old, on a VAX/VMS V7.2 system.

$ show proc/priv/id=90

17-JAN-2024 21:37:35.63 User: DECNET Process ID: 00000090
Node: DFE90A Process name: "EVL"

Authorized privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL
IMPERSONATDIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT
LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL
SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD

Process privileges:
ACNT may suppress accounting messages
ALLSPOOL may allocate spooled device
ALTPRI may set any priority value
AUDIT may direct audit to system security audit log
BUGCHK may make bug check log entries
BYPASS may bypass all object access controls
CMEXEC may change mode to exec
CMKRNL may change mode to kernel
IMPERSONATE may impersonate another user
DIAGNOSE may diagnose devices
DOWNGRADE may downgrade object secrecy
EXQUOTA may exceed disk quota
GROUP may affect other processes in same group
GRPNAM may insert in group logical name table
GRPPRV may access group objects via system protection
IMPORT may set classification for unlabeled object
LOG_IO may do logical i/o
MOUNT may execute mount acp function
NETMBX may create network device
OPER may perform operator functions
PFNMAP may map to specific physical pages
PHY_IO may do physical i/o
PRMCEB may create permanent common event clusters
PRMGBL may create permanent global sections
PRMMBX may create permanent mailbox
PSWAPM may change process swap mode
READALL may read anything as the owner
SECURITY may perform security administration functions
SETPRV may set any privilege bit
SHARE may assign channels to non-shared devices
SHMEM may create/delete objects in shared memory
SYSGBL may create system wide global sections
SYSLCK may lock system wide resources
SYSNAM may insert in system logical name table
SYSPRV may access objects via system protection
TMPMBX may create temporary mailbox
UPGRADE may upgrade object integrity
VOLPRO may override volume protection
WORLD may affect other processes in the world

Process rights:
SYSTEM resource
BATCH

System rights:
SYS$NODE_DFE90A

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>> The server software with the vulnerability could be the DECnet stack
>> running on that server.
>
> Any reason why you think DECnet is particularly prone to introducing
> security holes, per se?

Because, at best, it has only had a very small fraction of the effort
spent on probing it that the mainstream network stacks have had.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/17/2024 8:11 AM, Simon Clubley wrote:
>> BTW, has anyone been able to do a $ show proc/priv against the EVL listener
>> PID and are you able to post the output ?
>
> Full priv on my VMS 8.4-2L2 Alpha and 9.2-1 x86-64.
>

Thank you for checking Arne. Seeing this still being the case on x86-64
was an unpleasant surprise.

So, that's two full years VSI have had to look at this and they have
done nothing.

I wonder if they are sitting on any other issues that are just a weakness
at the moment, but may become an actual vulnerability if either further
probing is done, or if another unrelated issue is discovered and these
are chained together with that new issue.

For those of you with the premium support contracts who are worried about
this, then a formal _polite_ request to VSI to answer the above question
and to ask when the DECnet issues will be fixed might be in order.

You may have more luck getting them to fix these issues than I have had.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-17, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Well, rather old, on a VAX/VMS V7.2 system.
>
> $ show proc/priv/id=90
>
> 17-JAN-2024 21:37:35.63 User: DECNET Process ID: 00000090
> Node: DFE90A Process name: "EVL"
>
> Authorized privileges:
> ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL
> IMPERSONATDIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT
> LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
> PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL
> SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD
>

[snip]

Thank you for checking David. I wonder when VSI will get around to finally
fixing these issues ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/18/2024 8:06 AM, Simon Clubley wrote:
> On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>>> The server software with the vulnerability could be the DECnet stack
>>> running on that server.
>>
>> Any reason why you think DECnet is particularly prone to introducing
>> security holes, per se?
>
> Because, at best, it has only had a very small fraction of the effort
> spent on probing it that the mainstream network stacks have had.

Less probing and less evolution.

I don't think DECnet phase IV was worse than other networking
at the time (late 70's to early 90's). But other networking
which ended up being almost entirely TCP/IP evolved.

I don't know if phase V had better options that just did
not materialize because everyone only used the phase IV
compatibility stuff in phase V.

But if DEC and VMS had evolved like the rest of the IT world
then we would have been at phase VII or VIII now - and I am
sure that it would have been much better security wise.

Well - back to the real world. DECnet is old and has not
evolved.

Arne

On 1/18/2024 8:18 AM, Simon Clubley wrote:
> On 2024-01-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/17/2024 8:11 AM, Simon Clubley wrote:
>>> BTW, has anyone been able to do a $ show proc/priv against the EVL listener
>>> PID and are you able to post the output ?
>>
>> Full priv on my VMS 8.4-2L2 Alpha and 9.2-1 x86-64.
>
> Thank you for checking Arne. Seeing this still being the case on x86-64
> was an unpleasant surprise.
>
> So, that's two full years VSI have had to look at this and they have
> done nothing.
>
> I wonder if they are sitting on any other issues that are just a weakness
> at the moment, but may become an actual vulnerability if either further
> probing is done, or if another unrelated issue is discovered and these
> are chained together with that new issue.
>
> For those of you with the premium support contracts who are worried about
> this, then a formal _polite_ request to VSI to answer the above question
> and to ask when the DECnet issues will be fixed might be in order.
>
> You may have more luck getting them to fix these issues than I have had.

VSI has to prioritize engineering resources.

I think it would be hard to justify prioritizing DECnet
enhancements.

Customers will have to decide whether to drop DECnet
completely or perform sufficient mitigation to consider
the risk lowered to an acceptable level in their context.

Arne

On 1/17/24 6:11 AM, Simon Clubley wrote:
> On 2024-01-16, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 11 Jan 2024 13:48:37 -0000 (UTC), Simon Clubley wrote:
>>
>>> On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>> Nowadays, the whole Internet is built on the concept of running secure
>>>> protocols over insecure channels. Those secure protocols can in turn be
>>>> channels for older, insecure protocols--this is not rocket science.
>>>
>>> Things like SSL only protect data in motion. It does nothing to help you
>>> if the server software on the receiving end of that SSL connection has a
>>> vulnerability within it.
>>
>> Not sure why that?s relevant to the issue of whether to support DECnet or
>> not.
>
> The server software with the vulnerability could be the DECnet stack
> running on that server.
>
> BTW, has anyone been able to do a $ show proc/priv against the EVL listener
> PID and are you able to post the output ?
>
> I notice that no-one, including Mark yet, has posted this, so I wonder
> just how many of you are actually running the DECnet Phase IV stack on
> your machines.

Sorry, I am only infrequently on this forum.

On my system EVL runs with exactly the privs I specified earlier but I
did do some digging.

EVL is started by netacp in whatever account netacp is running using the
command file sys$system:evl.com. EVL neither raises nor lowers privs.
The startup command file normally looks like this:
$ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved.
$ SET NOON
$ IF "''EVL$COMMAND'" .NES. "" THEN EVL$COMMAND
$ RUN SYS$SYSTEM:EVL
$ PURGE/KEEP=3 EVL.LOG
$ LOGOUT/BRIEF

However, sometime in the dim and distant past (meaning I no longer
remember when or why) I inserted this line:

$ SET PROCESS/PRIVILEGES=(NOALL,SYSNAM,OPER,SYSPRV,NETMBX,TMPMBX)

which is why EVL is limited in privs on my system. Anyone concerned can
make the same edit.

Mark Berryman

On 1/18/24 6:06 AM, Simon Clubley wrote:
> On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>>> The server software with the vulnerability could be the DECnet stack
>>> running on that server.
>>
>> Any reason why you think DECnet is particularly prone to introducing
>> security holes, per se?
>
> Because, at best, it has only had a very small fraction of the effort
> spent on probing it that the mainstream network stacks have had.

Simon's postings would tend to indicate that he believes that anything
not subject to constant probing by hundreds or thousands of hack.., er,
security researchers is just full of latent bugs waiting to be discovered.

It might help to remember that the IP stack was designed by committee
and implemented by an even more diverse group, some good at programming,
some not so much. DECnet, however, was designed and implemented by a
much smaller group, which often leads to much better code. I suspect,
but don't know for sure, that the designers and implementers were also
essentially the same people. (They were also very good).

Also, once upon a time, DECnet was a more diverse network than the
internet. Until the internet went public in the early 90s, it was quite
limited in scope, consisting mainly of some government institutions,
some government contractors, and some universities. DECnet, however,
was used to implement a number of world-wide networks consisting of many
diverse endpoints. There was some probing that went on but not a whole
lot. For one, with DECnet the source was too easy to trace and, for
another, if any of the probes were successful I never heard of it (I was
on SPAN at the time). This was all DECnet phase IV. After the internet
went public, these networks ran multiple protocols in parallel,
including TCP/IP and DECnet. As DEC equipment was phased out at these
sites, so was DECnet. But it somehow managed to survive without issue
all those years. (The only known problems were caused by local
misconfigurations by people who didn't read the manual and simply
accepted defaults that should have been better. None were cause by the
stack itself.)

Finally, as I mentioned in an earlier post, it is trivial in today's
world to isolate one's DECnet stack from anything other than trusted
hosts. On any network where I have been involved, it some host were
compromised, and if that host were to try to probe DECnet, none of its
packets would even reach the DECnet interface of any host that was
actually running DECnet.

There are, after all, many ways to implement security.

My two cents.

Mark Berryman

On 2024-01-18, Mark Berryman <mark@theberrymans.com> wrote:
>
> Sorry, I am only infrequently on this forum.
>
> On my system EVL runs with exactly the privs I specified earlier but I
> did do some digging.
>
> EVL is started by netacp in whatever account netacp is running using the
> command file sys$system:evl.com. EVL neither raises nor lowers privs.
> The startup command file normally looks like this:
> $ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved.
> $ SET NOON
> $ IF "''EVL$COMMAND'" .NES. "" THEN EVL$COMMAND
> $ RUN SYS$SYSTEM:EVL
> $ PURGE/KEEP=3 EVL.LOG
> $ LOGOUT/BRIEF
>
> However, sometime in the dim and distant past (meaning I no longer
> remember when or why) I inserted this line:
>
> $ SET PROCESS/PRIVILEGES=(NOALL,SYSNAM,OPER,SYSPRV,NETMBX,TMPMBX)
>
> which is why EVL is limited in privs on my system. Anyone concerned can
> make the same edit.
>

Because that command is being run in the same process as the EVL listener
it will not help constrain an attacker. This is because all an attacker
needs to do in their shellcode is to reenable those privileges.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-18, Mark Berryman <mark@theberrymans.com> wrote:
> On 1/18/24 6:06 AM, Simon Clubley wrote:
>> On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>>>> The server software with the vulnerability could be the DECnet stack
>>>> running on that server.
>>>
>>> Any reason why you think DECnet is particularly prone to introducing
>>> security holes, per se?
>>
>> Because, at best, it has only had a very small fraction of the effort
>> spent on probing it that the mainstream network stacks have had.
>
> Simon's postings would tend to indicate that he believes that anything
> not subject to constant probing by hundreds or thousands of hack.., er,
> security researchers is just full of latent bugs waiting to be discovered.
>

Simon's relatively quick research into DECnet a couple of years ago would
seem to indicate that he has a point... :-)

Simon.

PS: $ set response/mode=good_natured :-)

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/18/2024 12:25 PM, Mark Berryman wrote:
> On 1/18/24 6:06 AM, Simon Clubley wrote:
>> On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>>>> The server software with the vulnerability could be the DECnet stack
>>>> running on that server.
>>>
>>> Any reason why you think DECnet is particularly prone to introducing
>>> security holes, per se?
>>
>> Because, at best, it has only had a very small fraction of the effort
>> spent on probing it that the mainstream network stacks have had.
>
> Simon's postings would tend to indicate that he believes that anything not
> subject to constant probing by hundreds or thousands of hack.., er, security
> researchers is just full of latent bugs waiting to be discovered.

No, really? Someone else noticed this? And here I thought it was just me ..

> It might help to remember that the IP stack was designed by committee and
> implemented by an even more diverse group, some good at programming, some not so
> much. DECnet, however, was designed and implemented by a much smaller group,
> which often leads to much better code. I suspect, but don't know for sure, that
> the designers and implementers were also essentially the same people. (They
> were also very good).

Well, it does work well, for what it does.

> Also, once upon a time, DECnet was a more diverse network than the internet.
> Until the internet went public in the early 90s, it was quite limited in scope,
> consisting mainly of some government institutions, some government contractors,
> and some universities. DECnet, however, was used to implement a number of
> world-wide networks consisting of many diverse endpoints. There was some
> probing that went on but not a whole lot. For one, with DECnet the source was
> too easy to trace and, for another, if any of the probes were successful I never
> heard of it (I was on SPAN at the time). This was all DECnet phase IV. After
> the internet went public, these networks ran multiple protocols in parallel,
> including TCP/IP and DECnet. As DEC equipment was phased out at these sites, so
> was DECnet. But it somehow managed to survive without issue all those years.
> (The only known problems were caused by local misconfigurations by people who
> didn't read the manual and simply accepted defaults that should have been
> better. None were cause by the stack itself.)

Sure, blame the user (guilty) ...

> Finally, as I mentioned in an earlier post, it is trivial in today's world to
> isolate one's DECnet stack from anything other than trusted hosts. On any
> network where I have been involved, it some host were compromised, and if that
> host were to try to probe DECnet, none of its packets would even reach the
> DECnet interface of any host that was actually running DECnet.
>
> There are, after all, many ways to implement security.
>
> My two cents.
>
> Mark Berryman
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/18/2024 12:25 PM, Mark Berryman wrote:
> Finally, as I mentioned in an earlier post, it is trivial in today's
> world to isolate one's DECnet stack from anything other than trusted
> hosts.  On any network where I have been involved, it some host were
> compromised, and if that host were to try to probe DECnet, none of its
> packets would even reach the DECnet interface of any host that was
> actually running DECnet.

Common practice.

And considered good enough for years.

But it may not continue so - ZTN is in fashion.

Arne

On Thu, 18 Jan 2024 13:06:21 -0000 (UTC), Simon Clubley wrote:

> On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>>> The server software with the vulnerability could be the DECnet stack
>>> running on that server.
>>
>> Any reason why you think DECnet is particularly prone to introducing
>> security holes, per se?
>
> Because, at best, it has only had a very small fraction of the effort
> spent on probing it that the mainstream network stacks have had.

But we already know it is an insecure protocol, and we already know how to
run such things securely, as I pointed out before.

On Thu, 18 Jan 2024 10:25:29 -0700, Mark Berryman wrote:

> DECnet, however, was designed and implemented by a
> much smaller group, which often leads to much better code.

Code (implementation) is one thing, design (protocol) is quite another.
DECnet had an address space so restricted, it make the 32-bit IP address
space seem expansive. And whose dumb idea was it to tie the DECnet address
to the MAC address? TCP/IP has ARP; even lowly AppleTalk had its own ARP-
equivalent; yet the clever DEC engineers never saw this as important for
their protocol stack.

On 1/18/2024 3:38 PM, Lawrence D'Oliveiro wrote:
> DECnet had an address space so restricted, it make the 32-bit IP address
> space seem expansive.

16 bit is less than 32 bit.

If DEC had known how large DECnet networks would become, then they
would probably have chosen 32 bit.

But it is difficult to predict the future.

> And whose dumb idea was it to tie the DECnet address
> to the MAC address?

It is pretty smart. No need for an extra protocol.

Arne

On Thu, 18 Jan 2024 23:02 +0000 (GMT Standard Time), John Dallman wrote:

> Different objectives. Internet Protocol was designed to be able to be
> adaptable to almost any kind of computer. DECnet was only for DEC OSes.

Hard to see how tying the protocol address to the MAC address was a good
idea in any way.

On 2024-01-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 18 Jan 2024 13:06:21 -0000 (UTC), Simon Clubley wrote:
>
>> On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Wed, 17 Jan 2024 13:11:31 -0000 (UTC), Simon Clubley wrote:
>>>> The server software with the vulnerability could be the DECnet stack
>>>> running on that server.
>>>
>>> Any reason why you think DECnet is particularly prone to introducing
>>> security holes, per se?
>>
>> Because, at best, it has only had a very small fraction of the effort
>> spent on probing it that the mainstream network stacks have had.
>
> But we already know it is an insecure protocol, and we already know how to
> run such things securely, as I pointed out before.

As I have already mentioned, that only protects data in transit.

If you can still reach the DECnet stack via the nice modern secure
protocol, you can still open your own connections to the DECnet stack
and launch attacks against the DECnet stack running on the server.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.