hardening flags
Hi all, are there any plans to add -fstack-clash-protection to the hardening flags? Martin
Re: enabling link time optimizations in package builds
Adrian Bunk: > On Fri, Jun 17, 2022 at 10:18:43AM +0200, Matthias Klose wrote: ... > > >... > > Link time > > optimizations are also at least turned on in other distros like Fedora, > > OpenSuse (two years) and Ubuntu (one year). > >... > > The idea is to file wishlist bug reports for those 373 packages and then see > > how far we get, and if it's feasible to already turn on LTO for bookworm. > > If not, it should be turned on by default for the following release. > > I assume these 373 packages have already been fixed/workarounded in Ubuntu? > Submitting 373 bugs with patches should settle the feasibility question. > For my software (bart), it triggers a compiler bug where the compiler crashes. Martin > A bigger worry is the schedule of such a change. > A major toolchain change shortly before the freeze means the vast > majority of packages will be shipped with non-LTO builds in the release, > with security updates or point release updates triggering a change to > an LTO built package. > This means few packages actually benefitting from LTO, but a higher > regression risk when fixing bugs in stable. > The best timing for such a change would be immediately after the release > of bookworm. >
Accepted bart 0.5.00-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 27 Aug 2019 14:18:12 +0200 Source: bart Binary: bart libbart-dev octave-bart Architecture: source Version: 0.5.00-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Martin Uecker Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Changes: bart (0.5.00-1) unstable; urgency=medium . [ Martin Uecker ] * New upstream version. * Standards-Version: 4.4.0 . [ Andreas Tille ] * debhelper-compat 12 * Remove trailing whitespace in debian/copyright Checksums-Sha1: 120135cc6ae05fddf756ac92838bca1982b8ea6c 2151 bart_0.5.00-1.dsc d39f63a97f6d9598e33968ab92fc49bbec8404f6 573262 bart_0.5.00.orig.tar.gz e8262f373ae5911854bf1f2f35bfe0528768663d 4904 bart_0.5.00-1.debian.tar.xz Checksums-Sha256: 99859838aa92ff2bea08a86d77e2f9dd93140a70e921229744042698c7c94a5d 2151 bart_0.5.00-1.dsc 30eedcda0f0ef3808157542e0d67df5be49ee41e4f41487af5c850632788f643 573262 bart_0.5.00.orig.tar.gz 16238c91561e31fcc6296ef9899cd65a73002de374568bbc56d622319e0e1af3 4904 bart_0.5.00-1.debian.tar.xz Files: 39dd59a056af76aa760265eb17fd5a93 2151 science optional bart_0.5.00-1.dsc 7100dece7b668ff0ad579682205dbdbe 573262 science optional bart_0.5.00.orig.tar.gz 0595600d3c0158b0b22d389320d6163b 4904 science optional bart_0.5.00-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQJCBAEBCAAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAl1mbC0OHHRpbGxlYUBy a2kuZGUACgkQV4oElNHGRtFDvQ//ShEb7SG7MHDnNSE4bmpKEA4kEQOZNPPjeGYu 6mQa0BCNcNb9SMwuGsjjoamdrzGyJNgvlJbZnsCK9ma+GNlewhcDFRNGx5PzfL+X m992gi+1gNdbs+8kih1ZzGXNyIPSC2KBLP8mTHqC2dJgvAg8YOfGSdxEkBfPUzuU LnnaEp8CgqMBggj2omhY28pU5cCvKRJNM1DE08BPrFnsTCPexonGrcYMn9ac+7Da W4e+8wfqmVZk34Clg6rRx3APnu+6ffwb8/BnxQRoN/og+ZzfIgNECctb1ZqM7Gsn oDuivf159hCNir/MArOeqNt7BWFnxoswHINnwt/VbYo2Rm5MbwYAp/g4WLNMoMhz L4tMrmPn7+mE3mAlYbLcmAiq2xb+cHtoCoEMtRTn+SUiEfeIQFVYLePK0Nw1WolI FFkUVC3zmAGqMOshtQuEp6hIuyOk/YLfNcxdYMyscj9z3xtUXbxM8UnIX7jbPhMr 9rQaeDGsroPnwJgkc2ZvR3Ee8QEdrIxJnspulnce9V70s1fBzmfnVIhkxFDDrOe0 6Kcr70jufScs0LLgzAPmcDZ192KcrHB69CxlUWdKUPxj+vYAEsO1KjDMtH8x4913 6HU0zehfQPsJsMTI3QpcfqFpSySrEcKvM95GV0ZSVRUY45yozmtJkZqepPp1yL5w guT8AOk= =frgs -END PGP SIGNATURE-
Accepted bart 0.4.04-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 11 Dec 2018 13:07:12 +0100 Source: bart Binary: bart libbart-dev octave-bart Architecture: source Version: 0.4.04-2 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Martin Uecker Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Changes: bart (0.4.04-2) unstable; urgency=medium . * Add some fixes from upstream. * Deactivate unit tests for ODE solver. * Deactivate unit tests for some archs. * Add autopkgtest for octave interface script. Checksums-Sha1: 188cb9e6cabfaa1ada44fb595b13e397ca73ef89 2146 bart_0.4.04-2.dsc b462e5359e6e591bc4e03050ab66f98a9fce1230 6392 bart_0.4.04-2.debian.tar.xz 0dd8c0a8004706c1d22416e400065d71d8db9af5 13950 bart_0.4.04-2_source.buildinfo Checksums-Sha256: 13ecdd9c13f51a2c91b5cdc4767f9bdc98d2a26ff4be3369f7120b71901bf0d5 2146 bart_0.4.04-2.dsc 08eeb680efc2f0dbd1dea924f31cde7668414386495d8349fefd5dad0dccfd37 6392 bart_0.4.04-2.debian.tar.xz e2447540666cfb6304ed3bc522a8d4d9b7220e6274acdc4f628721d6a380c0e6 13950 bart_0.4.04-2_source.buildinfo Files: 0ed5fb9796f2f4b626b1fa0687dc61a0 2146 science optional bart_0.4.04-2.dsc 6b47933ee5064feecd0419a09058283b 6392 science optional bart_0.4.04-2.debian.tar.xz 9d83512692dd126d4920034a9d846d17 13950 science optional bart_0.4.04-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJCBAEBCgAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlwRgMAOHHRpbGxlYUBy a2kuZGUACgkQV4oElNHGRtHHeA/9GBsz9aYgCfidhMCkC9q4m3AZ+M008RvMCyfz TM4qTxt/Y1OvXk/YEbyV2p2t/72TZZ8gtDPW2k3ZyEcyg+tnpti/Bf05loXbM/N2 YeO8GkeUX0YZf34HtbGsISdMVVVl6kl+saMQPkpGSmrnnEGCxKFaChLugg/b5rM7 6SmCh3rfclrrtNw5oJVo82N1VEhkYKTH4+oge+saBRBiOzF8LdBtgNHROhou6bMw HBKV3LtsEVGAGyVAac//TD7zG5h0cZbs1/jeIGkl9YSUQNYi05NBnwX7lOkSbqPS dvZH+A3bHvJf6gAGrCqj2a9je9djM8K5Jc3XSGJbMoEztLgSrraK+1CjByLdOgJ8 zHbdQUIYORthce4WYP7mshqFwurLPyZ7Yi2tuwXXbO5RGNJE0w1QIYPiXxwGbtAc jJbw4rP9zEFCnKVLq6HNznquBEsA9gnVzD9KT2kRWe//RCShen7tUs6y7bJ5InkO ZR2Ko073k3BV1e3pX83bd7Y7Gsx2TAnxg+Mq4pi28kJx9W2krNIy1Au+TNOBYzbB 0ECyEQzwsFnGs359hBZ6d0PYtixJbyvMHT1o2aKM5fzEUIdsxz4eTgN7r1cduIUy qlh7cRAEdrTe17cwdfp2aeTh5qTqLOG2GsBZM4tVdinjPa2PsY9Yc8axBv4nLr82 QA3JV+M= =qaO7 -END PGP SIGNATURE-
Accepted bart 0.4.04-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 10 Dec 2018 14:32:26 +0100 Source: bart Binary: bart libbart-dev octave-bart Architecture: source Version: 0.4.04-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Martin Uecker Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Changes: bart (0.4.04-1) unstable; urgency=medium . * New upstream version. * Relax error bound for new unit test. * Standards-Version: 4.2.1 Checksums-Sha1: 82ee49a2ea5d3c75c1ad1df889e741cc50153495 2119 bart_0.4.04-1.dsc bc5d3b34263a86cda4c0f49dd070631fc4339b04 550630 bart_0.4.04.orig.tar.gz 293813109c836a17bebbf19abe09354ad1d2bdf7 4568 bart_0.4.04-1.debian.tar.xz Checksums-Sha256: 5a1196d49745c2e6338b13f443e6f0317c7cb55aa0e82469af16d75a79f9d46f 2119 bart_0.4.04-1.dsc a3a8bf44e05232fa0f733dd9d3d9e2b0077d4c294e73cc5830949f7a65e432cd 550630 bart_0.4.04.orig.tar.gz 5a063c72695b31290347fc5bcf48cd338f0244342d34273c80c02d34a28cb03b 4568 bart_0.4.04-1.debian.tar.xz Files: da53ef55362291e148c6190fdc1d5e8a 2119 science optional bart_0.4.04-1.dsc a067347f56a6a5dce0d7de0ea232030e 550630 science optional bart_0.4.04.orig.tar.gz b1c2ca1fe0b25740636f6668b58ebbfc 4568 science optional bart_0.4.04-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQJCBAEBCAAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlwO4T8OHHRpbGxlYUBy a2kuZGUACgkQV4oElNHGRtHB4Q/9EP3BIiyellaKfd7SrRSzR04RICL4GIZNgzmV vBWe/bTwzUcdi/T5QnHapy4np4MXVcDHHaM4u6iWJ3DPy7GP501ULEPTZq3okFzH Hq1i4+fDSgU6T4F+LoGsuoWhx4n5NVYvVsm2IMpg1Pjax90tq30F2MurBUXleXNf Ie98Wx7d2v3hEdih3V+kqh6KgLJujteD0oT/0LlXbnaC9aGPZhixWd4BjkhDDNgS KzTisQJT7VaE6gmQ9T7uWA8FKy7Kg60Pnr2R4lPV79HDwqop0HdV69xjPRezMsrT rp+jo2Z25ksOojlUiBO6/8A2IF9nkqNNPWJo301bC06BcgO+gbykf7LOqJskHMux ckItDavGSAM8vthexVjtNNQn/cxgy3OXP0VtKU4el6RZumg+y0TduUbjILUghXHt Dijdduk7oNRpymFStKxGX6/QyjN05Y9BKzOWKOamciks7aZVzIk+vQww4LMP4Zsk Owv/jmn2Tz+oPDN0hSDNjIi1abH/pdOE9SKfjCY21V4cEl4iswlA/jqiV9sKMH+e +IGq8XX2N35MPSH3z+qoxeIwGpMUAlnWHTZnrtRRZ93zXkjxzgPl7WpiXgAgNBKp QMK06RG6S8GT2utiN+L5G2/+yueWEey4OUcD8zlLThENufaqm5M0w3DkSNIyvF7H oQh9GFg= =hVSH -END PGP SIGNATURE-
Accepted bart 0.4.03-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 03 May 2018 21:44:55 +0200 Source: bart Binary: bart libbart-dev octave-bart Architecture: source Version: 0.4.03-2 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team <debian-med-packag...@lists.alioth.debian.org> Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de> Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Closes: 897466 Changes: bart (0.4.03-2) unstable; urgency=medium . * Add missing header to libbart-dev. (Closes: #897466) Checksums-Sha1: 686ff5607047b2d3cb065abab4db8cd6ce7fc1a3 2119 bart_0.4.03-2.dsc ba10b8f48991becde02401acd0d4d3ea384405bd 4344 bart_0.4.03-2.debian.tar.xz 312e94933d53fe098171ac54d7551276cc452b38 6634 bart_0.4.03-2_amd64.buildinfo Checksums-Sha256: aa893d21a4cc339f684fd09e92ea925f8d13f9f44fa5796485d6881dae7c38aa 2119 bart_0.4.03-2.dsc 07b97126347acbea1dd1c790896ff051ef517b9a579440383bc518aec0dc8e2f 4344 bart_0.4.03-2.debian.tar.xz dd14a0e81259ae359cb681b1653cf2f1746b0538987396c81eeba73f253516e8 6634 bart_0.4.03-2_amd64.buildinfo Files: 8f7ba2634e9000f730c678cf8dfefec3 2119 science optional bart_0.4.03-2.dsc 7718ff97969baea804a742df919e375e 4344 science optional bart_0.4.03-2.debian.tar.xz 8a44a4253f9a1b8f04eb746832aa37c5 6634 science optional bart_0.4.03-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJCBAEBCgAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlrsktAOHHRpbGxlYUBy a2kuZGUACgkQV4oElNHGRtGeVg/8CwzB1CzuSNsjKTnAuo1EEGNUwwzjX07dJ95e ms/theDH35oPifpuLXHGiEJ5rq+uuE7lJoiXR/cJZ7EeUXOcCzWNJcASnTyL+qah ER6WiZd03yVnSPQqM0Dg6GYHw/KhjZN1wKXgPl/pUkUW++vtExAIoU91qz6q9ccJ R8xNnxwNUYqvF7ZcMC3GPTrCqxFsR+Cfh9JTrh93VjGtP/nCKFMYO6oRkSmTR5CU Rgg5BF/8vOhJArP8dh6SwM9qe9VM6RnJLA5tZWzbh57xKMmDUZfsg1qPEbxbrHiA b4OcOxtLiMY+NvxHQZKYxl2NvlLvIv7j6rSq1MWbSO9huoeJ0Mb4bMVV14x8hZZF VzwyKlGJ/LnbPRvLMQyIYgem/zhaubP4jY/sfddmAR31EHrPeoXuMlCH2yyCpplj crh8GTw5Pxx6XWPEn5Gs6nbz0y5Ho5DRK5w1Gfv+1z0/t9ANBQ4Vm7Pufy++A8eD 7eF8ApJNyIkjt8gcS+4PZcGssKCnGhbck+MX9Ea1CgsVgcvEzeTUO9/RnFjs81vd YdjpMMz7OMbcTA8t8HN9cmNot3qOTEw1Q7yxhwvidawr3cXYKXFxeZhEqeP7/zPh sieprI3fRCKZks31OMhre9iVH1oW9QbeY0X6Wf+XxW7IEJM8LNrLqRVDVoZVCO/Q XTWOZYA= =QYSd -END PGP SIGNATURE-
Accepted bart 0.4.03-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 27 Apr 2018 21:34:11 +0200 Source: bart Binary: bart libbart-dev octave-bart Architecture: source Version: 0.4.03-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team <debian-med-packag...@lists.alioth.debian.org> Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de> Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Changes: bart (0.4.03-1) unstable; urgency=medium . [ Martin Uecker ] * New upstream version. * Update copyright file. * Fix install. * Standards-Version: 4.1.4 * Secure url for copyright format. * Make vcs links point to salsa. . [ Andreas Tille ] * debhelper 11 Checksums-Sha1: 6bfd390333af273ef3524d9e977cf1213d0bd285 2119 bart_0.4.03-1.dsc 30960ee7d85d26fac1dc7078b0f8534e4df8daac 436582 bart_0.4.03.orig.tar.gz 6f12fba444a77d9504986f837b7774118062619c 4308 bart_0.4.03-1.debian.tar.xz Checksums-Sha256: 641ce948461911eb8917fded0b6b13aad4946eaaaf013c135602c9c958d08f15 2119 bart_0.4.03-1.dsc c116efd14e4e0ed7a7191e15a86868904f35685b75690445f6291d993963387f 436582 bart_0.4.03.orig.tar.gz 3b2fcc13731e11d524153e9f8d5287761512f32048b0aae611f440bd3251cdfa 4308 bart_0.4.03-1.debian.tar.xz Files: 430d0d9ea8f9d2adae9bdc2d8ba75693 2119 science optional bart_0.4.03-1.dsc e3328215bb77e790437b9ad451118109 436582 science optional bart_0.4.03.orig.tar.gz 9a718c6af3dfd655fadffae1fe7f7c1d 4308 science optional bart_0.4.03-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQJCBAEBCAAsFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlrlW50OHHRpbGxlYUBy a2kuZGUACgkQV4oElNHGRtH6DQ//Z8mQhaCc+lIT8M+cj9gXCDs3GRfqrnKT85RL pDadsDJWxFJiHRZwqREEwDPrFzuqaab7/A7zASRMHLOO/p8L1tGHGA95MtGolCZ1 PNYoZfatw95rjUU72MEPsEaX6/arunuGTepepuucdvUE/MHUteC1UBzTmkG+DNWg jhCUronzMTofzgnaZmyax09+RXYv3GP3DOzWMsKO2NkRd7z2i0ImDz95/Owj6WYd 880hxwoNIZs/lG8Gq67DCT9g9JjoKZ1TUk7gbe4JufYXr7YjdDOTVUu1OLRe+Xzn c4Q7kARSkSOAXEIYNR+hPYbUwpiA60AMy14K0+381edUAqa2WQjL2/7i/NXKqN3U V30+2viQf7PYNfKOzbEgZ3yKzuInSetPoVsOtQucOx3onq09dDFBVTxCyEU+U9hk W+RTZRgV9FYD0BLbzRcAv/qIRmWfljjAcak1dWjZhboT0PNwX05lmIMUrG7AtNz7 godJ8bMsQuRrLx+KjzJOWYkKgLTMRiTOUMYxp4S0fuKUWm81nTlqSrYjkafwVDhs t5x9/izPdiF2RsdUC0kTSxim5rnc0xWVl2Y9arQx7TefeZHzhf1DXdWWbcoWwJfb 3980urUcEuEXW+KAxw149Rn2to4GBMzw3ZIZlzGpJjTawIutMizi1H4gvSatLmY+ wKg/r4M= =Tyzw -END PGP SIGNATURE-
Accepted bart-view 0.1.00-1 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 17 Feb 2018 17:09:09 +0100 Source: bart-view Binary: bart-view Architecture: source amd64 Version: 0.1.00-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team <debian-med-packag...@lists.alioth.debian.org> Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de> Description: bart-view - viewer for multi-dimensional complex-valued data Closes: 851431 Changes: bart-view (0.1.00-1) unstable; urgency=medium . * Initial release. (Closes: #851431) Checksums-Sha1: b92a46e2a5821346e19f8125cd5dce81aaa21e74 1997 bart-view_0.1.00-1.dsc cd4d4a1ac2f95a137cd507d6271212c60244ed74 139140 bart-view_0.1.00.orig.tar.gz f03a25f00d09a8bc0117859238711f933dd99426 2488 bart-view_0.1.00-1.debian.tar.xz 9ce84a34ed930f8676576781cf667327b1415916 37880 bart-view-dbgsym_0.1.00-1_amd64.deb 763b657a3967d2d38adc8790ff28cfc5b9395581 13692 bart-view_0.1.00-1_amd64.buildinfo 715e05a2f7142bf977911b7446ba193614684126 53064 bart-view_0.1.00-1_amd64.deb Checksums-Sha256: 0b336a39acbbe80002190112cf94271fd7c0110517ec610c4b99f8f8aa3e14d4 1997 bart-view_0.1.00-1.dsc 3deb67ec213c24e5ca0d1b0e47c1a7a47e152661dc7b29fb2fe01d8d9667790e 139140 bart-view_0.1.00.orig.tar.gz bd22f35a7761d60adf144eb2a824317d9cced9d6126cb3877025567b0a0e8c64 2488 bart-view_0.1.00-1.debian.tar.xz 908bf9ec913eedda6806d6949d21f0c8b68278f9a956f34b1808967ac9cd0f1a 37880 bart-view-dbgsym_0.1.00-1_amd64.deb 9a949a0a8cff8ae1833999f80ecacd4505f8ac3d43b89ca55b5462b638a67a81 13692 bart-view_0.1.00-1_amd64.buildinfo 1e11fb75f3fd2876fef9af9ebc93c36b12c58af01d5e146956d9bae391adb5aa 53064 bart-view_0.1.00-1_amd64.deb Files: 74913c291385e0bc944713b8617462f2 1997 science optional bart-view_0.1.00-1.dsc 891f9aa18dc8e13a200c3bc57bcb9545 139140 science optional bart-view_0.1.00.orig.tar.gz b4109fd5df349233acaa488ffbb8cf2e 2488 science optional bart-view_0.1.00-1.debian.tar.xz aec5c3b1c77a307155983605977957b8 37880 debug optional bart-view-dbgsym_0.1.00-1_amd64.deb 794714a9e4a9be42acde1d76ddffbd74 13692 science optional bart-view_0.1.00-1_amd64.buildinfo f7b957322028483b0c22cb449e5ca83c 53064 science optional bart-view_0.1.00-1_amd64.deb -BEGIN PGP SIGNATURE- iQJFBAEBCAAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlqIltgRHHRpbGxlQGRl Ymlhbi5vcmcACgkQV4oElNHGRtGh1Q//ZlJgoJbs1WCfqb1S+yoj1i5ZpcmFDZWE gSwZlQErB3v3XlPdfCwmxJco+jRRE60PaNyatCmA4W7BgKwLBeqWh+MGG/ey+GjA chK3YDn/re6KeMlQWSHSmlZn8DxDOctbqjrqS1gHbyQmC3SJjMvTHqUCE9tAMiWI KmKrtGEJHgOq5PS8qb2uOun108p5myTCdmgueRVFH2ILficdoDjnGTHSeOrhws6f KDHy/yhoq9SgZWbMdC1Yuch/GSV0t9nOrhNHqHDsopqw5jPODtIPYHT1KIDXuN5Y jV6aEGDjEZ/pTZCpGCPakLV0om2oM3Dc0kYGp237aoEcCzkBczy2xIyNNHWUwp1M nNONLyqwcRYybIN9WDnNdki1N5URvqkP12cBDPQQmog4qxctLl6CPNZtecPTggpE +Tqpbu2a3lLPZPD5TFbUl8uAuZIHnEIJIsS3JO+sGE4KcsU0OS3lrGszD2t+/6tw Kk0jFuXioqZ7UaLu/kffPj3NIufGmveYiLhZvGaDrbFsLkvGAjiVBF/sp1yxWmED CFC9De13DMiB9JsV5RYtHajoQNo6wDHdVlWaveMdmJ1S1bNv0Eq/wEnPoEz+PF0k 4V9Q5z09nFjnMF8fDdNSzOQoUJm6cEAriWnP8S27Rfp/Jyk0xSVcd5ZU5idJFcLe Mg+6i7lTd7M= =tGp0 -END PGP SIGNATURE-
Accepted bart 0.4.02-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 27 Nov 2017 23:21:21 +0100 Source: bart Binary: bart libbart-dev octave-bart Architecture: source Version: 0.4.02-2 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team <debian-med-packag...@lists.alioth.debian.org> Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de> Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Changes: bart (0.4.02-2) unstable; urgency=medium . * Turn off unit tests on some architectures. Checksums-Sha1: 8d302cca46306706ef3be382e042de7b50c2b46b 2143 bart_0.4.02-2.dsc 7f157a0fb8c58562bc681cda264178b68589dcec 4168 bart_0.4.02-2.debian.tar.xz cddab884884fe80b752b3c8a67ee873f2b53fe50 6536 bart_0.4.02-2_amd64.buildinfo Checksums-Sha256: 2cb6fda96a2dcfaadeea2ae79a6149b62349cef173c066a04d763d1ab83b21d7 2143 bart_0.4.02-2.dsc 75adfa84da8ac15a9bd003e07848de623e306f8c2a95b54754601aa3610b79d5 4168 bart_0.4.02-2.debian.tar.xz 4d9d1a1e2ae34d2b55d837e055df62f89905ef5accfe002b6abbb434e756cf73 6536 bart_0.4.02-2_amd64.buildinfo Files: b246d03d668751b0172ab828574bcd66 2143 science optional bart_0.4.02-2.dsc aaddda69a02089192841947b67b1f7b8 4168 science optional bart_0.4.02-2.debian.tar.xz a4b53067cbcafd55c910a8d21169668c 6536 science optional bart_0.4.02-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlod070RHHRpbGxlQGRl Ymlhbi5vcmcACgkQV4oElNHGRtG2bhAAkLrYe9cUrTucbun5G4MBeUlojUgmRSZl GmxhNFMB18kFGQoEG6XrPZ8buMvsDIg5Rig9kHg9ffAKWUaFENYLF5911hfzUcWh PumutETRHJctUpJu8rD6lsQppn30ticjuWhxrnSIry2ahVSaACnZjJaA/ZGoBGmp h5pyXCghJ7UbcyI4VwrUjw4qQQUpM7j8wp176YgNpZcYKP82aqKi4NsCMQ98neAg 6EsTZmXbZD5NvOrlVp8s2pFAYV39/ppk+g6qrtCtE/LlG25QBiWzTJAtn7AgqyLL PdLCPZPhLexzNIttNvb3OdXE6vozV70wZzfigiwAjXuCs+T2Pmw6fXdBUtkZwMJM 8R20FsIUM4NNxgOUH3/FIVuySzrU1SQJNI0k5Ose5PnarPouo7X3PBNF8s/cnoUT RYzeRip9CZsp46uFKUY3Q119qYIpjNPWAHnu9UpDmhpxLNxhEbx/8bBPg8EqUWrU +2qF83mVQVxB+lo7VSJriY6sqzX1EmEIexRVCJ2uh3LlSP4RmH/Crerid1hHmFdw N283VB/ooYtmm0PuRbb4+nCXH9sllgNfhTJUov2WUYOCIwMNInUhsctojS5ZijAB BzpO1GPsny2pqPFX+I5/gKuOSHuUjwFmC17NI+KHQY99cjI4cVGXKhiMgAqidZ+F u1dYLfXwvtA= =M6Wl -END PGP SIGNATURE-
Accepted bart 0.4.02-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 27 Nov 2017 08:32:12 +0100 Source: bart Binary: bart libbart-dev octave-bart Architecture: source Version: 0.4.02-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team <debian-med-packag...@lists.alioth.debian.org> Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de> Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Changes: bart (0.4.02-1) unstable; urgency=medium . * New upstream version. * Simple test for autopkgtest. * Standards-Version: 4.1.1 Checksums-Sha1: 07f6cb4bdd3e44c5c2f3e4c5680e5f9fca747dfc 2143 bart_0.4.02-1.dsc f8a6626709fa9ab583f431809df26587648beb57 434636 bart_0.4.02.orig.tar.gz ef491b31f082a3bf02503b7fcdcbd27faa23db4d 3956 bart_0.4.02-1.debian.tar.xz 3ed9d346c0411d00b90a3f0e793ae504a19c2287 6536 bart_0.4.02-1_amd64.buildinfo Checksums-Sha256: d14b2b6a4621afc96d3315e3f4dc6f789518a51a627ad7d7d784b3c4ae485b30 2143 bart_0.4.02-1.dsc 2d53963dd80dbb02b3b539c8ef533e54b4ffdfd7365ccc973e0b110ee6559ddf 434636 bart_0.4.02.orig.tar.gz b7cd399a101584d609951a0fde738cfe397f8315943d71f427361f771a4d0097 3956 bart_0.4.02-1.debian.tar.xz c202a3551928807ea6991d36e406d203081f2acc5a988d743df69149aca244f0 6536 bart_0.4.02-1_amd64.buildinfo Files: f4776d0896b88ce3dcfd824cc6fb2971 2143 science optional bart_0.4.02-1.dsc b793fae2ec9d5cfd64b5f9494c2fc41c 434636 science optional bart_0.4.02.orig.tar.gz 5daea4348dd09389ad1cb312613d9f5e 3956 science optional bart_0.4.02-1.debian.tar.xz 28e549adaacfcf5c2b671da86a11b2e4 6536 science optional bart_0.4.02-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlobwcgRHHRpbGxlQGRl Ymlhbi5vcmcACgkQV4oElNHGRtH7Ug/9GtVRqUNQtFT1m8wKpjJaNoWzCKPWlCNA f1kjuariqqaE1C3pUpCKuam5/Lp4m9fX3MBjNIj+00OWEIpfcb9sHJ6r0aoGVIvG yLIYj0dEWZZC4aRoBx5alZ3qZ8pQyAt2O1Km/9uyhhnFOACkdcpsXhRvIHprrR0O yPDH4rr3HCX6cxK3MM5+cr03IJ9OO1cQDwBHox2Q+MCjW4ht31SieJ3zim2tbcPP WoSuzs7dr/WlMXMn5xp35HXUYM6v4agKh3Gaz3mR2yECF/ILW5Bfxp5U4opTHvFX gXMAfXDFMXKNbXqxizjM9oEJY4FXC39jxq4iLi+c/lxfQIkxsaVDeZQXH9YFSkGG wafZASusZg4LRl7q2Aw68oYmQPGAFXKtH4mx4RNz0qjonvpQhcLemk7MTrL1N5GT LPz/P4lPs7vSeEJvCyCs8WDbsWjy5aUAo3HPtcjlSYVRHAO1DDLlyJICciMqI8xL /uO8Hh01X9y2V6e1aS4KwcNMXRMXXgXGhxLIka9AqX0i3PczJNbBgHFNRvBwLung 7XSSus43R4Te1vJo69QyesopwLOlBY3OxNzzo3VC4b3FNBDC1qElig8dOF33ZUdC eXg07arIB1z/T5FQoPvB80F4J48XJlQClCreqFaORmwOzef/asNXjzh0CPCxwFYg ZLMMXTT5htk= =Ew+F -END PGP SIGNATURE-
Accepted bart 0.4.00-1 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Jan 2017 14:41:50 +0100 Source: bart Binary: bart libbart-dev octave-bart Architecture: source amd64 all Version: 0.4.00-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team <debian-med-packag...@lists.alioth.debian.org> Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de> Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Changes: bart (0.4.00-1) unstable; urgency=medium . [ Martin Uecker ] * New upstream version. . [ Andreas Tille ] * debhelper 10 * d/watch: version=4 * cme fix dpkg-control * Add missing Build-Depends: liblapacke-dev * hardening=+all Checksums-Sha1: 1cc1f302d0786b02dd9cc32ecc2b272f7a8183cf 2120 bart_0.4.00-1.dsc 1fb62c3a72711d9d5d216d462fadd18405d5feb2 335604 bart_0.4.00.orig.tar.gz f241be4bb79a1cb534db53804850c01fcb0caeaf 3888 bart_0.4.00-1.debian.tar.xz 44e2d7d2860d2811bcb9c946fbca8f191d1282c5 576314 bart-dbgsym_0.4.00-1_amd64.deb 7055df3812914b1f5576d756255022c47ec80449 5729 bart_0.4.00-1_amd64.buildinfo b498762df2ad81a1656e6ab53cac1d8d6c70576c 231482 bart_0.4.00-1_amd64.deb cb5bf5e1b740c950f85101068d6d87ccf15b5499 140780 libbart-dev_0.4.00-1_amd64.deb 8747656756748ae2dfe29a37e5f9877697fb84dc 4016 octave-bart_0.4.00-1_all.deb Checksums-Sha256: bfe3f92f49ef52588872984496d7f001b954100b81cf24cfca1342ce40bdeae7 2120 bart_0.4.00-1.dsc d077bae8850b2b5b813f7afa3c3f08274bbbafb794e9f824af68047c43222c5d 335604 bart_0.4.00.orig.tar.gz 4bda7d7d63424a563fbd2687decac3e73f6193021ee269449e8d577ad9b611e6 3888 bart_0.4.00-1.debian.tar.xz 0c53e40117a4ad7521d7f605f6ea2d686e88f3c912993a0f3a70cce4330820ae 576314 bart-dbgsym_0.4.00-1_amd64.deb 305e5901c02dfb8b07edbacbb44db1831fe8dca422a50b59631a46e8b3384508 5729 bart_0.4.00-1_amd64.buildinfo f80611d723c7bff644c10a6042ee1423219538291ce7a064188f427b2e2a31f3 231482 bart_0.4.00-1_amd64.deb 24c934162a0f2e431ce963df01d56838d313d014d10435f1e64c45fba1a4c0a8 140780 libbart-dev_0.4.00-1_amd64.deb 1577c1cd6b96a89d8841377ad8757a029ffc00c521a683b104fba335e067641d 4016 octave-bart_0.4.00-1_all.deb Files: e531ad325e01d21a16796b189feca87b 2120 science optional bart_0.4.00-1.dsc 85abc8be087dd102748177b7737c3ba1 335604 science optional bart_0.4.00.orig.tar.gz 42baebadf48e80d2531b17dc82e86703 3888 science optional bart_0.4.00-1.debian.tar.xz 806e6e15c7bff32f02f3c141df2fc64d 576314 debug extra bart-dbgsym_0.4.00-1_amd64.deb a2c91f40436d7d6ed87c11eccbc2a018 5729 science optional bart_0.4.00-1_amd64.buildinfo 5cca08d7e6e5965a4f3cb2f1a5f65452 231482 science optional bart_0.4.00-1_amd64.deb d7bc694e47d1a53fdf091677bff1ac77 140780 libdevel optional libbart-dev_0.4.00-1_amd64.deb e02d09a5b857604acec0b329517a5344 4016 science optional octave-bart_0.4.00-1_all.deb -BEGIN PGP SIGNATURE- iQJFBAEBCAAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAlh6nsERHHRpbGxlQGRl Ymlhbi5vcmcACgkQV4oElNHGRtHxZhAAmNs927cHIuSq96RE0ywsppbYrfXjbHRI 55nRNt/GYsB9lCEJq+1TrNU/bGPzhzLxLgg2NzZd/hHmuq4Zl3oMuala9JPPv7MP XKY9kz+KkQ3sMMEy0KSdE2qDCQnSIIwgtVKIZhfktt9L4OPgiPfDZyiaiZB02Va5 xSb2rmDGrPAcAsflOkHsu1dhqT265QHhvfBPkPopa+6Z6pra7u3DCjI5bmfBdmkR qsmrHXWCk43zb6nxHtxyBN+I1Wjqgqsu1f9QwB9Vv5cVC43X/MmI5Wq9bcT2blsz aDJj5wYCuKZycuFoPwA18W9vFAKMVOqK+JVfEW9V2mtTqcPCXm/30IpnirtPHEO3 y12uBdBou+DwI5s10loYWI/PxuEXsgxV8/dySypt+Z8cbjExe4bqcFE8Rj6jrAJi P4aYgpjSnUykdtY3vQlOk4HQ9WbR6sLQDggPUb8jIl+TlEJVHbNg42YzA/PvIWc3 GMy12QMS46sBQNBd48ovMvEo2kGDmQrcHWwRz3OIXlCvc5slgEpjX+y0MDDCtGj4 F1dfZZ5G3pNuGLX1G4phkUnil43GBeM0WUEeUntTKJuLlWSC2lnmJLfMuRSFt/oo jV4pl3Co7ysm8ySkfEl3maa3abd3WY76nT+bBbfyU9s1qD9W+tWqLqmsJdFKyiw0 yo+ePinhJac= =qTkD -END PGP SIGNATURE-
Bug#851431: ITP: bart-view -- Image viewer for multi-dimensional data (add-on to BART)
Package: wnpp Severity: wishlist Owner: Martin Uecker <martin.uec...@med.uni-goettingen.de> * Package name: bart-view Version : 0.0.01 Upstream Author : Martin Uecker <martin.uec...@med.uni-goettingen.de> * URL : https://github.com/mrirecon/view/ * License : BSD Programming Lang: C Description : Image viewer for multi-dimensional data (add-on to BART) This is a viewer for multi-dimensional complex-valued data. It is useful as an add-on to the Berkeley Advanced Reconstruction Toolbox (BART) for computational Magnetic Resonance Imaging which has been packaged for Debian already. This package will be maintained as part of the Debian Med team.
Accepted bart 0.3.00-1 (source amd64 all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 09 Feb 2016 23:42:36 +0100 Source: bart Binary: bart libbart-dev octave-bart Architecture: source amd64 all Version: 0.3.00-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team <debian-med-packag...@lists.alioth.debian.org> Changed-By: Martin Uecker <martin.uec...@med.uni-goettingen.de> Description: bart - tools for computational magnetic resonance imaging libbart-dev - Development files for BART octave-bart - Octave bindings for BART Closes: 806762 Changes: bart (0.3.00-1) unstable; urgency=medium . * Initial release. (Closes: #806762) Checksums-Sha1: 0b9e621a0cf2376a86fab87960a90f2c2505f536 2064 bart_0.3.00-1.dsc b34fbf39358011ebb44647ed6e3b291ad0835af8 280405 bart_0.3.00.orig.tar.gz 7ceda70f6c70838d0c97d2c92cfe3515c665227e 3524 bart_0.3.00-1.debian.tar.xz 4fbcb00be6259832740474b808ccfcddce20a7bc 521614 bart-dbgsym_0.3.00-1_amd64.deb 69c134ca6caaf75276a04f4df7122ebee1a2d471 185218 bart_0.3.00-1_amd64.deb 0081670bc4822d787b157452e205105793d68398 119714 libbart-dev_0.3.00-1_amd64.deb 390dd45d9ccf33a357e07d6d16a335dcc367207b 3866 octave-bart_0.3.00-1_all.deb Checksums-Sha256: 0967c98ccef8278cb6a45598e2671d3093d45cc5d888ed2f37d7069b2696e3b9 2064 bart_0.3.00-1.dsc 5f0d65ab059f70be42015e544a0e37aaf7564c19048d70ebc6afab115a9dc196 280405 bart_0.3.00.orig.tar.gz 2378bdb14c9d289a05c17330849ca10c79c002f90b46f85fab31ed7ec710a43f 3524 bart_0.3.00-1.debian.tar.xz 1d58e9bb6c92dbc0714a9da6d6af0cdf82b0f41ed52e9dda546b5242024fb25c 521614 bart-dbgsym_0.3.00-1_amd64.deb a4290a26bce4bf58353f6e0f7fd730c39135cb80cb859f6efbc8e9c3dc4b83a2 185218 bart_0.3.00-1_amd64.deb b7d8a9d9873152b60a40e0b60fce8fed4430792bba147a97ffeb295fa1de4e4c 119714 libbart-dev_0.3.00-1_amd64.deb 405cf19344cbe122c0872935f4a35a558ea4d121b4ae58a92e97d7c9df6d8840 3866 octave-bart_0.3.00-1_all.deb Files: aea0e850ff51b67284d6df50136d66a0 2064 science optional bart_0.3.00-1.dsc 1e2d385ff1bdfa5289de87aace0d5bdf 280405 science optional bart_0.3.00.orig.tar.gz a94a42c4a5328645c7a7652566e10776 3524 science optional bart_0.3.00-1.debian.tar.xz 05bfbc331e12d36743acd2eaa60b5c4e 521614 debug extra bart-dbgsym_0.3.00-1_amd64.deb a9916d457f2fee67ef52d33020c9005c 185218 science optional bart_0.3.00-1_amd64.deb 8be511a1ced625b754c575727ce523f2 119714 libdevel optional libbart-dev_0.3.00-1_amd64.deb fef89e9c241f61c66cd52699e4c5bf01 3866 science optional octave-bart_0.3.00-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJW0huhAAoJEM6uatOv6Cb7QD0QAI/qBHSVN3xojBaZu2b59YYI mNysVS3vUPohhexjBeHLIM7sHf2CAev9lOa/Uv4js9WlRrute0FTa7F7H9KTXZyp AA16HDMB9vLvi8Wd/or1jFXA4F5UZ+3BdBYRljaBtbgoWfUImmpVURYb9lw/rtQ9 14MUk8UsBeGU5Md+97aA7qaDVvlJ+MBqRNSlH4mrEfb8k8ejOVIhv7ItaAr5Bb7o LbCaPgwFmgYdH56FH35leRUkZ6xjAjpf60nlFOS8e5Fq+DMHOPKvE/sFTfxxAJ/U mpRxDcF+ziENaDrwlGK36ma34riC7hPhf4J20XYNmk6ColFzbmoXWPcVPQ9UZ41S ob7k/AQGsr1h4sg9adkgF73Lr5RjS/MTOHyV4xmDADLAX9xXSb+sX7phuoCAlBRi x9sVmUpdqyNch9FiEo2ykTIBmafkCz5qe+qQ/vGmJZLYxLWWwN2mpIVLaPjtUTrN ZaVTKCgkSEj1GSlSv8qmFU0xmFMyblLIga4lVvzj/5KpCVk185EagihFMEWqDd2n TmIxkNfLloSlCehGzMwC5JfKGTO57BlXO3+zS6hJExbzHqcvFlwI47X2Dz731+x5 kn9KARyAmiCrCH2fQMFG/Ok6K4Tu4KtRdwDlRsmX72jCqBlUUGY+FEgd+rlDLYU1 Eo6Me/41J5y4ZYmA62fj =2nWm -END PGP SIGNATURE-
Re: Bug#762839: bash without importing shell functions from the environment
Samuel Thibault: Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit : Samuel Thibault: Sounds crazy to me. Definitely. This is now out in the wild; exploits which simply replace echo or cat-without-/bin are going to happen. :-/ That's not so easy to exploit. You have to manage to inject those precise variable names. While everybody is looking at bash, isn't this the real the injection part? Why are there still programs which copy stuff from the network into environment without proper sanitation? This bash bug makes this easy to exploit, but it is not hard to imagine that this can confuse other programs in different ways. In fact, there were very similar bugs in the past: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0997 Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925182221.4ff545d1@lemur
Re: Re: Bug#762839: bash without importing shell functions from the environment
Russ Allbery r...@debian.org: Martin Uecker uec...@eecs.berkeley.edu writes: While everybody is looking at bash, isn't this the real the injection part? Why are there still programs which copy stuff from the network into environment without proper sanitation? The previous sanitization for environment variables mostly focused on not letting the client set arbitrary environment variables and instead tightly restricting which variables could be set. The problem with this vulnerability is that the varible doesn't matter, only the value, which is a new type of problem. See the link I posted. This was about shell escaping and fixed with sanitization of the content in dhclient. But for some reason it seems it was not applied to all variables, which would have prevented the present problem for dhcp. Also, prior to the discovery of this bug, I'm dubious that anyone would have found this particular environment variable pattern all that concerning. It's not obvious why it would be an issue. So only a pure whitelisting approach on environment variable *contents* would have been effective, and it's hard to define what language you want to restrict the contents to. Yes, it is a bit difficult to decide what is acceptable and what not. But environment variables are a huge attack surface because they are passed on and you have to garantuee that no child process does something stupid. E.g. some process may dump its complete environment into a log file and have a buffer overrun there... Does not seem unlikely to me. It's very useful in some web situations to get access to arbitrary client data via environment variables. I sometimes want *exactly* what the client sent as its Browser string, for instance, metacharacters and all. I should be able to get that as an environment variable and process it; there's no obvious reason to believe that should be unsafe. I would say it is problematic because it is not contained but ends up in a lot of places, i.e. all child processes. One could at least encode special characters etc... I think assuming the mere contents of an environment variable restricted to a namespace like HTTP_* and kept well away from, say, LD_* would not be interpreted as executable code is pretty reasonable. Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925194743.52fbc006@lemur
Re: ssl security desaster
Tollef Fog Heen wrote: * Martin Uecker [...] | There was a thread building packages with exact binary matches | about it. Unfortunately, most people seem to think that this is not | worth it. I don't think that's unfortunate; I think it's a waste of resources better spent elsewhere. If somebody hacks into a DD's machine, the obvious thing for an attacker to do is to trojan a Debian package. I wonder how long it would take to find out... Maybe it did already happen, who knows? | I believe that postinsts need the flexibility shell (or perl or | python or whatever) gives them. If you want to restrict postinsts | to only be able to do a limited set of operations, the quality of | packages will detoriate quite a bit as they are no longer flexible | enough to cater for all packages's needs. In fact, I think the opposite would be the case: The quality of Debian would rise, because there would be the need to establish standard interfaces for all reasonable cases where packages have to mess with the system during installation. Compare this with running windows applications without system privileges. You could argue as above, that the quality of those programs will detoriate, because applications are no longer flexible to cater for all applications's need. So where is the difference? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Tollef Fog Heen wrote: * Martin Uecker | Another problem I have argued about before, not directly related to this | incident, but IMHO another desaster waiting to happen: There is no | way to independetly validate that a debian binary package was | created from the corresponding source. How would you go about doing that? If you just mean «all packages should be built on the buildds», that's fairly easy to do, but if you are talking about actual verification of source = binary which can be done post-mortem, that's much harder. Actually, it's not that hard. If you build a package in a controlled environment, you get something which is in most cases already very reproducable. For many packages there are only a few time stamps which somehow end up in the built that make it non-reproducable. Since these time stamps are not really usefull anyway they could simply be removed. There was a thread building packages with exact binary matches about it. Unfortunately, most people seem to think that this is not worth it. | What bothers me too is the fact that the installer scripts of all | packages have root permissions during installation. While this might | be hard to do, in principle I see no good reason why installer | scripts could not be limited to certain tasks. I believe that postinsts need the flexibility shell (or perl or python or whatever) gives them. If you want to restrict postinsts to only be able to do a limited set of operations, the quality of packages will detoriate quite a bit as they are no longer flexible enough to cater for all packages's needs. A lot of packages have very simple scripts often only updating some kind of index after installation which could be done with triggers. In these cases, the scripts could possibly removed completely. Checking that the package does not overwrite files from other packages and installs files only to certain directories would then limit the security risks from installing the package to the users of a system which actually do use the software. In other cases, it might be possible to lock the scripts down with selinux, as Manoj pointed out in the thread mentioned above. Regards, Martin signature.asc Description: Digital signature
Re: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Kevin B. McCarty [EMAIL PROTECTED] wrote: If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of drop XXX patch, applied upstream. This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy? Speaking only for myself, let me comment on some extensive patching. I guess that some of my physics-related packages (cernlib, paw) are among the more heavily patched in Debian. Unfortunately upstream is dead, so there is *no way* to see the patches incorporated there. As other have already pointed out: In this case, it should be considered a fork. And even before they gave up the ghost, they were very conservative, refusing to consider most patches more complicated than trivial changes to fix complete breakage. Open source development does work well only if splitting up the development in different branches or even forks is strongly avoided and done only if it is strictly necessary. IMHO the Debian way of doing things makes it far too easy for package maintainers to diverge from the upstream source. I can't really comment on the examples you have provided, but in general, I feel that Debian has not found the right balance here. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
extensive patching
[EMAIL PROTECTED] wrote: I disagree. The cause of the disaster was not that Debian does its own patching, but the fact that that patch was buggy. Buggy patches happen all the time. The question is, how could something as bad as this slip through? And one important reason is IMHO, that splitting up the development/bug fixing/review by creating different software branches is bad. On the whole I think that Debian benefits a lot from custom patches, and in fact many packages would be severely buggy and/or wouldn't integrate properly with the rest of the system without them. It's not a secret that many projects benefit from Debian patches, so there might be something good with them. Clearly, Debian adds value by its patches. If those patches would be integrated upstream, then the whole free software community would benefit. Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. I would prefer if only security fixes and bugs which might cause data loss would fixed directly in Debian. Everything else should go upstream first. Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. Did you look at the code? This was not exactly a deeply hidden flaw in some obscure looking code. Upstream didn't see the patch. That's exactly the problem. And I doubt that there was any review of this code in all this 2 years. I think that defending the position of using pristine upstream source code are just a conservative position to guarantee that we can blame upstream or someone else if something like this happens again, not that bugs won't happen. Only those who don't do anything don't make mistakes. The point is to try to avoid mistakes, not to be able to blame upstream. I do not think this is true. The criticism comes partly from the outside (for example from me), so this is clearly not motivated in the way you suggest. And I do not blame the developer for his mistake. I blame the processes. Of course, the development and checking of the patches should be done as cooperatively with upstream as possible, as upstream might see something we're not seeing, but the way to the solution, in my opinion, is not to avoid patching but to develop a way to check them as extensively as possible. Checking something extensively is much easier if there is one canonical branch which everybody agrees on. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
martin f krafft [EMAIL PROTECTED] wrote: [2] And IMO we should go further than patches.d.o, we need to create a cross-distro infrastructure where we can share patches. We really have to show the way here... (we complained enough that ubuntu patches were unusable, surely we can show how to do it right when it comes to sharing patches with others and upstream) I am not convinced that more technological infrastructure is really the solution. Isn't simply the upstream source the right place for collaboration? IMHO the problem is not, that managing and reviewing patches in debian or sharing patches with other is distributions is too hard, but that it is *too easy* to introduce changes into Debian, removing all pressure for close cooperation with the upstream project. Regards, Martin signature.asc Description: Digital signature
Re: extensive patching
Barry deFreese wrote: [...] Buggy patches happen all the time. The question is, how could something as bad as this slip through? And one important reason is IMHO, that splitting up the development/bug fixing/review by creating different software branches is bad. Different software branches in what respect? Just by nature of having a distro package ? By having a large diff against the upstream source with changes unrelated to packaging. [...] Clearly, Debian adds value by its patches. If those patches would be integrated upstream, then the whole free software community would benefit. Which brings up at least two issues. Upstream not wanting the patches or dead upstream. Speaking from the games team alone I would bet that 50% or more of the packages have no upstream anymore. Should those packages be removed? If upstream is dead or unable to do his job well, somebody should fork the project (or take ownership). But this has nothing to do with packaging software and should in my opinion not be intermixed. Also, obviously, there are changes that make no sense to upstream that are strictly distro specific. Requiring distro specific changes feels wrong anyway. Software should be coupled by standardized interfaces. But I might be naive here. What are the distro specific changes we are talking about? Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. I think there should be a policy. I propose: I would prefer if only security fixes and bugs which might cause data loss would fixed directly in Debian. Everything else should go upstream first. Sounds good but again, what about unresponsive/dead upstreams. Do you leave your users to suffer ? Is Debian here to service the user community or not? Fork it. But not as part of the packaging work. Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. Did you look at the code? This was not exactly a deeply hidden flaw in some obscure looking code. Upstream didn't see the patch. That's exactly the problem. And I doubt that there was any review of this code in all this 2 years. I have seen links where upstream was asked about/notified of the patch so this isn't an entirely true statement. Egos play a big part in all of this as well. Upstream answered that it is okay too remove the seeding of the PRNG with uninitialized memory, but the concrete patch which additionally and erranously removed all seeding was never posted on openssl-dev. Regards, Martin signature.asc Description: Digital signature
Re: ssl security desaster
Hi Kevin! Kevin B. McCarty [EMAIL PROTECTED] wrote: Martin Uecker wrote: [...] Well, *assuming* the patch is good, a subset of users of the software (i.e. Debian users and users of downstream distributions) benefit from it between the time it's applied in Debian and the time it's applied upstream, and there are no major negatives that I can think of. But that assumption is what you really want to discuss, I guess. I think it is problematic even if the patch is good, because having different software branches fragments all kind of bug fixing/development and reviewing work, which could otherwise be shared upstream. As far as I know, Debian policy is silent about when to apply a patch or how to decide if it's good. If upstream is responsive, it might make sense to wait until someone from there reviews the patch and gives a thumbs-up or -down. That supposes it is clear how to get in touch with upstream, which I gather was one of the big mis-communications leading to the current state of affairs [1]. [1] http://advogato.org/person/branden/diary/5.html This might be part of the problem, but there was discussion with other upstream developers on openssl-dev. So the problem was not that there was no communication, but that the actual patch was not forwarded to the upstream developers. [..] As other have already pointed out: In this case, it should be considered a fork. It's really just an argument over semantics. I personally think of a real fork as one where someone purports to have taken over the role of upstream. You're welcome to have a different opinion (clearly you do). The XFree86 4.3.0 that Debian shipped with Sarge was also extremely heavily patched from the upstream version, but I don't believe most people thought of it as a real fork (unlike X.org). I guess you are right, it's not a fork, more like a branch. I could imagine that there are good reasons for having a Debian branch for something like X, but I don't think this is true for many packages. [...] At least for the example of my packages that I brought up, if I could not make an extensive set of patches, it is unlikely that the software could have met the policy and quality standards to be accepted into Debian. Whether it's better for Debian to ship heavily-patched software (that is still quite popular in the physics community) from a dead upstream, or not to ship it at all (forcing users to download it on their own from upstream's web site, then find and apply some set of patches grabbed from elsewhere on the web [2,3], then going through a baroque and obsolete build procedure [4]) is of course open for debate. You can guess that I hold the former of these opinions. Surely, this is very valuable work and I am not implying at all that you should stop it. But if upstream is dead, then their is no reason not to step in and simply take ownership of the package. Traditionally, if upstream was dead, somebody formally declared ownership of the software and took over development. I think this is the right thing to do, because then there is a new upstream where all other work can be shared. If upstream is incompetent, that somebody can step in and fork the software. Again, with a clear announcement. Then this step can be discussed openly and other users might switch over to the fork. Just integration all changes which are not accepted upstream as part of the packaging work just makes it too easy to diverge from upstream without good reason, without discussion and without an easy way for other users/distributions to see whats going on and to eventually switch over. One could certainly envision a distribution that used a Debian-like packaging infrastructure, but had a goal of trying to deviate from upstream's source code as little as possible. I think that such a distribution would either have serious QA problems (think for instance of embedded code copies, a security nightmare) or would be restricted to packaging a much smaller set of software than Debian does. YMMV. I don't now. I see no reason why all this good work which now ends up in Debian patches can't be seperated from the actual packaging work. Regards, Martin signature.asc Description: Digital signature
Re: extensive patching
Hi Michal! Martin Uecker [EMAIL PROTECTED] wrote: Upstream answered that it is okay too remove the seeding of the PRNG with uninitialized memory, but the concrete patch which additionally and erranously removed all seeding was never posted on openssl-dev. Are you sure? http://thread.gmane.org/gmane.comp.encryption.openssl.devel/10917 I don't see a patch there. This might sound like nitpicking, but a real patch would have provided some context to the two lines. Nevertheless, the right thing in my opinion would have been to propose a patch, wait until it is accepted, and then to package the new upstream version. Regards, Martin signature.asc Description: Digital signature
Re: extensive patching
On Fri, May 16, 2008 at 11:26:01AM -0700, Don Armstrong wrote: On Fri, 16 May 2008, Martin Uecker wrote: Requiring distro specific changes feels wrong anyway. Software should be coupled by standardized interfaces. But I might be naive here. What are the distro specific changes we are talking about? It'd be great[0] if we never had to do distribution specific changes.[1] However, considering the amount of software which is not LSB compliant, FHS compliant, policy compliant, ships internal libraries, has upstreams who don't understand API and ABIs, has slow release cycles, has insane upstreams, or otherwise includes bugs which need to be fixed, that'll only rarely be the case for some very simple packages. [...] 1: One could argue that if you can't come up with a relatively large list of distribution specific changes that need to be made yourself, you've not done the research to make useful suggestions for radically altering how Debian actually does development. Knowing the problem comes before the knowing answer. Because LBS, FHS, APIs and ABIs, slow release cycles, insane upstreams and bugs are Debian specific issues? I don't think so. signature.asc Description: Digital signature
ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Steinar H. Gunderson [EMAIL PROTECTED]: On Thu, May 15, 2008 at 05:11:27AM +0200, Goswin von Brederlow wrote: Also if you have 2 messages signed with the same random number you can compute the secret key. It is more complicated then this but simplified boils down to is computing k given (k + r) * Message1 == Signature1 and (k + r) * Message2 == Signature2. For the details, since everyone doesn't read Planet Debian: http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths /* Steinar */ If I understand this correctly, this means that not only should keys generated with the broken ssl lib be considered compromised, but all keys which were potentially used to create DSA signatures by those broken libs. In this case, the security advisory should clearly be updated. And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. I also wonder, what will the Debian community change in their processes to make such a security desaster less likely in the future? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Am Donnerstag, den 15.05.2008, 15:20 +0200 schrieb Thijs Kinkhorst: On Thursday 15 May 2008 14:04, Martin Uecker wrote: If I understand this correctly, this means that not only should keys generated with the broken ssl lib be considered compromised, but all keys which were potentially used to create DSA signatures by those broken libs. In this case, the security advisory should clearly be updated. The original advisory has this text: Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation. I read there exactly the thing you describe above. What is your suggestion? I missed this, sorry. The advisory for ssh does not include this information. Is this not relevant for ssh for some reason? To be clear, I have been quite impressed by the professional reaction to this (and other) security problems. But it still would like to see some more information here. (Which might already be in the works.) And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. The reasoning above does not go for the more common RSA keys, so this advice would not be appropriate I think. Ok. I also wonder, what will the Debian community change in their processes to make such a security desaster less likely in the future? You mean less likely than once in 15 years? We're open to your suggestions. Something as bad as this might be rare, still, if something can be improved, it should. Upstream complained about the extensive Debian patching. I think this is a valid criticism. For security sensitive packages, requiring changes to be signed-off by a second person might be a good idea too. Another problem I have argued about before, not directly related to this incident, but IMHO another desaster waiting to happen: There is no way to independetly validate that a debian binary package was created from the corresponding source. What bothers me too is the fact that the installer scripts of all packages have root permissions during installation. While this might be hard to do, in principle I see no good reason why installer scripts could not be limited to certain tasks. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Am Donnerstag, den 15.05.2008, 17:33 +0200 schrieb Thijs Kinkhorst: On Thursday 15 May 2008 16:47, Martin Uecker wrote: You mean less likely than once in 15 years? We're open to your suggestions. Something as bad as this might be rare, still, if something can be improved, it should. Upstream complained about the extensive Debian patching. I think this is a valid criticism. Of course things can be improved, probably always. I don't think that just one incident means that nothing must be changed, but I also contest that this incident in and of itself requires changes to be made. One incident just doesn't tell us much about the quality of Debian patches in general, either way. I don't question the quality of Debian patches in general. But I still think that something can be learned from this single incident. The security advantage of open source software is said to be: Many Eyes Make All Bugs Shallow! This of course can not work if every distribution basically creates its own branch. That's also what I dislike in Ben Laurie's blog post: he bases his conclusion on just this thing that indeed went horribly wrong, but is far from examplary for all patching that Debian, or distributions in general, do. I don't think he realises that far from all upstreams are as ideal as he seems to think. I am missing some self-criticism too. The use of uninitialized memory should have been fixed upstream long ago. (And this is *not* a rare case where the use of uninitialized memory is ok.) I welcome change and review of our processes, but taking one extreme incident as the base on which to draw conclusions seems not the wise thing to do. Why not? A plane crash is a very rare incident. Still every single crash is investigated to make recommendations for their future avoidance. If you're interested in for example changing the level to which software is patched in Debian, I suggest to start with a representative review of what gets patched and why it's done. That would give more base to see whether the extensive patching is indeed excessive. I do not have time to do statistics, but from looking at a lot of packages over the years I know that their a many changes in Debian packages which are not related to packaging. Besides security fixes or other really important fixes which have to go in very fast, I do not see no reason for all this Debian specific changes. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Fri, Sep 28, 2007 at 09:18:12PM -0500, Manoj Srivastava wrote: On Fri, 28 Sep 2007 23:04:00 +0200, Martin Uecker [EMAIL PROTECTED] said: There is some other thing I do not like about the way Debian packages work. Every package I install can actually completely compromise my system, because the maintainer scripts are run as root. You can, of course, run a strict mode SELinux system, and see that the apt_t security domain is sufficiently confined for your tastes (you may have a local security policy that tightens down the default project wide constraints, to the level you heart desires). That would be an option. But it is exactly like the problem with windows applications: Since the applications are used to having the privileges, it is much harder to lock them down. Martin
Re: Building packages with exact binary matches
On Thu, Sep 27, 2007 at 06:31:58PM -0500, Manoj Srivastava wrote: On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker [EMAIL PROTECTED] said: [...] But recompiling from what? If you do not get the exact same source, you have no hope of getting the same result. I had the impression that Debian distributes the source code from which the binaries are actually compiled and not some random variation. Yup, complete with all the trojans in the binary and all. You are seriously stating that is as easy to hide a trojan in the source code as in the binary? I have seen a lot trojans hiding in binaries but I have never seen that an open source project distributed trojaned source code. Maybe they where such incidents but there are certainly rare. And the way things work, the chances are that if the binary is tainted, the source would be tainted -- and you have got nowhere. If I wanted to hide a trojan somewhere I would to it in the binary and not in the source code. People actually look into source code on a regular basis but they seldom disassemble a binary. The window of opportunity is small. You have to replace the binary .deb in between the time it was built, and it was signed. That's a small window if you measure the time but it is not small window of opportunity. If the building host is compromised than it is trivial. And it seems that DDs do upload binaries which are compiled on their local machines. So it is actually enough if any of those machines is compromised. [..] So, someone replaces the binary compiled on the buildd with a fake one, in between the binary being built and it being signed? All the work to get bit-for-bit reproducibility for such a low priority attack vector? I do not think it is a low priority attack vector. If I would be a cracker and had a rootkit installed on a debian build host it would certainly insert a backdoor in ssh everytime it is compiled: Access to all debian running computers world wide! Compromise gcc? I see. So, fro all you know, every copy of gcc in the world now has the compile trojan into ssh built in, and again, no way for people peering at bits to see if there is a trojan buried in there to find out. Why all copies of gcc? A single copy of a gcc on a single host where official debian packages are compiled. And the gcc binary on the disc is unmodified: The compiler is patched after loading it in the memory by a rootkit. Not that a single binary copy of gcc was ever completely dissassembled and checked for trojans. That would probably take at least a year to do. BTW I did some tests and for 'dpkg' the only files which change between builds are the manpages and that's just because gzip stores the date of the orginal in the compressed file. This is one of the things, yes. ANy package with a tar archive would suffer similarly. That all files which are created by the actualy build process are already bit-identical (for dpkg) and only a postprocessing step adds time stamps is very promising, I think. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Fri, Sep 28, 2007 at 09:05:59AM -0700, Don Armstrong wrote: On Fri, 28 Sep 2007, Martin Uecker wrote: You are seriously stating that is as easy to hide a trojan in the source code as in the binary? Consider the fact that we've already had such a case,[1] whereas we've not (to my knowledge) distributed a trojaned binary. I'm not sure which is easier to hide, but it seems that making a source trojan is at least more frequent if not easier to create. I would not call this a trojan. But I guess I have to change my opinion anyway. Manoj is right: Trojaned upstream sources are a major security risk, against which exact binary matches do not help. But I still think they would still eliminate a lot of other risks, which should IMHO not be ignored. There is some other thing I do not like about the way Debian packages work. Every package I install can actually completely compromise my system, because the maintainer scripts are run as root. It would be nice if normal packages would not be allowed to have maintainer scripts and would only be allowed to install binaries in certain paths. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
Ben Finney [EMAIL PROTECTED] wrote: Martin Uecker [EMAIL PROTECTED] writes: On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Really? I trust the theory of special relativity because there is enormous evidence supporting it, and little evidence against it. There is enormous evidence for the Aristotle' believe that more massive objects fall faster and little evidence against it. Only a carefully crafted experiment shows that it is false. In the case of there are no messages, therefore I trust the security of the system, that's faith â belief in spite of an utter lack of evidence. The predictions must be testable by everbody and - of course - some must actually try to falsify them. Exact binary matches would allow everbody to check the integrity of the binary packages and I am quite sure that some people would do it. In this case no messages stating that something is wrong is not the same as lack of evidence, it is actually evidence for the assumption that everything is ok. Do you think this is blissfull ignorance, too? Worse, it's foolish. It is foolish to base his trust purely on the authority of some person. People's belief that massive objects fall faster was based on the authority of Aristotle. Debian user's trust in the integrity of some binary package is based on the authority of the person putting a gpg signature on it. In the lack of *any* evidence either way on a question, it's foolish to hold any position but unknown; That is a common misbelief. Some things are inherently more probable than other. and, if the question is important for a matter of trust, it's imperative to *get* some evidence before extending any trust. That is certainly true. Martin
Re: Building packages with exact binary matches
On Thu, Sep 27, 2007 at 02:26:49AM -0500, Manoj Srivastava wrote: On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker [EMAIL PROTECTED] said: On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote: Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. It is not about hearsay. It is about finding an error in a predictation. And I do not care *who* finds the error. Of course the predications have actually be checked. So you are right with your argument, if nobody actually does this, it would be ignorant to believe in a scientifc theory for the sole reason that nobody complains. Similar, if nobody recompiles the packages and checks for mismatches, then silence would in fact not imply that things are ok. But I question your premise: I have no doubt that some people would actually recompile packages and compare the hash. Even if it is not done normally, somebody would do this if doubts come up for some reason (e.g. some debian hosts are compromised again.). This alone would actually be worth a lot. But recompiling from what? If you do not get the exact same source, you have no hope of getting the same result. I had the impression that Debian distributes the source code from which the binaries are actually compiled and not some random variation. And the way things work, the chances are that if the binary is tainted, the source would be tainted -- and you have got nowhere. If I wanted to hide a trojan somewhere I would to it in the binary and not in the source code. People actually look into source code on a regular basis but they seldom disassemble a binary. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. If know that the source code wich has hash 4457575757575 compiled in the build environment with hash 4837373737 gives a package with hash 366336363, then it is actually *evidence* that something is seriously wrong if you end up with a package with a different hash. So, someone replaces the binary compiled on the buildd with a fake one, in between the binary being built and it being signed? All the work to get bit-for-bit reproducibility for such a low priority attack vector? I do not think it is a low priority attack vector. If I would be a cracker and had a rootkit installed on a debian build host it would certainly insert a backdoor in ssh everytime it is compiled: Access to all debian running computers world wide! BTW I did some tests and for 'dpkg' the only files which change between builds are the manpages and that's just because gzip stores the date of the orginal in the compressed file. Martin
Re: Building packages with exact binary matches
On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote: On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker [EMAIL PROTECTED] said: [...] No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? Actually, partly. I am a quantum mechanic by training (I just went sideways into computer because there was so little money in devoce modeling). I like the special relativity because the math is sound; it has predicted things we were not aware of before; and all kinds of experimental data matches the theory -- except when you get to very very small dimensions, but people are still working on that. I am a mathematical phycicist by training: There are no known problems with the SRT at the small scale. But you are right with your other point: The math of a scientific theory has to be sound. But it has to be related to reality, too. It is the last part we are talking about. Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. It is not about hearsay. It is about finding an error in a predictation. And I do not care *who* finds the error. Of course the predications have actually be checked. So you are right with your argument, if nobody actually does this, it would be ignorant to believe in a scientifc theory for the sole reason that nobody complains. Similar, if nobody recompiles the packages and checks for mismatches, then silence would in fact not imply that things are ok. But I question your premise: I have no doubt that some people would actually recompile packages and compare the hash. Even if it is not done normally, somebody would do this if doubts come up for some reason (e.g. some debian hosts are compromised again.). This alone would actually be worth a lot. [...] So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Really? What was the last time anyone looked through libsepol library code, eh? Or libselinux code? You do know dpkg and coreutils are linked to that? I would assume that there are people hacking on this code or at least somebody fixes a bug in it occasionally. I know I looked at the source code of libselinux once (but not closely). If in fact some code is never looked at, then it is propably a really bad idea to include it in critical packages. All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? No, the bug reporter goes and presents _evidence_ that can be checked, and a patch, or a source of the problem. No one jumps up and down and issue CVE's just become someone says things are not ok. And no one makes a security ssue go away if bunches of people rise up and say the code is juuust fiiine. I never claimed that I believe random people just saying things are ok or not ok. A binary mismatch is *evidence*. So if some random people come up with such evidence, then I can check it myself. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. If know that the source code wich has hash 4457575757575 compiled in the build environment with hash 4837373737 gives a package with hash 366336363, then it is actually *evidence* that something is seriously wrong if you end up with a package with a different hash. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. If you do not know who the signatories of the archive key are, I suggest you leanr, and see how the web of trust thing works for you, and whether or not you can trust the guy doing the builds. Nothing is bullet proof. And no one can make anyone trust anyone, including themselves. Like all security ractices, it is a tradeoff. I have decided to trust my fellow DD's, and to trust
Re: Building packages with exact binary matches
On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. Martin
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 01:03:27AM +0100, Benjamin A'Lee wrote: On Tue, Sep 25, 2007 at 12:04:15AM +0200, Martin Uecker wrote: Manoj Srivastava [EMAIL PROTECTED] wrote: Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Erm, if I can't trust the Debian Project to create trustworthy packages and verify their integrity, why should I trust anyone else to verify them? No, I trust that somebody would *falsify* them if there are compromised. See my reply to Manoj for an explanation. [...] You're also assuming that the source code is trustworthy. If the binary packages can be compromised, so can the source packages. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Martin
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Everyone does that now based on debian archive signatures. You do not need bit-by-bit verification for that. Again: How does this protect against a compromised build host? So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Ah. again, assume security until someone pulls us out of our ignorance. See above. So easy to do a denial of service attack by random slander of binaries and source (thanks, helpful botnet). All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. I kinda find your alternate shceme, based on bit-for-bit sameness, not to be all that secure, really. It is a feel good thing with little added secueity. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. However, this is all moot; unless someone does all the work to make things absolutely bit-for-bit the same, compile after compile, and manages to convince all the package ownsers to accept the changes, this is going nowhere. I am not even sure it can be done, technically. You are right: Currently, this is all moot. But I find this discussion very interesting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
Manoj Srivastava [EMAIL PROTECTED] wrote: On Mon, 24 Sep 2007 04:56:45 +0200, Martin Uecker [EMAIL PROTECTED] said: If policy would require the exact reproducability of binaries, then it would be a policy violation. That is not how things work around here. In a case like this, policy will _follow_ most packages being bit-for-bit identical, and can't be used as a stick to beat people on the head with. Ok. I do not see how this helps. Imagine a build host is compromised and this is noticed only after a few weeks. Theoretically every machine which downloaded and installed a package in this time could be compromised. And even worse: it is practically impossible to find out wether a package is actually affected! Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages three times in a row
On Mon, Sep 24, 2007 at 08:35:50PM +0200, Goswin von Brederlow wrote: Martin Uecker [EMAIL PROTECTED] writes: I think it would be really cool if the Debian policy required that packages could be rebuild bit-identical from source. At the moment, it is impossible to independly verify the integricity of binary packages. Greetings, Martin Some tools use randomization to get out of worst case situations or general optimization. For example when you look for an optimal allocation of register usage you can do a search by picking a random register allocation and repeat that a few thousand times to find a suitable minimum. Or a randomized heap that gives you O(1) time for all operations instead of O(lg n). I do not know of any compiler which does register allocation like that. This would be a debugging nightmare! By requiring bit-to-bit identical results you eliminate all such randomness and could seriously hinder the algorithm available for tools. Such algorithms would certainly use a pseudo-random number generator which could be seeded identically in each build. Do you actually know about any tool wich produces different output each time because of the use of a randomized algorithm? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages three times in a row
Patrick Winnertz wrote: Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau: Hmmhh, what do you do about programs etc that encode the build-time in the binary? I mean they obviously will change between builds? Hopefully they don't encode the build-time in the file list? We checked not for files which differ, but only for files which are missing in the first package. or which are missing in the second package. I think it would be really cool if the Debian policy required that packages could be rebuild bit-identical from source. At the moment, it is impossible to independly verify the integricity of binary packages. Greetings, Martin signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Building packages three times in a row
Neil Williams [EMAIL PROTECTED]: Martin Uecker [EMAIL PROTECTED] wrote: [...] I think it would be really cool if the Debian policy required that packages could be rebuild bit-identical from source. At the moment, it is impossible to independly verify the integricity of binary packages. This has been covered before - certain upstream macros are among many factors that ensure that this is unlikely. I, for one, use such macros upstream to indicate the build time of the actual executable installed so this will change the binary every time it is built. This could be fixed. You have md5sums and GnuPG signatures on the Release files - I see no benefit from bit-matching. The build host could be compromised. Not that unlikely. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
Joey Hess [EMAIL PROTECTED]: Joerg Jaspert wrote: On 11150 March 1977, Peter Eckersley wrote: I've seen reports from very large sites indicating that User-Agent strings are almost as useful as cookies for tracking their users. I cant believe this. Looking at the stats from packages.debian.org - U-A is the worst possible way to track users. Would be totally dumb to try something with U-A: Surely packages.debian.org is not a good example of a site with generally few Debian users. Anyway, you would combine User-Agent with other clues. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages three times in a row
Benjamin A'Lee [EMAIL PROTECTED]: On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote: Neil Williams [EMAIL PROTECTED]: This has been covered before - certain upstream macros are among many factors that ensure that this is unlikely. I, for one, use such macros upstream to indicate the build time of the actual executable installed so this will change the binary every time it is built. This could be fixed. In every binary that includes the build date in it? There's rather a lot; off the top of my head, Vim does it, and so does the Linux kernel AFAIK. I know. In a world where providing a correctly working clean target is already an issue, that's pretty far fetched. But IMHO being able to recreate binaries from source code in a reproducable way would be a milestone for security and QA. You have md5sums and GnuPG signatures on the Release files - I see no benefit from bit-matching. The build host could be compromised. Not that unlikely. And if the build host was compromised, how would that help any more than md5sums and gpg-signing? With access to the build host, whatever list of bits to match could be changed along with the binary, the md5sum, and the gpg-signature. Anyway, surely the point of hashes like md5, sha1, etc, is that it's much faster to do that than to compare large files bit by bit? The idea is not to replace hashes by bit-by-bit comparison, but to be able to *independendly* reproduce binaries from source code in a bit-identical way. Then third parties can recreate the binaries and publish recreated hashes. If the recreated hashes are identical then you can be sure that nobody has tempered with the build process and the binary is actually created from the unmodified sources. The current scheme just protects against tempering after signing. That is actually not very much. Martin
Re: Building packages with exact binary matches
On Mon, 24 Sep 2007 00:54:58 +0200 Martin Uecker [EMAIL PROTECTED] wrote: Neil Williams [EMAIL PROTECTED]: This has been covered before - certain upstream macros are among many factors that ensure that this is unlikely. I, for one, use such macros upstream to indicate the build time of the actual executable installed so this will change the binary every time it is built. ac This could be fixed. Fixed?? What the? You're asserting that this is a PROBLEM to be fixed? If policy would require the exact reproducability of binaries, then it would be a policy violation. It's good, it's useful, it's helpful. I'm confused, what is wrong with that? :-( I do not see how a date stamp in a binary is really usefull. Often it is just used as a cheap replacement of fine grained versioning information. But I do not think that's a good reason. The date on which a binary is built is actually completely irrelevant from a technical point of view. What's really usefull is the exact version of the source code and the build tools. Everything else should not matter at all! IMNSHO, this is not a bug, there is no good reason to prevent upstream from using such macros Ofcourse there is: reproducability and besides, there are other upstream processes that modify the built binaries every time the build proceeds. Think Latex and various other generation tools. These could be fixed too ;-) Also, any build process generates files that contain different references and linked objects - if a package hasn't been built for a while (no new uploads), what on earth is wrong with that not being a binary-match for a package that was built yesterday against updated libraries? See also this thread: http://lists.debian.org/debian-devel/2007/07/msg00588.html and http://lists.debian.org/debian-devel/2007/06/msg01076.html If the dependencies change between builds, so will the binary. That's an different issue. I am not complaing about the fact that binaries can change without source code changes, but that it is impossible to create an identical package even when you try. You have md5sums and GnuPG signatures on the Release files - I see no benefit from bit-matching. The build host could be compromised. Not that unlikely. That's why the autobuild process is not entirely automated. A real DD needs to sign off the ported packages. I do not see how this helps. Imagine a build host is compromised and this is noticed only after a few weeks. Theoretically every machine which downloaded and installed a package in this time could be compromised. And even worse: it is practically impossible to find out wether a package is actually affected! Martin
Re: Migrating to GPG - A mini-HOWTO
On Wed, Sep 15, 1999 at 01:19:34PM +0200, Paul Slootman wrote: [...] With dinstall a compromise is short lived and can be undone by erasing the effected package. Creating a new key and getting people to sign it cannot really be undone. How do you prove to whoever is able to erase the package that you are who you say you are? I.e. how do you convince them that they should in fact erase the package? With your old compromised key. Martin -- Not that I have anything much against redundancy. But I said that already. -- Larry Wall in [EMAIL PROTECTED]
