From nobody Fri Oct 20 08:28:41 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SBd5p6jThz4xVdS for ; Fri, 20 Oct 2023 08:28:46 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SBd5p1vrqz4DyX for ; Fri, 20 Oct 2023 08:28:46 +0000 (UTC) (envelope-from SRS0=FZaK=GC=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B0D57D788B; Fri, 20 Oct 2023 10:28:43 +0200 (CEST) Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 407AED7887; Fri, 20 Oct 2023 10:28:41 +0200 (CEST) Message-ID: Date: Fri, 20 Oct 2023 08:28:41 +0000 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED] To: Doug Hardie Cc: Tomoaki AOKI , stable@freebsd.org References: <20231003230335.0B92113333@freefall.freebsd.org> <765ea31d-8f07-4916-b6fd-ba220dec80dc@inoc.net> <20231020062618.9618dcfd42b083720d5dbd12@dec.sakura.ne.jp> <14ed5f0c-9dbc-48d6-959c-750f2db726d4@quip.cz> Content-Language: cs-Cestina From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ] X-Rspamd-Queue-Id: 4SBd5p1vrqz4DyX On 20/10/2023 00:14, Doug Hardie wrote: >> On Oct 19, 2023, at 16:16, Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >> On 19/10/2023 21:26, Tomoaki AOKI wrote: >>> On Thu, 19 Oct 2023 19:53:08 +0000 >>> Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >> [..] >> >>>> It is hackery workaround. freebsd-update must not overwrite user >>>> modified files without safe merge of conflicts. yet it did it in the >>>> past, for example pf.conf and some other vital files. >>>> >>>> Kind regards >>>> Miroslav Lachman >>> I don't think it hackery. >>> What should have been is that default sshf_config to be >>> in /etc/defaults and /etc/defaults/rc.conf points to it, and anyone >>> needs custom settings to create sshd_config in /etc/ssh (or in >>> somewhere else), like rc.conf case. >> >> I don't think /etc/ssh/sshd_config is the default not intended to be edited. I am on FreeBSD from 4.x times and it was always supposed to be modifed by users and was handled by mergemaster or etcupdate. If freebsd-update cannot deal with it then it is a bug in freebsd-update. >> All in all pre-installed /etc/ssh/sshd_config has almost everything commented out because defaults are built in. > > While that has been the norm since 2.5, it does have a significant problem that changes to sshd configuration variables do not get incorporated into updated systems easily. Yes, mergemaster will somewhat show you the new configuration items, they are not always obvious and are very easy to ignore. There was one update to sshd that caused it not to function without the new variable. I don't recall the version or variable anymore, but it caused me days of problems trying to figure out why I couldn't connect to my servers. And there was a problem with documented and shipped variable no longer works causing sshd failed to start after reboot: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209441 There always will be cases when something break badly. > I believe that adding a couple lines of sh code to the end of sshd.conf would cause it to read /usr/local/etc/sshd.conf and avoid those issues. That is done in other places in the rc process. I don't have sshd.conf on my system but I you mean sshd_config it is not parsed / interpreted by sh. It is passed directly to sshd. Kind regards Miroslav Lachman