Retguard: An improved stack protector for OpenBSD
41–50 of 73 posts
Re: Retguard: An improved stack protector for OpenBSD
#42Earlier quoted context omitted.
If nothing else, nobody "owns" CVS. Github (and thus, effectively git by sheer mass) is now owned by Microsoft.
Your "MS owns Git" argument is silly. By analogy, Facebook and Reddit must own HTML, because they are such popular Web sites. OpenBSD could easily use Git if they wanted to, and they'd never have to touch MS code, or an MS Web property.
Re: Retguard: An improved stack protector for OpenBSD
#43Earlier quoted context omitted.
If nothing else, nobody "owns" CVS. Github (and thus, effectively git by sheer mass) is now owned by Microsoft.
Your "MS owns Git" argument is silly. By analogy, Facebook and Reddit must own HTML, because they are such popular Web sites. OpenBSD could easily use Git if they wanted to, and they'd never have to touch MS code, or an MS Web property.
Re: Retguard: An improved stack protector for OpenBSD
#44Earlier quoted context omitted.
If nothing else, nobody "owns" CVS. Github (and thus, effectively git by sheer mass) is now owned by Microsoft.
Your "MS owns Git" argument is silly. By analogy, Facebook and Reddit must own HTML, because they are such popular Web sites. OpenBSD could easily use Git if they wanted to, and they'd never have to touch MS code, or an MS Web property.
Git is used by a comparatively small captive audience; most git users are invested in GitHub. MS is well positioned to run their "embrace, extend, extinguish" play if they wanted to.
Re: Retguard: An improved stack protector for OpenBSD
#45While I didn't understand most of this, any reason why they're still using CVS? Genuinely curious, I'm sure they have good reasons.
They've managed to maintain a consistent roughly-6 month release cadence since 1995. CVS is working for them, so why switch?
Re: Retguard: An improved stack protector for OpenBSD
#46Earlier quoted context omitted.
You must be jealous that we're self-hosted. ;-)
I made a program called Meta-CVS in 2002 that stores a versioned directory structure with permissions and symbolic links along with the files in an ordinary CVS repository. http://www.kylheku.com/~kaz/mcvs.html Meta-CVS has an import feature (mcvs grab) which detects renamed files. It fixes up symlinks pointing to moved files too and such. Meta-CVS didn't catch on widely because by the time I had it stable, CVS itsel…
https://www.dwheeler.com/essays/scm-security.html
On top of yours, the OpenCM and Aegis programs attempted to meet some of these requirements. Most ignore them. Big, blind spot in software security.
Re: Retguard: An improved stack protector for OpenBSD
#47Earlier quoted context omitted.
It is simple, they know it well and it works. Just like C89.
That was my first thought as well, then I realise CVS is not maintained for more then a decade. I know not everyone likes Git but wouldn't SVN be a better solution.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/
It's not especially active, but you can see the last change sets were in the past year, so "not maintained for more than a decade" doesn't apply to what they're using.
Re: Retguard: An improved stack protector for OpenBSD
#48Earlier quoted context omitted.
They put it into a system people will actually use. Just leaving these here... https://www.theregister.co.uk/2017/06/26/linus_torvalds_slam... https://www.theregister.co.uk/2018/01/19/grsecurity_libel_ap...
This is just drama and isn't informative in any way.
When the BDFL of one's kernel says something like that, combined with how radioactive the community interaction seems to have been in the past, the notion that one might get sufficient support or have positive interactions with the wider community while using the grsec kernel fork is dubious at best.
Re: Retguard: An improved stack protector for OpenBSD
#49Earlier quoted context omitted.
They've managed to maintain a consistent roughly-6 month release cadence since 1995. CVS is working for them, so why switch?
You could say the same abouf most stuff OpenBSD rewrites for improved security. Many of those things aren't even critical. They just do thd rewrites as part of code maintenance. Then, they use CVS instead of a high-integrity/security VCS. It's a little strange/inconsistent if compared to the general pattern of replacing old, insecure stuff.
The underlying security of the operating system and user applications running in it has very different risks and benefits versus the integrity of source code commits and who gets to make them.
The latter is something they're equipped to deal with without changing tools. They've decided that the costs of making that technology change aren't worth the benefits that it provides and I mostly agree.
Re: Retguard: An improved stack protector for OpenBSD
#50Earlier quoted context omitted.
This is just drama and isn't informative in any way.
It's informative in that it tells one that one should stay away from grsec's patch sets and why. When the BDFL of one's kernel says something like that, combined with how radioactive the community interaction seems to have been in the past, the notion that one might get sufficient support or have positive interactions with the wider community while using the grsec kernel fork is dubious at best.
Either way: I'm not saying Retguard is based on RAP --- my question was, "what's the relationship between the techniques". But if there is a relationship, OpenBSD should be explicit about it, so that we can keep track of the evolution of memory corruption countermeasures.
I do not care whether you think people should or shouldn't run grsecurity.