Dmitry Smirnov: > On Sunday, 26 April 2020 8:20:28 AM AEST Ximin Luo wrote: >> As I mentioned on firefox bugzilla [1], I have figured out the exact place >> in the firefox code responsible for this issue. >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1420286 > > Without looking into the proposed fix, I think there are few reasons not to > make any alterations: > > As much as I like the idea of symlinking resources from webextensions, > incorporating those resources at build-time make packaged addons less > fragile. Frequently synlinked Javascript libraries change/break often enough > on "apt upgrade" and when it happens maintainer have to resort to bundling of > working versions anyway but not before users experience (and report) > breakage. > > Diverging from upstream may not be desirable. I'm sure Firefox is difficult > enough to maintain without adding specific logic that have to be tested. >
The suggested patch is removing 3 lines, and changing 1 line. This is not hard to maintain. I see plenty of other patches in this firefox package already much larger than this, and I maintain larger patches in other similarly complex packages. > IMHO symlinks sandboxing was done upstream for security reasons. We may not > fully understand implication of changing this behaviour. > The source code doesn't mention any particular reason, and one person on the upstream bug report mentions it in such an off-the-cuff and non-explanatory way I can't take it into account as a serious data point. We shouldn't just let a mere mention of "security" scare us into not touching stuff and using our own reasoning to fix bugs. And I *did* think about the possible security considerations, as I explained in my previous email, and derived my suggested patch based on these considerations. (FWIW, I have done and am doing various types of security work professionally, and I'm confident about this type of reasoning in general.) > I've already discovered and documented working solution to incorporating > resources to webextension packages at build time. Updating packages is easy > enough and should be even possible with binNMUs to refresh their bundled > resources. That approach might be considered "good enough". > This is static linking, and in Debian we generally avoid doing that. I am not saying you shouldn't do it for your package, but we also shouldn't shy away from fixing infrastructural situations that force us into it. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git