Re: leaks in our only-signed-software fortress
To put things in perspective, I just wonder how strong this 'fortress' really is, and whether this strength is only in our perception or whether it is real. Let me give just one example: A developer downloads a tarball from an upstream source, configures it, and does make install, yet has not even once checked whether this tarball is secure or is not a root kit. Teus. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f3f5d25.3000...@gmail.com
Re: Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]
On Fri, Feb 17, 2012 at 07:07:40PM +0100, Samuel Thibault wrote: > Bastian Blank, le Fri 17 Feb 2012 19:02:59 +0100, a écrit : > > On Fri, Feb 17, 2012 at 06:59:51PM +0100, Samuel Thibault wrote: > > > Bastian Blank, le Fri 17 Feb 2012 18:52:10 +0100, a écrit : > > > > I see this: > > > > | Provides: libasound2-dev, liboss-salsa-dev > > > These, that's expected. > > > > No, this is not expected. libasound2-dev is a real package. > > On Linux. Then please remove promptly the Provides: line on Linux builds of the package. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218084856.ga21...@afflict.kos.to
Re: Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]
Riku Voipio, le Sat 18 Feb 2012 10:48:56 +0200, a écrit : > On Fri, Feb 17, 2012 at 07:07:40PM +0100, Samuel Thibault wrote: > > Bastian Blank, le Fri 17 Feb 2012 19:02:59 +0100, a écrit : > > > On Fri, Feb 17, 2012 at 06:59:51PM +0100, Samuel Thibault wrote: > > > > Bastian Blank, le Fri 17 Feb 2012 18:52:10 +0100, a écrit : > > > > > I see this: > > > > > | Provides: libasound2-dev, liboss-salsa-dev > > > > These, that's expected. > > > > > > No, this is not expected. libasound2-dev is a real package. > > > > On Linux. > > Then please remove promptly the Provides: line on Linux builds of > the package. As said in my very first mail, I've already done so in the repo, but asked the oss4 maintainers whether it's OK with them. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218101722.gg4...@type.famille.thibault.fr
Re: Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]
On Fri, Feb 17, 2012 at 07:28:49PM +, Ben Hutchings wrote: > On Fri, Feb 17, 2012 at 07:41:03PM +0100, Mike Hommey wrote: > > On Fri, Feb 17, 2012 at 06:08:59PM +, Ben Hutchings wrote: > > > On Fri, Feb 17, 2012 at 07:00:32PM +0100, Mike Hommey wrote: > > > > On Fri, Feb 17, 2012 at 06:40:28PM +0100, Samuel Thibault wrote: > > > > > Mike Hommey, le Fri 17 Feb 2012 18:36:56 +0100, a écrit : > > > > > > On Fri, Feb 17, 2012 at 06:23:00PM +0100, Samuel Thibault wrote: > > > > > > > Mike Hommey, le Fri 17 Feb 2012 18:09:37 +0100, a écrit : > > > > > > > > > sydney_audio_alsa.c:504:5: error: void value not ignored as > > > > > > > > > it ought to be > > > > > > > > > > > > > > > > Would anyone have a clue as to what the hell is happening? > > > > > > > > > > > > > > Unpacking liboss4-salsa-dev (from > > > > > > > .../liboss4-salsa-dev_4.2-build2005-2_armel.deb) ... > > > > > > > Selecting previously unselected package libtinfo-dev. > > > > > > > > > > > > > > I don't know why the buildds preferred liboss4-salsa-dev over > > > > > > > libasound2-dev. > > > > > > > > > > > > > > In my previous packaging of oss4's alsa-over-OSS emulation, I had > > > > > > > only > > > > > > > enabled the -dev in the non-linux archs. In the current > > > > > > > packaging, it's > > > > > > > enabled in all of them. I've now restricted it in oss4 too. Oss4 > > > > > > > packagers, any opinion against it? > > > > > > > > > > > > Oh, so OSS4 provides an Alsa API that is not compatible with Alsa's. > > > > > > > > > > It *is* compatible. With an older version of the API, which used void > > > > > there. > > > > > > > > So, it's compatible with an API that is older than Alsa v1.0.10rc1, > > > > released 7 years ago. What is surprising, however, is that Alsa didn't > > > > change its soname for the resulting ABI change... > > > > > > It's a compatible change; at least I don't know of a C architecture > > > ABI where replacing a void return type with int would be incompatible. > > > > The problem comes when you run something that uses the int variant and > > expects a sound result, against the version that returns a void, which > > in practice probably means returning the first argument on a lot of > > architectures, if the register is not overwritten in the function body. > > That's not exactly what i'd call compatibility. > > Well neither is the absence of new functions in old libraries. But > that's why we have shlibs and symbol files. Of course, if the minimum > version for that symbol has not been set to the version changing the > return type then that is a bug. We have shlibs and symbols file to work around the problem in Debian. On absolute terms, the change is still binary incompatible, and should be handled properly, with symbol versions or soname change. Neither of which was done in libasound, for that matter. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218104222.ga13...@glandium.org
Re: leaks in our only-signed-software fortress
Christoph Anton Mitterer: > Hey. > > I've decided that I think it's important to CC this d-d: > Debian has a good system of securing packages and making sure that only > signed stuff comes to the user. > Over time I've seen many holes in this: > - packages that are just wrapper packages, download something from > somewhere without doing any >hashsum checks at all I'm as concerned as you are and collected some examples over time that might give a perspective: http://www.koch.ro/blog/index.php?/archives/153-On-distributing-binaries.html September 2009 Apache.org got hacked - twice in eight months. December 2010 The proftpd Source Code contains a backdoor January 2011 Sourceforge, one of the biggest distributor of free software, got hacked. June 2011 The Wordpress Plugins AddThis, WPtouch and W3 Total Cache contain backdoors July 2011 The vsftpd server download was replaced with a hacked version July 2011 VLC suffers from Companies spreading Malware bundled with VLC August 2011 kernel.org got hacked September 2011 MySQL.com hacked to server malware November 2011 Takedown of the largest botnet ever. DNS resolving of the bots was compromised. December 2011 Does download.com enrich their downloads with malware? February 2012 unnoticed for 3 months, the Horde project served compromised downloads I think as a start it should be made a policy that any "wrapper" package that downloads code from the net must at least do a strong checksum check on the downloaded code. What about a debhelper script that receives an URL (or set of mirror URLs) and a SHA1 and does the download and check? Regards, Thomas Koch, http://www.koch.ro signature.asc Description: This is a digitally signed message part.
Re: leaks in our only-signed-software fortress
Am Samstag, den 18.02.2012, 11:48 +0100 schrieb Thomas Koch: > July 2011 VLC suffers from Companies spreading Malware bundled with VLC This is no problem for us, because the malware was distributed on some untrustworthy websites. We, as packagers, get the code directly from the Videolan project. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: leaks in our only-signed-software fortress
* Christoph Anton Mitterer , 2012-02-18, 06:09: I've decided that I think it's important to CC this d-d: Debian has a good system of securing packages and making sure that only signed stuff comes to the user. Over time I've seen many holes in this: - packages that are just wrapper packages, download something from somewhere without doing any hashsum checks at all Some firmware packages, some font packages, documentation etc. is/was like that. - packages that eventually run some code which was downloaded unsecured. debootstrap used to be like that, pbuilder, and some others All(/most?) of those would be RC bugs. I'll add to the list: - Packages that download and run untrusted code at build time. - Some packages load and process content that could be secured but (is/was) not. IIRC the Contents Files are not signed and therefore e.g. apt-file cannot secure this. FWIW, the Contents files _are_ signed, but AFAICS apt-file doesn't verify the signature. But why is that a big deal? Of those who actually DID checks, there were several that used weak checks (even though there was no need to),... e.g. things like MD5 checks instead of something "better". For many of those I've reported bugs (and I'm sure I didn't found a lot of them, and I'm further sure that new cases were introduced). Some where closed, some where just ignored or denied. Could you point us to those which were ignored or denied? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218113214.ga2...@jwilk.net
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012 12:32:14 +0100 Jakub Wilk wrote: > * Christoph Anton Mitterer , 2012-02-18, 06:09: > >I've decided that I think it's important to CC this d-d: > >Debian has a good system of securing packages and making sure that only > >signed stuff comes to the user. > >Over time I've seen many holes in this: > >- packages that are just wrapper packages, download something from > >somewhere without doing any hashsum checks at all > >Some firmware packages, some font packages, documentation etc. is/was > >like that. > >- packages that eventually run some code which was downloaded > >unsecured. > >debootstrap used to be like that, pbuilder, and some others Only a bug if this happens by default. It is perfectly acceptable to support an option to disable SecureApt - just as long as this is not the default. Tools in Debian need to work with systems outside Debian and those do not necessarily *need* SecureApt because the entire loop is internal or even local to the one machine. > All(/most?) of those would be RC bugs. > I'll add to the list: > - Packages that download and run untrusted code at build time. ...if on Debian buildds or by default. Private buildd's, by a selectable option - not a bug. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpS3ax3E5EVf.pgp Description: PGP signature
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012 11:48:27 +0100 Thomas Koch wrote: > I think as a start it should be made a policy that any "wrapper" package that > downloads code from the net must at least do a strong checksum check on the > downloaded code. Not possible to enforce as a 'MUST' because, by definition, third-party websites will not provide checksums for every possible download mechanism. Only a should is possible here - wherever a checksum can be verified independently, but even then, an unreliable upstream checksum method is better ignored than supported. > What about a debhelper script that receives an URL (or set of mirror URLs) > and > a SHA1 and does the download and check? Do you mean dget? If it's mirror URL's, most of the time you can use apt. If it's mirrors, fine. Anything downloaded from a site which is not part of *.debian.org or a mirror of *.debian.org cannot be expected to provide useful checksums. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpHgJMd2RLfl.pgp Description: PGP signature
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012, Teus Benschop wrote: > To put things in perspective, I just wonder how strong this 'fortress' > really is, and whether this strength is only in our perception or > whether it is real. Let me give just one example: A developer downloads > a tarball from an upstream source, configures it, and does make install, > yet has not even once checked whether this tarball is secure or is not a > root kit. Teus. Good packaging developers go to great lengths to be sure they are not going to distribute anything trojaned. This takes a lot of work, and often requires very goot working relationship with upstream to the point of getting upstream to change his processes. This does include tracking deviations from VCS to upstream releases, going over upstream changes when possible, and using crypto properly to verify authenticity of upstream commits and tarballs (when available. When it is not available, educating upstream about it is required). Obviously, sometimes due diligence is not done (some people are quite lazy), and sometimes it is just plain impossible to do. And sometimes the malicious change was done in such way that only a careful audit would find it. So, yes, you really risk it happening. If you want to minimize that chance, Debian stable is your friend as the window of opportunity to discover trojaned sources is much larger in stable than it is in testing and unstable. I'm not sure what the Debian project could do to make sure we're at least doing everything that is humanly possible, *on every package* (we already do it on many packages) to allow for early detection of trojaned upstream releases or trojaned upstream VCS. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218124650.gc20...@khazad-dum.debian.net
Re: Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]
Le vendredi 17 février 2012 à 22:13 +0100, Axel Beckert a écrit : > Ben Hutchings wrote: > > 'Let the user choose' is almost as stupid an idea for drivers as it > > is for health insurance. > > I.e. it is a good idea? This question would be funny if so many politicians weren’t spreading such shit around. > > No-one wants to think about that, they just want their shit to work. > > I disagree. Choice is one of the strengths of free software. Wrong, wrong, wrong again, and again wrong. http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]
Le samedi 18 février 2012 à 11:17 +0100, Samuel Thibault a écrit : > As said in my very first mail, I've already done so in the repo, but > asked the oss4 maintainers whether it's OK with them. What should be OK for our users is to remove the *entire* OSS crap from the Linux builds. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: leaks in our only-signed-software fortress
Le samedi 18 février 2012 à 06:09 +0200, Christoph Anton Mitterer a écrit : > Personally I decided to use GNOME-fallback, but via the meta-packages I > still got the GNOME shell... today > I've noticed that it silently installs an extension, which (I can only > assume this by the little > description) does some software installation/enabling for GNOME shell > from extensions.gnome.org. > To me this sounds more like a root-kit than a feature. No GNOME shell extension is ever downloaded without your consent. The browser plugin is only here to make this possible. Plugin integrity is guaranteed by SSL, and extensions have been checked before being put on the website. Anyway this doesn’t work very well so we’d be better with just putting those extensions in another Debian package, but I see this more as a functional problem than a security one. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: leaks in our only-signed-software fortress
Jakub Wilk writes: > Could you point us to those which were ignored or denied? At least pbuilder still disables secure APT by default, see #579028. Regards Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762f4cmh1@deep-thought.43-1.org
Bug#660341: ITP: ruby-kgio -- Kinder, gentler I/O for Ruby
Package: wnpp Severity: wishlist Owner: Hleb Valoshka <375...@gmail.com> * Package name: ruby-kgio Version : 2.7.2 Upstream Author : Eric Wong * URL : http://bogomips.org/kgio/ * License : LGPL-2.1 or LGPL-3 Programming Lang: Ruby Description : Kinder, gentler I/O for Ruby kgio provides non-blocking I/O methods for Ruby without raising exceptions on EAGAIN and EINPROGRESS. It is intended for use with the Unicorn and Rainbows! Rack servers, but may be used by other applications (that run on Unix-like platforms). It's required to package Unicorn. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218133632.14065.21539.reportbug@deneb.local
Bug#660342: ITP: ruby-raindrops -- Real-time stats for preforking Rack servers
Package: wnpp Severity: wishlist Owner: Hleb Valoshka <375...@gmail.com> * Package name: ruby-raindrops Version : 0.8.0 Upstream Author : Eric Wong * URL : http://raindrops.bogomips.org/ * License : LGPL-2.1 or LGPL-3 Programming Lang: Ruby Description : Real-time stats for preforking Rack servers Raindrops is a real-time stats toolkit to show statistics for Rack HTTP servers. It is designed for preforking servers such as Rainbows! and Unicorn, but should support any Rack HTTP server under Ruby 1.9, 1.8 and Rubinius on platforms supporting POSIX shared memory. It may also be used as a generic scoreboard for sharing atomic counters across multiple processes. It's required to package Unicorn. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218133905.14381.88092.reportbug@deneb.local
Bug#660343: ITP: ruby-aggregate -- Ruby class for accumulating aggregate statistics
Package: wnpp Severity: wishlist Owner: Hleb Valoshka <375...@gmail.com> * Package name: ruby-aggregate Version : 0.2.2 Upstream Author : Joseph Ruscio * URL : http://github.com/josephruscio/aggregate * License : MIT Programming Lang: Ruby Description : Ruby class for accumulating aggregate statistics Aggregate is a Ruby class for accumulating aggregate statistics and includes histogram support. It's required to package ruby-raindrops required by Unicorn. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218134125.14441.34997.reportbug@deneb.local
Bug#660347: ITP: python-cdo -- python wrapper for CDO climate Data Operators
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: python-cdo Version : 1.5.4 Upstream Author : uwe.schulzwe...@zmaw.de * URL : https://code.zmaw.de/projects/cdo * License : GPL Programming Lang: python Description : python wrapper for CDO climate Data Operators Climate Data Operators are a collection of command line Operators to manipulate and analyse Climate model Data. Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG. There are more than 400 operators available. This package provides a Python interface to CDO. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218134559.28490.65199.report...@ailm.sceal.ie
Re: leaks in our only-signed-software fortress
Am 18.02.2012 10:11, schrieb Teus Benschop: To put things in perspective, I just wonder how strong this 'fortress' really is, and whether this strength is only in our perception or whether it is real. Let me give just one example: A developer downloads a tarball from an upstream source, configures it, and does make install, yet has not even once checked whether this tarball is secure or is not a root kit. This is true but... a) this would be a general attack against all people, which are usually a tiny bit harder to do, then the local sysadmin just hacking colleagues.. b) as everyone is affected then (all users of the package),... there is a greater chance of notifying it most important... c) the ideal situation would of course be, that the maintainer has a good relationship to upstream, perhaps even met them in person, exchanged OpenPGP keys with them and uses those (or weaker means[0]) to verify every single download. Cheers, Chris. [0] Some projects secure their sites e.g. with X.509 certs by one of the commercial CAs I guess this is better than nothing, but many recent cases have shown us that the whole strict hierarchical trust model by X.509 is basically for trash. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/29f4cc7dc550446fc47e078c3c727...@scientia.net
Re: leaks in our only-signed-software fortress
Am 18.02.2012 13:14, schrieb Benjamin Drung: This is no problem for us, because the malware was distributed on some untrustworthy websites. We, as packagers, get the code directly from the Videolan project. So you meet them once in person and exchanged some kind of PKI/shared secret etc? That's great then of course and the ideal case of securely getting the sources as a maintainer :-) But I guess only a small fraction of our packages have such a secure trust path to their upstream. Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c6728367706314e815f09031fcedd...@scientia.net
Teams in changelog trailers
Now that we have a concept of a “team upload”[0], I'd like to have putting team's name in the changelog trailer officially deprecated. This would: 1) allow to always identify person responsible for a particular upload; 2) help to avoid situations where (inadvertently) no human name is mentioned in a changelog entry at all. What do others think? [0] Developer's Reference §5.11.7 http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-team-upload -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218140850.ga5...@jwilk.net
Re: leaks in our only-signed-software fortress
* Ansgar Burchardt , 2012-02-18, 14:14: Could you point us to those which were ignored or denied? At least pbuilder still disables secure APT by default, see #579028. The bug is closed. Am I missing something? But anyway, this is saddening. Hundreds (? - wild guess) of developers have been building their packages in insecure environment, yet pbuilder maintainer and a member of Security Team believe that it was a feature, not a bug. :| -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218141858.ga5...@jwilk.net
Re: leaks in our only-signed-software fortress
Am 18.02.2012 13:32, schrieb Jakub Wilk: I'll add to the list: - Packages that download and run untrusted code at build time. May I add a similar case... Take the non-free flash as example... (yeah I know it's non-free and not officially sec-supported).. Even if it would use some SHA512 sums (hardcoded into the package) to verify the download (I don't know whether it does),.. the update mechanism is still outsite of the package management system (on has to call update-flash or something like that)... so you bypass the whole central point of update management. FWIW, the Contents files _are_ signed, but AFAICS apt-file doesn't verify the signature. See #515942. But why is that a big deal? What do you mean? Of not verifying it? Well as always someone can attack you if you somehow (for whatever reason) rely on the information being correct. Moreover, if there is some automatic parsing of those files, you can also easily think of attack vectors by manipulating files,.. Could you point us to those which were ignored or denied? Phew... would have to do a lot of digging in my mails and bug reports to find them out again. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1ef6a4f196a3cdd6cab0b5940cbf4...@scientia.net
Re: leaks in our only-signed-software fortress
Am 18.02.2012 14:34, schrieb Neil Williams: >- packages that eventually run some code which was downloaded >unsecured. >debootstrap used to be like that, pbuilder, and some others Only a bug if this happens by default. It is perfectly acceptable to support an option to disable SecureApt - just as long as this is not the default. Tools in Debian need to work with systems outside Debian and those do not necessarily *need* SecureApt because the entire loop is internal or even local to the one machine. Agreed, but it WAS the default till recently,.. e.g. in debootstrap till 1.0.30, when my bug #560038 was fixed (thanks Joey :) ). And of course anything that used debootstrap (e.g. pbuilder, piuparts do so) was automatically insecure, too. (till then) Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/121005584832f4d35086604441f21...@scientia.net
Re: leaks in our only-signed-software fortress
Am 18.02.2012 14:40, schrieb Neil Williams: I think as a start it should be made a policy that any "wrapper" package that downloads code from the net must at least do a strong checksum check on the downloaded code. Not possible to enforce as a 'MUST' because, by definition, third-party websites will not provide checksums for every possible download mechanism. Well it's still possible then,... the maintainer can just calculate sums on his own. Of course this does not mean things are secure (the maintainer could already use a forged version)... but at least it helps again single MITM attacks. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0a9d69dc96c647151114bca2d8ebb...@scientia.net
Re: leaks in our only-signed-software fortress
Am 18.02.2012 15:30, schrieb Josselin Mouette: Personally I decided to use GNOME-fallback, but via the meta-packages I still got the GNOME shell... today I've noticed that it silently installs an extension, which (I can only assume this by the little description) does some software installation/enabling for GNOME shell from extensions.gnome.org. To me this sounds more like a root-kit than a feature. No GNOME shell extension is ever downloaded without your consent. The browser plugin is only here to make this possible. Plugin integrity is guaranteed by SSL, and extensions have been checked before being put on the website. Well I guess the problem here are three things: - Communication You say now, that GNOME checks all what they put up there, and nothing is every installed automatically. This makes things a bit better,... but it's not really obviously documented. At least not for a just-a-user like me. Of course one can always say read the code + go into the developer docs,... but if I have to do this for everything, than I'm just screwed. - Trust I really do not trust GNOME/Mozilla etc. here do do all this in a secure and right way. At least for Mozilla there are hundredths of extensions, they surely can't check them all. - Bypassing the package management system IMHO, software in Debian should ONLY be installed by the package management system with one exception: When the user really downloads/(optionally compiles)/installs himself. Especially software should not bring its own package management system in form of app-store-like thingies. Of course I know it's difficult to prevent this. Upstreams just do it... and ways around it (e.g. our Mozilla Extension Packages) are a big effort for us. Nevertheless, solve this via packages, would be the right way (IMHO). Anyway this doesn’t work very well so we’d be better with just putting those extensions in another Debian package, but I see this more as a functional problem than a security one. Great :) Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/74ac1eea31fb134b60c8ef405d676...@scientia.net
Re: leaks in our only-signed-software fortress
* Christoph Anton Mitterer , 2012-02-18, 16:19: Take the non-free flash as example... (yeah I know it's non-free and not officially sec-supported).. Even if it would use some SHA512 sums (hardcoded into the package) to verify the download (I don't know whether it does),.. the update mechanism is still outsite of the package management system (on has to call update-flash or something like that)... so you bypass the whole central point of update management. Completely agreed! We should remove flashplugin-nonfree from the archive. Or wait, even simpler, you could just not install it. FWIW, the Contents files _are_ signed, but AFAICS apt-file doesn't verify the signature. See #515942. You can easily check yourself that Contents-* checksums are mentioned in the Release files, even for lenny. (Though indeed they weren't in Feb 2009.) Feel free to unarchive and reopen the bug. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218144754.ga6...@jwilk.net
Re: Teams in changelog trailers
Hi. On Sat, Feb 18, 2012 at 03:08:50PM +0100, Jakub Wilk wrote: > Now that we have a concept of a “team upload”[0], I'd like to have > putting team's name in the changelog trailer officially deprecated. > > This would: > 1) allow to always identify person responsible for a particular upload; To be very pedantic, the signature on the last upload should reveal this, right? > 2) help to avoid situations where (inadvertently) no human name is > mentioned in a changelog entry at all. > > What do others think? One problem arises if the last person who "made" the upload (in case it was sponsored) does not put his/her name. I just wish to know what other situations where having just team uploads makes life harder. Thanks. Kumar -- Footnotes are for things you believe don't really belong in LDP manuals, but want to include anyway. -- Joel N. Weber II discussing the 'make' chapter of LPG -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218151321.ga4...@bluemoon.alumni.iitm.ac.in
Re: Teams in changelog trailers
Kumar Appaiah (18/02/2012): > > This would: > > 1) allow to always identify person responsible for a particular upload; > > To be very pedantic, the signature on the last upload should reveal > this, right? Not if the team upload is prepared by someone who then gets sponsored by a DD (or a DM from the relevant team). Mraw, KiBi. signature.asc Description: Digital signature
Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)
Hello, On Wed, 01 Feb 2012, Josselin Mouette wrote: > Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit : > > I agree that an automatic solution would be prefered. However, as long > > as such someone does not stand up and write such a program removing > > existing solutions is . > > The point is, no one will write such a program until we remove support > for the old system entirely. FWIW, it looks like Josselin suggested this in #497779 more than 3 years ago already. So he certainly tried something else before simply removing the mailcap file. I pinged the mime support maintainer, pointing to Russ' mail explaining how to generate mailcap entries out of the desktop files. Hopefully this will help since he seemed interested into supporting this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218154410.ga22...@rivendell.home.ouaza.com
Re: leaks in our only-signed-software fortress
Jakub Wilk writes: > * Ansgar Burchardt , 2012-02-18, 14:14: >>>Could you point us to those which were ignored or denied? >>At least pbuilder still disables secure APT by default, see #579028. > > The bug is closed. Am I missing something? pbuilder was changed to pass the --keyring argument to debootstrap by default and there now is an option to enable secure apt, but it is still disabled by default. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkcgb1ko@deep-thought.43-1.org
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012 16:25:20 +0200 Christoph Anton Mitterer wrote: > Am 18.02.2012 14:40, schrieb Neil Williams: > >> I think as a start it should be made a policy that any "wrapper" > >> package that > >> downloads code from the net must at least do a strong checksum check > >> on the > >> downloaded code. > > Not possible to enforce as a 'MUST' because, by definition, > > third-party > > websites will not provide checksums for every possible download > > mechanism. > > Well it's still possible then,... the maintainer can just calculate > sums on his own. Against what? The source is only downloaded from upstream once per upstream release, what is there to check against? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpV0KWdtHDkd.pgp Description: PGP signature
Re: Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]
On Fri, Feb 17, 2012 at 18:36:56 +0100, Mike Hommey wrote: > Oh, so OSS4 provides an Alsa API that is not compatible with Alsa's. > Awesome. > The oss4 package should die a painful death. Cheers, Julien signature.asc Description: Digital signature
Re: Teams in changelog trailers
On Sat, Feb 18, 2012 at 15:08:50 +0100, Jakub Wilk wrote: > What do others think? > Yes please. Cheers, Julien signature.asc Description: Digital signature
Improving hwclock support in Debian (testing wanted)
Hi, The attached patch against current util-linux cleans up hwclock handling with the following changes: • There are currently two init scripts, hwclockfirst.sh and hwclock.sh. The reasons for these two originally existing (/etc/localtime not being present until after /usr was mounted AFAICT) no longer exist. I've removed hwclockfirst and adjusted the hwclock init script to run before checkroot. • Currently the setting for if the hardware clock is in UTC or local time is set with the UTC setting in /etc/default/rcS. However, this needlessly duplicates the /existing/ setting in hwclock's own configuration file (/etc/adjtime). This means hwclock's behaviour is overridden and its configuration overwritten *every shutdown*. This patch migrates the existing UTC= setting to UTC/LOCAL in /etc/adjtime. • The hwclock init scripts use the --utc and --localtime options (based on the UTC setting). This patch changes hwclock to use the value in /etc/adjtime. • The udev hwclock-set script now runs unconditionally in all cases using --tzset. (It's a no-op for UTC.) • If the user runs "hwclock --systohc (--utc|--localtime) this is now handled correctly. The clock state is recorded in /etc/adjtime and correctly handled on restart. This means the UTC setting in /etc/default/rcS doesn't screw things up by requiring two separate changes to do the same thing. • systemd uses /etc/adjtime as for hwclock to store the hardware clock UTC/LOCAL configuration. This change means there's a single place to store the hardware clock configuration for all init systems. I've tested the patch on a powerpc system for a PST timezone using UTC and LOCAL options both with and without udev support (commented out the udev conditionals to test non-udev code). It would be great to have some testing on different hardware and setups with UTC or local time to make sure this covers all possible configurations without any regressions. There's an additional patch for d-i clock-setup to make this work for new installs as well (#660093). I'll file a bug with this patch against util-linux once this is properly tested. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 util-linux-hwclock-decruft.patch.bz2 Description: Binary data
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012 15:59:38 +0200 Christoph Anton Mitterer wrote: > Am 18.02.2012 10:11, schrieb Teus Benschop: > > To put things in perspective, I just wonder how strong this > > 'fortress' > > really is, and whether this strength is only in our perception or > > whether it is real. Let me give just one example: A developer > > downloads > > a tarball from an upstream source, configures it, and does make > > install, > > yet has not even once checked whether this tarball is secure or is > > not a > > root kit. Detecting a root kit in downloaded source isn't trivial. If the package has completely changed and has been *replaced* with a toolkit, then any maintainer will notice that it doesn't build the files expected. A determined attack which tries to embed a root kit within an existing package/binary would be much more difficult for anyone to pick up, potentially even upstream. If a binary file built for the previous version of the upstream is a few Kb bigger in the next release, no maintainer is going to see that as anything more than entirely expected of a new upstream release. > This is true but... > a) this would be a general attack against all people, which are usually > a tiny bit harder to do, then the local sysadmin just hacking > colleagues.. So what is the point of the entire thread? Downloading upstream sources is a general thing for everyone using that package but it is done by one person (usually) and (usually) without any upstream checksums. It's a complete non-issue because there is 0% chance of getting every conceivable upstream team to implement anything like this. There may be other clues (file naming conventions, layout styles, weird compile messages appearing etc.) but none of those are reliable. > b) as everyone is affected then (all users of the package),... there is > a greater chance of notifying it But it is still down to chance. Overall, it's not something that I'm going to lose any sleep over. There's no way that I'll be asking my upstream teams to even consider it, nor would I implement it for my own upstream projects. I happen to use upstream sites which provide something like this but their security models aren't perfect. I used to provide detached GnuPG signatures alongside my uploaded source tarballs but nobody cared or even noticed if I inadvertently broke the signature. (This is for packages which regularly got downloaded for inclusion into Fedora, ArchLinux, Gentoo and numerous other distros other than Debian/Debian-based ones which get the source directly from me.) Honestly, nobody cares. > most important... > c) the ideal situation would of course be, that the maintainer has a > good relationship to upstream, perhaps even met them in person, > exchanged OpenPGP keys with them and uses those (or weaker means[0]) to > verify every single download. Completely unrealistic for most maintainers. Now, I could be really smug here and say that for some of my packages, I have absolute and airtight security between maintainer and upstream but that's only because I am sole maintainer and sole upstream.. (if you want better security than that, keep dreaming) .. but I also have other packages where upstream provide no checksums whatsoever. I've been lucky enough to meet one member of one of those upstream teams once (at a conference ~3 yrs ago which I haven't been able to attend since) but we had much more important stuff to discuss than signing / checksumming the download directory. Besides, meeting someone once with little chance of ever meeting them again is not a particularly strong indication that I should sign their GnuPG key (which is why I don't attend mass keysignings any longer). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpSoIf9ctVJ1.pgp Description: PGP signature
Re: Improving hwclock support in Debian (testing wanted)
On Sat, Feb 18, 2012 at 03:59:23PM +, Roger Leigh wrote: > Hi, > > The attached patch against current util-linux cleans up hwclock > handling with the following changes: • Also adds /etc/default/hwclock and hwclock(5) which permit configuration without editing the initscript, and also documents all the undocumented knobs used by the scripts. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218163428.gg26...@codelibre.net
Re: Teams in changelog trailers
Hi, Jakub Wilk wrote: > Now that we have a concept of a “team upload”[0], I'd like to have > putting team's name in the changelog trailer officially deprecated. Seconded. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 signature.asc Description: Digital signature
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012 15:49:30 +, Neil Williams wrote: > On Sat, 18 Feb 2012 16:25:20 +0200 > Christoph Anton Mitterer wrote: > > > Am 18.02.2012 14:40, schrieb Neil Williams: > > >> I think as a start it should be made a policy that any "wrapper" > > >> package that > > >> downloads code from the net must at least do a strong checksum check > > >> on the > > >> downloaded code. > > > Not possible to enforce as a 'MUST' because, by definition, > > > third-party > > > websites will not provide checksums for every possible download > > > mechanism. > > > > Well it's still possible then,... the maintainer can just calculate > > sums on his own. > > Against what? The source is only downloaded from upstream once per > upstream release, what is there to check against? He's talking about stuff like flash-nonfree (or whatever) where we ship a wrapper that wgets the actual tarball for you from the distributor, and checks the checksum of whatever it ends up with. The maintainer can grab a copy, checksum it (perhaps if paranoid do the download from elsewhere on a different day, make sure the checksums match), and then sign a package containing the checksum that he generated to ensure that everyone that installs the package gets the same tarball, or sees an error message. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpfT82GLERlY.pgp Description: PGP signature
Re: Teams in changelog trailers
On Sat, Feb 18, 2012 at 3:08 PM, Jakub Wilk wrote: > 1) allow to always identify person responsible for a particular upload; > 2) help to avoid situations where (inadvertently) no human name is mentioned > in a changelog entry at all. > > What do others think? It would be very appropriate, in Debian Multimedia we already do so. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMHuwox6ZsfWQCzTFGs5opASinKP=qvSQdvzxtActrR=cpa...@mail.gmail.com
Re: leaks in our only-signed-software fortress
On Sat, Feb 18, 2012 at 11:48:27AM +0100, Thomas Koch wrote: > What about a debhelper script that receives an URL (or set of mirror > URLs) and a SHA1 and does the download and check? Please use something stronger than SHA-1. SHA-1 has some weaknesses and something like SHA-256 or SHA-512 should be used in new applications. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: leaks in our only-signed-software fortress
Am 18.02.2012 16:18, schrieb Jakub Wilk:
The bug is closed. Am I missing something?
But anyway, this is saddening. Hundreds (? - wild guess) of
developers have been building their packages in insecure environment,
yet pbuilder maintainer and a member of Security Team believe that it
was a feature, not a bug. :|
And looking at my current sid pbuilderrc manpage I read at least:
APTGETOPT=('--force-yes')
Extra flags to give to apt-get. Default is --force-yes,
which
will skip key verification of packages to be installed.
Unset if
you want to enable key verification.
=> what does verification mean here?
and
PBUILDERSATISFYDEPENDSOPT=('--check-key')
Array of flags to give to pbuilder-satisfydepends.
Specifying
--check-key here will try to verify key signatures.
=> "try"? Doesn't sound trustworthy at least :(
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/42cef275f2916e38bd6cb5c037dcc...@scientia.net
Re: leaks in our only-signed-software fortress
Am 18.02.2012 19:03, schrieb brian m. carlson: On Sat, Feb 18, 2012 at 11:48:27AM +0100, Thomas Koch wrote: What about a debhelper script that receives an URL (or set of mirror URLs) and a SHA1 and does the download and check? Please use something stronger than SHA-1. SHA-1 has some weaknesses and something like SHA-256 or SHA-512 should be used in new applications. +1 SHA1 has some weaknesses but I guess it's not yet (!!!) something were we have to make big concerns in real world threads... but: I guess the main point with respect to things like these is the following: Maintainers (or people in general) SHOULD get a sense of security and the obvious question here is: Why use something weaker, when something better is broadly available and technically feasible (I mean e.g. sums on source code make no performance problem,... when someone does streaming of large data, there can be benefit from using something weaker but faster (e.g. MD5 or) in contrast to stronger but slower (SHA512). Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b116548c250ddc4aba34ee83384c8...@scientia.net
Re: leaks in our only-signed-software fortress
Am 18.02.2012 18:45, schrieb Philip Hands: He's talking about stuff like flash-nonfree (or whatever) where we ship a wrapper that wgets the actual tarball for you from the distributor, and checks the checksum of whatever it ends up with. Yes! (perhaps if paranoid do the download from elsewhere on a different day, make sure the checksums match), Actually things like this should be done, if nothing better (signatures + trust path) is available... of course it doesn't make things 100% sure, but even if it gets us just some 10% likeliness of noting an attack it's worth it (IMHO). Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1f837ecb03fe0f56151a5e3c6369b...@scientia.net
Re: leaks in our only-signed-software fortress
On Sat, Feb 18, 2012 at 04:31:19PM +0100, Ansgar Burchardt wrote: > Jakub Wilk writes: > > * Ansgar Burchardt , 2012-02-18, 14:14: > >>>Could you point us to those which were ignored or denied? > >>At least pbuilder still disables secure APT by default, see #579028. > > > > The bug is closed. Am I missing something? > > pbuilder was changed to pass the --keyring argument to debootstrap by > default and there now is an option to enable secure apt, but it is still > disabled by default. This should be safe to enable now. We had problems enabling it in sbuild (in 2005) when tools first started supporting it for backward- compatibility reasons, but it's been the default for some time now (since July 2008) since everything we would want to build on supports it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218174609.gi26...@codelibre.net
Re: leaks in our only-signed-software fortress
On 02/18/2012 08:40 PM, Neil Williams wrote: > On Sat, 18 Feb 2012 11:48:27 +0100 > Thomas Koch wrote: > > >> I think as a start it should be made a policy that any "wrapper" package >> that >> downloads code from the net must at least do a strong checksum check on the >> downloaded code. >> > Not possible to enforce as a 'MUST' because, by definition, third-party > websites will not provide checksums for every possible download > mechanism. > We're trying to mitigate risks of a man-in-the-middle attack here. Not to authenticate a content, which is the job of the maintainer. We want to check that the file is the same one as the one the maintainer downloaded. Which means that if there isn't a checksum on the third-party website, a maintainer can just run sha512sum and save the checksum in his download script (or next to it) by himself for later runtime check. So yes, a MUST can happen, IMO. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f3fea8b.50...@debian.org
Re: leaks in our only-signed-software fortress
On 02/18/2012 09:30 PM, Josselin Mouette wrote: > Plugin integrity is > guaranteed by SSL, and extensions have been checked before being put on > the website. > I feel much much safer now that I know that my plugin downloads are protected by Diginotar ! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f3febc7.2040...@debian.org
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012, Neil Williams wrote: > On Sat, 18 Feb 2012 16:25:20 +0200 > Christoph Anton Mitterer wrote: > > Am 18.02.2012 14:40, schrieb Neil Williams: > > >> I think as a start it should be made a policy that any "wrapper" > > >> package that > > >> downloads code from the net must at least do a strong checksum check > > >> on the > > >> downloaded code. > > > Not possible to enforce as a 'MUST' because, by definition, > > > third-party > > > websites will not provide checksums for every possible download > > > mechanism. > > > > Well it's still possible then,... the maintainer can just calculate > > sums on his own. > > Against what? The source is only downloaded from upstream once per > upstream release, what is there to check against? Upstream VCS, previous releases (when the diff is small enough), request that upstream publish in an email message the sha1sum or sha256sum when they announce a new release, etc. How much it will protect Debian users, depends entirely where the trojan instertion point was. So far, the more common insertion points have NOT been upstream's development box, but rather the public distribution points and vcs trees. Heck, even for dead upstream you still get the stuff from the other distros to compare Debian's with, even if you did it only to check for interesting patches from other distros, it would still increase the chances of you noticing something is weird. And it is part of the job of a downstream maintainer to educate upstream when necessary, even if it takes a lot of diplomacy and a lot of effort. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218184237.gh20...@khazad-dum.debian.net
Re: leaks in our only-signed-software fortress
On Sat, 18 Feb 2012, Philip Hands wrote: > On Sat, 18 Feb 2012 15:49:30 +, Neil Williams wrote: > > On Sat, 18 Feb 2012 16:25:20 +0200 > > Christoph Anton Mitterer wrote: > > > Am 18.02.2012 14:40, schrieb Neil Williams: > > > >> I think as a start it should be made a policy that any "wrapper" > > > >> package that > > > >> downloads code from the net must at least do a strong checksum check > > > >> on the > > > >> downloaded code. > > > > Not possible to enforce as a 'MUST' because, by definition, > > > > third-party > > > > websites will not provide checksums for every possible download > > > > mechanism. > > > > > > Well it's still possible then,... the maintainer can just calculate > > > sums on his own. > > > > Against what? The source is only downloaded from upstream once per > > upstream release, what is there to check against? > > He's talking about stuff like flash-nonfree (or whatever) where we ship > a wrapper that wgets the actual tarball for you from the distributor, > and checks the checksum of whatever it ends up with. > > The maintainer can grab a copy, checksum it (perhaps if paranoid do the > download from elsewhere on a different day, make sure the checksums > match), and then sign a package containing the checksum that he > generated to ensure that everyone that installs the package gets the > same tarball, or sees an error message. I believe there are "downloader" packages in Debian that do just that, and the practice isn't new. It is far better than nothing, as it effectively shortens the time window where a trojan can be inserted in the distribution point. That's not even close to 100% coverage, but it is nothing to sneeze at, either. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218184507.gi20...@khazad-dum.debian.net
Re: leaks in our only-signed-software fortress
On Sat, Feb 18, 2012 at 04:42:38PM -0200, Henrique de Moraes Holschuh wrote: > > Against what? The source is only downloaded from upstream once per > > upstream release, what is there to check against? > > Upstream VCS, previous releases (when the diff is small enough), request > that upstream publish in an email message the sha1sum or sha256sum when they > announce a new release, etc. A good part of upstreams use git, let's educate them about signed tags. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Improving hwclock support in Debian (testing wanted)
On Feb 18, Roger Leigh wrote: > • There are currently two init scripts, hwclockfirst.sh and > hwclock.sh. The reasons for these two originally existing Why do you still bother with init scripts? With very good approximation, nowadays all systems which need hwclock (i.e. are not containers, chroots, etc) use udev: http://qa.debian.org/popcon-graph.php?packages=udev+module-init-tools&show_installed=on&want_legend=on&want_ticks=on&from_date=2012-02-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 -- ciao, Marco signature.asc Description: Digital signature
Re: Improving hwclock support in Debian (testing wanted)
On Sat, Feb 18, 2012 at 08:00:28PM +0100, Marco d'Itri wrote: > On Feb 18, Roger Leigh wrote: > > > • There are currently two init scripts, hwclockfirst.sh and > > hwclock.sh. The reasons for these two originally existing > Why do you still bother with init scripts? With very good approximation, > nowadays all systems which need hwclock (i.e. are not containers, > chroots, etc) use udev: This updates both the init script and the udev hwclock script. Also, the init script is still needed to sync the clock on shutdown; AFAIK udev only triggers the hwclock on startup when the rtc device is registered. In addition to that, this ensures that it works uniformly on non-Linux- and non-udev-using systems. The (previously undocumented) configuration variables for both the init script and the udev script are now set in /etc/default/hwclock. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218194040.gj26...@codelibre.net
Bug#660405: ITP: libpackage-new-perl -- simple base package from which to inherit
Package: wnpp Severity: wishlist Owner: Florian Schlichting * Package name: libpackage-new-perl Version : 0.07 Upstream Author : Michael R. Davis * URL : http://search.cpan.org/perldoc?Package::New * License : BSD Programming Lang: Perl Description : simple base package from which to inherit The Package::New object provides a consistent constructor for objects, similar to Package::Base or Object::Tiny. It provides the methods 'new' and 'initialize', as well as a methode 'dump' for debugging through Package::New::Dump. libpackage-new-perl is a new dependency of libgeo-googleearth-pluggable-perl. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218210151.24958.31678.report...@island.zedat.fu-berlin.de
Re: Teams in changelog trailers
Le Sat, Feb 18, 2012 at 05:51:57PM +0100, Stefano Zacchiroli a écrit : > > It'd be nice if debbugs could understand "[ Debian Developer ]" lines > and give credit to the appropriate individuals when closing bugs > mentioned in changelogs. But I understand that's not entirely trivial to > do, and I don't consider that to be enough of a reason to keep around > hard to attribute changelog entries. Hi Stefano, If there is ambiguity about credit, perhaps the BTS boilerplate could be amended to include a disclaimer that not all of it shall come to the uploader. Recenlty, I have uploaded new packages with changelogs like the following. r-cran-proto (0.3-9.2-1) unstable; urgency=low * Team upload. [ Carlos Borroto ] * Initial release (Closes: #657994) -- Charles Plessy Wed, 01 Feb 2012 13:47:24 +0900 At first I worried that it would deprive Carlos from the credit of preparing the package. But in the end, I think that such a changelog clearly presents the responsibilities, credit aside. I am responsible for having uploaded the package, and Carlos is responsible for making this packaging happen. If the changelogs were about credit, what would be missing there would be the contribution of the team to the packaging work of Carlos, and that would bring us back putting the team's name in the changelog signature, which is not as informative as having a human name. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120219005934.ga14...@falafel.plessy.net
Re: Teams in changelog trailers
On Sat, Feb 18, 2012 at 04:24:39PM +0100, Cyril Brulebois wrote: > Kumar Appaiah (18/02/2012): > > > This would: > > > 1) allow to always identify person responsible for a particular upload; > > > > To be very pedantic, the signature on the last upload should reveal > > this, right? > > Not if the team upload is prepared by someone who then gets sponsored by > a DD (or a DM from the relevant team). In which case the sponsor of the upload is responsible for the upload, right? The person signing and uploading is "responsible" for the content of the upload, whether directly as the person who prepared the upload or as someone who has checked what is being sponsored before uploading it. The signer is taking responsibility, if I understand correctly. Thanks. Kumar -- I've heard a Jew and a Muslim argue in a Damascus cafe with less passion than the emacs wars." -- Ronald Florence in -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120219020114.gb12...@bluemoon.alumni.iitm.ac.in
Re: Teams in changelog trailers
On Sat, Feb 18, 2012 at 08:01:14PM -0600, Kumar Appaiah wrote: > On Sat, Feb 18, 2012 at 04:24:39PM +0100, Cyril Brulebois wrote: > > Kumar Appaiah (18/02/2012): > > > > This would: > > > > 1) allow to always identify person responsible for a particular upload; > > > > > > To be very pedantic, the signature on the last upload should reveal > > > this, right? > > > > Not if the team upload is prepared by someone who then gets sponsored by > > a DD (or a DM from the relevant team). > > In which case the sponsor of the upload is responsible for the upload, > right? The person signing and uploading is "responsible" for the > content of the upload, whether directly as the person who prepared the > upload or as someone who has checked what is being sponsored before > uploading it. The signer is taking responsibility, if I understand correctly. But pedantry aside, I am also for Jakub's original suggestion. Kumar -- I did this 'cause Linux gives me a woody. It doesn't generate revenue. -- Dave '-ddt->` Taylor, announcing DOOM for Linux -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120219021329.gc12...@bluemoon.alumni.iitm.ac.in
Re: [Pkg-oss4-maintainers] Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]
Hi all, 2012/2/18 Julien Cristau : > On Fri, Feb 17, 2012 at 18:36:56 +0100, Mike Hommey wrote: > >> Oh, so OSS4 provides an Alsa API that is not compatible with Alsa's. >> Awesome. >> > The oss4 package should die a painful death. 2012/2/18 Josselin Mouette : > Le vendredi 17 février 2012 à 22:13 +0100, Axel Beckert a écrit : >> Ben Hutchings wrote: >> > 'Let the user choose' is almost as stupid an idea for drivers as it >> > is for health insurance. >> >> I.e. it is a good idea? > > This question would be funny if so many politicians weren’t spreading > such shit around. > >> > No-one wants to think about that, they just want their shit to work. >> >> I disagree. Choice is one of the strengths of free software. > > Wrong, wrong, wrong again, and again wrong. > http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html (I haven't been involved in oss4 packaging for a while now but since I did write the original ITP I feel like I could drop my 2 cents..) I find it interesting to have such very sharp comments on a package that has been around for quite some times now. Regardless, if we go down the path of making straight up choices for our users, I'd suggest that we also get rid of either Gnome or KDE.. They already don't fit both in our install medias anymore, right? More seriously there are people who care about their sound drivers in more specific ways than the average user who "just wants his shit to work" (sic). There are also people using OSes that do not have ALSA and, interestingly, we happen to support some of those. I am personally all about our making choices as a distribution as to which set of software we choose to focus on. However, it is also possible to provide alternatives that have a smaller user base but are nevertheless interesting for some people. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABWZ6OR5JwbwFzACNS3D-D-qYYwHoWKmrNoyRxZz55K=5ge...@mail.gmail.com
