Issues changing an ubuntu package from native to non-native?
Hi, I would like to change a source package in ubuntu from native to non-native. The main reason is that I personally have a hard time dealing with native package, specially one that spawns multiple ubuntu releases. While I could perhaps be convinced to keep it as is, or learn how to properly deal with such packages, I think the question is still valid: is there a precedence or best practice to follow when converting a native package to non-native? And can that be done together with an SRU as well (the SRU itself being driven for other reasons, and this change would just piggy-pack on it)? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Xen hypervisor patches for Intel MDS bug, XSA 297
Hi, I'm unsure what the fate of [1] should be. Upstream released patches for all minor versions, and Debian included a new upstream [2], albeit only in their unstable release. Qemu is also 'universe' (partly?), so it's unclear to me why Qemu is patched, but Xen isn't. All required patches seem available. Regards, Wiebe [1] https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1829550 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929129 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
New gcc hardening defaults in eoan (-fstack-clash-protection + -fcf-protection)
Hi, The security and foundations teams have been working to enable a couple new hardening options in GCC as default for eoan / 19.10. These are -fstack-clash-protection and -fcf-protection. -fstack-clash-protection causes GCC to instrument variable-length stack allocations so that each page is probed at allocation time to turn possible code-execution "stack clash" attacks (via jumping stack guard pages) into just a segmentation fault / denial of service. -fcf-protection adds support for Intel's control-flow enforcement technology (CET) instructions (these require hardware support but on older hardware which does not support these new instructions these are just no-ops). These are not enabled on all architectures, in particular -fstack-clash-protection is not enabled on 32-bit ARM archs (as this is buggy) and -fcf-protection is only enabled on x86 archs (amd64/i386/x32) as this is only available on this hardware. These options can be disabled by using -fno-stack-clash-protection and -fcf-protection=none respectively in CFLAGS / CPPFLAGS as documented at [1]. Results from a test rebuild with these new options enabled _and using gcc-9_ is at [2] and help would be appreciated in fixing any build failures. Thanks in particular to Matthias (doko) on the Foundations team for his help with this. Cheers, Alex [1] https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fstack-clash-protection [2] https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190614-eoan.html -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
