Which assembler does clang on OpenBSD use?
Hi, clang can use its integrated assembler or some other assembler (GNU as, I presume). How do I find out which one is used by default? The man page only says: "Whether the integrated assembler is on by default is target dependent". My platforms are aarch64 and i386, if it helps. Regards Stanislav
Authentication in OpenIKED
Hello, I have a question regarding authentication options in OpenIKED on OpenBSD 7.2 On my test lab I have one OpenBSD 7.2 machine with OpenIKED configured to use PSK and a macOS 13.2.1 client that can connect to it. I read in: man iked.conf that PSK should not be used, so I am now investigating EAP with MSCHAP-V2 and X.509 certificate authentication, but I am confused as to which is more secure. It seems to me that if I use EAP with MSCHAP-V2, I need a certificate on the OpenBSD machine, but I can connect from the macOS client with a user name and password, whereas X.509 authentication requires an X.509 certificate on *BOTH* client and server - is that correct ? If it is, is the reason that X.509 authentication is more secure because of the two certificates required, whereas authentication with EAP with MSCHAP-V2 is less secure because only one certificate is required ? Thanks, - J
Re: Hoping to donate/sell a Talos II motherboard
On Tue, Feb 28, 2023 at 7:46 PM wrote: > > My friend has a spare Talos II motherboard that is currently sitting in his > house > in Indiana USA collecting dust. > > https://www.raptorcs.com/TALOSII/ > > I have convinced him to donate/sell it to an open source project or developer. > > I reached out to Richard Stallman, and he agreed to take the board. I am > certain that the > FSF would put it to good use. My friend and I have not yet decided, to whom > we will give > the motherboard. Is it possible that I could give it to someone or project, > such that all > parties here would benefit? > > Is there any project or developer here that would be willing to take this > motherboard and create > virtual machines that other projects could have access to? > > Thoughts? I trimmed some of the non-relevant lists. The Talos workstations are PowerPC based. There are users on debian-powerpc who would put it to good use. https://lists.debian.org/debian-powerpc/ . And I am envious of your friend. I've got a Talos on my wishlist for a daily driver. Jeff
[Solved] Re: How to produce statically linked sshd binary
Thanks everyone, After some friendly advice off-list I was able to solve the problem. It was very simple really. However, since it is dubious practice at best, and runs contrary to the OpenBSD project goals, it feels wrong to share the "solution" here. Anyone interested may contact me off-list. Best Regards, Erling On Tue, Feb 28, 2023 at 04:42:53AM +0100, Erling Westenvik wrote: > Hi! > In the past, at least into several 6.x releases, I was able to produce a > statically linked sshd(8) binary like this: > > # cd /usr/src/usr.bin/ssh > # make clean > # make LDSTATIC=-static lib sshd > # strip /usr/src/usr.bin/ssh/sshd/sshd > > On a fresh 7.2 install however, the above won't do anymore. > > (It stops dead complaining about the "lib"-part in LDSTATIC=. When > trying without "lib" it goes on for a while but ends with complaints > about malloc-something. As you probabley understand by now, I'm not > exactly a wizard.. : ) > > Anyone up for outlining a simple "how-to"? > > Kind regards, > > Erling
Re: How to produce statically linked sshd binary
Ashlen wrote: > To sum it all up, what you're trying to do is hazardous and likely to end > poorly. That's why it's unsupported. Sorry, that last sentence is incorrect. our source tree contains what we want, and i the simplest way possible for our requirements. Whatever reconfiguration the rest of you want is your own problem. Complaining about it or writing essays is so completely missing the point.
Re: How to produce statically linked sshd binary
On 23/02/28 16:17, Erling Westenvik wrote: > Thanks. And I "know".. > > Use case: sshd in single user on quasi FDE-encrypted servers on co-location > not > accessible via KVM/AMT. I've done this on many machines since 2014. > > I acknowledge that it isn't recommended practice (and definitely not > supported!) but if anyone should want to help out, feel free to contact me > off-list! > > Best regards > > Erling (Keeping this on-list for the archives so anyone with a similar idea is aware of the consequences before attempting it. I hope you understand) I mean this in the kindest way: this sounds a lot like the "XY Problem." From what I can tell, you're presupposing that X (a statically linked and more vulnerable sshd) is the most appropriate way to handle Y (accessing single-user mode on those servers). It tends to be much more helpful to ask directly about Y. So it's OK, and even preferable, to focus on asking about Y, providing X as an explanation of what you've tried when prompted for it or if it seems appropriate to include. In any case, I can't speak much to how to do X here because I've never dealt with opening up single-user to remote login. In fact, I'd actually do whatever I could to find a different way of handling this. I'll explain why briefly. As you probably already know, single-user gives an exceptional level of control over system internals that are normally unavailable for security reasons---even root in multi-user is prohibited from doing these things. Its use is therefore best reserved for exceptional circumstances. It also follows that you should log in to single-user mode over a physical connection rather than a remote one if at all feasible, as an unauthorized party gaining this level of access is "game over" (this sort of thing is an attacker's fantasy, to say the least...). To sum it all up, what you're trying to do is hazardous and likely to end poorly. That's why it's unsupported.
Re: How to produce statically linked sshd binary
Thanks. And I "know".. Use case: sshd in single user on quasi FDE-encrypted servers on co-location not accessible via KVM/AMT. I've done this on many machines since 2014. I acknowledge that it isn't recommended practice (and definitely not supported!) but if anyone should want to help out, feel free to contact me off-list! Best regards Erling On Mon, Feb 27, 2023 at 09:09:02PM -0700, Theo de Raadt wrote: > Oh my god, don't do that! > > Your program will have a single aspect of randomness. > > If you leave it as it is, it has 6 .so's with independent random placement, > and 4 of them (sshd, ld.so, libc.so, and libcrypto.so) are randomly linked > at boot. > > These independent randomness are an incomplete but strong mitigation > against ROP attack methods. > > What you are trying to do is counter productive. > > Erling Westenvik wrote: > > > Hi! > > In the past, at least into several 6.x releases, I was able to produce a > > statically linked sshd(8) binary like this: > > > > # cd /usr/src/usr.bin/ssh > > # make clean > > # make LDSTATIC=-static lib sshd > > # strip /usr/src/usr.bin/ssh/sshd/sshd > > > > On a fresh 7.2 install however, the above won't do anymore. > > > > (It stops dead complaining about the "lib"-part in LDSTATIC=. When > > trying without "lib" it goes on for a while but ends with complaints > > about malloc-something. As you probabley understand by now, I'm not > > exactly a wizard.. : ) > > > > Anyone up for outlining a simple "how-to"? > > > > Kind regards, > > > > Erling > >
Re: Mtr prob request
Crystal Kolipe : > I'm working on the UTF-8 support in the kernel right now. I need a font with > glyphs for at least some of the extra characters. I can't just pull any old > font off of a website and convert it to the right format for use in the > kernel. > I'm expected to draw my own glyphs. Furthermore, I'm expected to write my > own font editor to boot, (which I did last Sunday, actually). Thx for this news and for your effort to each of you working on UTF-8. You have possibly 2.5 bilions + 1 fans more as surely I add myself to those bsd citizens it is really essential - for different reasons - having these chinese and non characters metabolized at system level. Without mention, the pain thinking to the Linoox support of Unicode.. -- Daniele Bonini Feb 28, 2023 10:42:52 Crystal Kolipe : > I'm working on the UTF-8 support in the kernel right now. I need a font with > glyphs for at least some of the extra characters. I can't just pull any old > font off of a website and convert it to the right format for use in the > kernel. > I'm expected to draw my own glyphs. Furthermore, I'm expected to write my > own font editor to boot, (which I did last Sunday, actually).
Re: Recommended place to store static arp entries
On Tue, Feb 28, 2023 at 03:30:18PM +0200, Cristian Danila wrote: > Dear Misc, > > I would really appreciate if more experienced members of you > could suggest if there is a dedicated place or recommended > place for OpenBSD where static arp entries should be stored. > I found many answers over the internet, in some books it is > mentioning /etc/netstart. > Also on very old thread fro OpenBSD I see it was discussed at > some point a possible idea like /etc/arp.conf > https://marc.info/?l=openbsd-bugs&m=103773290509612&w=2 > In the same thread it was mentioned rc.conf but definitly rc.conf > is a file that states that is should not be edited. > Or maybe rc.conf.local as an alternative? > > Where do you recommend storing static arp entries? To be honest I never had the need to store static arp entries. So for me the best place is /dev/null. Now if I really had to choose I would select the interface's hostname.if file to add static entries. It is the place where the interface gets its network which is the place arp entries hang off of. It will all be configured together and immediatly usable. -- :wq Claudio
Recommended place to store static arp entries
Dear Misc, I would really appreciate if more experienced members of you could suggest if there is a dedicated place or recommended place for OpenBSD where static arp entries should be stored. I found many answers over the internet, in some books it is mentioning /etc/netstart. Also on very old thread fro OpenBSD I see it was discussed at some point a possible idea like /etc/arp.conf https://marc.info/?l=openbsd-bugs&m=103773290509612&w=2 In the same thread it was mentioned rc.conf but definitly rc.conf is a file that states that is should not be edited. Or maybe rc.conf.local as an alternative? Where do you recommend storing static arp entries? Thank you.
Hoping to donate/sell a Talos II motherboard
Hello you fabulous developers! My friend has a spare Talos II motherboard that is currently sitting in his house in Indiana USA collecting dust. https://www.raptorcs.com/TALOSII/ I have convinced him to donate/sell it to an open source project or developer. I reached out to Richard Stallman, and he agreed to take the board. I am certain that the FSF would put it to good use. My friend and I have not yet decided, to whom we will give the motherboard. Is it possible that I could give it to someone or project, such that all parties here would benefit? Is there any project or developer here that would be willing to take this motherboard and create virtual machines that other projects could have access to? Thoughts? Thanks, Joshua Branson FOSS enthusiast https://gnucode.me
Re: Mtr prob request
On Tue, Feb 28, 2023 at 09:16:23AM +0100, Daniele B. wrote: > Janne Johansson wrote: > > # GPLv2+ > > > > So this is why it would not be considered, even if someone wanted it in > > base. > > > > It is not a goal in itself to move stuff from ports to base. > > Thanks for the extended explanation too. > > This remind me two important stuff. The first is to not trust 100% software > just because is > the ports/packages and this should be enough worrisome. Second do not accept > 3rd party > requests to install packages that could compromise your system although > source of requests > appears "100%" clean. ** It's always a good idea to look over the software you are about to install before installing it, and even more so before allowing it to become something that you rely on. This includes looking at who wrote it, who maintains it, and what their development style is. Some open source software is developed in a controlled way, and some is developed in a very ad-hoc and slap-dash way. Just to take one example - software which doesn't have specific releases, but just tells you to 'download the latest code from git', is always something I am suspicious of. Firstly, it's lazy. Secondly, it means that there is much less likely to be a sizeable base of users running the same code, which is useful for testing. Thirdly, can I trust their git repository not to have been compromised? I want a simple source tarball, that somebody at least tested compiles successfully, with a hash of some sort that I can verify against a difficult to compromise source, (public mailing list post, third party website, etc). This takes effort. If a project doesn't want to make that effort, what else are they potentially slacking on? And can it negatively affect the stability of my machines? OpenBSD is great in this regard. Releases are _very_ well organised, and being able to plan upgrades around a 6 month release cycle is a major benefit. Also, in _my_ experience, with software that _I_ use, (so other people's experiences may be different), I've found that software licensed under the GPL, or that has come from a source with a linux background, tends to be more likely to suddenly want to pull in a whole new set of libraries as dependencies after an upgrade. This seems to stem from the misguided idea that writing new code to do foo when code already exists to do foo is a bad thing. It's not. Especially if the existing foo requires 200 external libraries just to toggle a few bits, and do something that could be done in 10 lines of well-written C. Once again, OpenBSD scores well here. How many external libraries does smtpd depend on? How many does httpd depend on? When you upgrade to OpenBSD 7.3, are you likely to find an extra 200 Mb of libraries installed as part of base, just because httpd added support for sending one new header? No, of course not. None of the OpenBSD developers would support such a move. And we can pretty much _rely_ on that. So you can make a commitment to OpenBSD _now_ and your chances of getting burned some time in the future are probably quite slim. (As long as we are talking about the _base_ system.) The sudden extra dependencies required by new versions of software in ports might include things that I don't want on my system. Or at least not on particular production systems. At some point, some dependency of gstreamer started to require rust, and this makes it difficult, (but not impossible), to compile and use webkit without installing rust on the same system. I've got nothing against rust particularly, but the rust compiler is written in rust, so by default a source build is not truely from source, because you need to download some pre-compiled binaries to bootstrap the compile process. Last time I tried to build it starting from an ancient C version of the rust compiler it wasted a lot of time. All of this is a big part of why basically all of the new software that we develop in house at Exotic Silicon is written from scratch. If I write software during work time, I'm expected to justify any use of external libraries, because we do not want to create a dependency on something that we do not control. I'm working on the UTF-8 support in the kernel right now. I need a font with glyphs for at least some of the extra characters. I can't just pull any old font off of a website and convert it to the right format for use in the kernel. I'm expected to draw my own glyphs. Furthermore, I'm expected to write my own font editor to boot, (which I did last Sunday, actually). Other people mock this approach. But it works, and as far as I'm concerned our software is better for it. Our website CMS runs fast on very low-spec hardware. Why? Because it's about 2000 lines of tight C code, with ZERO use of software from ports. We wrote our own fcgi handler, we didn't run to the ports tree for one. So the take
Re: Mtr prob request
Not to mention, the main mistake of mine is to have accepted to install a package to make stuff like traceroute (already included in the base) does. -- Daniele Bonini Feb 28, 2023 09:16:25 Daniele B. : > Janne Johansson wrote: >> Really simple actually, www.openbsd.org/goals.html , point #2 >> >> * "Integrate good code from any source with acceptable licenses... the GPL >> is not acceptable >> when adding new code" >> and the mtr ports Makefile: >> https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/mtr/Makefile?annotate=1.75 >> line 10 or so, >> # GPLv2+ >> >> So this is why it would not be considered, even if someone wanted it in base. >> >> It is not a goal in itself to move stuff from ports to base. > > Thanks for the extended explanation too. > > This remind me two important stuff. The first is to not trust 100% software > just because is > the ports/packages and this should be enough worrisome. Second do not accept > 3rd party > requests to install packages that could compromise your system although > source of requests > appears "100%" clean. > > > > > -- Daniele Bonini > > Feb 28, 2023 08:24:19 Janne Johansson : > >> Den mån 27 feb. 2023 kl 16:22 skrev Daniele B. : >>> Janne Johansson : >>> It has been in ports/packages since 1999, it will stay there. >>> >>> Ok, thanks for the update. >> >> Really simple actually, www.openbsd.org/goals.html , point #2 >> >> * "Integrate good code from any source with acceptable licenses. ISC >> or Berkeley style licences are preferred, the GPL is not acceptable >> when adding new code" >> (where "any source" doesn't mean "take any random program you find" >> but rather "do not place external values on the source of a program we >> decided we want to integrate") >> >> and the mtr ports Makefile: >> https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/mtr/Makefile?annotate=1.75 >> line 10 or so, >> # GPLv2+ >> >> So this is why it would not be considered, even if someone wanted it in base. >> >> It is not a goal in itself to move stuff from ports to base. >> >> -- >> May the most significant bit of your life be positive.
Re: Mtr prob request
Janne Johansson wrote: > Really simple actually, www.openbsd.org/goals.html , point #2 > > * "Integrate good code from any source with acceptable licenses... the GPL is > not acceptable > when adding new code" > and the mtr ports Makefile: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/mtr/Makefile?annotate=1.75 > line 10 or so, > # GPLv2+ > > So this is why it would not be considered, even if someone wanted it in base. > > It is not a goal in itself to move stuff from ports to base. Thanks for the extended explanation too. This remind me two important stuff. The first is to not trust 100% software just because is the ports/packages and this should be enough worrisome. Second do not accept 3rd party requests to install packages that could compromise your system although source of requests appears "100%" clean. -- Daniele Bonini Feb 28, 2023 08:24:19 Janne Johansson : > Den mån 27 feb. 2023 kl 16:22 skrev Daniele B. : >> Janne Johansson : >> >>> It has been in ports/packages since 1999, it will stay there. >> >> Ok, thanks for the update. > > Really simple actually, www.openbsd.org/goals.html , point #2 > > * "Integrate good code from any source with acceptable licenses. ISC > or Berkeley style licences are preferred, the GPL is not acceptable > when adding new code" > (where "any source" doesn't mean "take any random program you find" > but rather "do not place external values on the source of a program we > decided we want to integrate") > > and the mtr ports Makefile: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/mtr/Makefile?annotate=1.75 > line 10 or so, > # GPLv2+ > > So this is why it would not be considered, even if someone wanted it in base. > > It is not a goal in itself to move stuff from ports to base. > > -- > May the most significant bit of your life be positive.
