Accepted gnu-efi 3.0u+debian-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 31 Mar 2014 19:56:19 +0200 Source: gnu-efi Binary: gnu-efi Architecture: source amd64 Version: 3.0u+debian-4 Distribution: unstable Urgency: low Maintainer: Daniel Baumann m...@daniel-baumann.ch Changed-By: Daniel Baumann m...@daniel-baumann.ch Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0u+debian-4) unstable; urgency=low . * Updating to standards version 3.9.5. * Building with dh --parallel. Checksums-Sha1: 9e127b5ede4fd53c82b06ccf0932d5188ee2407f 1359 gnu-efi_3.0u+debian-4.dsc e9008dc004890bc633e609b76b4ff0d0150a0aa8 5280 gnu-efi_3.0u+debian-4.debian.tar.xz c227c47ff0ef01018dce66b9f016c1edc754f538 110170 gnu-efi_3.0u+debian-4_amd64.deb Checksums-Sha256: 13dad02a855adb9521df63f3933582bd56968327c23e9233886ff4867031b05d 1359 gnu-efi_3.0u+debian-4.dsc f6dfaef43ce1b9b3776a5c59cc74238fc791339efdc8c4e2199729f30942d88e 5280 gnu-efi_3.0u+debian-4.debian.tar.xz db78b3fde7d8cb3e2c5a029d1ce9eafa084910b43bb5586962d515e9892e0a2f 110170 gnu-efi_3.0u+debian-4_amd64.deb Files: 6fb5959c1f9ca6380abdf36a4c06900c 1359 devel optional gnu-efi_3.0u+debian-4.dsc 317a1c481a5a610425c7d4758b18cfae 5280 devel optional gnu-efi_3.0u+debian-4.debian.tar.xz 9e50f575945fdf9d2dc2166625d77dae 110170 devel optional gnu-efi_3.0u+debian-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlM5ulQACgkQ+C5cwEsrK547wgCggremLM1AKd/RexNHCywvQyGJ /mYAoNQ+PL+5lpH1Zj3i2Os1ONNfw/Nl =ESqO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wuhvs-0005pq...@franck.debian.org
Accepted gnu-efi 3.0u+debian-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 17 Oct 2013 10:06:18 +0200 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0u+debian-3 Distribution: experimental Urgency: low Maintainer: Daniel Baumann m...@daniel-baumann.ch Changed-By: Daniel Baumann m...@daniel-baumann.ch Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0u+debian-3) experimental; urgency=low . * Updating vcs fields. Checksums-Sha1: 508c6dec090ff44f37add1ec7d1e55cb966fd2b2 1376 gnu-efi_3.0u+debian-3.dsc 1d05c0ab98e754a74ced6f51777c4e6e7e74bfe1 5220 gnu-efi_3.0u+debian-3.debian.tar.xz 5bcd80533bdf907bbc14e960a3358d2f7f144aaf 109736 gnu-efi_3.0u+debian-3_i386.deb Checksums-Sha256: 22fe29a71f8253e2e019ab96b30be8c3d8b7a473cc3acc474082c11921a5466c 1376 gnu-efi_3.0u+debian-3.dsc c3a1157731088eea9a6f44e60eee3b0940da6bbdb88f8469b7ec5f95b17950e8 5220 gnu-efi_3.0u+debian-3.debian.tar.xz 99cd597aa1929511931de10fcc4557fd1792c0d1bbe30ed46d68d3fe95b5ecc4 109736 gnu-efi_3.0u+debian-3_i386.deb Files: 067f6abd187851c01e2d8f2a40adab7a 1376 devel optional gnu-efi_3.0u+debian-3.dsc c8a6801fa0ac5b4dcda4aabaac94a5b8 5220 devel optional gnu-efi_3.0u+debian-3.debian.tar.xz 79af0a565f5a48421852b46e49b51c6b 109736 devel optional gnu-efi_3.0u+debian-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJfm0UACgkQ+C5cwEsrK55MWQCgmQufF/QWVDr9Ozs01QHabseM S/MAoOBY8A1hZeph00X3yrhNiz1LqrEN =kczo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vwjjk-0003r9...@franck.debian.org
Accepted gnu-efi 3.0u+debian-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 17 Jul 2013 10:34:32 +0200 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0u+debian-2 Distribution: experimental Urgency: low Maintainer: Daniel Baumann m...@daniel-baumann.ch Changed-By: Daniel Baumann m...@daniel-baumann.ch Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0u+debian-2) experimental; urgency=low . [ Daniel Baumann ] * Adding vcs fields. . [ Steve Langasek ] * Passing architecture arguments when building the x86_64 code on i386; otherwise the upstream build system wrongly assumes that if uname says x86_64, it doesn't have to pass -m64 to the compiler. . [ Daniel Baumann ] * Wrapping control fields. Checksums-Sha1: dc61c2a7f2ddc43ac1f970ae526298102434b771 1358 gnu-efi_3.0u+debian-2.dsc e4c64e46ef0ab003440e95e1742c493b822c1bcd 5204 gnu-efi_3.0u+debian-2.debian.tar.xz 151edf082734e596b74f6271cf14a1b98393b65c 109696 gnu-efi_3.0u+debian-2_i386.deb Checksums-Sha256: 28c5d4201e0b959888c5cba607684cded41b33f4621daff0905c7dce49f1b731 1358 gnu-efi_3.0u+debian-2.dsc fdba7f04b6425a7552287b6423ed582dc62f5b0f9e65f0a7464e384b005bb604 5204 gnu-efi_3.0u+debian-2.debian.tar.xz 22b7db3c099f924d1b7457e5b037e145a9e4b91646e5751378e1fefb69ee530e 109696 gnu-efi_3.0u+debian-2_i386.deb Files: 811dc32809e3959d05cf6bb85ec75a6a 1358 devel optional gnu-efi_3.0u+debian-2.dsc 8acc68d689a6ffef6ba238b637855d6d 5204 devel optional gnu-efi_3.0u+debian-2.debian.tar.xz 2e8e4f90bb8b313c363a43416105b153 109696 devel optional gnu-efi_3.0u+debian-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHmWjQACgkQ+C5cwEsrK54FVACcCt1nQ1wzSaPYXf8NGh6r1bNG eKwAnR4tQ+1w3vIu3H4edVaTlXgrJLen =ZyPV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uznte-wq...@franck.debian.org
Accepted gnu-efi 3.0u+debian-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 18 Jun 2013 10:38:29 +0200 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0u+debian-1 Distribution: experimental Urgency: low Maintainer: Daniel Baumann m...@daniel-baumann.ch Changed-By: Daniel Baumann m...@daniel-baumann.ch Description: gnu-efi- Library for developing EFI applications Closes: 712639 Changes: gnu-efi (3.0u+debian-1) experimental; urgency=low . * Merging upstream version 3.0u+debian (Closes: #712639). * Dropping no-stack-protector.patch, included upstream. Checksums-Sha1: 6559c63d034306905eb06819511f4b499051822f 1235 gnu-efi_3.0u+debian-1.dsc ca9831e9b50948331bfbd159cd3904d80ab20064 109184 gnu-efi_3.0u+debian.orig.tar.xz aa567e4f587aca585223dad81bed7ec0b59d27b4 5004 gnu-efi_3.0u+debian-1.debian.tar.xz d5ce1b19c8b5b31d69849f7729066afd79f8a236 109562 gnu-efi_3.0u+debian-1_i386.deb Checksums-Sha256: e1a0a7de623a006b8e6c61ac0d2a55402d8dea727df57dc69a0c40fe514c5b95 1235 gnu-efi_3.0u+debian-1.dsc 429abb1eb25f8eeecfc2ccb36f38194e62e6f4d6151e3fca4c8d4e34b125cb9f 109184 gnu-efi_3.0u+debian.orig.tar.xz e3764c20f2e6675020b36f11a4ad766103d62d88accfe60813718fa8dcd86e76 5004 gnu-efi_3.0u+debian-1.debian.tar.xz 4726cfd478ac73ec197b2e11b2f975ed449b2fee493489e1730fb162c5e09e55 109562 gnu-efi_3.0u+debian-1_i386.deb Files: 9dc7387eceb4c885ad58ed336c23a852 1235 devel optional gnu-efi_3.0u+debian-1.dsc ef277b3807a6e5dc19434edf0480b354 109184 devel optional gnu-efi_3.0u+debian.orig.tar.xz c0320139e74c8d4fe1c77f30447c3a2e 5004 devel optional gnu-efi_3.0u+debian-1.debian.tar.xz 19037cca7485603bf97eae428982c481 109562 devel optional gnu-efi_3.0u+debian-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHAHa4ACgkQ+C5cwEsrK55epQCglcR/lh9/WJmqI4BtJo0WRhbi 1coAoKEi9z7B1g4XSvWIIbWykbqzHEG0 =RaQ/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uorrf-0005nw...@franck.debian.org
Accepted gnu-efi 3.0t+debian-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 09 Jun 2013 10:04:12 +0200 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0t+debian-2 Distribution: experimental Urgency: low Maintainer: Daniel Baumann m...@daniel-baumann.ch Changed-By: Daniel Baumann m...@daniel-baumann.ch Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0t+debian-2) experimental; urgency=low . * Dropping suggests on elilo. Checksums-Sha1: aee574ffc33175d2df43cdb708bcd47c607e6a8a 1235 gnu-efi_3.0t+debian-2.dsc 5ca7180d407bee33cb3199af38f94ae6bfa55454 5352 gnu-efi_3.0t+debian-2.debian.tar.xz 7df88614d57babfa9b83e49e8f876af0eb087bc3 102428 gnu-efi_3.0t+debian-2_i386.deb Checksums-Sha256: 9914d0c9d2de55569450bc0dd53fdf71ca765270ea6a46ce0ebf1f703f110aa6 1235 gnu-efi_3.0t+debian-2.dsc 6e1c21afb8fb563f002c759fd887e9582e5c008fbd27579759a30053022aa92a 5352 gnu-efi_3.0t+debian-2.debian.tar.xz c3f2fa76f0c30044c6b10c597f77dce1cb4acef17c0a3b61c40ee8a0e3f37c2e 102428 gnu-efi_3.0t+debian-2_i386.deb Files: 07c4537ecb8ba5c0c850c2cabe744aed 1235 devel optional gnu-efi_3.0t+debian-2.dsc 02be16b1c3a044019c07b33797b3a7a4 5352 devel optional gnu-efi_3.0t+debian-2.debian.tar.xz faae0273edab7acb9c7399ee0ae1eba6 102428 devel optional gnu-efi_3.0t+debian-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlG0N14ACgkQ+C5cwEsrK54baQCggseYhvk+yh5B1FAdXiU+nt1X FxoAn3Bogx7jqsZWWOJXeNgt6tCCq5Sq =R4fg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ulbmf-0001sq...@franck.debian.org
Accepted gnu-efi 3.0t+debian-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 13 Mar 2013 18:22:37 +0100 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0t+debian-1 Distribution: experimental Urgency: low Maintainer: Daniel Baumann m...@daniel-baumann.ch Changed-By: Daniel Baumann m...@daniel-baumann.ch Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0t+debian-1) experimental; urgency=low . * Merging upstream version 3.0t+debian. * Updating year in copyright file. * Refreshing no-stack-protector.patch. Checksums-Sha1: a44d7bc02cbf1916aa1f1d56967d2c2033d7f70d 1235 gnu-efi_3.0t+debian-1.dsc 384de8764669c2e6162ad2f2b90f00b4211657b1 102228 gnu-efi_3.0t+debian.orig.tar.xz 90f9f7846113c14a50d34b92d0a222ee57b04446 5332 gnu-efi_3.0t+debian-1.debian.tar.xz 197811c099123c7386871bd9f0270f73ac3935de 102398 gnu-efi_3.0t+debian-1_i386.deb Checksums-Sha256: 311442bdf31e95e8958822fa9c9d316c34d7a50e108a22c07ba18aedbb2207b9 1235 gnu-efi_3.0t+debian-1.dsc 14bee6066f3a92a2c8d0801a5c7524d5495526c5043cd82b2d9889047205505e 102228 gnu-efi_3.0t+debian.orig.tar.xz ee66835438959996b8832ab2e1b7eacad1426bc1598a4cac11d5c9b3eb0931bc 5332 gnu-efi_3.0t+debian-1.debian.tar.xz e5fda2e44b8e04f98e21c83b11e87742953740ac3d09c606edfef4fc653231da 102398 gnu-efi_3.0t+debian-1_i386.deb Files: a1d81d1afa3f10eb6d80747e7711f697 1235 devel optional gnu-efi_3.0t+debian-1.dsc 4befb9fe1e60d922b80e98282fc98787 102228 devel optional gnu-efi_3.0t+debian.orig.tar.xz 898a784fc19843055cbcf9e3573f6a9f 5332 devel optional gnu-efi_3.0t+debian-1.debian.tar.xz c8c7c4fca8469b4646c927242ce1675e 102398 devel optional gnu-efi_3.0t+debian-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlFAttAACgkQ+C5cwEsrK55/tACgyhYrsycAXCfRcPqaRGGXrLYz WNMAoMJgN+EgJhTDEBRFj8FLYvce28a4 =StmS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ufpxr-0004uo...@franck.debian.org
Accepted gnu-efi 3.0s+debian-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 10 Mar 2013 20:46:34 +0100 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0s+debian-3 Distribution: unstable Urgency: low Maintainer: Daniel Baumann m...@daniel-baumann.ch Changed-By: Daniel Baumann m...@daniel-baumann.ch Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0s+debian-3) unstable; urgency=low . * Removing all references to my old email address. Checksums-Sha1: bf9adb4490410481cf31379a46793c5117cd038e 1235 gnu-efi_3.0s+debian-3.dsc 804c1e5b27b36415ec4ea527f5b1879bcc3f1684 5288 gnu-efi_3.0s+debian-3.debian.tar.xz 40616ac026d6fe630d54fe2ffe21e3675c4ad2e1 100954 gnu-efi_3.0s+debian-3_i386.deb Checksums-Sha256: af80a12232b490e92846c4002826400fe79ae69006113e8b923c844984562ad1 1235 gnu-efi_3.0s+debian-3.dsc 8a1f780fb854f47bd3571bc46590b02a57de9c167b10a11c336c34078d4c9ade 5288 gnu-efi_3.0s+debian-3.debian.tar.xz 0bda4852ed1119121d3325adf8d6aeddb48b12409a9080c3c7bd7904fbed5eea 100954 gnu-efi_3.0s+debian-3_i386.deb Files: 85f533985a6b34326acf6aa51d67c07b 1235 devel optional gnu-efi_3.0s+debian-3.dsc 1026b8980ca15ab3fac65fae4d9fdf3c 5288 devel optional gnu-efi_3.0s+debian-3.debian.tar.xz 842390de65f398577863980fccf1dc0e 100954 devel optional gnu-efi_3.0s+debian-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlE84/AACgkQ+C5cwEsrK566uACgie1+YbEmppxFJtnlMftgO/Hz TakAnRfoQfDibFg2qAoSa7Imp7T1RtMF =94GJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uenc8-0006i9...@franck.debian.org
Accepted gnu-efi 3.0s+debian-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 20 Feb 2013 16:41:16 +0100 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0s+debian-2 Distribution: unstable Urgency: low Maintainer: Daniel Baumann daniel.baum...@progress-technologies.net Changed-By: Daniel Baumann daniel.baum...@progress-technologies.net Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0s+debian-2) unstable; urgency=low . * Adding no-stack-protector.patch from Colin Watson cjwat...@ubuntu.com to make other packages being able to link against gnu-efi. * Dropping dpkg-source compression levels. * Adding dpkg-source local-options. Checksums-Sha1: 93dae8c4a1f1768b8b2b154df7e2301ed7e19dcd 1253 gnu-efi_3.0s+debian-2.dsc e0be73c05d6690782a0fbcef678e86001bb69bf1 5284 gnu-efi_3.0s+debian-2.debian.tar.xz 98a0a61323338f7b56c6a284b5aaae8804dd5d1c 100976 gnu-efi_3.0s+debian-2_i386.deb Checksums-Sha256: 5a82da9f087af0be13016bb3e6f8ec47e58c9197133e4676a2b9af4dde6d7cca 1253 gnu-efi_3.0s+debian-2.dsc aa0897ad7130e921ea165fedece13d48169e2bf82c70486d2942e6ca562abad1 5284 gnu-efi_3.0s+debian-2.debian.tar.xz 6e45d4c46496a2360d07967a3ff7bfc405f4ce30b78e56daafafa4a1366da321 100976 gnu-efi_3.0s+debian-2_i386.deb Files: 945e8bde1e3448f6b89fa681425dc615 1253 devel optional gnu-efi_3.0s+debian-2.dsc 90c070466b3614e1c9f9824a3d9348ee 5284 devel optional gnu-efi_3.0s+debian-2.debian.tar.xz a917c4d6e6ce233e9f2ce7162c41fc29 100976 devel optional gnu-efi_3.0s+debian-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlEk724ACgkQ+C5cwEsrK56LgQCeOKm/8ifN6M8HaaP4q9wTWPX0 xwEAn2A2QXK2XJysoXWHaBiJanbhmyOl =j/Ue -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1u8c7s-0007du...@franck.debian.org
Accepted gnu-efi 3.0s+debian-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 11 Dec 2012 07:19:59 +0100 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0s+debian-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann daniel.baum...@progress-technologies.net Changed-By: Daniel Baumann daniel.baum...@progress-technologies.net Description: gnu-efi- Library for developing EFI applications Changes: gnu-efi (3.0s+debian-1) unstable; urgency=low . * Merging upstream version 3.0s+debian. Checksums-Sha1: 8dcd72881e7a7ba304aceb8bcbc89226d1cb78c0 1253 gnu-efi_3.0s+debian-1.dsc cbb10a1fb401b359992fccaf29b9ee9a2c84e061 100032 gnu-efi_3.0s+debian.orig.tar.xz 7c29c474e9aa6ecc8444a738c8dbf59798c1fb07 4788 gnu-efi_3.0s+debian-1.debian.tar.xz c3853fa4e1fbd0a5bcc71be3d796948580d33e18 100866 gnu-efi_3.0s+debian-1_i386.deb Checksums-Sha256: 80a79783629b2e5cb0424dc6721345bdaf6c5548aad7e58242fcdeeef2634b5e 1253 gnu-efi_3.0s+debian-1.dsc 3b2285023c40199edb59cc7448d69be599cbbb9f6f30ac66f034ff447aa9e66b 100032 gnu-efi_3.0s+debian.orig.tar.xz 73b5a9e6b631ac3edd26d236cba7aea2b0b9fbc55e54ad766895e27e03a1d8db 4788 gnu-efi_3.0s+debian-1.debian.tar.xz 5028c2936e1e7eb0772e95858d1ed53761299476e79f81d6c228edbe09e85c8c 100866 gnu-efi_3.0s+debian-1_i386.deb Files: 7ee34ba09a6392143d2917367bd11266 1253 devel optional gnu-efi_3.0s+debian-1.dsc b5430dbebd969f5b8049b2f94a0b9e28 100032 devel optional gnu-efi_3.0s+debian.orig.tar.xz 2b844f5db85fb6af659cac99028431d0 4788 devel optional gnu-efi_3.0s+debian-1.debian.tar.xz b4f90f06540162090434818d545ef276 100866 devel optional gnu-efi_3.0s+debian-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlDG0MsACgkQ+C5cwEsrK55OYQCglcbCyCd3YdalPWTa5df4lOZ2 QPMAn21LZ/Gemn9fNyo30N4OQ2pCU5Dx =rTZn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tijoi-000816...@franck.debian.org
Accepted gnu-efi 3.0r+debian-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 25 Sep 2012 09:07:00 +0200 Source: gnu-efi Binary: gnu-efi Architecture: source i386 Version: 3.0r+debian-1 Distribution: experimental Urgency: low Maintainer: Daniel Baumann daniel.baum...@progress-technologies.net Changed-By: Daniel Baumann daniel.baum...@progress-technologies.net Description: gnu-efi- Library for developing EFI applications Closes: 637276 679627 Changes: gnu-efi (3.0r+debian-1) experimental; urgency=low . * Merging upstream version 3.0r+debian (Closes: #637276, #679627): - Rebuilding upstream tarball without debian directory. * Removing useless whitespaces at EOL and EOF. * Updating package to debhelper version 9. * Updating package to standards version 3.9.4. * Making build-depends on binutils unversioned, already fulfilled by wheezy. * Sorting architectures in gcc-multilib build-depends alphabetically. * Wrapping build-depends to 80 chars per line. * Adding homepage field. * Sorting architectures field alphabetically. * Removing pre-wheezy conflicts on libc6-i386. * Removing French spacing in package long-description. * Rewriting copyright file in copyright-format version 1.0. * Prefixing debhelper files with package name. * Simplifying debhelper docs file by using wildcard. * Removing watch file. * Reorganizing rules file in minimized debhelper form. * Switching to source format 3.0 (quilt). * Switching to xz compression. * Adding todo file. Checksums-Sha1: ccdb4ee974eab4b860c7d7b23344eff45d2c890b 1250 gnu-efi_3.0r+debian-1.dsc 9b0c4b890a7db5129e35f3ce26fd4d2fdf24ba59 99712 gnu-efi_3.0r+debian.orig.tar.xz 65e8bf932b76447f19d792592cff1bdc38b2927c 4788 gnu-efi_3.0r+debian-1.debian.tar.xz 548b40e48d5af366c6c38ff5e754a3730ba1cba5 101172 gnu-efi_3.0r+debian-1_i386.deb Checksums-Sha256: 833c90f6f3463beafc3540462956d5cb6fdfba999502676f388a304fb6d61190 1250 gnu-efi_3.0r+debian-1.dsc 0211c0825a6cac21d366cd809c18a8a1c30f4cbf3537100ab36b20bf160a6aef 99712 gnu-efi_3.0r+debian.orig.tar.xz 5c48e48ab15eab10c7fae9b8a9080ffb9554d0b39236fda2fbd8789367f13f00 4788 gnu-efi_3.0r+debian-1.debian.tar.xz e094fc000f481a108831915fbc147a34466284aacc0d87df8b88cc568dfbc7a5 101172 gnu-efi_3.0r+debian-1_i386.deb Files: 18a3f1f8b93a2d24692eedfa155f4cc0 1250 devel optional gnu-efi_3.0r+debian-1.dsc 1b10d13102a13fbc48cf881b667bbb5e 99712 devel optional gnu-efi_3.0r+debian.orig.tar.xz 449f8786349bc966ddae4521d927073a 4788 devel optional gnu-efi_3.0r+debian-1.debian.tar.xz 7fe6f67ebd40d8ad79ee614f00e9ba66 101172 devel optional gnu-efi_3.0r+debian-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlBhX4gACgkQ+C5cwEsrK55elgCeMUxeZ846AEjUXGsNKEABXk4o snQAoJaGs184+Xyj2uggtDyMRC67kaRx =Si/6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tgpre-0002fj...@franck.debian.org
Re: EFI in Debian
On Sun, Jul 08, 2012 at 07:30:48PM -0400, Ted Ts'o wrote: So in answer to your question, there are plenty of Android devices which are trivially unlockable. (And once a Nexus phone is unlocked, it's you can get a root shell trivially; no jail-breaking necessary. Of course this is true for an attacker/thief who has managed to steal your phone, but if you want to unlock the phone, it's easily doable on many Android devices.) Note that the unlock process wipes the data on the phone which does provide some security here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120717162018.ga8...@sirena.org.uk
Re: EFI in Debian
Le lundi 2 juillet 2012 18:42:13, Steve McIntyre a écrit : Hey folks, As you might have seen from recent discussions about the Fedora and Ubuntu strategies for how to deal with EFI and Secure Boot, there are potentially major issues in the area. In Debian we don't (yet) have a plan, so it's high time that we had some discussion. I've set up a BoF at DebConf for this: https://penta.debconf.org/penta/schedule/dc12/event/925.en.html That's Monday 9th July, 15:00 local time (21:00 UTC). Sorry for my naive questions but I want to be sure I understand the goal behind secure boot correctly. I'm not talking about Microsoft here but as stated by Bdale yesterday there is many people who see a value in secure boot to protect their system. Please correct any mistake I do in my reasonning and if I'm plain wrong just ignore my email or send me a notice on IRC or private email. Suggestions for the implementation are after the questions. What I'd really like to understand is why is protecting the boot so important for these people? Secure boot is designed to prevent booting code anywhere in the boot sequence which is infected by a malware. But if such an infection happens, it means a flaws in the system was used during the last run. It should normally not be possible to modify any of the code in the boot sequence without appropriate privilege. When the flaws was exploited, then the attacker had sufficient access to change e.g. EFI and could thus have done whatever nasty things he wanted on the system. And as long as the system is not rebooted, nothing can prevent it to do so. From this, I came to the conclusion that secure boot only provides additional security when the administrator discover the flaws, either via a CVE/DSA/whatever announce, or because he realized the system is having a strange behavior (ex: something suspicious in the logs). Then, he will try to patch the flaw by upgrading its kernel and want to be sure at reboot that the malware didn't manage to infect the patched kernel in the mean time. In other words, the administrator want to be sure at reboot that the problem is solved (at least for this flaw, there could be other flaws of course but they need to be found). If I understood all this correctly and that my conclusions are correct then I believe there could be an interest the secure boot functionality. Don't get me wrong, I'm really concerned about all the side effect of this technology with regards to locked down systems. There is an important need to both be able to disable secure boot and to be able to change and add main/CA keys. But there is nothing we can do technically about this. Implementation So the first question is wether we play secure boot or not. I believe that by playing it we don't remove anything to the users. No matter we play it or not, they will not be free to install whatever software they want as long as secure boot is activated (and this become a forever on ARM systems with windows certified logo). But by providing a signed image of Debian we provide at least a bit more security for people with secure boot enabled. Second question is with what key to sign Debian image and our bootloader. Should we use Microsoft key or use our own key and ask the users who wants to benefit from secure boot to install the Debian key. I personnally don't like the idea of using the key of Microsoft as we give them a switch to prevent Debian systems from being booted. On the other hand, I don't know if it will be easy to install new CA keys. At last, there is the question of what to sign. If we want secure boot to be really useful then we should sign all the way from the bootloader to the kernel modules. Thoughts about this? Best regards. signature.asc Description: This is a digitally signed message part.
Re: EFI in Debian
On Tue, 10 Jul 2012, Thomas Preud'homme robo...@celest.fr wrote: When the flaws was exploited, then the attacker had sufficient access to change e.g. EFI and could thus have done whatever nasty things he wanted on the system. And as long as the system is not rebooted, nothing can prevent it to do so. http://etbe.coker.com.au/2011/12/28/secure-boot-protecting-against-root/ I've written a blog post about some of the issues related to secure boot at the above URL. Some of the problems include the fact that workstations have a lot of uptime nowadays (so a machine that has a trojan in RAM is likely to stay that way for a while) and that an attack which is performed once can be performed on every boot. http://www.coker.com.au/selinux/play.html Also in that post I address the apparently common misconception that secure boot makes it impossible for a remote root user to damage the system. As an aside I have a Wheezy based SE Linux Play Machine online right now, it demonstrates root as an account that can't damage the system - but that root account also can't be used for system administration... From this, I came to the conclusion that secure boot only provides additional security when the administrator discover the flaws, either via a CVE/DSA/whatever announce, or because he realized the system is having a strange behavior (ex: something suspicious in the logs). Then, he will try to patch the flaw by upgrading its kernel and want to be sure at reboot that the malware didn't manage to infect the patched kernel in the mean time. In other words, the administrator want to be sure at reboot that the problem is solved (at least for this flaw, there could be other flaws of course but they need to be found). The problem with that is the wide variety of ways that the system is configured. We would need some way to verify, inspect, or revert every change to a security sensitive config file to restore a compromised system. Signing every config file isn't viable as you can't sign it locally (and taking every changed config file from a disconnected system is a PITA). Inspection isn't good as even competent sysadmins will have a hard time recognising every potential mistake in a config file. Reverting changes (IE wiping /etc on upgrade) is unpleasant, but maybe we could have a patch management system to treat all changes to /etc as patches. This might be viable. At last, there is the question of what to sign. If we want secure boot to be really useful then we should sign all the way from the bootloader to the kernel modules. No. The easiest way of doing that properly would be to have a filesystem that includes signing and not allow high integrity processes (either processes with a high integrity label according to Biba or a system domain in SE Linux) to read files that weren't signed. The harder way of doing that would be to have the system dynamic loader, every interpreter (the shell, Perl, etc), and every important process that reads a config file (IE most daemons) check signatures on all files. There's really not much benefit in having a signed kernel and modules if you can have a trojan loaded from /root/.bashrc ! -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207102108.57283.russ...@coker.com.au
Re: EFI in Debian
Le mardi 10 juillet 2012 13:08:57, Russell Coker a écrit : On Tue, 10 Jul 2012, Thomas Preud'homme robo...@celest.fr wrote: When the flaws was exploited, then the attacker had sufficient access to change e.g. EFI and could thus have done whatever nasty things he wanted on the system. And as long as the system is not rebooted, nothing can prevent it to do so. http://etbe.coker.com.au/2011/12/28/secure-boot-protecting-against-root/ I've written a blog post about some of the issues related to secure boot at the above URL. Some of the problems include the fact that workstations have a lot of uptime nowadays (so a machine that has a trojan in RAM is likely to stay that way for a while) and that an attack which is performed once can be performed on every boot. http://www.coker.com.au/selinux/play.html Ah yeah, I read that blog post. I like your blog by the way. Anyway, I had the exact same impression. That's why I came to the conclusion it's only useful after fixing a flaw in order to be sure the problem is fixed on next reboot. But for machine which never reboot it's indeed useless. Also in that post I address the apparently common misconception that secure boot makes it impossible for a remote root user to damage the system. As an aside I have a Wheezy based SE Linux Play Machine online right now, it demonstrates root as an account that can't damage the system - but that root account also can't be used for system administration... Of course, if you are root you can do whatever you want. That's the definition of root. The problem with that is the wide variety of ways that the system is configured. We would need some way to verify, inspect, or revert every change to a security sensitive config file to restore a compromised system. Signing every config file isn't viable as you can't sign it locally (and taking every changed config file from a disconnected system is a PITA). Inspection isn't good as even competent sysadmins will have a hard time recognising every potential mistake in a config file. Reverting changes (IE wiping /etc on upgrade) is unpleasant, but maybe we could have a patch management system to treat all changes to /etc as patches. This might be viable. Mmmmh, indeed I didn't think about all these important files. But then, if not everything is signed it reduce the number of ways an exploit can survive accross fix+reboot to files. Yes, it's still a large surface. Actually if you go down that road you'd need to sign everything you use. No matter that the kernel, bootloader and firmware are intact if your webserver is infected and giving access to important files of your system for example. The problem is that it becomes very hard to implement for a rather small benefit (IMHO). At last, there is the question of what to sign. If we want secure boot to be really useful then we should sign all the way from the bootloader to the kernel modules. No. The easiest way of doing that properly would be to have a filesystem that includes signing and not allow high integrity processes (either processes with a high integrity label according to Biba or a system domain in SE Linux) to read files that weren't signed. The harder way of doing that would be to have the system dynamic loader, every interpreter (the shell, Perl, etc), and every important process that reads a config file (IE most daemons) check signatures on all files. There's really not much benefit in having a signed kernel and modules if you can have a trojan loaded from /root/.bashrc ! Yes, true. That's what in the end everything you care about should be signed. But I don't think it's doable. So either we don't do secure boot at all (benefit is it requires no additional work), or we do secure boot on part of the system which guarantee that when this part of the system is upgraded to fix a flaws, it will only be booted if it was not compromised before the fix. Sort of it provides a way of knowing cryptographically if part of the system was infected or not. Best regards. signature.asc Description: This is a digitally signed message part.
Re: EFI in Debian
In article 20120708235244.gb24...@thunk.org Ted Ts'o wrote: Matthew Garret believes that this is a requirement; however, there is no documented paper trail indicating that this is actually necessary. There are those who believe that Microsoft wouldn't dare revoke a Linux key because of the antitrust issues that would arise. Hey, it's hardly my fault that nobody else bothered turning up to the well-advertised events where this got discussed... This would especially true if the bootloader displayed a spash screen with a huge penguin on it, and the user was obliged to hit a key acknowledging the spash screen before the boot was allowed to continue. James is working on a signed bootloader which would do this. Well, sure, we could associate Large picture of a penguin on your boot screen with your machine has been hacked, but I'm not convinced that's a great strategy. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sogcu-0007me...@chiark.greenend.org.uk
Re: EFI in Debian
On Mon, Jul 09, 2012 at 04:48:38PM +0100, Matthew Garrett wrote: In article 20120708235244.gb24...@thunk.org Ted Ts'o wrote: Matthew Garret believes that this is a requirement; however, there is no documented paper trail indicating that this is actually necessary. There are those who believe that Microsoft wouldn't dare revoke a Linux key because of the antitrust issues that would arise. Hey, it's hardly my fault that nobody else bothered turning up to the well-advertised events where this got discussed... If it's documented on paper, it didn't happen. :-) Discussions in smoke-filled rooms, even if they are well-advertised, don't really impress me (This isn't your fault, but Microsoft's.) - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120709162649.ga7...@thunk.org
Re: EFI in Debian
On Mon, Jul 09, 2012 at 12:26:49PM -0400, Ted Ts'o wrote: On Mon, Jul 09, 2012 at 04:48:38PM +0100, Matthew Garrett wrote: Hey, it's hardly my fault that nobody else bothered turning up to the well-advertised events where this got discussed... If it's documented on paper, it didn't happen. :-) Discussions in smoke-filled rooms, even if they are well-advertised, don't really impress me (This isn't your fault, but Microsoft's.) I look forward to the LF's discussion of this being made public, then. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120709163145.ga2...@srcf.ucam.org
Re: EFI in Debian
+++ Steve Langasek [2012-07-07 15:58 -0600]: On Sat, Jul 07, 2012 at 11:09:57PM +0200, Andreas Barth wrote: * Steve Langasek (vor...@debian.org) [120707 22:54]: On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote: If OTOH we have to pay a fee just for our software to work on platforms that just happen to be using Microsoft’s certificate, this is clearly abusive. I would object to do so, and I believe we would (at least in Europe) have a very strong case in court against such practice. Note that the Windows 8 requirements stipulate that users must in all cases retain the ability to disable Secure Boot on their x86 systems from the firmware. It's really a question of ease of installation, and whether Secure Boot provides any additional security protection that we think it's worth providing to Debian users out of the box. IIRC it's not the same on embedded hardware. The distinction is between x86 and ARM, and the Windows 8 cert requirements for ARM appear to have as their goal to prevent any other OS to be bootable on that hardware. Which is pretty outrageous IMHO and may well become a serious problem once PC-like ARM hardware becomes widely available (laptops and capable tablets). It is very disappointing that once they agreed to free-up x86 everyone said, 'oh that's alright then', failing to appreciate that ARM hardware will (likely) be just as ubiquitous as x86 quite soon. Hopefully enough people will produce hardware that isn't crippled in this way, but if Windows 8 is a popular platform one may get a greatly restricited choice. Will Android machines make secure boot turn-offable or another key installable, or will thay follow the Microsoft lead and lock everything down too? A competition case is much harder to bring here because Windows has almost zero share on ARM and can use that as an excuse. Of course, as we know in Debian architecture is really irrelevant to the question of 'is this OS dominant and using its dominance in one area to restrict competition in another'? This makes the ARM/x86 distinction in the rules a devious scheme to reduce competition, which seems to be working so far (and in our case prevent us using such computers usefully at all). In an ideal world the fact that can't unlock your device and install another OS will be seen as a consumer disadvantage and reduce the supply of hardware with no ability to install alternate keys, but that seems an unlikely outcome, as most people don't care, or won't until it's too late. I'm not sure what we can actually do about this technically. Approximately nothing, except look for ways to hack the secure boot mechanism on interesting hardware. I can't recall if the rules for arm actually prevent the bootloader allowing the loading of other keys, or just prevent turning off secure boot. I think the latter, but as there is no requirement for this feature it may be rare in practice. By making this easily available in UEFI I suppose that may encourage manufacturers to enable it. So I don't think you should expect MS to sign any UEFI ARM bootloader binaries at all. Quite. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120708131523.gy13...@stoneboat.aleph1.co.uk
Re: EFI in Debian
On Sun, 8 Jul 2012, Wookey woo...@wookware.org wrote: The distinction is between x86 and ARM, and the Windows 8 cert requirements for ARM appear to have as their goal to prevent any other OS to be bootable on that hardware. Which is pretty outrageous IMHO and may well become a serious problem once PC-like ARM hardware becomes widely available (laptops and capable tablets). It is very disappointing that once they agreed to free-up x86 everyone said, 'oh that's alright then', failing to appreciate that ARM hardware will (likely) be just as ubiquitous as x86 quite soon. Hopefully enough people will produce hardware that isn't crippled in this way, but if Windows 8 is a popular platform one may get a greatly restricited choice. I expect that by most metrics Android phones outsell PCs nowadays (largely because phone contracts encourage replacement every 2 years and some portion of the phones break before then). A significant portion of the Android phones sold are locked down such that you can't change which version of the kernel you run and can't get root access in any reasonable manner. The iPhone has a comparable market volume to Android phones and is uniformly locked down. In terms of making ARM systems less free it doesn't seem to me that the MS initiative in this regard is making things much worse than they are at the moment. Also it should be noted that while porting Linux to an ARM device designed for Windows (such as a Windows phone) would probably take a lot of work it's relatively easy to get your own Linux build on an Android phone if it's not locked down. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207090034.03088.russ...@coker.com.au
Re: EFI in Debian
On Sun, 2012-07-08 at 14:15 +0100, Wookey wrote: [...] A competition case is much harder to bring here because Windows has almost zero share on ARM and can use that as an excuse. Of course, as we know in Debian architecture is really irrelevant to the question of 'is this OS dominant and using its dominance in one area to restrict competition in another'? [...] It's not irrelevant. OS dominance is dependent on relationships with hardware manufacturers (not the same for different architectures) and application developers (often uninterested in porting, however easy it is). Did Windows NT take over PowerPC? No. Alpha? Not even after FX!32 provided fast x86 emulation. And the application developers used to Win32 (or Windows Forms) won't be able to port to Windows RT without first rewriting for the 'Windows Runtime' APIs. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Re: EFI in Debian
On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote: Will Android machines make secure boot turn-offable or another key installable, or will thay follow the Microsoft lead and lock everything down too? Are there any Android devices that aren't *already* bootloader locked or require jailbreaking to get root? I don't think Microsoft is creating a trend here, locked down ARM devices are already the norm AFAICT. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6e1edc87s6ftxffj1hvr4spobxtcoh6enxgvq3brqh...@mail.gmail.com
Re: EFI in Debian
Paul, am Sun, Jul 08, 2012 at 10:00:05AM -0600 hast du folgendes geschrieben: On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote: Will Android machines make secure boot turn-offable or another key installable, or will thay follow the Microsoft lead and lock everything down too? Are there any Android devices that aren't *already* bootloader locked or require jailbreaking to get root? I don't think Microsoft is creating a trend here, locked down ARM devices are already the norm AFAICT. there's a difference between requiring jailbreaking to get root and being able to flash a random different software image. The Samsung Galaxy S is perfectly able to get flashed, but with the default image you don't get root. I'm sort of ok with that because I couldn't care less about the default image. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: EFI in Debian
On Sun, Jul 08, 2012 at 10:00:05AM -0600, Paul Wise wrote: On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote: Will Android machines make secure boot turn-offable or another key installable, or will thay follow the Microsoft lead and lock everything down too? Are there any Android devices that aren't *already* bootloader locked or require jailbreaking to get root? I don't think Microsoft is creating a trend here, locked down ARM devices are already the norm AFAICT. The Galaxy Nexus (and Nexus devices in general) can be unlocked by simply running the fastboot oem unlock command which is distributed as part of the Android SDK. The unlock process will erase all of the user data for security reasons (so that if someone steals your phone, they can't use the unlock process to break security and grab all of your data, including silly things like the authentication cookies which would allow an attacker access to your google eaccount). HTC and ASUS have also been selling their newer android with an unlocked bootloader. Most Samsung devices are shipped with unlocking tools, so it came as a bit a surprise when the Verizon Samsung Galaxy S3 came with a locked bootloader. Some have blamed Verizon, but there's no proof of that as far as I know. So in answer to your question, there are plenty of Android devices which are trivially unlockable. (And once a Nexus phone is unlocked, it's you can get a root shell trivially; no jail-breaking necessary. Of course this is true for an attacker/thief who has managed to steal your phone, but if you want to unlock the phone, it's easily doable on many Android devices.) - Ted P.S. Personally, I recommend that people buy SIM unlocked, and easily boot-unlocked Android phones; and if you get Google Experience Nexus that isn't subsidized by Carriers, its firmware updates don't have to get approved by carriers. It also means you don't get any carrier-mandated or handset-manfacturer-mandated bloatware. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120708233048.ga24...@thunk.org
Re: EFI in Debian
On Fri, Jul 06, 2012 at 05:32:44AM +0100, Ben Hutchings wrote: 2. Upstream kernel support: when booted in Secure Boot mode, Linux would only load signed kernel modules and disable the various debug interfaces that allow code injection. I'm aware that David Howells, Matthew Garrett and others are working on this. Matthew Garret believes that this is a requirement; however, there is no documented paper trail indicating that this is actually necessary. There are those who believe that Microsoft wouldn't dare revoke a Linux key because of the antitrust issues that would arise. This would especially true if the bootloader displayed a spash screen with a huge penguin on it, and the user was obliged to hit a key acknowledging the spash screen before the boot was allowed to continue. James is working on a signed bootloader which would do this. It's not even obvious that the spash screen is needed, BTW. Canonical is not using a splash screen and is not signing the kernel or kernel modules. It will be *very* interesting if Microsoft dares to revoke Canonical's certificate, or refuse to issue a certificate. I'm sure there are developers in Europe who would be delighted to call this to the attention of the European Anti-Trust regulators --- you know, the ones who have already fined Microsoft to the tune of 860 million Euros ($1.1 billion USD). So personally, I would hope that at least some distributions will patch out the splash screen, and apply for a certificate. If we have multiple distributions using different signing policies and slightly different approaches (which is the beauty of free/open source boot loaders; everyone can tweak things slightly), we can see how Microsoft will react. It should be entertaining - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120708235244.gb24...@thunk.org
Re: EFI in Debian
Hi, Ben Hutchings b...@decadent.org.uk writes: 2. Upstream kernel support: when booted in Secure Boot mode, Linux would only load signed kernel modules and disable the various debug interfaces that allow code injection. I'm aware that David Howells, Matthew Garrett and others are working on this. That makes dkms modules unusable when using secure boot. I guess we would have to build binary packages for all supported kernel versions? 5. Key management policy. Similar issues to archive signing keys, but these keys also need to be available at build time. (a) Should they be held by package maintainers and/or the auto-builders for the relevant architectures? (b) sbuild and/or pbuilder will need to know how to inject them into the build environment for the relevant packages. (c) How do we handle key replacement when exploitable code needs to be blacklisted? Do these need to be available when building the kernel packages or would it be possible to have the signatures in a separate package? The latter would allow moving the signing off the auto-builders and having either a human maintainer or a dedicated system do so instead (so the auto-builders would not need access to the keys). It would also allow signing modules provided in the maintainer upload. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3yfoci0@marvin.43-1.org
Re: EFI in Debian
On Sat, 2012-07-07 at 08:46 -0600, Ansgar Burchardt wrote: Hi, Ben Hutchings b...@decadent.org.uk writes: 2. Upstream kernel support: when booted in Secure Boot mode, Linux would only load signed kernel modules and disable the various debug interfaces that allow code injection. I'm aware that David Howells, Matthew Garrett and others are working on this. That makes dkms modules unusable when using secure boot. I guess we would have to build binary packages for all supported kernel versions? The Linux kernel hardly has a perfect security record, but signing code that is too bad even for staging will be a quick route to blacklisting. I would absolutely oppose signing out-of-tree modules with Debian keys. 5. Key management policy. Similar issues to archive signing keys, but these keys also need to be available at build time. (a) Should they be held by package maintainers and/or the auto-builders for the relevant architectures? (b) sbuild and/or pbuilder will need to know how to inject them into the build environment for the relevant packages. (c) How do we handle key replacement when exploitable code needs to be blacklisted? Do these need to be available when building the kernel packages or would it be possible to have the signatures in a separate package? That is possible... but the installation process would be tricky. The latter would allow moving the signing off the auto-builders and having either a human maintainer or a dedicated system do so instead (so the auto-builders would not need access to the keys). It would also allow signing modules provided in the maintainer upload. It would also help sites to sign with their own PK, if they want to take full advantage of Secure Boot. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Re: EFI in Debian
On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote: Le vendredi 06 juillet 2012 à 05:32 +0100, Ben Hutchings a écrit : 1. General consensus in the project that supporting the option of Secure Boot, including purchase of a Microsoft-signed certificate, is worthwhile and not entirely objectionable. Not entirely objectionable indeed, but it really depends on what we would have to pay for. As long as it is only covering for administrative costs of Microsoft emitting a new certificate, it is fine. Microsoft has indicated their intent to provide the Secure Boot CA services free of charge. AIUI the only associated fee is to a third party, Verisign, for them to provide the service of establishing digital identity to Microsoft's standards. If OTOH we have to pay a fee just for our software to work on platforms that just happen to be using Microsoft’s certificate, this is clearly abusive. I would object to do so, and I believe we would (at least in Europe) have a very strong case in court against such practice. Note that the Windows 8 requirements stipulate that users must in all cases retain the ability to disable Secure Boot on their x86 systems from the firmware. It's really a question of ease of installation, and whether Secure Boot provides any additional security protection that we think it's worth providing to Debian users out of the box. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: EFI in Debian
* Steve Langasek (vor...@debian.org) [120707 22:54]: On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote: If OTOH we have to pay a fee just for our software to work on platforms that just happen to be using Microsoft’s certificate, this is clearly abusive. I would object to do so, and I believe we would (at least in Europe) have a very strong case in court against such practice. Note that the Windows 8 requirements stipulate that users must in all cases retain the ability to disable Secure Boot on their x86 systems from the firmware. It's really a question of ease of installation, and whether Secure Boot provides any additional security protection that we think it's worth providing to Debian users out of the box. IIRC it's not the same on embedded hardware. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120707210957.gg2...@mails.so.argh.org
Re: EFI in Debian
On Sat, Jul 07, 2012 at 02:48:59PM -0600, Steve Langasek wrote:
On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote:
If OTOH we have to pay a fee just for our software to work on platforms
that just happen to be using Microsoft’s certificate, this is clearly
abusive. I would object to do so, and I believe we would (at least in
Europe) have a very strong case in court against such practice.
Note that the Windows 8 requirements stipulate that users must in all cases
retain the ability to disable Secure Boot on their x86 systems from the
firmware. It's really a question of ease of installation, and whether
Secure Boot provides any additional security protection that we think it's
worth providing to Debian users out of the box.
This argument seems to depend on how thoroughly Microsoft will enforce
their Windows 8 requirements. AFAIU, the fact that Windows 8
requirements might, at least theoretically, be disattended is something
that played a role also in Canonical/Ubuntu decision to stay away from
Grub. All in all, it doesn't seem wise to rely on the fact that Windows
8 requirements will be enforced, especially when disattending them gives
an advantage to Microsoft, by making it even harder to install other
OSs.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: EFI in Debian
On Sat, Jul 07, 2012 at 11:09:57PM +0200, Andreas Barth wrote: * Steve Langasek (vor...@debian.org) [120707 22:54]: On Fri, Jul 06, 2012 at 10:14:01AM +0200, Josselin Mouette wrote: If OTOH we have to pay a fee just for our software to work on platforms that just happen to be using Microsoft’s certificate, this is clearly abusive. I would object to do so, and I believe we would (at least in Europe) have a very strong case in court against such practice. Note that the Windows 8 requirements stipulate that users must in all cases retain the ability to disable Secure Boot on their x86 systems from the firmware. It's really a question of ease of installation, and whether Secure Boot provides any additional security protection that we think it's worth providing to Debian users out of the box. IIRC it's not the same on embedded hardware. The distinction is between x86 and ARM, and the Windows 8 cert requirements for ARM appear to have as their goal to prevent any other OS to be bootable on that hardware. So I don't think you should expect MS to sign any UEFI ARM bootloader binaries at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120707215813.gb24...@virgil.dodds.net
Re: EFI in Debian
Le vendredi 06 juillet 2012 à 05:32 +0100, Ben Hutchings a écrit : 1. General consensus in the project that supporting the option of Secure Boot, including purchase of a Microsoft-signed certificate, is worthwhile and not entirely objectionable. Not entirely objectionable indeed, but it really depends on what we would have to pay for. As long as it is only covering for administrative costs of Microsoft emitting a new certificate, it is fine. If OTOH we have to pay a fee just for our software to work on platforms that just happen to be using Microsoft’s certificate, this is clearly abusive. I would object to do so, and I believe we would (at least in Europe) have a very strong case in court against such practice. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1341562441.21607.269.camel@pi0307572
Re: EFI in Debian
On 06/07/12 06:32, Ben Hutchings wrote: 1. General consensus in the project that supporting the option of Secure Boot, including purchase of a Microsoft-signed certificate, is worthwhile and not entirely objectionable. (I am assuming that it would be a waste of time to use our own platform key, as anyone who can work out how to install that can also disable Secure Boot.) This are the FSF recommendations: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Re: EFI in Debian
On Fri, Jul 6, 2012 at 5:41 AM, Carlos Alberto Lopez Perez wrote: This are the FSF recommendations: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web These seem much more in line with the Debian social contract than any the actions of other distributions or of the suggestions we have had. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gdau-v4bb4xwwpcgspn0neofpr0o4vfzegqcxqxjd...@mail.gmail.com
Re: EFI in Debian
Tanguy wrote: Steve McIntyre, 2012-07-02 18:42+0200: As you might have seen from recent discussions about the Fedora and Ubuntu strategies for how to deal with EFI and Secure Boot, there are potentially major issues in the area. In Debian we don't (yet) have a plan, so it's high time that we had some discussion. I've set up a BoF at DebConf for this: I cannot attend, but hoping it can be useful, here are some pointers to things I wrote some time ago on this subject. A blog post explaining how to set up Debian to boot via UEFI: http://tanguy.ortolo.eu/blog/article51/debian-efi A message to this list detailing the UEFI boot procedure and what is required to support it: je7174$b6p$1...@dough.gmane.org http://lists.debian.org/debian-devel/2012/01/msg00168.html Cool, thanks for the pointers. If you can make it, please try to join the session via video and irc? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1smsq0-0005px...@mail.einval.com
Re: EFI in Debian
On Wed, Jul 04, 2012 at 12:51:01PM +, Tanguy Ortolo wrote: Tanguy Ortolo, 2012-07-04 14:13+0200: A blog post explaining how to set up Debian to boot via UEFI: http://tanguy.ortolo.eu/blog/article51/debian-efi A message to this list detailing the UEFI boot procedure and what is required to support it: je7174$b6p$1...@dough.gmane.org http://lists.debian.org/debian-devel/2012/01/msg00168.html (basically, we already have everything needed to boot via UEFI (not with SecureBoot of course, though), only the Debian installer does not support it) James Bottomly has been doing some work to support Secure Boot. See: http://lwn.net/Articles/503820/ His work was done specifically to help other community distributions beyond Ubuntu and Fedora. We (the LF Technical Advisory Board) are currently investigating if there is more the LF can do to support distributions. We're not in the position to promise anything just yet, but if Debian has any suggestions of things that you might like, do please let me know. Regards, - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706022737.ga9...@thunk.org
Re: EFI in Debian
On Thu, 2012-07-05 at 22:27 -0400, Theodore Ts'o wrote: On Wed, Jul 04, 2012 at 12:51:01PM +, Tanguy Ortolo wrote: Tanguy Ortolo, 2012-07-04 14:13+0200: A blog post explaining how to set up Debian to boot via UEFI: http://tanguy.ortolo.eu/blog/article51/debian-efi A message to this list detailing the UEFI boot procedure and what is required to support it: je7174$b6p$1...@dough.gmane.org http://lists.debian.org/debian-devel/2012/01/msg00168.html (basically, we already have everything needed to boot via UEFI (not with SecureBoot of course, though), only the Debian installer does not support it) James Bottomly has been doing some work to support Secure Boot. See: http://lwn.net/Articles/503820/ His work was done specifically to help other community distributions beyond Ubuntu and Fedora. We (the LF Technical Advisory Board) are currently investigating if there is more the LF can do to support distributions. We're not in the position to promise anything just yet, but if Debian has any suggestions of things that you might like, do please let me know. UEFI running in qemu is likely to be very useful for development of UEFI support by the Debian installer and Debian CD teams. Secure Boot is another matter, which I was planning to raise *after* the release as it's controversial and I don't think we have time to do anything about it for wheezy. But here's what I think we would need: 1. General consensus in the project that supporting the option of Secure Boot, including purchase of a Microsoft-signed certificate, is worthwhile and not entirely objectionable. (I am assuming that it would be a waste of time to use our own platform key, as anyone who can work out how to install that can also disable Secure Boot.) 2. Upstream kernel support: when booted in Secure Boot mode, Linux would only load signed kernel modules and disable the various debug interfaces that allow code injection. I'm aware that David Howells, Matthew Garrett and others are working on this. 3. A suitable free boot loader: when booted in Secure Boot mode it would only load signed EFI executables. There seem to be several projects under way to do this. 4. EFI code signing tool. Matthew Garrett seems to have that in hand. 5. Key management policy. Similar issues to archive signing keys, but these keys also need to be available at build time. (a) Should they be held by package maintainers and/or the auto-builders for the relevant architectures? (b) sbuild and/or pbuilder will need to know how to inject them into the build environment for the relevant packages. (c) How do we handle key replacement when exploitable code needs to be blacklisted? 6. User documentation: users need to be informed that when running Linux under Secure Boot some major features are disabled, and that they have the option to turn it off. (Or install their own platform key.) So, returning to your question: I think that LF may be able to help with 5(c), 6, and perhaps 3 (encouraging more coordinated development). Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Re: EFI in Debian
Steve McIntyre, 2012-07-02 18:42+0200: As you might have seen from recent discussions about the Fedora and Ubuntu strategies for how to deal with EFI and Secure Boot, there are potentially major issues in the area. In Debian we don't (yet) have a plan, so it's high time that we had some discussion. I've set up a BoF at DebConf for this: I cannot attend, but hoping it can be useful, here are some pointers to things I wrote some time ago on this subject. A blog post explaining how to set up Debian to boot via UEFI: http://tanguy.ortolo.eu/blog/article51/debian-efi A message to this list detailing the UEFI boot procedure and what is required to support it: je7174$b6p$1...@dough.gmane.org http://lists.debian.org/debian-devel/2012/01/msg00168.html -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jt1c0d$qn1$1...@dough.gmane.org
Re: EFI in Debian
Tanguy Ortolo, 2012-07-04 14:13+0200: A blog post explaining how to set up Debian to boot via UEFI: http://tanguy.ortolo.eu/blog/article51/debian-efi A message to this list detailing the UEFI boot procedure and what is required to support it: je7174$b6p$1...@dough.gmane.org http://lists.debian.org/debian-devel/2012/01/msg00168.html (basically, we already have everything needed to boot via UEFI (not with SecureBoot of course, though), only the Debian installer does not support it) -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jt1e7k$fik$1...@dough.gmane.org
EFI in Debian
Hey folks, As you might have seen from recent discussions about the Fedora and Ubuntu strategies for how to deal with EFI and Secure Boot, there are potentially major issues in the area. In Debian we don't (yet) have a plan, so it's high time that we had some discussion. I've set up a BoF at DebConf for this: https://penta.debconf.org/penta/schedule/dc12/event/925.en.html That's Monday 9th July, 15:00 local time (21:00 UTC). -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702164213.gc12...@einval.com
Re: EFI in Debian
On Mon, Jul 02, 2012 at 05:42:13PM +0100, Steve McIntyre wrote:
As you might have seen from recent discussions about the Fedora and
Ubuntu strategies for how to deal with EFI and Secure Boot, there are
potentially major issues in the area. In Debian we don't (yet) have a
plan, so it's high time that we had some discussion. I've set up a BoF
at DebConf for this:
https://penta.debconf.org/penta/schedule/dc12/event/925.en.html
That's Monday 9th July, 15:00 local time (21:00 UTC).
Hi Steve, thanks for taking care of that. We're indeed a bit late in our
reflections on this matter and we should come up with a plan for both
Wheezy (if still feasible?) and the future. I unfortunately won't be
able to make it for the BoF, as I've to leave shortly after DebCamp. But
I encourage everyone to participate in the BoF and please work on a
report or minutes so that we can have a discussion on list (either here
or on -boot) afterwards.
For those who are not familiar with the crux of secure boot, here are a
few recent references on the matter:
- Fedora's plans http://mjg59.dreamwidth.org/12368.html
- Ubuntu's plans
http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and-secure-boot/
(with a more technical discussion of it at
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html )
- FSF's paper
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
