Date: Thu, 14 Nov 2019 10:20:10 -0800 From: Gordon Tetlow <gordon@tetlows.org> To: George Mitchell <george+freebsd@m5p.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Correct SVN revision for latest security fix Message-ID: <20191114182010.GG6969@gmail.com> In-Reply-To: <7d65fc8f-e9b9-6472-199e-41f5010a8714@m5p.com> References: <7d65fc8f-e9b9-6472-199e-41f5010a8714@m5p.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--UKNXkkdQCYZ6W5l3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Resending this to the mailing list now that I have sorted my memberships to allow me to post to the list. On Wed, Nov 13, 2019 at 02:56:02PM -0500, George Mitchell wrote: > The attached security-advisories message cites an incorrect SVN revision > number for updating to fix CVE-2018-12207. The revision given is > r354653, but it should be r354654 to include the UPDATING fix and > the newvers.sh change to report the correct "p" level. I sent a > note about this as a reply to the message (so it actually went to > freebsd-security), but I suspect my reply is lost in the moderation > queue. Can someone please fix this? -- George SA's and EN's have always pointed to the actual patch to fix the issue, not the UPDATING/newvers.sh changes. Furthermore, it's not clear what the right order of operations should be when releasing a batch of SA's and EN's. There are 3 possible scenarios. 1. Commit everything in one giant commit. 2. Commit UPDATING/newvers.sh, then commit patches independently. 3. Commit patches independently, then commit UPDATING/newvers.sh. 1 is a non-starter as I don't want to commit everything at once. Downstream users may decide they don't want one particular update in a batch, but need to take everything else. If they are smushed together in a single commit, this is difficult. 2 causes a race condition. It's entirely possible to create a build that lists the patch version as being updated, but the patches haven't yet been pulled into that tree. This is the worst scenario in my book as the user may think they are protected when they haven't actually taken the update. I recognize this is a remote possibility due to timing, but I want to be able to guarantee if a user see -p1, they have the patches that were released as part of -p1. 2 gives a narrow window where we can't give that guarantee. 3 is what we do currently. This has the drawback you cite above. If you checkout the revision cited, the patch level hasn't been revved at this point. What I can say though, if you are running a system that lists -p1, then you are guaranteed to have the patches that were part of -p1. Between the options above, I'll pick option three. Best regards, Gordon Hat: Security Officer --UKNXkkdQCYZ6W5l3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEuyjUCzYO7pNq7RVv5fe8y6O93fgFAl3NmtpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJC MjhENDBCMzYwRUVFOTM2QUVEMTU2RkU1RjdCQ0NCQTNCRERERjgACgkQ5fe8y6O9 3fiBAQf+MA+Xfll0qGq0bNxdGLGzHVsaoTLpOctAt0P87lAGQwf7Q9j6B74rI1WH NvPErBf8X4Q0s1hdOTERB+1fQdYKgleHQEvOP5vSSG3sBUxn2Pb0/+OQZYrDLA93 G274ffK7WhRGvuTIjbG81XBHNhAqwgjpLv9rpnsm5XkYMYvjKzXV+kY1gn6YbuLU IUcLZLe6DEZiqnzmPHBFrfIfKnZ255Hxev8OKmkmUlznRf2kBl0VRHdActaq1NTe wMzZCkN3y6Tng3pOXzUjSAmBMsHCcMX4jxGV2+oEhAiQNZxgeZQ2MvqKFRbKY/cf hxwQvwXKAR1X7xVVoPg5c/cFooJ2kw== =RwQT -----END PGP SIGNATURE----- --UKNXkkdQCYZ6W5l3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191114182010.GG6969>