I need a mechanism to allow for software updates to be
installed. The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

Pisser is that I need a mechanism that will be supportable
for 20-30 years. This likely rules out many commodity
approachs (will we be using NANO-SD cards? PICO-SD cards?
will USB A/B have given way to C? Or D/E/F?)

If you assume updates are few and far between, the cost
of the transport medium has little impact on TCO (unlike
on-line updates which have a big impact on TCO!).

And, if you further assume that the time to perform an
update is immaterial (because they are infrequent and
because the system allows updates to happen WHILE it is
in use -- unlike "reboot to complete your update"),
then you don't need a fast interface to deliver the new
content.

So, it seems that a reasonable approach could be a "module"
that talks to the product using an existing communications
medium inherent in the product's design (in my case, wired
or wireless ethernet). The design of the "update device"
can then change with each update -- so long as the system
interface remains constant.

A dog slow "processor" that can push packets from some
storage medium out to the system interface offers lots
of design opportunities for processing (dedicated logic)
and storage (media devices).

Because it is active, it can also make note of how and
when it was "consumed" (should reuse want to be discouraged)

As it's only a one-time use device, there's no need to make it
serviceable -- discard when done. (no desire to have it
returned for reuse as it's cost would be a handful of dollars;
likely less than the price of a first class *stamp*, soon)

Any problems with this approach? Export controls may be an
issue but I can leave that to someone else to sort out;
maybe just ignore those markets? (I've had to work in markets
where you had to smuggle EPROMs through customs...)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25-Nov-23 10:09 am, Don Y wrote:

I need a mechanism to allow for software updates to be
installed.  The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

Pisser is that I need a mechanism that will be supportable
for 20-30 years.  This likely rules out many commodity
approachs (will we be using NANO-SD cards?  PICO-SD cards?
will USB A/B have given way to C?  Or D/E/F?)

If you assume updates are few and far between, the cost
of the transport medium has little impact on TCO (unlike
on-line updates which have a big impact on TCO!).

And, if you further assume that the time to perform an
update is immaterial (because they are infrequent and
because the system allows updates to happen WHILE it is
in use -- unlike "reboot to complete your update"),
then you don't need a fast interface to deliver the new
content.

So, it seems that a reasonable approach could be a "module"
that talks to the product using an existing communications
medium inherent in the product's design (in my case, wired
or wireless ethernet).  The design of the "update device"
can then change with each update -- so long as the system
interface remains constant.

A dog slow "processor" that can push packets from some
storage medium out to the system interface offers lots
of design opportunities for processing (dedicated logic)
and storage (media devices).

Because it is active, it can also make note of how and
when it was "consumed" (should reuse want to be discouraged)

As it's only a one-time use device, there's no need to make it
serviceable -- discard when done.  (no desire to have it
returned for reuse as it's cost would be a handful of dollars;
likely less than the price of a first class *stamp*, soon)

Any problems with this approach?  Export controls may be an
issue but I can leave that to someone else to sort out;
maybe just ignore those markets?  (I've had to work in markets
where you had to smuggle EPROMs through customs...)

I wouldn't want to rely on wireless ethernet - there's too much in there
that could change over time to the extent that no then available device
could talk to it.

Preventing managers from causing on-line update to become available is
really difficult as long as software can do updating, since even if
on-line update is not implemented from day one, it could be implemented
via the last non-online update.

The solution is a device that is physically incapable of updating itself
unless some local action is taken, such as pressing a button. As long as
no one implements a remote button-pressing device.

Sylvia.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: free.spam

The idiot Sylvia Else <sylvia@email.invalid> persisting in being an Off-topic troll...

--
Sylvia Else <sylvia@email.invalid> wrote:

Path: not-for-mail
From: Sylvia Else <sylvia@email.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Long term software update mechanism
Date: Sat, 25 Nov 2023 11:05:54 +1100
Lines: 62
Message-ID: <kscs31F66frU1@mid.individual.net>
References: <ujrafj$2gf17$2@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit
X-Trace: individual.net rDAKk/p80ahAuOyreqglRwODgCyyiFGoPMV5B5rN7vuObKYaZd Cancel-Lock: sha1:IxqlpO6k0LxADXqrLtDB/xMlRRY= sha256:D5s9zx7ZQmydI9qJXpN/oaMITEk+tJ/yIvrgDbolerc=
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
Content-Language: en-US
In-Reply-To: <ujrafj$2gf17$2@dont-email.me>
X-Received-Bytes: 3733

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: free.spam

The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

--
Don Y <blockedofcourse@foo.invalid> wrote:

Path: not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Long term software update mechanism
Date: Fri, 24 Nov 2023 16:09:30 -0700
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <ujrafj$2gf17$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 23:09:41 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="6f5b1a0178efa4f620cd38698cdeb5ed";
logging-data="2636839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9rjAEDZfHs21SL5I0Y+oS"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:ZdSS3m+PMFjQdXP0pKljPgl0M8o=
Content-Language: en-US
X-Received-Bytes: 3093

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/24/2023 5:05 PM, Sylvia Else wrote:

On 25-Nov-23 10:09 am, Don Y wrote:

I need a mechanism to allow for software updates to be
installed.  The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

Pisser is that I need a mechanism that will be supportable
for 20-30 years.  This likely rules out many commodity
approachs (will we be using NANO-SD cards?  PICO-SD cards?
will USB A/B have given way to C?  Or D/E/F?)

If you assume updates are few and far between, the cost
of the transport medium has little impact on TCO (unlike
on-line updates which have a big impact on TCO!).

And, if you further assume that the time to perform an
update is immaterial (because they are infrequent and
because the system allows updates to happen WHILE it is
in use -- unlike "reboot to complete your update"),
then you don't need a fast interface to deliver the new
content.

So, it seems that a reasonable approach could be a "module"
that talks to the product using an existing communications
medium inherent in the product's design (in my case, wired
or wireless ethernet).  The design of the "update device"
can then change with each update -- so long as the system
interface remains constant.

A dog slow "processor" that can push packets from some
storage medium out to the system interface offers lots
of design opportunities for processing (dedicated logic)
and storage (media devices).

Because it is active, it can also make note of how and
when it was "consumed" (should reuse want to be discouraged)

As it's only a one-time use device, there's no need to make it
serviceable -- discard when done.  (no desire to have it
returned for reuse as it's cost would be a handful of dollars;
likely less than the price of a first class *stamp*, soon)

Any problems with this approach?  Export controls may be an
issue but I can leave that to someone else to sort out;
maybe just ignore those markets?  (I've had to work in markets
where you had to smuggle EPROMs through customs...)

I wouldn't want to rely on wireless ethernet - there's too much in there that could change over time to the extent that no then available device could talk to it.

I (currently) only use wired connections. This for several reasons:
- requires physical access for tampering/interception/DoS
- allows power to be distributed remotely
- high bandwidth regardless of scale

But, I can't rule out someone, eventually, opting for a wireless connection (with caveats) within the system -- for some special need.

Preventing managers from causing on-line update to become available is really difficult as long as software can do updating, since even if on-line update is
not implemented from day one, it could be implemented via the last non-online update.

The bar is set pretty high, for that. I don't use a TCP/IP stack
so anyone wanting to talk to the outside world would have to undertake
the task of integrating that functionality and associated "capabilities" (permissions) as well as determining who/what would use them.

(The hardware to do so is a relatively trivial undertaking)

Additionally, developing (and validating) a mechanism to protect the rest
of the system from any potential hostile actions that the new attack
surface makes possible.

And, of course, committing to supporting an update server (and policy)
at a well-known address for a substantial period of time.

If you "run the numbers", it's cheaper to make a semi-disposable
device to do this (that gives you the ability to keep revising
subsequent devices as different storage media come into fashion)

The solution is a device that is physically incapable of updating itself unless
some local action is taken, such as pressing a button. As long as no one implements a remote button-pressing device.

New devices ("nodes") are introduced to my system by exactly such a
mechanism. The admission terminal is intended to be located someplace physically secure (so the initial communications with the device can
be secure and so only trusted personnel can perform said actions).

The device's identity and capabilities are discovered through this
admission process, followed by KEX and the registration of the device
in the system's configuration.

Thereafter, the ultimate network location of the device is discovered
when it finds it's ultimate home.

I was thinking of using the same mechanism, protocol, etc. for an
"updater" device -- whose function is to deliver new software to the
system. As this is of a transitory nature, the device need never
"appear" anywhere other than the admission terminal and, there, only
for the time it takes to dump its contents.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25-Nov-23 4:30 pm, a a wrote:

The arsehole Don Y <blockedofcourse@foo.invalid> persisting in being an Off-topic troll...

That seems rather harsh.

The line between hardware and software has become rather blurred, with
many devices that Joe public would think of as just electronics actually containing some software elements.

Sylvia.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/25/2023 12:34 AM, Sylvia Else wrote:

On 25-Nov-23 4:30 pm, a a wrote:

I'm surprised ANYONE still sees posts from "a a"!

That seems rather harsh.

The line between hardware and software has become rather blurred, with many devices that Joe public would think of as just electronics actually containing
some software elements.

I suspect there are far more "deeply embedded" devices in existence,
today, than "pure electronic" devices -- both in numbers and designs.
It seems far too easy to put a processor into a design rather than
a few discretes (and then let feeping creaturism do the rest!)

In fact, the question centered around a physical DEVICE to deliver
updates -- instead of the ubiquitous "software service" that is
used, nowadays. (I actually suggested it could be "dedicated logic")

[I guess it takes a certain level of intelligence to be able to
perceive that (likely "a a" doesn't rise to that level). But,
that's what you'd expect from folks who live under bridges...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, November 24, 2023 at 3:09:47 PM UTC-8, Don Y wrote:

I need a mechanism to allow for software updates to be
installed. The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

Pisser is that I need a mechanism that will be supportable
for 20-30 years. This likely rules out many commodity
approachs (will we be using NANO-SD cards? PICO-SD cards?
will USB A/B have given way to C? Or D/E/F?)

Futureproofing is an unsolved problem. Backstop for
such issues, is swapping major parts of the device
back to the factory.

This assumes the factory with the update is not in a war zone
or supervolcano caldera.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/11/2023 23:09, Don Y wrote:

I need a mechanism to allow for software updates to be
installed.  The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

An Ethernet socket and a dedicated line to connect it to whatever
hardware du jour happens to be?
I can't see physical wired Ethernet going away any time soon.
(other cheap fast serial protocols are available)

I still have the odd thing hanging around that requires it's firmware to
be bitbashed down a bidirectional parallel printer port (remember
them?). I keep one such machine with that, RS485, an ancient SCSI card
and even more antique IEEE488 card for just such occasions.

The one that really annoys me is my high end internet radio tuner (early adopter) the BBC has effectively bricked it since they changed their
streaming format and the device now more than 5 years old is no longer supported. It is a *BIG* problem with so-called "smart" devices :(

It still works fine for ROW programme content.

--
Martin Brown

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Martin Brown <'''newspam'''@nonad.co.uk> wrote:

On 24/11/2023 23:09, Don Y wrote:

I need a mechanism to allow for software updates to be
installed.  The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

An Ethernet socket and a dedicated line to connect it to whatever
hardware du jour happens to be?
I can't see physical wired Ethernet going away any time soon.
(other cheap fast serial protocols are available)

I still have the odd thing hanging around that requires it's firmware to
be bitbashed down a bidirectional parallel printer port (remember
them?). I keep one such machine with that, RS485, an ancient SCSI card
and even more antique IEEE488 card for just such occasions.

The one that really annoys me is my high end internet radio tuner (early adopter) the BBC has effectively bricked it since they changed their streaming format and the device now more than 5 years old is no longer supported. It is a *BIG* problem with so-called "smart" devices :(

It still works fine for ROW programme content.

Gee, Martin, what part of “move fast and break things“ didn’t you get? ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2023 3:50 AM, Martin Brown wrote:

On 24/11/2023 23:09, Don Y wrote:

I need a mechanism to allow for software updates to be
installed.  The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

An Ethernet socket and a dedicated line to connect it to whatever hardware du jour happens to be?
I can't see physical wired Ethernet going away any time soon.

Yes, I predicated my entire design on it being available as a
communications technology (between nodes). So, why not ALSO
rely on it as the medium over which to deliver updates from
an "updater node" (that only interacts with the system for the
duration of the update delivery)?

(other cheap fast serial protocols are available)

Ethernet gives me the distance, bandwidth and power delivery
capability the system's nodes need. If I use some OTHER
medium for the updates' delivery, then I add another
technological dependency.

I still have the odd thing hanging around that requires it's firmware to be bitbashed down a bidirectional parallel printer port (remember them?). I keep one such machine with that, RS485, an ancient SCSI card and even more antique IEEE488 card for just such occasions.

I have a parallel port based 10Base2 adapter. I use it with
a Compaq Portable 386 (surprisingly, it gets almost 100KB/s)
as the portable has only two (expansion) ISA slots (which I
have already made use of).

The one that really annoys me is my high end internet radio tuner (early adopter) the BBC has effectively bricked it since they changed their streaming
format and the device now more than 5 years old is no longer supported. It is a
*BIG* problem with so-called "smart" devices :(

Yes. One of my design constraints was NOT to require the
continued availability of any outside service in order for the
system to remain operational.

Sadly, most smart devices have gone the other route, arguing that
they "need" to do so in order to handle the DDNS issue.

"Really? I need for you to be involved so I can talk to my
stove from afar? Even if I'm in the NEXT ROOM???"

I'm giggly with anticipation of some {nation,world}-wide
hack on one of these services that remotely crashes (or
activates!) every such appliance and the public outrage
that comes with it...

It still works fine for ROW programme content.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday 26 November 2023 at 17:56:04 UTC, Don Y wrote:

On 11/26/2023 3:50 AM, Martin Brown wrote:

On 24/11/2023 23:09, Don Y wrote:

I need a mechanism to allow for software updates to be
installed. The (abused) "on-line" approach is unacceptable
(it forces the device to be "exposed" and makes updates
too easy (which seems to mean too frequent!).

An Ethernet socket and a dedicated line to connect it to whatever hardware du
jour happens to be?
I can't see physical wired Ethernet going away any time soon.

Yes, I predicated my entire design on it being available as a
communications technology (between nodes). So, why not ALSO
rely on it as the medium over which to deliver updates from
an "updater node" (that only interacts with the system for the
duration of the update delivery)?

(other cheap fast serial protocols are available)

Ethernet gives me the distance, bandwidth and power delivery
capability the system's nodes need. If I use some OTHER
medium for the updates' delivery, then I add another
technological dependency.

I still have the odd thing hanging around that requires it's firmware to be bitbashed down a bidirectional parallel printer port (remember them?). I keep
one such machine with that, RS485, an ancient SCSI card and even more antique
IEEE488 card for just such occasions.

I have a parallel port based 10Base2 adapter. I use it with
a Compaq Portable 386 (surprisingly, it gets almost 100KB/s)
as the portable has only two (expansion) ISA slots (which I
have already made use of).

The one that really annoys me is my high end internet radio tuner (early adopter) the BBC has effectively bricked it since they changed their streaming
format and the device now more than 5 years old is no longer supported. It is a
*BIG* problem with so-called "smart" devices :(

Yes. One of my design constraints was NOT to require the
continued availability of any outside service in order for the
system to remain operational.

Sadly, most smart devices have gone the other route, arguing that
they "need" to do so in order to handle the DDNS issue.

"Really? I need for you to be involved so I can talk to my
stove from afar? Even if I'm in the NEXT ROOM???"

I'm giggly with anticipation of some {nation,world}-wide
hack on one of these services that remotely crashes (or
activates!) every such appliance and the public outrage
that comes with it...

It still works fine for ROW programme content.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27-Nov-23 4:55 am, Don Y wrote:

"Really?  I need for you to be involved so I can talk to my
stove from afar?  Even if I'm in the NEXT ROOM???"

It bothers me that such devices are typically inside one's firewall, and
that one's security is therefore dependent on whatever security is in
place at the server side.

I've created a separate LAN for such devices (Smart TV, etc), but that's
going to beyond the skills of most owners, who are most likely not even
aware of the issue.

Sylvia.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/2023 5:29 PM, Sylvia Else wrote:

On 27-Nov-23 4:55 am, Don Y wrote:

"Really?  I need for you to be involved so I can talk to my
stove from afar?  Even if I'm in the NEXT ROOM???"

It bothers me that such devices are typically inside one's firewall, and that one's security is therefore dependent on whatever security is in place at the server side.

Exactly. We don't let ANYTHING talk to the outside world
(save for this "disposable" computer used solely for email
and WWW).

I've created a separate LAN for such devices (Smart TV, etc), but that's going
to beyond the skills of most owners, who are most likely not even aware of the
issue.

Note that there is nothing that says those devices can't be
semi-malignant and canvas the devices they can reach on
<whatever> subnet you set up.

"Sylvia also appears to have a Nest thermostat, a Ring
doorbell, and an LG refrigerator... in addition to *me*!"

Given how little effort towards security is typically invested in the
*initial* design of products (it is most often "an afterthought"),
how can you be sure you aren't putting your customer at risk?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)