Re: isakmpd link dynamically

2021-02-11 Thread Patrick Wildt
Am Thu, Feb 11, 2021 at 11:29:58AM +0100 schrieb Alexander Bluhm:
> - recommit in /usr/src/usr.sbin -> we loose history

I know no one cares about git, but if the move was committed in a
"single cvs commit", git would understand it's simply a move of files.
So yeah, cvs wouldn't cope, but git would.



Re: isakmpd link dynamically

2021-02-11 Thread Alexander Bluhm
On Wed, Feb 10, 2021 at 04:16:10PM -0700, Theo de Raadt wrote:
> When I re-ordered rc in Slovenia many years ago, I got it right.

NFS /usr over IPsec cannot work.  Without IPsec it is fine.
1. mount -s /usr >/dev/null 2>&1
2. start_daemon syslogd ldattach pflogd nsd unbound ntpd
3. start_daemon iscsid isakmpd iked sasyncd ldapd npppd

> So, I think we should move these two daemons.

What do you mean with "move"?
- install them in /usr/sbin -> inconsistent with usr.sbin source tree
- recommit in /usr/src/usr.sbin -> we loose history
- move the history to /cvs/src/usr.sbin -> someone said no more cvs surgery

I would like to commit my static linking diff as is.
Moving looks more complex to me.

bluhm



Re: isakmpd link dynamically

2021-02-10 Thread Theo de Raadt
Oh wait I misread.

When I re-ordered rc in Slovenia many years ago, I got it right.

So, I think we should move these two daemons.

Addendum: shared library linking increases the .so footprint, and
cross-.so ROP attacks are a tiny bit more difficult in OpenBSD.



Re: isakmpd link dynamically

2021-02-10 Thread Theo de Raadt
Alexander Bluhm  wrote:

> Hi,
> 
> Every time we ship a libcrypto erratum, we have to relink isakmpd.
> I think that isakmpd and iked are in /sbin due to a historic mistake.
> Probably it is for people who mount /usr via NFS over IPsec.

That was the reason originally.  Today I am not sure it makes sense.

Looking at the early daemons:

start_daemon syslogd ldattach pflogd nsd unbound ntpd
start_daemon iscsid isakmpd iked [...]

Some of these daemons can startup asyncronously, and if they are
configured to speak to the outside world, may end up outside a
configured vpn tunnel until the vpn routes are installed.  It is a bit
weird.  We could re-order a bit to make this better, maybe.  Should
we bother?

It is kind of funny, because syslogd startup (enabled by default) is
obviously broken for nfs diskless with seperate /usr, and potentially
seperate /var.

I guess noone is doing diskless with seperate /usr?  A part of me
wishes it kind of worked.  Pushing nfs diskless people into single
partition non-shared is a regression, isn't it?

> Moving isakmpd to /usr/sbin is hard, linking dynamically is easy.
> Lines stolen from iked.

If we are going to do this, why not move them.  We can install a
symbolic link from /sbin for a year or two, and then later stop
installing it, and basically all our users would be fine.



Re: isakmpd link dynamically

2021-02-10 Thread Vitaliy Makkoveev
On Wed, Feb 10, 2021 at 06:33:49PM +0100, Alexander Bluhm wrote:
> Hi,
> 
> Every time we ship a libcrypto erratum, we have to relink isakmpd.
> I think that isakmpd and iked are in /sbin due to a historic mistake.
> Probably it is for people who mount /usr via NFS over IPsec.
> 
> Moving isakmpd to /usr/sbin is hard, linking dynamically is easy.
> Lines stolen from iked.
> 
> Is there any reason to include bsd.subdir.mk?
> 
> ok?
> 

Indeed bsd.subdir.mk looks unreasonable here, but I'm not sure about
isakmpd.

> bluhm
> 
> Index: sbin/isakmpd/Makefile
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sbin/isakmpd/Makefile,v
> retrieving revision 1.88
> diff -u -p -r1.88 Makefile
> --- sbin/isakmpd/Makefile 10 Jul 2017 21:30:37 -  1.88
> +++ sbin/isakmpd/Makefile 10 Feb 2021 17:21:44 -
> @@ -87,4 +87,6 @@ generated: ${GENERATED}
>  BUILDFIRST = ${GENERATED}
>  
>  .include 
> -.include 
> +
> +# Don't compile isakmpd as static binary by default
> +LDSTATIC=
>