svn commit: r348482 - stable/11/sys/netipsec

[John Baldwin]

On 5/31/19 3:47 PM, Warner Losh wrote:
> On Fri, May 31, 2019 at 4:36 PM John Baldwin <jhb at 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