Linux use may increase in the desktop sector

[stam]

I think rather than “fear” it’s probably more a concern about discontinuation of security updates etc, which will leave machines unprotected and on a professional level this would be unacceptable. Then of course there’s things like drivers etc.

That’s probably why using unsupported OS’s isn’t recommended. But of course nothing to stop you using them on age appropriate hardware, as long as you accept the security risks.

As a parenthesis, anyone remember the blaster worm? It infected all Windows XP boxes on the network automatically - when this worm was raging, all our cardiac ultrasound machines ran windows XP embedded as their core OS and simply connecting them to the hospital network got them all infected and locked out - it’s things like this that security updates quietly protect us from, so I hear Richard’s concern about using unsupported OS’s…

[FourthWorld]

Frightening.

Maybe I'm extremely naive, but FourthWorld seens always frightened about unsupported operating systems; I'm not:
currently deploying MacOS 10.7, 10.6 and 10.4 (PPC) as well as some fairly ancient Linux versions.

Subscribe to many infosec newsletters?

I wonder if time spent studying software vulnerabilities may be a factor in our different levels of comfort using software the vendor themselves recommend no one use.

https://www.cvedetails.com/vulnerabilit ... ows-7.html

[richmond62]

I wonder if time spent studying software vulnerabilities

Absolutely.

Unfortunately, or fortunately, I spend time teaching Bulgarian children English and so on, so
do not really have the time (or the inclination, to be honest) to do that sort of thing.

[AxWald]

Hi,

LC is still seen as an Apple Macintosh and iOS first society.

Funny: first time I have seen that.

Hint: Have a look at any release notes and check where's the vast majority of changes targeted.
Hint 2: Look at the screen shots of any documentation of LC Ltd.
Hint 3: Install & try a 9.* version of LC on a contemporary Win machine.
Hint 4: Compare what's possible on Android & on iOS.
Hint 5: Well, Linux - try Hint 3 with any contemporary Linux distribution, and see how well LC integrates with what Linux users expect today ;-)

Subscribe to many infosec newsletters?

I wonder if time spent studying software vulnerabilities may be a factor in our different levels of comfort using software the vendor themselves recommend no one use.

Btw., Richard, do you know if there's plans for a mechanism to keep all those 3rd party libs up-to-date that any LC StandAlone contains? There's the CEV browser, bsdiff, curl, FreeType, giflib, iODBC, jpeglib, libbzip2, libpng, libxml2, libzip, OpenSSL, Original SSLeay, PCRE, PostgresSQL, skia, sqlitedataset, zLib, WebKit, did I forget some? Many of these are patched/ fixed/ updated quite often, but how are we supposed to benefit from this?

Once a StandAlone/APK is compiled these are out there, in fixed versions. Is there really no way but to recompile our projects & do fresh installs each time a fixed version of OpenSSL comes out, or the CEV is updated (and found its way into a new LC version)? Isn't it that, at the current state, ANY LC project out there, that's older but a few weeks, is a potential security risk?

Have fun!

[richmond62]

Hint: Have a look at any release notes and check where's the vast majority of changes targeted.
Hint 2: Look at the screen shots of any documentation of LC Ltd.
Hint 3: Install & try a 9.* version of LC on a contemporary Win machine.
Hint 4: Compare what's possible on Android & on iOS.
Hint 5: Well, Linux - try Hint 3 with any contemporary Linux distribution, and see how well LC integrates with what Linux users expect today

Hint (1): Maybe that's where the largest number of bug reports are coming from?

Hint 2: That could be because development is done on Macintosh computers:
after all, it would be fairly daft just to pop over to Windows or Linux for the sake
of a handful of screenshots.

Hint 3: Did it on 15 machines running either Windows 8 or Windows 10 this summer: NOT a single problem.

Hint 5: well, apart from the non-situation with sound, I have never had an real problems with Linux and LiveCode.

[stam]

Yeh I have to agree, I installer LC 9.6.x on a couple of Windows 10 boxes for debugging purposes (so only very light use). Didn’t notice any disparities with my main Mac installation…

[jacque]

Once a StandAlone/APK is compiled these are out there, in fixed versions. Is there really no way but to recompile our projects & do fresh installs each time a fixed version of OpenSSL comes out, or the CEV is updated (and found its way into a new LC version)? Isn't it that, at the current state, ANY LC project out there, that's older but a few weeks, is a potential security risk?

That's the case for any app in any language. When bugs are fixed users need to install an update. As a plus, releasing regular updates increases your reputation as a responsible developer.

[FourthWorld]

I wonder if time spent studying software vulnerabilities

Absolutely.

Unfortunately, or fortunately, I spend time teaching Bulgarian children English and so on, so
do not really have the time (or the inclination, to be honest) to do that sort of thing.

Staying on top of details can be a lot, and eats into sleep as much as time (the Internet is a nasty place).

Good general guidance for everyone is simple enough: When an OS vendor says a given version of their product should not be used, it should not be used.

[FourthWorld]

Btw., Richard, do you know if there's plans for a mechanism to keep all those 3rd party libs up-to-date that any LC StandAlone contains?

I can't imagine why there wouldn't be. Seems little point to using third-party ecosystems if you're not using third-party ecosystems,

Once a StandAlone/APK is compiled these are out there, in fixed versions. Is there really no way but to recompile our projects & do fresh installs each time a fixed version of OpenSSL comes out, or the CEV is updated (and found its way into a new LC version)? Isn't it that, at the current state, ANY LC project out there, that's older but a few weeks, is a potential security risk?

As Jacque noted, with any software there's always a lag between source update and downstream patch availability.

The length of time between patch availability and updates to downstream tools that use it will vary, and there's an age-old debate between bundles and dependencies: bundles let a developer deliver standalone apps (like LC or Ubuntu's Snap delivery format), but at the cost of size and potential lag in component updates; dependencies allow an app to always use the most current components on the system, at the cost of what's commonly referred to as "DLL hell".

And even among OSes we see wide variance. A good example is the Ubuntu packaging team, where they've honed their process to be able to put new version of packages into their update system within one hour. A bad example is Apple's history of holding back patches until they complete other goals for the OS, delaying some updates by several weeks (though in all fairness, that criticism was a widely-discussed issue several years ago; hopefully they're no longer the slowest of the Big Three to push updates these days).

But then there are the cases where Apple has chosen not to provide package updates at all, often for licensing concerns (Apple seems to avoid anything using GPLv3, presumably for its patent protection clause). For example, rsync is currently at v3.2.3, but last I checked macOS hasn't updated since v2.6.9 from 2006. A lot of security-related issues have been addressed over the years, some flagged as critical.

Here's a list of outdated packages in macOS as of 2014 (if anyone here has a more recent list please post it):
https://robservatory.com/behind-os-xs-m ... nix-tools/

All that said, another consideration to balance timeliness of patching is upstream vulnerability. If a package has been compromised at the source, those quick to update will spread the vulnerability that much faster. Modern hacks are sometimes clever and not easy to review for all possible vulnerabilities. So while there have been famous cases of upstreams in npm and Python packages years ago that wreaked havoc when everyone rushed to get the latest build, more recently one of the most serious hacks in history occurred with a compromised component slipped into the build stream for the popular Solar Winds security package, allowing hostile nation state actors deep inside a large number of US and other government systems along with some of the biggest corporations in the world:
https://www.npr.org/2021/04/16/98543965 ... winds-hack

Patching is a delicate balancing act, and I'm not sure anyone gets it perfect. LC's ambitions seem to provide a reasonable balance at least as far as any bundle system (as opposed to DLL hell system) can go.

[richmond62]

Staying on top of details can be a lot

-

headInSand.jpeg (6.13 KiB) Viewed 4458 times

-
a good thing I wasn't wearing my kilt when that photo was taken.