On 5/31/19 3:47 PM, Warner Losh wrote: > On Fri, May 31, 2019 at 4:36 PM John Baldwin <j...@freebsd.org> wrote: > >> On 5/31/19 1:26 PM, John Baldwin wrote: >>> Author: jhb >>> Date: Fri May 31 20:26:56 2019 >>> New Revision: 348482 >>> URL: https://svnweb.freebsd.org/changeset/base/348482 >>> >>> Log: >>> MFC 348205: >>> Add deprecation warnings for IPsec algorithms deprecated in RFC 8221. >>> >>> All of these algorithms are either explicitly marked MUST NOT, or they >>> are implicitly MUST NOTs by virtue of not being included in IETF's >>> list of protocols at all despite having assignments from IANA. >>> >>> Specifically, this adds warnings for the following ciphers: >>> - des-cbc >>> - blowfish-cbc >>> - cast128-cbc >>> - des-deriv >>> - des-32iv >>> - camellia-cbc >>> >>> Warnings for the following authentication algorithms are also added: >>> - hmac-md5 >>> - keyed-md5 >>> - keyed-sha1 >>> - hmac-ripemd160 >>> >>> Approved by: re (gjb) >> >> Sigh, so I just noticed while testing an MFC of another commit that adds >> deprecation warnings (GELI) that these warnings don't actually fire in 11 >> because gone_in(13, ...) only warns on 12.x and later: >> >> void >> _gone_in(int major, const char *msg) >> { >> >> gone_panic(major, P_OSREL_MAJOR(__FreeBSD_version), msg); >> if (P_OSREL_MAJOR(__FreeBSD_version) >= major) >> printf("Obsolete code will removed soon: %s\n", msg); >> else if (P_OSREL_MAJOR(__FreeBSD_version) + 1 == major) >> printf("Deprecated code (to be removed in FreeBSD %d): >> %s\n", >> major, msg); >> } >> >> I guess we could make the later test unconditional on stable/11 (and >> possibly >> make that change on HEAD and MFC it)? I think I understand why we did that >> originally (you could MFC warnings back to older branches without annoying >> users to keep code in sync), but I wonder if in practice we don't want the >> warnings always enabled? >> > > "It seemed like a good idea at the time" I think is why we did it, but it > turns out that it's not such a good idea. I agree: we should always warn in > older branches because latter-day releases of those branches will be > proximate to the removal time in major + 2. This is a perfect example of > this.
Another datapoint in favor that I realized after my original e-mail is that gone_panic() doesn't have the + 1 check. If you set the associated sysctl to 2 (not the default) to panic for deprecated things, it will panic over something that it doesn't warn about by default. -- John Baldwin _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"