Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 25 Feb 2021 16:56:18 -0500
From:      Karl Denninger <karl@denninger.net>
To:        Warner Losh <imp@bsdimp.com>
Cc:        FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Subject:   Re: How do I know if my 13-stable has security patches?
Message-ID:  <7d4e7a1f-da3e-2860-62b1-7be88123bee9@denninger.net>
In-Reply-To: <CANCZdfo2zq1fR5q7X47QFAFt00WrfvSzyqg4vDVbRwdGGXgfMQ@mail.gmail.com>
References:  <CAN6yY1tTt%2BEn6hzMYrjm2fRkUPBAuN9t8%2BR27Z3To_sJRbfUVA@mail.gmail.com> <1748076.jFELhIj8lM@ravel> <CAN6yY1sehRjej7vf3B_TPsg%2BecpDLG=naQ2oiMZ=DATs3PUGzQ@mail.gmail.com> <3308997.ajJYar8FF2@ravel> <001a5401-c334-5937-4ce3-315ff89e34be@denninger.net> <CANCZdfo2zq1fR5q7X47QFAFt00WrfvSzyqg4vDVbRwdGGXgfMQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail 

[-- Attachment #1 --]
On 2/25/2021 15:56, Warner Losh wrote:
>
> On Thu, Feb 25, 2021 at 6:37 AM Karl Denninger <karl@denninger.net 
> <mailto:karl@denninger.net>> 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.

(list of further "stuff")

But that's my entire point Warner.

The time (and present items) on a given machine to know whether it is 
covered by a given advisory under the "svn view of the world" is one 
command, and no sources.  That is, if the advisory says "r123456" has 
the fix, then if I do a "uname -v" and get something larger, it's safe.

If I get something smaller it's not.

I don't need the source on the machine, I don't need svn on the target 
or, for that matter, do I need to know if the source tree I have on a 
build machine is coherent with whatever is on the running machine.  I 
simply need to know if the source that built the code that is running 
was updated *after* the commit that fixes the problem.  What if the 
source /isn't on that machine /because you build on some system and then 
distribute?  Does every machine now have to be coherent with your source 
repository in order to be able to figure out where you are or worse, it 
must keep the source from which that specific installation, 
individually, was built? /What if the source isn't there at all /because 
you run binary code and update with freebsd-update?

Unless I've missed something that's what was lost and IMHO needs to be 
restored; a way to know that in seconds with nothing other than the 
operating OS on the box (e.g. via uname) and the advisory with its 
"greater than X is safe" from the mailing list.  Am I misunderstanding 
the current state of things in this regard?

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H

00H^Ōc!5
H0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA0
170817164217Z
270815164217Z0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0"0
	*H
0
h-5B>[;olӴ0~͎O9}9Ye*$g!ukvʶLzN`jL>MD'7U45CB+kY`bd~b*c3Ny-78ju]9HeuέsӬDؽmgwER?&UURj'}9nWD i`XcbGz\gG=u%\Oi13ߝ4
K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏNTa(25DD5.l<g[[ZarQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ!}ș+2k/bųE,n当ꖛ\(8WV8	d]b	yXw	܊:I39
00U]^§Q\ӎ0U#0T039N0b010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA	@Ui0U00U0
	*H
:P U!>vJnio-#ן]WyujǑR̀Q
nƇ!GѦFg\yLxgw=OPycehf[}ܷ['4ڝ\[p6\o.B&JF"ZC{;*o*mcCcLY߾`
t*S!񫶭(`]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@jެEgl
)0JG`%k35PaC?σ
׳HEt}!P㏏%*BxbQwaKG$6h¦Mve;[o-Iی&
I,Tcߎ#t wPA@l0P+KXBպT	zGv;NcI3&JĬUPNa?/%W6G۟N000k#Xd\=0
	*H
0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0
170817212120Z
220816212120Z0W10	UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
	*H
0
T[I-ΆϏdn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~_KPn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr>е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5	dDB7k-)9Izs-JAv
J6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@y]}6ٽeY9Y2xˆ$T=eCǺǵbn֛{j|@LLt1[Dk5:$=	`	M00<+00.0,+0 http://ocsp.cudasystems.net:88880	U00	`HB0U0U%0++03	`HB
&$OpenSSL Generated Client Certificate0U%՞V=؁;bzQ0U#0]^§Q\ӎϡ010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CAH^Ōc!5
H0U0karl@denninger.net0
	*H
۠A0-j%--$%g2#ޡ1^>{K+uGEv1ş7Af&b&O;.;A5*U)ND2bF|\=]<sˋL!wrw٧>YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n”} ͬ:{hTP3B.;bU8:Z=^Gw8!k-@xE@i,+'Iᐚ:fhztX7/(hY` O.1}a`%RW^akǂpCAufgDixUTЩ/7}%=jnVZvcF<M=
2^GKH5魉
_O4ެByʈySkw=5@h.0z>
W1000{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	`HeE0	*H
	1	*H
0	*H
	1
210225215618Z0O	*H
	1B@3`~;%8t\IuÑƧ;珤5jl)Y:K 9L<80l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+7100{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0*H
	10{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	*H
.f2د-oá
η6f*OD[ل:RB?/M1e>wB}v 3m!3U
qS-<g>r:(eΝUOlb$j4gK[\EK_mQL2{&*5&Ֆ Zm_af@eQPE+۵JR9*)PP	b~/m^\v^Z#{52Ax!S"d]/hhMU*ay%XcyB
`
v3S_m2䴉N^O0\ߧe>sF	~<f/moYB.ۦ/WDlppKDXMWf&g8\0Y[k&
S$ʘ/ɋ<⭻ln4X&0^#wW4f@?EɖqUQ$|{{&b0%i哺
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d4e7a1f-da3e-2860-62b1-7be88123bee9>