From owner-freebsd-security@freebsd.org Thu Sep 3 14:22:25 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E2C293E79DB for ; Thu, 3 Sep 2020 14:22:25 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [209.237.23.5]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bj30w6qjQz4W0D for ; Thu, 3 Sep 2020 14:22:24 +0000 (UTC) (envelope-from marquis@roble.com) Received: from roble.com (roble.com [209.237.23.50]) by mx5.roble.com (Postfix) with ESMTP id 1961330221; Thu, 3 Sep 2020 07:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roble.com; s=rs060402; t=1599142937; bh=X/GnhB1Val1D9ArbZXUu+dwWd+4yBsvtYRZzD//Y50Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WGnaFaUc+W0ADKeLXWzSBablT7feABFN4aoFt1Y0XuBC1RahdLkaQnUJy/luZ5aHS 2rCs3H5KSAWOtdWXB830Gd4e9gU98A3oBNvfbhDruNa31KGNk/+1/kMt//DMgIRbJv dTWP15mGQAu8ewX0iT9AZHYU1Q60vBiKOLvYcz2A= Date: Thu, 3 Sep 2020 07:22:17 -0700 (PDT) From: Roger Marquis To: tech-lists cc: freebsd-security@freebsd.org Subject: Re: A question about Security Advisories In-Reply-To: <20200903121553.GA80905@bastion.zyxst.net> Message-ID: References: <49a1d50c-34d1-239f-1d52-1ebba6799d62@shurik.kiev.ua> <20200903121553.GA80905@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Bj30w6qjQz4W0D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=roble.com header.s=rs060402 header.b=WGnaFaUc; dmarc=pass (policy=none) header.from=roble.com; spf=pass (mx1.freebsd.org: domain of marquis@roble.com designates 209.237.23.5 as permitted sender) smtp.mailfrom=marquis@roble.com X-Spamd-Result: default: False [-3.82 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; R_DKIM_ALLOW(-0.20)[roble.com:s=rs060402]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.237.23.0/24]; NEURAL_HAM_LONG(-0.97)[-0.970]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[roble.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[roble.com,none]; NEURAL_HAM_SHORT(-0.86)[-0.863]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:17403, ipnet:209.237.0.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-security] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 14:22:25 -0000 The SMUP (single monolithic update procedure) was implemented several years ago IIRC. At the time it was explained that there were insufficient staff resources to continue doing QA for incremental builds, even ones as simple as usr.bin/gzip. That said it is still just as straightforward to it yourself. What I wonder is why staff is so resource constrained? Is it fundamentally due to a broken funding model? Are potential volunteers turned away for not having submitted enough patches and other questionable policy hurdles? Are there other organizational reasons why such burdensome upgrades are left for end-users? A lot of this maintenance hassle will someday be resolved with base packages but even that project has been resource constrained. The FreeBSD Foundation has not, to the best of my knowledge, commented on these resource constraints or potential resolutions. Quarterly and Annual reports occasionally mention them but only in passing. How do we get someone on the Board/Foundation who is willing and able to prioritize these important issues? Roger Marquis >> Hi, >> Last years all Security Advisories regarding base system in the "update >> your vulnerable system via a source code patch " section recommends to >> rebuild a whole world instead of an affected part of a base system. This >> is in a most cases an overhead. >> >> For example 9 years old SA-11:04 [1] offers: >> >> b) Execute the following commands as root: >> >> # cd /usr/src >> # patch < /path/to/patch >> # cd /usr/src/usr.bin/compress >> # make obj && make depend && make && make install >> # cd /usr/src/usr.bin/gzip >> # make obj && make depend && make && make install >> >> What is a reason we stop to do it? I understand that the preferred way >> now is a binary upgrade. > > +1 I've been wondering this as well. What is the reason for it? > -- > J. >