[Buildroot] [PATCH] polarssl: deprecate on security grounds
Peter Korsgaard
peter at korsgaard.com
Tue Oct 11 17:13:00 UTC 2016
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:
> Hello,
> On Mon, 10 Oct 2016 14:26:33 -0300, Gustavo Zacarias wrote:
>> The 1.2.x branch is no longer maintained and the latest release from the
>> maintained branches (2.3, 2.1, 1.3) were security releases, so more
>> likely than not 1.2 is affected.
>> In consequence switch shairport-sync to the openssl backend.
>>
>> Signed-off-by: Gustavo Zacarias <gustavo at zacarias.com.ar>
> I'm fine with the principle, but..
>> Config.in.legacy | 10 ++++++++++
> ... with your change, we get two definitions of the
> BR2_PACKAGE_POLARSSL variable. The addition to Config.in.legacy should
> only take place when the package gets removed. Deprecated packages are
> meant to still allow the build to take place. But with the
> Config.in.legacy option having the same name, you can't build, because
> you're selecting BR2_LEGACY, which prevents the build from starting.
> In fact, amusingly, with our process, "deprecating" a package means
> that it blindly disappears for users.
Yeah, that isn't really good. Perhaps we need to add a 'select
BR2_NEEDS_DEPRECATED' to everything depending on BR2_DEPRECATED and add
some logic to warn if BR2_NEEDS_DEPRECATED && !BR2_DEPRECATED?
> But if you remove the package, we are warning the user by aborting the
> build, thanks to the Config.in.legacy mechanism.
> So I'm wondering if we shouldn't simply drop the polarssl package
> altogether, in order to take advantage from the Config.in.legacy
> mechanism.
> Yann, Peter, Arnout, what do you think?
Yes, I agree. Lets just remove it and add it to Config.in.legacy.
--
Venlig hilsen,
Peter Korsgaard
More information about the buildroot
mailing list