On Sat, 17 Aug 2024 11:05:40 -0700
Kent Borg wrote:
> I seem to remember someone saying that firewalls don't fail "off", or
> something like that.
>
> Well, on a Linode machine I have, running very standard Debian, with
> no real customizations, I noticed today the firewall was off:
That was m
I seem to remember someone saying that firewalls don't fail "off", or
something like that.
Well, on a Linode machine I have, running very standard Debian, with no
real customizations, I noticed today the firewall was off:
root@www:/home/kentborg# ufw status
Status: inactive
root@www:/home/ke
On Sat, 10 Aug 2024 09:52:32 -0700
Kent Borg wrote:
> I sometimes feel like I'm the only one who doesn't want a car to be a
> rolling "smartphone". My current car has an engine computer the
> controls ignition stuff, but otherwise is close to completely manual.
> And as a result, I might keep ru
On 8/10/24 05:49, Rich Pieri wrote:
You know how in-car software is notoriously insecure and never updated?
Red Hat are looking to change that with Red Hat Automotive.
I sometimes feel like I'm the only one who doesn't want a car to be a
rolling "smartphone". My current car has an engine compu
On 2024-08-10 10:21, Rich Pieri wrote:
On Sat, 10 Aug 2024 10:13:20 -0400
Daniel M Gessel wrote:
Isn't ShareLaTeX "LaTeX on a server"? Don't you upload your files (or
edit them in a browser), then LaTeX is run on their machines?
No. It's collaborative LaTeX: multiple concurrent editing. At
On Sat, 10 Aug 2024 10:13:20 -0400
Daniel M Gessel wrote:
> Isn't ShareLaTeX "LaTeX on a server"? Don't you upload your files (or
> edit them in a browser), then LaTeX is run on their machines?
No. It's collaborative LaTeX: multiple concurrent editing. At least
that's what it used to be. I don'
On 2024-08-10 08:49, Rich Pieri wrote:
I've ranted about how ShareLaTeX, now Overleaf(?), abuses containers to
distribute garbage code. Here are some counter-examples that I use
daily.
Isn't ShareLaTeX "LaTeX on a server"? Don't you upload your files (or
edit them in a browser), then LaTeX is ru
> On Fri, 9 Aug 2024 18:07:27 -0400
> ma...@mohawksoft.com wrote:
>
>> There was no failure, it was nothing more than constantly evolving
>> technology adjusting to new realities.
>
> This.
>
> I've ranted about how ShareLaTeX, now Overleaf(?), abuses containers to
> distribute garbage code. Here a
On Fri, 9 Aug 2024 18:07:27 -0400
ma...@mohawksoft.com wrote:
> There was no failure, it was nothing more than constantly evolving
> technology adjusting to new realities.
This.
I've ranted about how ShareLaTeX, now Overleaf(?), abuses containers to
distribute garbage code. Here are some counter
Steve Litt wrote:
> Dan Ritter said on Tue, 6 Aug 2024 13:03:04 -0400
>
> >The rise of virtual machines and containers is an admission of
> >systemic failure: people gave up on managing dependencies in a
> >sensible manner. Rather than have a deployment system which
> >produces a working program
On 2024-08-09 13:36, Kent Borg wrote:
On 8/6/24 10:03, Dan Ritter wrote:
The rise of virtual machines and containers is an admission of
systemic failure: people gave up on managing dependencies in a
sensible manner.
I've always considered the reason to be that the traditional idea of
what s
> Dan Ritter said on Tue, 6 Aug 2024 13:03:04 -0400
>
>>The rise of virtual machines and containers is an admission of
>>systemic failure: people gave up on managing dependencies in a
>>sensible manner. Rather than have a deployment system which
>>produces a working program plus libraries and confi
On Fri, 9 Aug 2024 10:36:27 -0700
Kent Borg wrote:
> The OS clearly isn't doing enough to manage dependencies if people
> prefer what BIOS offers (or I guess UEFI these days) to what the OS
> offers. A mark of failure for the OS.
Kinda but kinda not?
Virtual machines have been around for deca
On 8/6/24 10:03, Dan Ritter wrote:
The rise of virtual machines and containers is an admission of
systemic failure: people gave up on managing dependencies in a
sensible manner.
I've always considered the reason to be that the traditional idea of
what services an OS should offer has become tat
Dan Ritter said on Tue, 6 Aug 2024 13:03:04 -0400
>The rise of virtual machines and containers is an admission of
>systemic failure: people gave up on managing dependencies in a
>sensible manner. Rather than have a deployment system which
>produces a working program plus libraries and configuratio
> On 8/7/24 09:41, Kent Borg wrote:
>
> -kb, the Kent who is lazy and likes having fast data structures for
> free, even though he is sure Mark could implement a faster B-tree in C*.
I know you are saying this with some humor, however, it is circumstantial.
What happens when you have billions of
On 8/7/24 09:41, Kent Borg wrote:
Again, the posting says this requires further investigation with the
early guess that Rust is being nicer to the cache.
Turns out there was a followup post.
https://bcantrill.dtrace.org/2018/09/28/the-relative-performance-of-c-and-rust/
I think it is fair to
On 8/6/24 18:39, Rich Pieri wrote:
On Tue, 6 Aug 2024 16:31:29 -0700
Kent Borg wrote:
C/C++ compilers are more mature, so there are better optimizers for
C/C++ programmers. This is an advantage for C. Though, not always:
sometimes the machine code will simply be as fast as it possible, and
som
> On 8/6/24 14:53, ma...@mohawksoft.com wrote:
>> I call BS on that whole paragraph. Rust is OK, but ANYTHING you can
>> write
>> in Rust can be written to be faster in C/C++.
>
> Both are compiled languages, frequently using related compilers. Both
> are going to approach as-fast-as-possible. Theo
On Tue, 6 Aug 2024 16:31:29 -0700
Kent Borg wrote:
> C/C++ compilers are more mature, so there are better optimizers for
> C/C++ programmers. This is an advantage for C. Though, not always:
> sometimes the machine code will simply be as fast as it possible, and
> sometimes Rust will be that fa
> On Tue, 6 Aug 2024 18:12:25 -0400
> ma...@mohawksoft.com wrote:
>
>> Without getting into too much detail, their SVC server product had a
>> real-time polling process that maintained timers on various
>> processes, if the processing took too long, the system would
>> "fail-over" to the other node
On 8/6/24 14:53, ma...@mohawksoft.com wrote:
I call BS on that whole paragraph. Rust is OK, but ANYTHING you can write
in Rust can be written to be faster in C/C++.
Both are compiled languages, frequently using related compilers. Both
are going to approach as-fast-as-possible. Theoretically.
On Tue, 6 Aug 2024 18:12:25 -0400
ma...@mohawksoft.com wrote:
> Without getting into too much detail, their SVC server product had a
> real-time polling process that maintained timers on various
> processes, if the processing took too long, the system would
> "fail-over" to the other node. They we
>> - virtual machines impose a penalty of 1% or more -- worse when
>>not optimally configured
That's not even the half of it. I've done a few deep dives in VM
performance and one of the more insidious problems is scheduling multiple
CPUs for a VM. I was having a discussion with another engin
> On Tue, 6 Aug 2024 00:31:39 -0400
> Bill Bogstad wrote:
> The Rust language is an example of people doing exactly this. It's
> good, not perfect, but much better than C. And when optimized well, it
> can perform on par with or better than C.
I call BS on that whole paragraph. Rust is OK, but A
On 2024-08-06 13:03, Dan Ritter wrote:
Daniel M Gessel wrote:
On 2024-08-06 11:47, Dan Ritter wrote:
Daniel M Gessel wrote:
On 2024-08-06 00:31, Bill Bogstad wrote:
We would have a whole lot fewer moles to whack if we changed our tools.
In some cases a 5% performance hit is huge - offeri
Daniel M Gessel wrote:
>
>
> On 2024-08-06 11:47, Dan Ritter wrote:
> > Daniel M Gessel wrote:
> > > On 2024-08-06 00:31, Bill Bogstad wrote:
> > > > We would have a whole lot fewer moles to whack if we changed our tools.
> > > In some cases a 5% performance hit is huge - offering up "our progra
On 2024-08-06 11:47, Dan Ritter wrote:
Daniel M Gessel wrote:
On 2024-08-06 00:31, Bill Bogstad wrote:
We would have a whole lot fewer moles to whack if we changed our tools.
In some cases a 5% performance hit is huge - offering up "our programmers
make mistakes" as a justification is a non
Daniel M Gessel wrote:
> On 2024-08-06 00:31, Bill Bogstad wrote:
> > We would have a whole lot fewer moles to whack if we changed our tools.
>
> In some cases a 5% performance hit is huge - offering up "our programmers
> make mistakes" as a justification is a non-starter.
Remember that:
- virt
On 2024-08-06 00:31, Bill Bogstad wrote:
We would have a whole lot fewer moles to whack if we changed our tools.
In some cases a 5% performance hit is huge - offering up "our
programmers make mistakes" as a justification is a non-starter.
But enabling checks on security critical systems make
On Tue, 6 Aug 2024 00:31:39 -0400
Bill Bogstad wrote:
> Did I say that I wanted perfection? In text that you removed, I
No. Kent was suggesting that. I'm sorry that I conflated your and their
arguments. Because you and I are in vehement agreement.
> programs by something like 5-10%. Does an
On Sun, Aug 4, 2024 at 11:22 AM Rich Pieri wrote:
>
> On Sat, 3 Aug 2024 22:05:49 -0400
> Bill Bogstad wrote:
>
> > I think it is basically because the industry has convinced itself
> > that bugs are inevitable and there is no way to mitigate those bugs
> > becoming security problems. Back in t
On Sun, 4 Aug 2024 12:38:00 -0700
Kent Borg wrote:
> Rich Pieri wrote:
>
> > First, the original quote is, "[t]he worst enemy of security is
> > complexity."
> Okay.
>
> And I am quoting Peter Gutmann, circa now. I like his version better.
Yes, well, it seems to me that you still aren't get
On 2024-08-04 15:38, Kent Borg wrote:
On 8/4/24 11:07, Daniel M Gessel wrote:
people will try to isolate trusted networks from the untrusted
outside world;
And I assert that it is usually a bad design to pretend that "trusted
networks" are worthy of trust. That's not paranoid enough.
Don't
On 8/4/24 11:07, Daniel M Gessel wrote:
people will try to isolate trusted networks from the untrusted outside
world;
And I assert that it is usually a bad design to pretend that "trusted
networks" are worthy of trust. That's not paranoid enough.
any such scheme is called a "firewall".
B
On Sun, 4 Aug 2024 09:45:06 -0700
Kent Borg wrote:
Security is not a state. It's an iterative process.
I originally wrote a lot of tearing down of straw-man assertions like
firewalls failing open (they don't: they fail closed so there is no
access in or out and therefore there is no damage). But
Securing systems imposes overhead of various kinds, so people will try
to isolate trusted networks from the untrusted outside world; any such
scheme is called a "firewall".
Firewalls seem like a good thing.
___
Discuss mailing list
Discuss@driftwood.b
On 8/3/24 19:05, Bill Bogstad wrote:
What you are basically saying is that we need to write software that
has essentially 0 bugs.
I'm saying we need to at least try.
The measure of success isn't that there are 0 bugs, it is that that we
are reducing the numbers of bugs. And at least eliminati
On Sat, 3 Aug 2024 22:05:49 -0400
Bill Bogstad wrote:
> I think it is basically because the industry has convinced itself
> that bugs are inevitable and there is no way to mitigate those bugs
> becoming security problems. Back in the 90s, I found security
> fascinating; but when I realized that
On Fri, Aug 2, 2024 at 2:31 PM Kent Borg wrote:
> On 8/1/24 18:46, Rich Pieri wrote:
> > Because we didn't have firewalls in the 1980s.
>
>
> Both of of these were happening because we *were* aware there were
> problems and we *knew* needed to do something about them.
>
> In the mid '90s the
On Fri, 2 Aug 2024 14:28:25 -0400
Daniel M Gessel wrote:
> On 2024-08-02 08:38, Rich Pieri wrote:
> > Probably the closest to perfection we have right now is iPhone.
> Maybe it's my broken sense of humor, but trying to reconcile this
> sentence posted to a Linux discussion group creates a knee
On 8/1/24 18:46, Rich Pieri wrote:
Because we didn't have firewalls in the 1980s.
Correct. Commercial firewalls date to 1995. But it was not an obscure
product offering, Data Communications Magazine called the first one "Hot
product of the year". We were aware there were problems, that is why
On 2024-08-02 08:38, Rich Pieri wrote:
Probably the closest to perfection we have right now is iPhone.
Maybe it's my broken sense of humor, but trying to reconcile this
sentence posted to a Linux discussion group creates a knee-wobbling
quantity of cognitive dissonance...
_
On Fri, 2 Aug 2024 07:35:22 -0400
Dan Ritter wrote:
> The second biggest problem is that we started using a
> firewall-evading technology to invite other people to run code on
> our machines -- web browsers.
This is a big piece of why Kent's perfectly secure system is a myth: no
matter how much
Daniel M Gessel wrote:
> Firewalls seem like an ideal solution: a trusted network inside an effective
> firewall is free from the (not insignificant) overhead of security.
>
> But firewalls aren't completely effective and are only one tool that we all
> use on a daily basis.
The biggest problem
Firewalls seem like an ideal solution: a trusted network inside an
effective firewall is free from the (not insignificant) overhead of
security.
But firewalls aren't completely effective and are only one tool that we
all use on a daily basis.
On 2024-08-01 21:46, Rich Pieri wrote:
On Thu,
On Thu, 1 Aug 2024 16:37:47 -0700
Kent Borg wrote:
> And all of that was built on the unquestioned assumption that
> firewalls are how we keep our computing safe.
I think you're putting the cart before the horse.
Because we didn't have firewalls in the 1980s. The concept existed and
probably a
My bro runs BSD with a mail and web server (and maybe some other stuff
too), but he has organized everything into jails so each service is a
different environment, but it's all one physical machine - I don't
really understand the details.
I run sshd on my RPis but not on my laptop. I configure
On 8/1/24 15:28, Rich Pieri wrote:
Because 40 years ago there were maybe 50,000 nodes on ARPANET.
AWS goes back to 2002. By 2006 S3 and Elastic Compute were available.
Twenty years, to go from blank sheet to "Are you a backend programmer or
frontend programmer?", because now almost everyone a
On 8/1/24 14:34, Daniel M Gessel wrote:
This thread makes me want to ask:
As an amateur (and neophyte) sys-admin, what should I be doing to
check for vulnerabilities and attacks? My brother runs a publicly
visible server, but I'm not familiar with the tools he uses and when I
ask him, it all
On Thu, 1 Aug 2024 14:41:47 -0700
Kent Borg wrote:
> Since the term "zero trust" was first coined (30-bleeping years ago!,
> in 1994) we have tailored a *lot* of stuff, from scratch. The entire
> cloud, for example, a lot by any standard. We mostly built all from
> scratch, following *no* ones ve
On 8/1/24 14:06, Dan Ritter wrote:
I agree that's a nice way to build tailored systems
Since the term "zero trust" was first coined (30-bleeping years ago!, in
1994) we have tailored a *lot* of stuff, from scratch. The entire cloud,
for example, a lot by any standard. We mostly built all from
This thread makes me want to ask:
As an amateur (and neophyte) sys-admin, what should I be doing to check
for vulnerabilities and attacks? My brother runs a publicly visible
server, but I'm not familiar with the tools he uses and when I ask him,
it all goes over my head!
Is there a guide/boo
Kent Borg wrote:
> On 8/1/24 10:29, Dan Ritter wrote:
> > Zero Trust means that you don't*grant* access based on the
> > sender's IP.
>
> I like my version better: Design and build your system so that every node is
> secure enough to sit on today's open internet.
That's great. Give it another n
On 8/1/24 10:29, Dan Ritter wrote:
Zero Trust means that you don't*grant* access based on the
sender's IP.
I like my version better: Design and build your system so that every
node is secure enough to sit on today's open internet.
The idea of granting access based on the other node's IP add
On Thu, 1 Aug 2024 10:03:28 -0700
Kent Borg wrote:
> P.P.S. My decades long dislike of firewalls is *finally* getting
> trendy with the impressive name "Zero Trust Architecture", it even
> has a TLA: "ZTA". Nice when the world finally catches up here and
> there.
Zero Trust does not mean no fire
As a contrary opinion, I think firewalls are great.
I deal with computer security on a regular basis. Do you know how many
threats there are? OMG its crazy. Every day I hears of crap that just
blows my mind. Just recently OpenSSH_8.9p1 fixed an issue where an
external agent can get root access to
Kent Borg wrote:
> Anyway, finally to the point.
>
> What is going on in this short excerpt (out of a very long e-mail of such
> stuff):
>
> > From 103.203.58.1 - 1 packet to tcp(8001)
> > From 103.224.217.31 - 1 packet to tcp(23)
> > From 103.229.127.36 - 1 packet to udp(1434)
> >
I mostly don't like firewalls, seems to me it is better to only listen
on the ports one wants to listen on and only listen on those for
specific good reasons. Firewalls are mostly used as a substitute for
such discipline. Also, iptables rules are a pain to set up, looking more
prone to error th
59 matches
Mail list logo
