RE:About a mass bug report not based on Sid or Jessie.
> It may be that libgc upstream's autogen.sh script is not really 'right' in > some way. But there may well be a lot of upstreams like that, which is > why maintainers need clear guidance on how to deal with this, without > having to become autotools experts. i.e how to determine when they can > just run dh_autoreconf and when they need to do something more > involved. for example in my package hkl (I am also the upstream), the autogen.sh also run gtkdocize #!/bin/sh test -d m4 || mkdir m4 gtkdocize || exit 1 autoreconf -ivf -- 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/a2a20ec3b8560d408356cac2fc148e53b1e6e...@sun-dag3.synchrotron-soleil.fr
Re: debconf reconfiguration from postinst of another package
]] Jonas Smedegaard > How to reconfigure one package from another? I don't think this is supported today at all, and any success at doing so would be a bug. If you have a package that uses debconf as the UI to ask questions that go into a configuration file, that's fine. If you then later change the values in the debconf database and run dpkg-reconfigure, the config script should grab the current settings from the configuration file on disk and seed the debconf db with those, overwriting your changes. This is the whole «debconf is not a registry» thing. What you could do is provide your own debconf database with a higher priority, with those settings then pre-seeded (you would then accept and discard writes to «locked» keys). This makes the problem slightly easier, since you're then just left with «how do you trigger a dpkg-reconfigure». Sadly, I don't think dpkg provides the hooks you need to do that today. I think it could be useful to have it, so you could do «dpkg --needs-reconfigure A B C» and those would then be put in a state where they'd be reconfigured at the next opportunity. Care would of course have to be taken to avoid loops. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87sip9y8hz@vuizook.err.no
Re: Proposing amd64-hardened architecture for Debian
On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote: > Facing last week's Heartbleed [1] bug the need for improving the > security of our systems became more apparent than usually. In Debian > there are widely used methods for Hardening [2] packages at build time > and guidelines [3] for improving the default installations' security. Riding the Heartbleed publicity wave seems unwise, unless you can propose a hardening flag that would have protected users from Heartbleed. Else, Heartbleed merely serves on a example how wallpapering problems over with "hardened" binaries often doesn't help you at all.. Considering that most issues protected by compiler hardening are also detectable by static/dynamic code analysis, a more effective security measure would be to spend time with clang static analyzer, valgrind, trinity and other tools... or actualy reviewing patches that security critical projects recieve. Riku -- 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/20140419112659.ga22...@afflict.kos.to
Re: Proposing amd64-hardened architecture for Debian
Hi Riku, 2014-04-19 13:26 GMT+02:00 Riku Voipio : > On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote: >> Facing last week's Heartbleed [1] bug the need for improving the >> security of our systems became more apparent than usually. In Debian >> there are widely used methods for Hardening [2] packages at build time >> and guidelines [3] for improving the default installations' security. > > Riding the Heartbleed publicity wave seems unwise, unless you can > propose a hardening flag that would have protected users from > Heartbleed. Else, Heartbleed merely serves on a example > how wallpapering problems over with "hardened" binaries often > doesn't help you at all.. > > Considering that most issues protected by compiler hardening are > also detectable by static/dynamic code analysis, a more effective security > measure would be to spend time with clang static analyzer, valgrind, trinity > and other tools... or actualy reviewing patches that security critical > projects recieve. Thank you for bringing this up now. I have just managed to compile openssl, without the fix for the Heartbleed test but with -fsanitize=address, and as I expected it avoids leaking anything, I see only this in the Apache2's error.log: ... [Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid 3068020544] AH00094: Command line: '/us r/sbin/apache2' = ==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c READ of size 1 at 0xb4960411 thread T2 ASAN:SIGSEGV ==18459==AddressSanitizer: while reporting a bug found another one.Ignoring. = ==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c READ of size 1 at 0xb4960411 thread T5 ASAN:SIGSEGV ==18461==AddressSanitizer: while reporting a bug found another one.Ignoring. ... Since this is exactly the flag I looked at for amd64-hardened, if we had this arch existing a few weeks ago it would have prevented successful attacks on this platform. I used Heartleech for triggering the bug and the attached debdiff on openssl. The PoC is fragile because you need to set LD_PRELOAD=libasan1 and compile the package with the following command: CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc I have also disabled OpenSSL's feelist implementation because any custom memory handling would be disabled on amd64-hardened to let ASAN work effectively. During creating the PoC I have hit several bugs which I had to work around in the patch: Changes: openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low . * Enable -fsanitize=address * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS * Add patch to fix freelist reuse from here: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version! * Add patch 'Check i before r[i]' to fix buffer overflow by reading * Export ssl3_write_bytes() for compiling Heartleech * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386 Cheers, Balint diff -Nru openssl-1.0.1f/debian/changelog openssl-1.0.1f/debian/changelog --- openssl-1.0.1f/debian/changelog 2014-01-06 19:02:23.0 +0100 +++ openssl-1.0.1f/debian/changelog 2014-04-18 14:18:09.0 +0200 @@ -1,3 +1,16 @@ +openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low + + * Enable -fsanitize=address + * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS + * Add patch to fix freelist reuse from here: +http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse + * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version! + * Add patch 'Check i before r[i]' to fix buffer overflow by reading + * Export ssl3_write_bytes() for compiling Heartleech + * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386 + + -- Balint Reczey Thu, 17 Apr 2014 20:12:10 +0200 + openssl (1.0.1f-1) unstable; urgency=high * New upstream version diff -Nru openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch --- openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch 1970-01-01 01:00:00.0 +0100 +++ openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch 2014-04-17 20:17:12.0 +0200 @@ -0,0 +1,33 @@ +From 73c92dfa0c15d7932d86130a525d1a1bc43c312a Mon Sep 17 00:00:00 2001 +From: "Dr. Stephen Henson" +Date: Tue, 28 Jan 2014 15:10:27 + +Subject: [PATCH] Check i before r[i]. + +PR#3244 +(cherry picked from commit 9614d2c676ffe74ce0c919d9e5c0d622a011cbed) +--- + ssl/s3_srvr.c |4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +Index: openssl-1.0.1f/ssl/s3_srvr.c +=== +--- openssl-1.0.1f.orig/ssl/s3_s
Re: Proposing amd64-hardened architecture for Debian
On Sat, Apr 19, 2014 at 14:26:59 +0300, Riku Voipio wrote: [...] > Riding the Heartbleed publicity wave seems unwise, unless you can > propose a hardening flag that would have protected users from > Heartbleed. Else, Heartbleed merely serves on a example > how wallpapering problems over with "hardened" binaries often > doesn't help you at all.. > +100 on this one. Hardening may be nice, but wouldn't have helped at all w.r.t. Heartbleed (or any of the other recent SSL/TLS issues). > Considering that most issues protected by compiler hardening are > also detectable by static/dynamic code analysis, a more effective security > measure would be to spend time with clang static analyzer, valgrind, trinity > and other tools... or actualy reviewing patches that security critical > projects recieve. > Or maybe even just enable -Wall when compiling and take compiler warnings seriously (plus explicitly silence the ones you are entirely sure they are spurious). I wish people did that, it would so much help even starting static analysis efforts as it helps rule out all the code that static analysis cannot formally reason about due to its inconsistencies in typing. See [1] for some of those - if only I had more time, I'd be reporting lots more that are still on my stack for review. And I haven't even started reporting missing include files (and thus missing declarations). I will propose an MBF for that as soon as time permits. Best, Michael [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@debian.org&tag=goto-cc pgpfve1WAfSgn.pgp Description: PGP signature
Re: Proposing amd64-hardened architecture for Debian
previously on this list Michael Tautschnig contributed: > > Riding the Heartbleed publicity wave seems unwise, unless you can > > propose a hardening flag that would have protected users from > > Heartbleed. Else, Heartbleed merely serves on a example > > how wallpapering problems over with "hardened" binaries often > > doesn't help you at all.. > > > > +100 on this one. Hardening may be nice, but wouldn't have helped at all > w.r.t. > Heartbleed (or any of the other recent SSL/TLS issues). I am afraid you have this completely backwards. You can't use idiotic programming to justify anything. http://marc.info/?l=openbsd-misc&m=139715715931884&w=2 I am glad they are cleaning OpenSSL up http://undeadly.org/cgi?action=article&sid=20140418063443 Especially when what they have found is "very surprising" -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- 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/547070.34899...@smtp119.mail.ir2.yahoo.com
Bug#745259: ITP: apt-transport-tor -- APT transport for anonymous package downloads via Tor
Package: wnpp Severity: wishlist Owner: Tim Retout * Package name: apt-transport-tor Version : 0.1 Upstream Author : Tim Retout * URL : https://github.com/diocles/apt-transport-tor * License : GPL Programming Lang: C++ Description : APT transport for anonymous package downloads via Tor Provides support in APT for downloading packages anonymously via the Tor network. . APT already includes mechanisms for guaranteeing the authenticity of the packages you download. However, an adversary sniffing your network traffic can still see what software you are installing. . Install apt-transport-tor, edit your sources.list to include only tor:// URLs, and you can "apt-get install anarchism" without fear of reprisals. This software works! It was forked from the apt HTTPS transport. It doesn't yet have a build system or any packaging, but hopefully that's the easy part. Tim -- 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/20140419225032.23729.94870.reportbug@thinkpad
Arm64 port live on debian-ports
You may or may not have noticed that 'arm64' is coming. This a 64-bit arm architecture also known as 'aarch64' and implemented in the ARM CPU architecture 'v8'. Apart from iphones there is no publically available 64-bit silicon yet, but that'll be changing rapidly later this year and this port will start to become quite important. The arm64 port is now building on real buildds in debian-ports (as opposed to my previous bootstrapping efforts in Ubuntu and my initial Debian bootstrap repo on people.debian.org). It recently passed 3000 (source) packages. 207 packages FTBFS so far, so if your packages are there please take a look and fix them (or ask for advice if it's not clear what's needed). http://buildd.debian-ports.org/status/architecture.php?a=arm64&suite=sid There are about 270 pending arm64 bugfixes, some of which will be for those build failures: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=arm64 If there is an Ubuntu patch for your package is also very likely to contain an arm64 fix. If upstream changes are needed please check the Linaro aarch64 bugtracker ( https://bugs.launchpad.net/linaro-aarch64 ), and if there is no mention please bring it to the attention of Riku Voipio or me so we can put it on a list. The main doc for the port is https://wiki.debian.org/Arm64Port I've started a section there on porting for maintainers: https://wiki.debian.org/Arm64Port#Porting_packages_for_arm64_-_Maintainer_info which should give some pointers. There isn't (yet) a proper DSA porting box, but I can give you shell access to a machine if you need it. Just ask. Further builds are currently stalled on qt4/kdelibs/gtk+3/swig/php/openjdk. Once that lot is done libselinux, gettext and db5.3 can be built properly and much of the rest of the archive will become buildd-buildable. I expect this to happen in May. I'm mostly offline for the next couple of weeks (at conference + holiday afterwards) so nothing much will happen for a while, but if some of you have fixed stuff when I get back that would be lovely :-) 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: https://lists.debian.org/20140420012701.gv29...@stoneboat.aleph1.co.uk
Re: Proposing amd64-hardened architecture for Debian
On Sat, Apr 19, 2014 at 02:06:45PM +0200, Bálint Réczey wrote: > Hi Riku, > > 2014-04-19 13:26 GMT+02:00 Riku Voipio : > > On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote: > >> Facing last week's Heartbleed [1] bug the need for improving the > >> security of our systems became more apparent than usually. In Debian > >> there are widely used methods for Hardening [2] packages at build time > >> and guidelines [3] for improving the default installations' security. > > > > Riding the Heartbleed publicity wave seems unwise, unless you can > > propose a hardening flag that would have protected users from > > Heartbleed. Else, Heartbleed merely serves on a example > > how wallpapering problems over with "hardened" binaries often > > doesn't help you at all.. > > > > Considering that most issues protected by compiler hardening are > > also detectable by static/dynamic code analysis, a more effective security > > measure would be to spend time with clang static analyzer, valgrind, trinity > > and other tools... or actualy reviewing patches that security critical > > projects recieve. > Thank you for bringing this up now. > I have just managed to compile openssl, without the fix for the > Heartbleed test but with -fsanitize=address, and as I expected it > avoids leaking anything, I see only this in the Apache2's error.log: > ... > [Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid > 3068020544] AH00094: Command line: '/us > r/sbin/apache2' > = > ==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c > READ of size 1 at 0xb4960411 thread T2 > ASAN:SIGSEGV > ==18459==AddressSanitizer: while reporting a bug found another one.Ignoring. > = > ==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c > READ of size 1 at 0xb4960411 thread T5 > ASAN:SIGSEGV > ==18461==AddressSanitizer: while reporting a bug found another one.Ignoring. > ... > > Since this is exactly the flag I looked at for amd64-hardened, if we > had this arch existing a few weeks ago it would have prevented > successful attacks on this platform. Well this is certainly impressive - I was not aware of AddressSanitizer, seems like very powerful and easy to us instrumentation tool. AddressSanitizer does not look like a flag intended for hardening. The performance slowdown is quite steep. The instrumentation code itself might be buggy, causing exploitation potential in itself. Essentially this sounds about as wise as running server code under valgrind. > I used Heartleech for triggering the bug and the attached debdiff on openssl. > > The PoC is fragile because you need to set LD_PRELOAD=libasan1 and > compile the package with the following command: > CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc > > I have also disabled OpenSSL's feelist implementation because any > custom memory handling would be disabled on amd64-hardened to let ASAN > work effectively. > > During creating the PoC I have hit several bugs which I had to work > around in the patch: > > Changes: > openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low > . >* Enable -fsanitize=address >* Disable freelist using -DOPENSSL_NO_BUF_FREELISTS >* Add patch to fix freelist reuse from here: > http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse >* CVE-2014-0160 a.k.a Heartbleed is not fixed in this version! >* Add patch 'Check i before r[i]' to fix buffer overflow by reading >* Export ssl3_write_bytes() for compiling Heartleech >* Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386 This doesn't really look like a magical "if it was just compiled with hardening flags, this wouldn't have happened" case. The PoC required elobarate knowledge where the bug was and how it was hidden by openssl's memory allocations. With -DOPENSSL_NO_BUF_FREELISTS the bug would have been found with static analysis anyways... Riku -- 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/20140420054723.ga26...@afflict.kos.to
Bug#745271: ITP: ruby-fog-brightbox -- Brightbox Cloud support for the fog gem
Package: wnpp Severity: wishlist Owner: Pirate Praveen * Package name: ruby-fog-brightbox Version : 0.0.2 Upstream Author : Paul Thornthwaite * URL : https://rubygems.org/gems/fog-brightbox * License : Expat Programming Lang: Ruby Description : Brightbox Cloud support for the fog gem Module for the 'fog' gem to support Brightbox Cloud -- 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/20140420060719.31345.21013.report...@ravel.debian.org
