8 Aug
2022
8 Aug
'22
4:39 p.m.
Again sent earlier. Thanks for the intervening comments about
vulnerabiliteis and versions.
A lot of issues and suggestions have been made and raised. My brief
response is that yes, according to nmap and my intention I had port 23,
for ssh (I moved it) and port 5900 open and the rpc port, I think. I'm
going by memory.
Theoretically the only pinhole in the ISP router firewall was port 23.
To use port 5900, you had to use an ssh tunnel.
My web server is on another machine. Since I only use it for
development, I don't leave it up.
My actual web pages are hosted externally on a vendor's box.
My experience with the upgrade treadmill is that it is a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
The developers for Fedora 13 were no smarter or dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
The issue with an older release is that nifty new things come out and
you can't really use them. But, if you run a VM with a recent version
of the distro, you can use them just fine.
The other issues is that if you are getting vendor support, they can
only reasonably commit to supporting a limited number of versions.
This is AMD hardware from '06.
-Gary
On Fri, Aug 05, 2022 at 06:19:54PM -0700, Rick Moen wrote:
Quoting Brian E. Lavender (brian(a)brie.com):
----- End forwarded message -----
Gary,
You were running Fedora 13?
If so, _that_ is likely a big problem. Fedora 13's initial release was
May 25, 2010, and it was EOLed on June 24, 2011.
Because Fedora. If you don't want to keep moving to newer versions,
it's about the worst possible distro. (But it's possible Gary meant
that he did _original_ installation 15 years ago, but has been following
the recommended upgrade treadmill^W path.
Linus Sphinx wrote:
You know, I have a _lot_ of things to be grateful for, and somewhere on
the list is the glad tidings that I don't need to rely on
Bleepingcomputer.com for IT information.
Over the past 1.5 months since its discovery, the new botnet used
over 3,500 unique IPs worldwide to scan and attempt brute-forcing Linux
SSH servers.
[...]
The SSH brute-forcing relies on a list of credentials downloaded from
the [command and control server]. [...]
*snore*
So, doorknob-twisting for "joe accounts", like user=service
password=manager and like that.
Guestimate the math, and measure the lengthly setup and teardown times
for remote connections to an sshd, and you'll find that
dictionary-attacking an sshd with any reasonable rules set about
password quality and length is going to take an appreciable fraction of
the time to the heat death of the universe, to succeed.
I mentioned upthread that a lot of IT device comes from gadget freaks.
The _other_ common problem is that most security _articles_ are
copied-pasted press releases from security/antimalware firms.
So, they're big on shockhorror, and small on conveying understanding.
I've only quick-glanced at this article about enforcing password policy
via PAM, so won't swear to it being a good one:
https://www.techrepublic.com/article/controlling-passwords-with-pam/
Of course, if you're the -only- user, you ought to stick to decent
passwords without PAM forcing you to. (Also, a user who can su to
root has the power to overrule PAM. But if you do that, you have only
yourself to blame for consequences.)
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com 
9 Aug
9 Aug
4:29 p.m.
On 8/8/22 09:39, saclug(a)garymcglinn.com wrote:
My experience with the upgrade treadmill is that it is
a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
This is a perfectly valid viewpoint. A friend in the computer security
industry, a senior developer, agrees with you 100%. Like all things
security, this stance has plusses and minuses, but it's sensible.
If that's your choice, there's a premium on defending your system's
attack surface, and maintaining due diligence. Since you've chosen
Fedora, SELinux should be enabled (I know, there are a million
recommendations to turn it off, all wrong) and a solid set of firewall
rules should be in place. Certificate-only SSH might have prevented
your last attacker from compromising the host, or a 14-character
passphrase, or diligent log review. For example (fedora):
# ausearch -ts week-ago --success no --interpret
or maybe
# last -x
I recognize that most security recommendations present hurdles,
SELinux configuration and firewall rules are no exception. I'm
working on a suite of tools to help with that, but they're not
ready for release.
Fedora seems to be at one end of a spectrum, with
perhaps Slackware on the other end, where the above strategy
seems a little weak. Fedora seems to push out changes quickly and
with great tumult, not infrequently requiring patches to their
patches. In contrast, Slackware releases after exhaustive testing
and review, and doesn't seem to chase - or incorporate- moving
targets. I'm not recommending one over the other, just trying to
compare and contrast.
The developers for Fedora 13 were no smarter or dumber
than the
developers who are writing Fedora 36. Or pick your distro of choice.
I disagree. The previous generation of developers (Alan Cox was
an exemplar) were more careful, thoughtful, and expert in their
craft. Kids these days... Eventually they'll get better, maybe
better than the Old Guard. But for now, there are a plethora of
semi-skilled Kool Kids in the fray. Perhaps my view is jaundiced
because I'm doing front-end (web) development this month.
The issue with an older release is that nifty new
things come out and
you can't really use them. But, if you run a VM with a recent version
of the distro, you can use them just fine.
The other issues is that if you are getting vendor support, they can
only reasonably commit to supporting a limited number of versions.
Again, some distributions are like mayflies, some are like elephants.
Fedora is perhaps an unconventional choice for longevity.
--
Chuck Polisher
6:39 p.m.
Thanks for your insights and thoughts. I would be in denial, except
that I can't ignore that my system was rebooted by an actor other than
me. Yes, I should be reviewing the logs more. I'm not sure about SSH
certificate access as there seems to be a very active attack directly
against these in the last few months. And, many of the systems I was
using to SSH into my box aren't as physically secure and if they were
hacked, it would give access to my set up.
SElinux, I"ll have to look into it more. As you mentioned, I have been
turning it off.
And, I was wrong, now that I am recovering things, I can see I was
running Fedora 19, not 13. Memory can be a bit fickle :)
My passwords are at least 14 characters ( I just counted on my fingers)
and fairly complex. But I'm still grappling with the fact that I have a
low bandwidth connection and a brute force attack should be prohibitivly
slow. I can see a lot of attemps, thousands for sure, but it should
take a lot more than that.
I've been using SSH to make a VNC tunnel so I can access this desktop
from anywhere. Which has lots of advantages, especially when accessing
sites that have 2 factor authentication.
I've been refusing to make my phone into a security device. It's a toy
or perhaps a tool for business. So, my contact number has been a land
line via voice for the 2nd factor.
I'm going to have to review everything and come up with a new solution.
Maybe I'll get two phones or something. But the whole shoving ads and
"news" at me and forced upgrades and harvesting of personal information
really turn me off about phones. Friends complain that I never have my
phone on me. I am somewhat surprised that they think I should be
instantly available almost 24/7. Well, I prefer to control my time as
opposed to letting the Borg/phone do it.
I'm delusional, I know, I still think I'm someboday and I'm not quite
willing to join the Borg of nobodies :)
-Gary
gn Tue, Aug 09, 2022 at 09:29:37AM -0700, Charles Polisher wrote:
On 8/8/22 09:39, saclug(a)garymcglinn.com wrote:
My experience with the upgrade treadmill is that
it is a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
This is a
perfectly valid viewpoint. A friend in the computer security
industry, a senior developer, agrees with you 100%. Like all things
security, this stance has plusses and minuses, but it's sensible.
If that's your choice, there's a premium on defending your system's
attack surface, and maintaining due diligence. Since you've chosen
Fedora, SELinux should be enabled (I know, there are a million
recommendations to turn it off, all wrong) and a solid set of firewall
rules should be in place. Certificate-only SSH might have prevented
your last attacker from compromising the host, or a 14-character
passphrase, or diligent log review. For example (fedora):
# ausearch -ts week-ago --success no --interpret
or maybe
# last -x
I recognize that most security recommendations present hurdles,
SELinux configuration and firewall rules are no exception. I'm
working on a suite of tools to help with that, but they're not
ready for release.
Fedora seems to be at one end of a spectrum, with
perhaps Slackware on the other end, where the above strategy
seems a little weak. Fedora seems to push out changes quickly and
with great tumult, not infrequently requiring patches to their
patches. In contrast, Slackware releases after exhaustive testing
and review, and doesn't seem to chase - or incorporate- moving
targets. I'm not recommending one over the other, just trying to
compare and contrast.
The developers for Fedora 13 were no smarter or
dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
I disagree.
The previous generation of developers (Alan Cox was
an exemplar) were more careful, thoughtful, and expert in their
craft. Kids these days... Eventually they'll get better, maybe
better than the Old Guard. But for now, there are a plethora of
semi-skilled Kool Kids in the fray. Perhaps my view is jaundiced
because I'm doing front-end (web) development this month.
The issue with an older release is that nifty new
things come out and
you can't really use them. But, if you run a VM with a recent version
of the distro, you can use them just fine.
The other issues is that if you are getting vendor support, they can
only reasonably commit to supporting a limited number of versions.
Again, some distributions are like mayflies, some are like elephants.
Fedora is perhaps an unconventional choice for longevity.
--
Chuck Polisher
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com 
10 Aug
10 Aug
5:47 a.m.
Quoting saclug(a)garymcglinn.com (saclug(a)garymcglinn.com):
Again sent earlier. Thanks for the intervening
comments about
vulnerabilities and versions.
Glad to. Hope they're useful.
A lot of issues and suggestions have been made and
raised. My brief
response is that yes, according to nmap and my intention I had port 23,
for ssh (I moved it) and port 5900 open and the rpc port, I think. I'm
going by memory.
My instant reaction would be to think that having an RPC portmapper
process running and exposed (TCP/UDP port 111) to public networks is...
curious.
RPC portmappers have a troubling security history, although that's a
complex story that includes but is not limited to them making
firewalling complex to the point of near-impossibility, because by
definition they hand out service port assignments to other services, and
that alone is a challenge to control. Possibly, you're already fully
aware of that.
The other thing that is curious about that is that, when I think of RPC
portmapper daemons, I think of them as the foundation of NIS and NFS --
both of which are likewise security-challenging. Thus the old joke
dating back to SunOS 2.0 days that NFS stands for "No Friggin'
Security".
Theoretically the only pinhole in the ISP router
firewall was port 23.
To use port 5900, you had to use an ssh tunnel.
I'm curious what you use the RPC portmapper for, then, and how you
manage the security of services handed ports by it.
My experience with the upgrade treadmill is that it is
a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
The developers for Fedora 13 were no smarter or dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
Well, let's talk about that.
Any host is going, over time, to require security maintenance, as to (at
minimum, all software exposed to public data, which includes the
kernel's network stack and all network services that use the network
stack (and can be reached from public).
It is _absolutely_ feasible to adopt a set of software issued 15 years
ago as part of a distro release, and for it to retain reasonable
security going forward indefinitely, long past when distro security
updates cease for that release -- _provided_ that you diligently assume
manual security maintence duties from that time forward.
I may be doing a similar thing with my next server rebuild: I plan to
have a very sparse, very hardened base system, that is just enough of a
system to run KVM/qemu as a hypervisor. The system would then run two
guest VM sessions, one of which would be my production server, the other
the in-progress beta for its replacement.
In all likelihood (pending testing), I may compile my own host-system
kernel in order to exercise maximum control on completely omitting code
I don't absolutely need, so that it isn't present even as unloaded
modules. And maybe I'll do the same for related code, maybe switching
the libc to one of the minimal ones, and so on.
If I do that, then any such portion of the host-OS system will be
outside the distro package regime, though I might bother to construct
local packages so that the distro regime is aware of them, maybe with
package pinning. The entire host-OS system would probably be under
Ansible or Puppet configuration management, anyway.
But, the main point is, _you_ become the security maintainer of such a
system. _You_ have to spend time reading CVEs and deciding what's
system-relevant and what to do about it.
Backing up a bit, I'll confess I wasn't really paying close attention to
your original "Hacked" posting eight days ago. If I understand
correctly:
1. After noting an unexplained reboot,
2. you looked in "the audit log" and found successful SSH login (not by
you) using a keypair, and some stuff about a service on a high-numbered port.
[Ugh, Mailman3's Hyperkitty archiver is _still_ dreadful.]
I'm not at all sure that initial entry was via ssh. That sounds quite
improbable, for lots of reasons, including "how did the user's public key
get into authorized_keys"?. OTOH, I have insufficient data to say what
the avenue of entry was.
Going by your detailed description of the many things that the intruders
changed and broke, it may be way too late to figure out for sure what
the avenue of entry was. However, if you really _were_ running a
15-year-old Linux kernel, then don't forget that the public attack
service includes the network stack -- and CVEs for the kernel get
ignored for 15 years at your peril.
6:30 a.m.
Typo patrol:
Going by your detailed description of the many things
that the intruders
changed and broke, it may be way too late to figure out for sure what
the avenue of entry was. However, if you really _were_ running a
15-year-old Linux kernel, then don't forget that the public attack
service includes the network stack -- and CVEs for the kernel get
^^^^^^^
"surface"
ignored for 15 years at your peril.
11 Aug
11 Aug
9:46 p.m.
On Mon, Aug 08, 2022 at 09:39:34AM -0700, saclug(a)garymcglinn.com wrote:
My experience with the upgrade treadmill is that it is
a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
The developers for Fedora 13 were no smarter or dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
There are probably a boat load of known vulnerabilities in F13. It's
probably a script kitty winter wonderland, depending upon what you have
installed/running! If you you want software that is secure proof, you
have to run something like "Ironsides", written using SPARK/Ada.
https://ironsides.martincarlisle.com/
Beyon that, the best is to keep patching on a stable distro that doesn't
have API changes, or minimal changes.
Brian
--
Brian Lavender
http://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
10:08 p.m.
Quoting Brian E. Lavender (brian(a)brie.com):
There are probably a boat load of known
vulnerabilities in F13.
The only way running Internet-exposed Fedora 13, even for a minimal host
that's just barely enough of an OS build to support a hypervisor, in
2022, would involve the local sysadmin _completely_ having assumed and
diligently carried out, without fail, all security maintenance
_manually_ for all eleven years, since 2011-06-24, when Security Team
coverage of F13 ceased permanently.
That would mean diligently reading all CVEs for all local components
exposed to public traffic -- including the Linux kernel (especially its
network stack), all public-facing services, and all of their libs and
support utilities -- doing, as appropriate, paring of
code/functionality, upgrading, mitigating, applying needed source
patches, etc.
That could be done, by a sufficiently determined and well-prepared
sysadmin who wishes to hand-maintain a very minimal system for
locally-compelling reasons. Gary, _did_ you do all that?
If you didn't, Gary, that's likely a key part of your problem. And
dismissing the problem of need to plug proven security holes with "the
upgrade treadmill is that it is a waste of time" is a reminder that
denial isn't a river in Egypt.
12 Aug
12 Aug
11:34 a.m.
The work of managing your own distro even for a device like a media server
or handheld gameplayer around the turn of the century was a huge task
that's broken more than one admin but almost manageable as long as you
didn't have to do the custom apps too but that was long before the
opensource eco-system puddle swole up into an ocean. Think you'd need a
team of at least 4-6 to do it now. Freezing a version forever is not even
an option today, waiting until it's hacked aka letting your users find the
bugs never was.
On Thu, Aug 11, 2022 at 4:09 PM Rick Moen <rick(a)linuxmafia.com> wrote:
Quoting Brian E. Lavender (brian(a)brie.com):
There are probably a boat load of known
vulnerabilities in F13.
The only way running Internet-exposed Fedora 13, even for a minimal host
that's just barely enough of an OS build to support a hypervisor, in
2022, would involve the local sysadmin _completely_ having assumed and
diligently carried out, without fail, all security maintenance
_manually_ for all eleven years, since 2011-06-24, when Security Team
coverage of F13 ceased permanently.
That would mean diligently reading all CVEs for all local components
exposed to public traffic -- including the Linux kernel (especially its
network stack), all public-facing services, and all of their libs and
support utilities -- doing, as appropriate, paring of
code/functionality, upgrading, mitigating, applying needed source
patches, etc.
That could be done, by a sufficiently determined and well-prepared
sysadmin who wishes to hand-maintain a very minimal system for
locally-compelling reasons. Gary, _did_ you do all that?
If you didn't, Gary, that's likely a key part of your problem. And
dismissing the problem of need to plug proven security holes with "the
upgrade treadmill is that it is a waste of time" is a reminder that
denial isn't a river in Egypt.
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
12 Aug
12 Aug
5:35 p.m.
Anyone who is in charge of security on systems for an organization of
any size should do all those things anyhow. Vendor support may not be
focused on the requirements of a specific organization. Most security
is driven by configuration and organizational policy. The vast majority
of hacks are social. I used to go though all the attack vectors, but
nothing ever applied to me. I got tired or reading about how firefox
had a vulnerability because a page running on a tab other than the
current one, could open a window.
My system, which is reasonably secure, has just been running for 15
years or so. I've been doing a lot of rebooting and I notice the BIOS
boot screen says something about indestrutable and list a bunch of
hazards like humidity that I am protected from. Maybe it will last
another 15 years :).
I could probably just ignore the hack and be fine. What do I have to
steal? Some tax returns and meatloaf recipies. All the things I wanted
to keep private 15 years ago are now routinly stolen. My contacts,
where I've been, who I saw, and my correspondence. As a public servant,
my salary is public. If tax returns are made public, and there is
occasional talk about that, it will only leave the meatloaf recipies.
So, no, for this system, I don't spend time doing all the security
activities that I would if I had an organization with data that needed
to be protected. Getting bricked is no fun, I'll admit, but it isn't
the end of the world either.
I enjoy learning and using the technology. I'll beef some things up and give it a
whirl. Review what I back up. I missed my raid scripts. Basically, I want security and
privacy just because I should be able to have these things. I'd like to get back some
of the privacy I've lost, but I seem to be alone in that.
-Gary
On Thu, Aug 11, 2022 at 03:08:55PM -0700, Rick Moen wrote:
Quoting Brian E. Lavender (brian(a)brie.com):
There are probably a boat load of known
vulnerabilities in F13.
The only way running Internet-exposed Fedora 13, even for a minimal host
that's just barely enough of an OS build to support a hypervisor, in
2022, would involve the local sysadmin _completely_ having assumed and
diligently carried out, without fail, all security maintenance
_manually_ for all eleven years, since 2011-06-24, when Security Team
coverage of F13 ceased permanently.
That would mean diligently reading all CVEs for all local components
exposed to public traffic -- including the Linux kernel (especially its
network stack), all public-facing services, and all of their libs and
support utilities -- doing, as appropriate, paring of
code/functionality, upgrading, mitigating, applying needed source
patches, etc.
That could be done, by a sufficiently determined and well-prepared
sysadmin who wishes to hand-maintain a very minimal system for
locally-compelling reasons. Gary, _did_ you do all that?
If you didn't, Gary, that's likely a key part of your problem. And
dismissing the problem of need to plug proven security holes with "the
upgrade treadmill is that it is a waste of time" is a reminder that
denial isn't a river in Egypt.
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
13 Aug
13 Aug
8:11 a.m.
Quoting saclug(a)garymcglinn.com (saclug(a)garymcglinn.com):
Anyone who is in charge of security on systems for an
organization of
any size should do all those things anyhow.
No, that would be insane.
My system, which is reasonably secure
O RLY?
Good luck to you. Peace, out.
12 Aug
12 Aug
5:07 p.m.
There may be. But I doubt if many apply to me. However, on a whim, I
installed Fedora 36 on the new drive and it works great. It's possible
that there was some other issue that was causing me difficulty in
upgrading. One prime candidate is operator error. Be that as it may, I
am now working on getting things working under Fedora 36.
I did some reading on UEFI and I have lots of philosopical
disagreements, primarily the same one I always have: It solves a problem
that shouldn't or doesn't exist and it is unnecessarily complex. Is
this really the wave of the future? I notice my Fedora 36 install
didn't use it. Apparently the NSA thinks it is a good idea. They go
all google eyed and mushy over secure boot. On their
page they have a "call for action" and a disclaimer that they aren't
making a recommendation within 3 adjacent paragraphs.
UEFI looks like a WinTel boondoggle to me. Putting a simulator of
Snoopy flying his dog house in a spreadsheet just has to be a good idea.
Apparently the NSA is now the old NSA calld SIGNT and the new NSA called
CSS. I don't know how this all relates to DHS.
-Gary
On Thu, Aug 11, 2022 at 02:46:23PM -0700, Brian E. Lavender wrote:
On Mon, Aug 08, 2022 at 09:39:34AM -0700,
saclug(a)garymcglinn.com wrote:
My experience with the upgrade treadmill is that
it is a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
The developers for Fedora 13 were no smarter or dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
There are probably a boat load of known vulnerabilities in F13. It's
probably a script kitty winter wonderland, depending upon what you have
installed/running! If you you want software that is secure proof, you
have to run something like "Ironsides", written using SPARK/Ada.
https://ironsides.martincarlisle.com/
Beyon that, the best is to keep patching on a stable distro that doesn't
have API changes, or minimal changes.
Brian
--
Brian Lavender
http://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
14 Sep
14 Sep
3:31 p.m.
It's a rare day when I don't patch FC38.
On Wed, Sep 13, 2023 at 3:09 PM <lug-nuts(a)bigbrie.com> wrote:
There may be. But I doubt if many apply to me.
However, on a whim, I
installed Fedora 36 on the new drive and it works great. It's possible
that there was some other issue that was causing me difficulty in
upgrading. One prime candidate is operator error. Be that as it may, I
am now working on getting things working under Fedora 36.
I did some reading on UEFI and I have lots of philosopical
disagreements, primarily the same one I always have: It solves a problem
that shouldn't or doesn't exist and it is unnecessarily complex. Is
this really the wave of the future? I notice my Fedora 36 install
didn't use it. Apparently the NSA thinks it is a good idea. They go
all google eyed and mushy over secure boot. On their
page they have a "call for action" and a disclaimer that they aren't
making a recommendation within 3 adjacent paragraphs.
UEFI looks like a WinTel boondoggle to me. Putting a simulator of
Snoopy flying his dog house in a spreadsheet just has to be a good idea.
Apparently the NSA is now the old NSA calld SIGNT and the new NSA called
CSS. I don't know how this all relates to DHS.
-Gary
On Thu, Aug 11, 2022 at 02:46:23PM -0700, Brian E. Lavender wrote:
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
On Mon, Aug 08, 2022 at 09:39:34AM -0700,
saclug(a)garymcglinn.com wrote:
> My experience with the upgrade treadmill is that it is a waste of time.
> By its own admission (if a concept can have that) the new versions will
> have issues and you need to upgrade. If the issues with an older
> version don't affect you, then it is perfectly fine to use it. Why
> upgrade and risk the fact that the new issues will affect your use
case.
The
developers for Fedora 13 were no smarter or dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
There are probably a boat load of known vulnerabilities in F13. It's
probably a script kitty winter wonderland, depending upon what you have
installed/running! If you you want software that is secure proof, you
have to run something like "Ironsides", written using SPARK/Ada.
https://ironsides.martincarlisle.com/
Beyon that, the best is to keep patching on a stable distro that doesn't
have API changes, or minimal changes.
Brian
--
Brian Lavender
http://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
_______________________________________________
Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
228
days inactive
630
days old
12 comments
6 participants
participants (6)
-
Brian E. Lavender -
Charles Polisher -
Linus Sphinx -
lug-nuts＠bigbrie.com -
Rick Moen -
saclug＠garymcglinn.com