> Required TODOs:
> - embedded libfdt is outdated and well, embedded. Please build and link
> against the libfdt1 / libfdt-dev that is in main.
>
> Cannot do =)
>
...
Thanks for the explanation why even a normal static link won't work here.
I didn't think about it Firmware'ish execution in that regard.
> It would be nice if I could build-depend on libfdt-dev source package +
> built-using. That way any CVEs would leave enough breadcrumbs to follow.
>
Yeah some trick like that, but I can see that this won't work easily.
>
> But this is no different to how grub2 vendorizes lzo, gcrypt, and a few
> other things. All of which is rebuilt freestanding. So at best I can
> notify security team to add an embedded source copy mapping.
Your explanation is fine, we will only want Security to "sign off" on
it which usually
means they will establish such a not to track it correctly.
> W.r.t. being out of date I see that upstream did import 1.5.1 but not
> 1.6.0. I can work with them to update to 1.6.0 at least.
Being outdated wasn't too much of an issue (as it isn't too old).
It was more an FYI on that as an example what the embedded lib might miss.
No need to action on this one.
But the tests would still be interesting - do you think this could get
a reasonable autopkgtest or would that be more pain than gain?
P.S. Assigning to security for evaluation
** Changed in: opensbi (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
** Changed in: opensbi (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906668
Title:
[MIR] opensbi
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/opensbi/+bug/1906668/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
