> I had presumed this was a general requirement for any package, and not > limited to code in Go. But sure.
I can't tell if you're being serious or just taking an opportunity to be snarky, but I will answer as if you actually don't understand why Go is unique. Normally, if the security team updates a compiled library, it's fairly easy to test. They install the updated library and run some of the apps that link against it. A relatively small QA surface, though certainly not trivial. And usually the maintainers of the apps that link against it aren't involved at all. But Go is statically linked. Let's say the security team updates a Go library package. Now every app which uses that library needs to be rebuilt [1]. There's obviously a lot more that could go wrong when you have to rebuild (including things that are unrelated to the original fix). And if apps have their own bundled version of the code instead of using the packaged library, the security team has to go and patch the app especially with the security fix. Which is a whole new layer of complexity for them. [2] So as part of the giant discussion about whether to allow Go code in main at all, the security team had a set of requirements, to reduce the burden on them: Built-Using, dh-golang, and unbundling. And getting the maintainer on the hook for help testing rebuilds and if anything goes wrong. And while yes, usually maintainers are friendly and helpful, everyone has different time constraints and priorities, and the security team wants to make sure the maintainers plan accordingly, understanding that more time will have to be carved out to help test updates than a normal C package. It's easier to get agreement up front than chase someone in the middle of a heated security update. But thanks for agreeing to help with updates. And now the only missing piece is Built-Using landing. And can you get the security team to comment on this bug mentioning your exemption from unbundling libraries that might be shared with other Go apps, so that there's a paper trail on that? Thanks. [1] We know which apps need a rebuild from their Built-Using line. Hence that requirement. [2] pay-service bundles some code that is unique to it, which is fine -- it only *needs* to be unbundled if other code uses it too. But it also bundles code like gettext that is not unique. Those libraries can and should be unbundled. But I'm not blocking on it per your exemption from the security team. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614202 Title: [MIR] pay-service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pay-service/+bug/1614202/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
