From owner-freebsd-stable@freebsd.org Thu Feb 25 20:57:04 2021 Return-Path: Delivered-To: freebsd-stable@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 100755487DE for ; Thu, 25 Feb 2021 20:57:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DmlTQ1sZlz3hww for ; Thu, 25 Feb 2021 20:56:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x835.google.com with SMTP id f17so5186370qth.7 for ; Thu, 25 Feb 2021 12:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vhyJ0B9OXGaDyty6V9gMJEL9jfJGmFFEcajl/oCzkRk=; b=tuui721nV6zbR2nit01i+VftTeCkY539MAEvKjnQA5wk6wpe6Lrc/qg1GIzoP3xTHJ kdFUuuiiE3auMgh3dCMZPdOSfZZkjcwpP7V0my8/9XEo3HImVKjEnKl5q0LWE6dbN9iR uoTp03nfggjrTtAm+BqB8SqEGPFJdCztKv7uLyBU8JT3NlY6GDsH/SiPDpZXWMTowfpI Q8hCNboq1SwFw3VW6BtZJc5jC/g6OrXaPBYiCTMFos9y0fMwrpdUzL5s9ESX+1xI08pj YcGDC7FjLjqnwbPotMAji8wmeMzQml1OEWOyQsCub7Xiw4YJEvl04usi4itjBO079VWm 6IlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vhyJ0B9OXGaDyty6V9gMJEL9jfJGmFFEcajl/oCzkRk=; b=KUM0iTl5pw+yAA8QWB5OGClAy5IZKo2GCxM3RrE2ynl15pNRRRnvOkUPIej07OrMrS 4Gv7rV9xQt46Y3g718XZU7N4OIcZ+kctkBXrXUdVgFDoyxSWX8DIV/yI9DaX2awhvnmc VV4smjI1IvThct76WKiLuiW1YfLgYr5NJwEheCARfDT9dbrRkGg+GsFKAS+43kBMZ0Lc GK1BOsb+c56O7UsBzJkdgBxHbHzpFKPXnyyW2lK62kG01OXWAK6a0byPBWr4uUppWWFn zu31qpboXklYKDZ+OPEAMgrTE4nAohu2iXdpEJuPOfd/wJr+hX+YbMCjNOfViR+lee9y HzDA== X-Gm-Message-State: AOAM5301/UnF1IjNR5xI50VhgqCiVtQ0XFHABeiUKd0SrbIrgsmKAyQd NAoDjHeCjkkcNybtEynGUTbqXfj9aV1DHWMatqhFOtHQgBEfVYcn X-Google-Smtp-Source: ABdhPJwCMe80QwUj199v/bemiXSgxw+c0i7gSpnjoztZFhWKJ5euiFn8qz05ZanWOL1HLnKvLzCIucpXokPFdp5WKts= X-Received: by 2002:a05:622a:1c9:: with SMTP id t9mr4358303qtw.244.1614286612401; Thu, 25 Feb 2021 12:56:52 -0800 (PST) MIME-Version: 1.0 References: <1748076.jFELhIj8lM@ravel> <3308997.ajJYar8FF2@ravel> <001a5401-c334-5937-4ce3-315ff89e34be@denninger.net> In-Reply-To: <001a5401-c334-5937-4ce3-315ff89e34be@denninger.net> From: Warner Losh Date: Thu, 25 Feb 2021 13:56:41 -0700 Message-ID: Subject: Re: How do I know if my 13-stable has security patches? To: Karl Denninger Cc: FreeBSD-STABLE Mailing List X-Rspamd-Queue-Id: 4DmlTQ1sZlz3hww X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=tuui721n; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::835) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::835:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::835:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-stable] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 20:57:04 -0000 On Thu, Feb 25, 2021 at 6:37 AM Karl Denninger wrote: > On 2/25/2021 04:30, Olivier Certner wrote: > >> Neither command is what I'd call 'intuitive', so it would have taken me > a > >> long time to find either of them. I cut and pasted the 'git branch' > command > >> and it took me a moment to realize what that meant. Never ran "grep -l" > on > >> a pipe, I guess. > > You made me laugh! Apart from relatively simple commands, git's > interface is > > far from intuitive. That's the reason why I regret that it became the > hugely > > dominant DVCS. > > Regression doesn't have to come to a project, but if the tools you > choose do things like this then you have to work around them as a > project to avoid the issue, and that might wind up being somewhat of a > PITA. > > This specific issue is IMHO quite severe in terms of operational > impact. I track -STABLE but don't load "new things" all the time. For > security-related things it's more important to know if I've got > something out there in a specific instance where it may apply (and not > care in others where it doesn't; aka the recent Xen thing if you're not > using Xen.) Otherwise if everything is running as it should do I wish > to risk introducing bugs along with improvements? If not in a > security-related context, frequently not. > > Well, this used to be easy. Is your "uname" r-number HIGHER than the > "when fixed" revision? You're good. Now, nope. Now I have to go dig > source to know because there is no longer a "revision number" that > monotonically increments with each commit so there is no longer a way to > have a "point in time" view of the source, as-committed, for a given > checked-out version. > > IMHO that's a fairly serious regression for the person responsible for > keeping security-related things up to date and something the project > should find a way to fix before rolling the next -RELEASE. (Yeah, I know > that's almost-certain to not happen but it's not like this issue wasn't > known since moving things over to git.) > We should likely just publish the 'v' number in the advisories. It's basically a count back to the start of the project. We put that number in uname already. You can also find out the 'v' number in the latest advisories by cloning the repo and doing the same thing we do in newvers.sh: % git rev-list --first-parent --count $HASH and that will tell you. This needn't be on the target machine since the hashes are stable across the world. That's kinda the whole reason we did the 'v' number: to provide a stable, monotonically increasing number that's unaffected by vendor merges (the cXXXX number was affected by merges). If you have a 'c' number in your uname the answer is super simple: you are affected. The problem, though, can happen when you run a shallow clone or gitup to get the sources and build from that. In that case the v number is bogus (hmmm, we should omit it when we have a shallow clone maybe). In that case you'll need to do the following on a clone somewhere (not necessarily on the target machine): % git log --max-count 100000 --oneline $UNAME_HASH | grep $ADVISORY_HASH The other alternative: you can do a 'git fetch' to pull the new hashes without doing a merge with what's on the machine. Then you can do % git log --oneline stable/13..freebsd/stable/13 | grep $ADVISORY_HASH and if you get a hit, you don't have the patch yet installed. The advantage of this is that this is work you'll need to do eventually anyway. If you don't have it, then a % git merge --ff-only freebsd/stable/13 will pull it in. If it turns out you did have it in the history before the shallow clone, then you can choose to update or not. If you choose to update, do the merge. If you choose not, then do nothing. The next 'git pull --ff-only' will do the right thing, as will repeating this process for the next advisory. The only harm is a few extra bytes pulled and/or a few extra compressed revs on the branch. Of course, the above assumes that you're running the sources == system binaries. If in doubt, substitute $UNAME_HASH for the bare stable/13 in the above. Warner