Hal Murray :
> Is this an opportunity to clean up that area?
I don't think so. It's pretty clean now, functionally speaking - I put
a lot of work into rationalizing the configurator structures and the
way they talk to the protocol machine.
I suppose it might be if we were willing to make
cimparib
> The current blocker on the port is that Flex and Bison can't yet emit Go
> code. I'm probably going to have to fix that myself. There are roughly
> equivalent tools such as goyacc that are fine for new projects, but
> guaranteeing that you get the same accept grmmar from specifications in two
Hal Murray :
>
> >> If you want to claim your Go program has no buffer overruns,
> >> you can't call out to big complicated libraries written in c. You
> >> would have to rewrite them in Go.
>
> > Fair point. That changes my to-do list.
>
> Could you please say more? What did you add or drop?
>> If you want to claim your Go program has no buffer overruns,
>> you can't call out to big complicated libraries written in c. You
>> would have to rewrite them in Go.
> Fair point. That changes my to-do list.
Could you please say more? What did you add or drop?
--
These are my opinions
Hal Murray :
>
> e...@thyrsus.com said:
> >> I think you have jumped to an unreasonable conclusion by assuming that Go
> >> makes seccomp unintestering. Are you going to rewrite OpenSSL in Go?
> > No. There's an opennsl binding: ...
>
> That's the whole point of my comment. OpenSSL is written
e...@thyrsus.com said:
>> I think you have jumped to an unreasonable conclusion by assuming that Go
>> makes seccomp unintestering. Are you going to rewrite OpenSSL in Go?
> No. There's an opennsl binding: ...
That's the whole point of my comment. OpenSSL is written in c. If there is a
typ
Yo Eric!
On Wed, 2 Sep 2020 20:35:38 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Buffer overruns are just one way a program might make unexpected
> > system calls. Even if you can guarantee that a Go program could
> > never be maliciously corrupted externally, you can never
Gary E. Miller via devel :
> Buffer overruns are just one way a program might make unexpected system
> calls. Even if you can guarantee that a Go program could never be
> maliciously corrupted externally, you can never guarantee that the
> Go program can not be trojaned.
Everything is cost gradie
Yo Eric!
On Wed, 2 Sep 2020 19:39:05 -0400
"Eric S. Raymond via devel" wrote:
> > > Even without that, are you sure there are no bugs in Go?
>
> No, I'm not. But neither do I think seccomp is actually *possible*
> in Go at this point, which tends to relieve us of having to support
> it.
Alr
Hal Murray :
>
> e...@thyrsus.com said:
> > I think you misunderstand. I don't believe seccomp is objectively very
> > important in itself, and never have. My problem with dropping it is that if
> > we do that, we could be seen to have abandoned part of a security defense in
> > depth because it
On 9/2/20 2:30 PM, Hal Murray wrote:
>> I do ship an AppArmor profile.
>
> Thanks. That's the word I was fishing for.
>
> I've never worked with it. Is there a good introductory writeup?
There is various documentation, but I don't have anything off the top of
my head to direct you to.
> Are t
e...@thyrsus.com said:
> I think you misunderstand. I don't believe seccomp is objectively very
> important in itself, and never have. My problem with dropping it is that if
> we do that, we could be seen to have abandoned part of a security defense in
> depth because it's too much work. That'
> I do ship an AppArmor profile.
Thanks. That's the word I was fishing for.
I've never worked with it. Is there a good introductory writeup?
Are their similar facilities available on other OSes/distros?
--
These are my opinions. I hate spam.
_
On 9/1/20 10:27 PM, Hal Murray via devel wrote:
> What's the word for what Debian does?
In the package: no seccomp.
I really don't see the advantage in seccomp; it seems like a lot more
trouble than it is worth.
I do ship an AppArmor profile.
--
Richard
signature.asc
Description: OpenPGP di
Yo Eric!
On Wed, 2 Sep 2020 14:33:10 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Lost me. seccomp applies to Go as much as it applies to C.
>
> Why do you think so? My understanding is that the reason you want to
> block unexpected system calls is becase C buffer overrun
Gary E. Miller via devel :
> Lost me. seccomp applies to Go as much as it applies to C.
Why do you think so? My understanding is that the reason you want to
block unexpected system calls is becase C buffer overruns can be used
to make weird machines.
You can't do that in Go, because there's no
Yo Eric!
On Wed, 2 Sep 2020 05:52:54 -0400
"Eric S. Raymond via devel" wrote:
> Hal Murray :
> > You keep saying seccomp is important. What does it buy us? ntpd
> > is a big complicated program. It reads and writes files. It opens
> > network connections. What else would a bad guy need to d
Hal Murray :
> You keep saying seccomp is important. What does it buy us? ntpd is a big
> complicated program. It reads and writes files. It opens network
> connections. What else would a bad guy need to do?
I think you misunderstand. I don't believe seccomp is objectively
very important i
[This has been in the works for a while, but I keep forgetting to type it in.]
Seccomp is a rathole. I'm tired of it. I think my time will be better spent
on other things and/or our time could be better spent on other approaches -
jails and such. What's the word for what Debian does?
---
19 matches
Mail list logo
