We talked about it, and strictly speaking this could be anywhere from. a) yay a new feature for free for just a no change rebuild to b) this new feature is violating the SRU policy and not allowed to happen, we need to upload code that avoids that any coming e.g. security fix will switch it on unplanned.
And there is a lot of middle ground between (a) and (b) to bikeshed forever. We discussed this in the Server Team and came to the point that we are ok either way (enabling it now or uploading a "avoid this to be activated" change). What we'd want to avoid is that this just hangs around and will be enabled "by accident" on any other upload. For the decision if we want to push for @Security Team: - (we heard Dimitri in comment #2) from securities POV, was there a general plan around the new openssl and TLS to enable it in Bionic throughout packages? - if there is a bigger plan does it come with a reference we can use as argument for the SRU to convince the SRU team that the change is safe and required? - what would be your security POV guidance for this case here, should we rebuild and enable or upload a change to avoid enabling it in Bionic at all? - are there other packages known which might need the same treatment? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841936 Title: Rebuild haproxy with openssl 1.1.1 will change features (bionic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
