Bug#765719: general: System restarts on "shutdown -h now"
Package: general Severity: normal Dear Maintainer, * What led up to the situation? After the last upgrade, the system would not halt any more. Instead, it runs into a restart cycle. The restart bypasses GRUB, i.e. one a computer with multiple OS, it restarts linux directly. The machine in use is a Lenovo Thinkpad X220. * What exactly did you do (or not do) that was effective (or ineffective)? I tried some hints from users with similar experiences, including the "acpi=force" setting, the selection of a different kernel at the first start, a manual intervention (for i in /sys/bus/usb/devices/*/power/control; do echo on > $i; done) on the USB power control settings, and shutdowning in all flavors. * What was the outcome of this action? Continues restarting -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- 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/20141017132818.3809.88811.reportbug@duckling
Bug#906249: general: Long pause after lightdm login, gimp not starting except under strace
Package: general
Severity: normal
Dear Maintainer,
after upgrading to debian testing, I ran into a few problems. First of all, as
I am using fluxbox, and intend to continue, I could not use gdm any more -
after login, the login screen would reappear after some time. Login to gnome
was no problem. I installed lightdm and configured it to use X (instead of
wayland). Right now, login is working, and the desktop appears, but only after
a pause of up to several minutes which can be shortened by moving the mouse.
Afterwards, everything seems to run normal, except: The gimp. On calling "gimp"
form the command line, nothing happens. When using "strace gimp", the program
starts; yet, opening jpg images is not possible (freeeze), the preview creation
fails as well.
I do not know whether these bugs are related; somehow, as all of them are about
starting programs, with strange measures to overcome at least the first
obstacles (mouse movements, strace-call) I somehow suspect it.
Sincerely yours,
Moritz
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (750, 'testing'), (50, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968),
LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
In linux.debian.devel, you wrote: > but I think that hotbabe demonstrates a larger issue. The only issue I can see is that WNPP does not seem to by a fully sufficient synchronization point for the creation of new Debian packages. This ITP has been filed although two RFPs already exist (as hotbabe and hot-babe), which have neither been retitled nor merged.
Bug#284778: ITP: freebooters -- Free "Pirates!" like strategy game
Package: wnpp Severity: wishlist * Package name: freebooters Version : 0.2.2 Upstream Author : [EMAIL PROTECTED] * URL : http://home.gna.org/freebooters * License : GPL Description : Free "Pirates!" like strategy game The Caribbean Sea in the late 16th century: The Dutch, French, English and Spanish crown aim to expand their areas of influence. You as an auspiscious young captain are trying to make the best of it, as you may either become a brave merchant soul, a freebooting hero of your crown or a bloodlusty dreaded pirate leader. . Freebooters will hopefully become a free clone of the Sid Meier classic "Pirates!". It's written in C++ using SDL, makes use of the Ogre 3D engine and is licensed under the GNU General Public License. The main intent of this ITP is to prevent duplicated packaging efforts; unofficial Debian packages are available since the 0.1 release, but an attempt to introduce them into the main archive will be made post-sarge with the 0.3 release, which will be the first playable release. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-386 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Re: Bug#294209: ITP: reminiscence -- REminiscence is a rewrite of the engine used in the game Flashback from Delphine Software
In linux.debian.devel, you wrote: >> Description: free implementation of Delphine Software's FlashBack engine >> REminiscence is an engine capable of runing any game based on the >> FlashBackengine. >> . >> To actually make use of ScummVM, you currently need to get the orginal >> FlashBack game data-files >> > Did you mean ScummVM there? REminiscense follows the principle way ScummVM works, but it's an independant implementation in SDL. There has been a similar attempt to provide a free engine for Flashback, which the author withdrew after the original producer contacted him. (I forgot the name of the project). Are there similar issues for REminiscense? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mplayer, the time has come
A Mennucc wrote: > and there are wonderful feats that 'mplayer' that do not need : decss, > faad, lame & xvid Why should Debian's mplayer be unable to support XVID? The MPEG4 codec from libavcodec will play any XVID just fine and libavcodec is already part of Debian in xine-lib and ffmpeg. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Matthew Garrett wrote: >> As I understand it, SCC *binaries* get their own domain / mirrors / >> everything, but the *source* shall be shared with the main archive. > > Uh. Not if you want to distribute any GPLed material. The FSF doesn't consider this a problem: http://www.gnu.org/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSites Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Matthew Palmer wrote: > But a DSA *is* the first highly visible announcement that *Debian* is > affected. A general "this is a problem" announcement might make the > crackers cackle with glee, but a DSA with a "m68k, mips, and arm updates > will be forthcoming in a week or so" is a signal to brush off that list of > Debian boxes running the relevant arches you had been quietly collecting for > a couple of months. Come on, this is a non-issue: The huge majority of remotely exploitable security bugs are related to stack or heap overflows. Anyone clever enough to write specific exploits for fringe architectures (as using the usual "might work on Fedora/i386" PoC exploits posted to full-disclosure will not suffice) will have no problems to deduce whether Debian is affected once the initial advisory from distributions with a more relaxed security process is available (such as Gentoo). In the contrary I assume that currently the security mechanism for alls archs is hindered by the fact that the slowest arch sets the pace. There has been a XSF-SVN commit for the latest libxpm vulnerability some days ago, which hasn't culminated into a DSA yet. How long does an xfree86 build take on arm, mips or m68k? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
In linux.debian.devel, you wrote: >> The need for gcc-2.95 usually means the source code is broken (in C99 >> terms) and should be fixed. Do you have an example of an use case where >> this is unfeasible, and which is important enough to justify continued >> maintenance of gcc 2.95? [..] > Also, people have some code (old completed internal projects, etc), which > probably would never be ported to newer C++ standards (it's plainly too big > job), but which are still useful to keep working - e.g. for > demonstration/education/similar purposes. > > I have to deal with the both above situations. And I believe I'm far not > alone here. So there is user benefit from keeping gcc 2.95 in usable state. > Not fixing internal compiler bugs - user who faces old compiler's failure > to build code should seriously consider switching to newer versions - but > just keeping packages installable and usable. I agree. Plus, compilation of C code with 2.95 is typically twice as fast as 4.0. While 2.95 may be too buggy wrt C++, it's still useful for C. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
In linux.debian.devel, you wrote: > Worse, the existance of a practical md5(A+B+C)=3Dmd5(A+D+C) attack means > that it's not out of the question that there're md5(A+B)=3Dmd5(C+D) > attacks in the hands of particularly well resourced groups (which is > worse, since the version uploaded to the archive could then be entirely > innocent looking). Personally, I don't have any interest in making the > NSA's job any easier, or that of other signals intelligence groups. While this is arguably true (the NSA claims to have developed asymmetric cryptography ten years ahead of Diffie/Hellman), it seems that nowadays the end of the cold war and improved corporate interest have shifted things, so I'm personally not _too_ worried about that. >> >> Moving away from MD5 is certainly not a bad idea, but it's not clear >> >> whether the alternatives are any better. Sure, everyone recommends >> >> SHA-256 at this stage, but nobody can give a rationale. >> > MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or >> > higher) are significantly harder to break in practice, >> So? If SHA256 is so much better, why is that nobody can prove it, or >> at least can provide some evidence which supports that claim? "The >> numbers are bigger" is the main argument at this point, which is >> awfully similar to the usual snake-oil arguments (although there is a >> slight difference, of course). > > SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better > than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is > fragile, but not broken, and is extensible. Do you have other > suggestions? I'd suggest the combination of several hash systems, e.g. RIPEMD-160, a SHA-based algorithm and possibly Tiger. >> > and there's nothing better yet. >> In terms of security, there are some better hash functions. =20 > > My understanding was that there aren't other hash functions that've had > remotely similar levels of cryptographic analysis to md5 and sha. IIRC, > the elliptic curve cryptography stuff was supposed to be similarly neat, > until people started analysing it seriously, at which point it broke. I'm not aware of any attacks beyond birthday attacks, which are still infeasible for the recommended key sizes of >= 160 bits. ECC has several patent problems, though. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian and the desktop
Christian Perrier wrote: > And, anyway, the KDE/Gnome thing is only one of the points I meant > about the "usability" of our default desktop system, when we target > our dear Bob User. This is beyond tasksel, but Bob User would profit immensely from generic menu entries. SuSE does this and I think it's very helpful. Most people don't care, which web browser they are using and if they're browsing through their application menu, they're confused by an entry called "Kopete", while an entry called "Instant Messaging Program" is a lot more helpful. So maybe menu should be extended to keep both forms, so that the generic form can be chosen during installation. Once Bob User has turned into Bob Hacker he can switch back to the detailed form. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Petter Reinholdtsen wrote:
> But it is not doing a great job with processing a few old uploads. I
> consider it a problem that no decision have been taken on the few
> really old uploads (xvidcap, rte, mplayer).
One of the FTP masters (I forgot who) once said that the best way to
help get mplayer into the archive would be to present an overview of
the patent situation surrounding MPEG and the like. ffmpeg has such
an overview in README.patents, which might serve as a good basis, as
the core library code of mplayer, ffmpeg and xvidcap is identical.
(libavcodec/libavformat)
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Jeroen van Wolffelaar wrote: > I explicitely said that stripping it > anyway will make the whole pondering on whether it can be in the > (source) package at all moot for the question whether mpeg encoding > would be legal to ship on ftp.debian.org. To the best of my knowledge, > mpeg encoding stuff is nowhere near the core funcionality of mplayer > anyway, isn't it? The encoding functionality is built into a separate binary; mencoder. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Lars Wirzenius wrote: [Less strong "ownership" of packages. > This idea hasn't been tested. It could be tested if > some group of maintainers declared that some or all > of their packages were part of the experiment, that > anyone could NMU them for any reason whatsoever, as > long as they take proper care not to mess the package > up. > > (I'm willing to participate in such an experiment > myself, but I haven't thought out the details yet.) Why don't we add a status field into the PTS, where a maintainer can denote her "NMU policy" for a given source package? E.g. a selection box, ranging from "Don't dare to touch this, I bite" to "Feel free to 0d-NMU for every severity as long a you send the patch". Or a free-form field, if that doesn't suffice. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: poppler (was: Work-needing packages report for Dec 30, 2005)
Frank Küster wrote: >>poppler (#344738), orphaned 4 days ago >> Reverse Depends: libpoppler-glib-dev libpoppler-dev abiword-plugins >>libpoppler-qt-dev libkpathsea4 evince libpoppler0c2-qt tetex-bin >>libpoppler0c2-glib > > ... and hopefully some more in the future. There are a couple of > packages with copies of xpdf code in them (different minor versions, of > course...), and they have been an annoying source of work every time a > security issue pops up in xpdf. As we (or rather Martin Pitt) have > shown with tetex-bin, switching to poppler is quite easy; but for that > the package should be well maintained. These source packages embed xpdf source and should be fixed to use poppler if possible: gpdf pdftohtml kdegraphics (kpdf) koffice libextractor cupsys also embeds xpdf source, but uses xpdf-utils for current versions. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345353: O: mantis
Hilko Bengen wrote:
> What's worse: Support from upstream in general and especially security
> handling has been less than optimal.
Plus, security problems are rather frequent. CVE has issued 28 IDs for
2002-2005.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Manoj Srivastava wrote: >> I suspect a similar system for Debian might increase visibility and >> commitment from a large set of users. > > Lacking quality control of the input, I am not at all > convinced that this is desirable. You know the "old adage of computer > men", GIGO. All the given examples (like secure-testing, d-i, debian-kernel and lots of other Alioth projects) have far better precautions against crap entering the archive than the traditional one-man-show approach. Peer review through an svn-commits mailing list is the best that can happen to a sub-project or package. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: poppler
Frank Küster wrote: >> These source packages embed xpdf source and should be fixed to use poppler >> if possible: >> >> gpdf >> pdftohtml >> kdegraphics (kpdf) >> koffice >> libextractor > > AFAIK, poppler was created by the freedesktop people specifically in > order to replace xpdf code in Gnome and KDE applications. Therefore I > expect that at least kpdf an gpdf, and probably koffice will link > against poppler in a new release (and already do in CVS?) I've heard that gpdf is to be replaced by evince in GNOME, which already links dynamically, so it's probably best to remove it for Etch. Unfortunately kpdf upstream seems quite reluctant to switch to poppler, see http://bugs.kde.org/show_bug.cgi?id=119455. I don't know the status of koffice. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Theodore Ts'o wrote: > I can give a couple of examples; one is way back when, before I took > over the maintenance of the e2fsprogs package, and was merely the > upstream author. The then maintainer of e2fsprogs attempted to add > support for filesystems > 2GB, but botched the job, and the result was > people with filesystems > 2GB would in some circumstances, get their > filesystems trashed. Of course, those people complained directly to > me, and the reputation of e2fsprogs took a hit as a result. I was > pissed, but I was informed there was nothing I could do; the > maintainer of the package can do whatever they want, upstream wishes > be d*mned, unless you try to go through a rather painful appeal > process via a then-relatively inactive technical committeee. If it lured you into becoming a DD we should mess up more upstream code :-) Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350391: ITP: glest -- Free 3D fantasy real-time-strategy game
Package: wnpp Severity: wishlist Owner: Moritz Muehlenhoff <[EMAIL PROTECTED]> * Package name: glest Version : 2.0pre Upstream Author : Glest Team * URL : http://www.glest.org * License : GPL for the code, permissive free license for the game data Description : Free 3D fantasy real-time-strategy game Glest is a free fantasy 3D real time strategy game with impressive graphics. See http://www.josezanni.com/glest/descargas/demoglest_v1.2.mpg for a demo video. Glest will be packaged/maintained by the Debian Games Team. Anyone interested in helping/joining see http://wiki.debian.org/Games/Development for details. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352064: ITP: wormux -- A clone of the Worms game
Package: wnpp Severity: wishlist Owner: Moritz Muehlenhoff <[EMAIL PROTECTED]> * Package name: wormux Version : 0.7 Upstream Authors: Jean-Christophe DUBERGA, Laurent DEFERT SIMONNEAU, Lawrence AZZOUG Matthieu FERTRÉ, Renaud LOTTIAUX, Victor STINNER * URL : http://www.wormux.org * License : GPL Description : A clone of the Worms game Almost everyone has heard of the Worms(R) series of games, developed by Team17. Worms was created in 1990, the goal of the game consisting of a several teams of "worms" fighting to the death on a 2D map. Wormux is heavily influenced by all games in this genre, including Scorched Earth and Liero. . Wormux is free software clone of this game concept. Though currently under heavy development, it is already very playable, with lots of weapons (Dynamite, Baseball Bat, Teleportation, etc.). There are also lots of maps available for your battling pleasure! Wormux takes the genre to the next level, with great customisation options leading to great gameplay. There is a wide selection of teams, from the Aliens to the Chickens. Also, new battlefields can be downloaded from the Internet, making strategy an important part of each battle. . Homepage: http://wormux.org Previous versions of Wormux depended on a development version of clanlib, that's why a previous ITP never made it into a real package and was later closed due to inactivity. As of version 0.7 Wormux is ported to SDL. Wormux is packaged upstream for Debian by Jean Parpaillon, I've been in contact with him and after the usual package review further releases will be maintained together with him as part of the Debian Games Group. (http://wiki.debian.org/Games/Development) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Adam McKenna wrote: >> No, like chosing ati over nvidia for graphic cards, or silicon image over >> others for SATA cards. > > Wait a minute, did I miss a memo? ATI isn't the devil anymore? It surely is, the current generation of ATI cards doesn't even support 2D with free drivers (beyond VESA, of course) and the previous generation needed to be reverse-engineered for 3D. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaing Xen 3.0 etc for Debian
Matthew Grant wrote: > 2) Their stable release uses a kernel that is not patched for security > holes. It is, the status of the currently prepared sarge2 update can be found at http://wiki.debian.org/DebianKernelSargeUpdateStatus > Fortunately, individual security fixes are almost all only small > patches that are easily merged with any kernel tree with the editing of > maybe 2 or 3 lines at worst. This means that any kernel tree should be > easily maintainable, once the security fix patches are identified in the > kernel.org git change-sets. =20 > > This identification process has to be done at the moment for the current > stable Debian kernel, so if the security fix patches where done by > individual CVE, and documented with the kernel versions they are needed > for, We do track them by CVE ID: http://svn.debian.org/wsvn/kernel/patch-tracking/?rev=0&sc=0 > any Xen kernel tree should be easily maintainable separately. And who should do this? Kernel updates already consume way too much time, the approach by Bastian with xen being a subflavour of the linux-2.6 source package seems the only feasible. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311787: ITP: lincity-ng -- City simulation game with polished GUI and graphics
Package: wnpp Severity: wishlist Owner: Moritz Muehlenhoff <[EMAIL PROTECTED]> * Package name: lincity-ng Version : 0.9.0rc1 Upstream Author : lincity-ng developers group (several people) * URL : http://lincity-ng.berlios.de * License : GPL (most media files are dual-licensed with a CC license) Description : City simulation game with polished GUI and graphics Lincity-ng is a fork of the original lincity game with a more user-friendly interface and completely new, polished isometric graphics made in Blender. See http://lincity-ng.berlios.de/wiki/index.php/Image:Liftoff2.png for an example. The 0.9 release is playable with some rough edges. As lincity-ng is more or less an almost new game and more resource demanding than the original lincity, both should co-exist just fine. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-rc5 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-uk] Sun have (probably) patented apt-get
In linux.debian.devel, you wrote: > Today the EU gets to vote on the same issue. They can elect to have a > thriving software industry well placed to replace the now crippled USA > as the dominant force in the software industry. > > Europe, its time to choose. It has chosen a few minutes ago; the commision's directive has been rejected by the European parliament. This is not as good as the solution proposed in the first reading or the amendments made by Mr. Rocard, but it's still pretty much a victory for the Free software world. Let's hope that this will lead to the invalidation of the 30,000 software patents already granted by the European patent body. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two versions of pan in etch?
Søren Boll Overgaard wrote:
> Essentially, what it boils down to is this: Would it be prudent to include two
> separate versions of pan in etch (perhaps named pan and pan2)?
This should be avoided where possible; if they share a common code base it's
quite likely that discovered security problems need to be fixed in both source
packages.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMU for mantis - dependecy for php5 fixed
Daniel Knabl wrote: > could anyone please have a look at the changes I've made to the mantis > package?! It should now support/depend on/work with php5 too. > Also I've tested it on several machines both with testing and > unstable, and there were no errors during installation nor with > upgrades from earlier versions. > > The files can be found here:=20 > > http://www.tirolinux.net/~daniel/mantis/mantis_0.19.4-3.3.diff.gz > http://www.tirolinux.net/~daniel/mantis/mantis_0.19.4-3.3.dsc > http://www.tirolinux.net/~daniel/mantis/mantis_0.19.4-3.3_all.deb > http://www.tirolinux.net/~daniel/mantis/mantis_0.19.4-3.3_i386.changes An NMU to fix PHP5 compatability is not enough. Mantis is currently unmaintained, horribly insecure (20 vulnerabilities since 2005) and very outdated (current stable in 1.0.5). In the current state it's hardly security-supportable for Etch and should rather be removed entirely. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: searchable d.o/security/
Javier Fernández-Sanguino Peña wrote: >> today I searched for a specific DSA and its really pain if=20 >> you just know the package but no DSA number (correct me if I missed=20 >> something). > > What kind of search are you trying to do? Package to DSA? Bug to DSA? > If so, it would not be difficult to have a page listing all packages and the > DSAs issued to them (it might be a little bit large though). Would that cov= > er your need? It already exists, e.g. for mutt: http://idssi.enyo.de/tracker/source-package/mutt Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why not only support Sid and Testing?
Marc Haber wrote: >> I know I am in for an argument, but I think it is a good >>question. I'm sure many of you have read Mark's blog: >>http://www.markshuttleworth.com/archives/56. It says 76% of Debian >>users run unstable and probably a fair fraction of the rest run testing. > > I tend to doubt these numbers, especially if they come from a source > that is known for its Ubuntu / Canonical marketing blurb. So do I. A more credible source are apt sources being downloaded. In this area stable's market share was about 3/4, oldstable something around 1/12 and the rest testing/unstable. (All figures are at least half a year old and from the top of my memory, which may be failing me. IIRC it was aj who mentioned them in IRC). Maybe the FTP masters can provide more current figures. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#386911: ITP: Claroline -- Course Management System for Online Learning
Victor Manuel Mtz wrote: > * Package name: Claroline > Version : 1.7.8 > Upstream Author : Lederer Guillaume <[EMAIL PROTECTED]> > * URL : http://www.claroline.net > * License : GPL > Description : Course Management System for Online Learning > > Claroline is a free application based on PHP/MySQL allowing teachers or > education organizations to create and administrate courses through the > web. > > Developed from teachers to teachers, Claroline is built over sound > pedagogical principles allowing a large variety of pedagogical setup > including widening of traditional classroom and online collaborative > learning. However, it also seems to be built over unsound web programming principles allowing a large variety of security exploits including widening of SQL queries and online collaborative cross-site-scripting. (CVE-2006-3257, CVE-2006-2868, CVE-2006-2284, CVE-2006-1596, CVE-2006-1595, CVE-2006-1594, CVE-2006-0411, CVE-2005-1377, CVE-2005-1376, CVE-2005-1375, CVE-2005-1374 and possibly more, I stopped digging deeper) I don't think this should enter the archive. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: local copies of libs
Hendrik Sattler wrote: > since I often see that packages keep local copies of libs and use those, I= >=20 > kind of want to object to arguments for such build behaviour. > > The latest one I found is xmms-wma: it uses a local stripped-down copy of=20 > ffmpeg's libavcodec and libavformat. > > The given reasons are pretty much always the same. Here: > * linking this way uses less memory >=2D Well certainly if you only look at your own package. In combination wit= > h a=20 > program that links against libavcodec (4.5MB, probably the main reason for= >=20 > this argument), the combination consumes more memory. > > Maybe such libs as libavcodec would benefit from a local split (one master = > lib=20 > with smaller codec libs and a lib with common routines) or a plugin=20 > mechanism. This would stop this non-sense of using local copies. > >=46or some, the reason is acceptable, for some it isn't? So what makes it=20 > candidate for a bug report with a severity greater than wishlist? > What is the main opinion among Debian maintainers? libavcodec had several vulnerabilities and without doubt it'll have more in the next 30 months after Etch release. So it's absolutely necessary to link dynamically. (Many do already, e.g. xine-lib). I'll file RC bugs for any packages still embedding or link statically soon, just haven't had the time yet. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#391686: ITP: ipw3945-daemon -- Binary userspace regulatory daemon for Intel PRO/Wireless 3945ABG cards
Jurij Smakov wrote: > * Package name: ipw3945-daemon > Version : 1.7.22 > Upstream Author : Intel Corporation > * URL : http://http://bughost.org/ipw3945/ > * License : Redistribution only (non-free) > Programming Lang: available only in binary form > Description : Binary userspace regulatory daemon for Intel PRO/Wireless > 3945ABG cards Hasn't it been reverse-engineered yet, so that we can provide a free solution? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: local copies of libs
Reinhard Tartler wrote: >> libavcodec had several vulnerabilities and without doubt it'll have more in >> the next 30 months after Etch release. So it's absolutely necessary to >> link dynamically. (Many do already, e.g. xine-lib). >> I'll file RC bugs for any packages still embedding or link statically soon, >> just haven't had the time yet. > > It would be very helpful from the ffmpeg side, if there finally was a > real release, on which application could rely on binary/sourcelevel > compatibility. > > See also http://ffmpeg.mplayerhq.hu/faq.html#SEC22 for reference I know, I'm following ffmpeg upstream for a long time. But it's sufficient if dynamic linking is ensured every 18 months for a the stable releases, if you want to test stuff between releases feel free to link statically. > Besides this, linking dynamically against ffmpeg results in loss of > features and performance. At least I was told this by an ffmpeg developer. The performance overhead should be negligable. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: local copies of libs
Hendrik Sattler wrote: >> libavcodec had several vulnerabilities and without doubt it'll have more in >> the next 30 months after Etch release. So it's absolutely necessary to >> link dynamically. (Many do already, e.g. xine-lib). >> I'll file RC bugs for any packages still embedding or link statically soon, >> just haven't had the time yet. > > I just opened a bug against xmms-wma for that (important, with patch): #391238 > If you want it to be RC, you have to change severity. Thanks, severity raised. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor
Kjetil Kjernsmo wrote: > I could imagine this creating an undesired overhead for the Security > Team in case of a flaw. > > I would therefore suggest splitting TinyMCE into a package of its > own. Unfortunately, I'm not a DD myself. That would be much appreciated. The second troublemaker if adodb, which seems embedded in several webapps as well. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396927: ITP: xyssl -- lightweight crypto and SSL/TLS library
Arnaud Cornet wrote: > * Package name: xyssl > Version : 0.1 > Upstream Author : Christophe Devine <[EMAIL PROTECTED]> > * URL : http://xyssl.org/ > * License : LGPL > Programming Lang: C > Description : lightweight crypto and SSL/TLS library Do you have sufficient crypto expertise to maintain this? I'm having some doubts that a SSL lib with a 0.1 version, which was released only a week ago provides real benefit to Debian. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch
Loïc Minier wrote: >> - goobox > > Alternative programs available with a superset of the features, and an > active upstream. I'm waiting for a final ack of the maintainer that > the alternatives are indeed okay and that we can proceed with removal. If goobox's unique feature is remote audio CD playback it won't need need gstreamer's ffmpeg support for it, so dropping ffmpeg support might be a solution if the removal of goobox is not possible. > As soon as the above issues are cleared in testing, I'll request the > removal of the GStreamer 0.8 suite of testing and unstable. Thanks for resolving this! Cheers Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
Josselin Mouette wrote: > By hiding behind upstream, you're simply refusing to fix the problem. > The patch is a hack that is only guaranteed to work on a Debian system, > and upstream will refuse it until it is done in a proper way. This is > not how things work. Forwarding fixes upstream is important but it > doesn't come before fixing the Debian bug. > >> > As the situation is very similar in mplayer, mplayer is considered >> > RC-buggy by the security team. There was an exception for >> > gstreamer-ffmpeg because it was considered too difficult to fix, but I >> > don't think this is justified and this should be considered >> > release-critical as well. >> >> Again, nothing new. As you state yourself, this was already discussed >> and an exception was granted. Beside, you miss the important point >> that gst-ffmpeg heavily patches (read: "replaces") the ffmpeg build >> system, wihle mplayer has a close-to-vanilla ffmpeg tree. > > The exception was granted because of this assumption, which is *entirely > wrong*, as gst-ffmpeg ships a vanilla ffmpeg tree. It took me less than > one hour to figure it out and to build a working package with the Debian > ffmpeg library. > >> "Dropping GStreamer 0.8 for etch" is not "building gst-ffmpeg against >> Debian's ffmpeg"; any of these changes can be achieved in whatever >> order, these are orthogonal, even if both would help security support >> (in a different way). As I'm not considering building gst-ffmpeg >> against ffmpeg for etch, I kindly suggest we let this subthread die or >> be continued in the upstream bug report where it would be more useful. > > As the security people are the ones being really affected, I would like > to have Moritz' input on this matter. Are you ready to grant an > exception to gstreamer-ffmpeg and not to mplayer while the situation of > both packages is strictly identical? When preparing DSA-992 for ffmpeg I looked at other packages embedding libavcodec and IIRC gst-ffmpeg's copy was forked at that time. If it's technically feasible to fix gst-ffmpeg 0.10 to link dynamically against etch's libavcodec that would be of course the preferred solution, especially if it should bring in new bugfixes/features (that's what I understood about your previous comment about H264?) However, we're rather late in the release cycle and if Loic as one of the GNOME maintainers thinks that adapting gst-ffmpeg is too risky or not possible w/o regressions in the depending apps that would be understandable. OTOH you're among the GNOME maintainers as well and should have the full picture as well, so I'm a bit confused. I'd conclude to: 1. Let's all avoid flames (the latest followups have become too hostile) and concentrate on an Etch release, which kicks ass. 2. If the GNOME maintainers come to an agreement that linking dynamically is possible it would be _much_ appreciated, if not we need to bite the bullet. And for mplayer; it provides dynamic linking out of the box and it's not an important infrastructure package like gstreamer, so the above does not apply. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404762: ITP: freesynd -- Free implementation of the Syndicate engine
Package: wnpp Severity: wishlist Owner: Moritz Muehlenhoff <[EMAIL PROTECTED]> * Package name: freesynd Version : 0.1 Upstream Author : QuantumG <[EMAIL PROTECTED]> * URL : http://freesynd.sf.net/ * License : GPL Programming Lang: C++ Description : Free implementation of the Syndicate engine Syndicate is an isometric sci-fi action game created by Bullfrog in 1993. Freesynd attempts to provide a free engine, while using the data taken from the original game. Status: * The first level is "playable". * Most of the menus are complete and functional. * Some juttering of agent movement has been noted. * Agent AI is different from the original game. * No trees or doors on the map. * The minimap is not complete. * Tax collection and other functionality of the world map are not done. (Right now it's targeted for experimental/contrib). -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch's upgrades during life cycle
Luis Matos wrote: > Many users have complaints about in the middle of the life cycle, or > before the debian stable release no longer supports new hardware. > Therefor a new kernel would be needed for d-i ( or an hardware > compatibility update for the kernel and modules). > > My proposal would be in point releases to change the kernel a bit to > support more hardware. That kernel would be tested, ofcourse. > > What i am saying is: is it possible to in a lenny or lenny++ change the > way debian upgrades it's stable, just for the kernel? Yes, there are plans for a second set of kernels (and probably xservers) nine months after Etch release, which will also have security support. However nothing's fixed yet, as the current focus is on getting Etch ready. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
Javier Fernández-Sanguino Peña wrote: > On Thu, May 25, 2006 at 05:30:23PM +0200, Luca Capello wrote: > > FYI, Martin's explanation is at [1], which passed on Planet Debian. > > > > Thx, bye, > > Gismo / Luca > > > > [1] http://blog.madduck.net/geek/2006.05.24-tr-id-at-keysigning > > FWIW, I noted down those keys I would *not* sign and didn't tell the people > at the KSP that I would not sign them. I guess his experiment "only one in > ten said that they would *not* sign it" is moot unless he backs it up with > the signatures he eventually got sent from those he showed a wrong ID to. Yes, that is true. I did the same for some people showing really weird ID like their university cafeteria card. > That being said I (personally) already decided not to sign people that showed > me something that was *not* a passport and noted that in my KSP paper page > through it. Unfortunately, I'm not confindent in my ability to disntiguish > forgeries so that means that people: > > - showing their country's ID card That's idiocy. The German identity card is an officially issued authentication device and substitutes a passport. (Which is true for the whole European Union, so you should know). In fact the identity card (despite the name written on it and the pages holding visa stamps) is almost identical to the passport. (With the exception of very new passports containing additional biometric features.) > and not showing any passports or showing passports: > > - which did not had the *same* spelling as the name in the key (letter by > letter) The German passport/ID card has official ASCII transliterations of umlaut names, so if you have discarded signatures on that assumption you didn't read exactly enough. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: egroupware upgrade drops several applications -- suggestions?
Peter Eisentraut wrote: > The upgrade to the new egroupware upstream drops several applications such as > the trouble-ticket system and the forum (because they were unmaintained or > the functionality was picked up by something else). I'm not sure how to > arrange an upgrade to this new version. On the one hand, no one wants to > maintain the old stuff anymore, so it should disappear from the Debian > distribution. On the other hand, if a sarge->etch upgrade potentially throws > away a bunch of functionality and data, users won't be happy. > > What to do? With a giant blob of software like egroupware every admin should be well aware that an update might require some manual interaction. We give users a full year to upgrade to the next stable release, so I'd suggest to just drop it. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#377697: New version of squid hangs at startup
Luigi Gangitano wrote: > Since this is a compile time choice and kernel 2.4.27 is still in the > archive we have the following options: > > 3. drop support for older kernels (will etch release with a 2.4 > default kernel?) > > Please give your advice. Etch will only support 2.6 kernels, so anyone still insisting to run Etch-squid with 2.4 kernels for whatever reasons, may still disable epoll() support locally. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#379857: ITP: git-completion -- content addressable filesystem (bash completion)
Sebastian Harl wrote: > * Package name: git-completion > Version : 0+20060722 > Upstream Author : Ben Clifford <[EMAIL PROTECTED]> > * URL : http://www.hawaga.org.uk/ben/tech/gitcompletion/ > * License : GPL > Description : content addressable filesystem (bash completion) > > git is a stupid (but extremely fast) directory content manager. It doesn't do > a whole lot, but what it 'does' do is track directory contents efficiently. > . > This package contains the bash completion for git, cogito and stg. Why should this be a separate package? Either include it in the bash package or into the /etc/bash_completion.d of git, cogito and stg. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326797: ITP: pentagram -- Engine for Ultima VIII: Pagan
Package: wnpp Severity: wishlist Owner: Moritz Muehlenhoff <[EMAIL PROTECTED]> * Package name: pentagram Version : CVS snapshots Upstream Author : W. J. Palenstein, P. Burke, M. Horn, R. Nunn, D. Reichardt, M. Jimenez * URL : http://pentagram.sourceforge.net * License : GPL Description : Engine for Ultima VIII: Pagan Pentagram is a free engine for playing "Ultima VIII: Pagan" on modern operating systems. Although there are reports of people having completed the game, the engine still has rough edges and is not yet ripe for a stable release, but could profit from more wide-spread testing. Pentagram requires the original game data, so it's targeted at contrib. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: curl status update
In linux.debian.devel, you wrote: > That's actually not true, GnuTLS has the reverse licensing issues from > OpenSSL. OpenSSL cannot be linked with GPL-licensed software; GnuTLS, > OTOH, is licensed under the GPL (as opposed to the LGPL), Only some extra features not present in OpenSSL (like SRP auth) are licensed under the GPL, the rest of the code is LGPLed. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages that need to be rebuilt agaisnt libssl0.9.8
In linux.debian.devel, you wrote: >> a lot of people bugged me about the new version and upstream only recommends >> this version. It also closes a grave security bug. > > Hm, that wasn't listed in the changelog. Anyway, there hasn't been a security > advisory about openssl recently, did you backport a patch to the sarge version > (and prefereably also, to the woody version) and informed the security team? Christoph is probably referring to CAN-2005-2946 and bug #314465, which is about the fact that MD5 is the default digest algo in openssl. This bug has an inflated severity, it's not overly urgent. There have been several collision attacks on MD5 (i.e. you can create a foo/bar pair, which share a common hash), but no second preimage attacks have been demonstrated so far (i.e. creating a bar, which shares a hash with a given foo). Several exploits have been derived from the basic collision attacks, though, (google for Kaminski or Daum/Lucks for some cool demonstrations), but it's not as grave as it might appear. Upgrading to SHA-1 is still a good idea, of course, but no need to break things more than necessary. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages that need to be rebuilt agaisnt libssl0.9.8
In linux.debian.devel, you wrote: > Moritz Muehlenhoff wrote: >> Upgrading to SHA-1 is still a good idea, of course, > > Correct me if I'm wrong, but haven't there been collision attacks on > SHA-1, too? Yes, but to public knowledge they're only feasible with government grade hardware, while MD5 is subject to attacks with much lower complexity. There might be an AES-like competition for the next-gen hash in 2006, but I'm not sure if it has been decided yet. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages that need to be rebuilt agaisnt libssl0.9.8
In linux.debian.devel, you wrote: >> beneficial to at least document such security issues, by informing security >> team, filing an RC bug on your own package, and mentioning the CVE ID (or at >> the very least, a short description of the bug fixed) in your changelog >> entry. > > It is documented in bug #314465. But it is not really a bug which you > can fix by backporting. It's about MD5 hashes being insecure. I talked > with upstream about the issue and follow their arguments: Well, it's not that MD5 is secure in 0.9.8, it's just that the default hash has been changed. So changing /etc/openssl.cnf's "default_md = md5" to "default_md = sha1" would have the same effect, as sha1 is already present in 0.9.7; only the more complex SHA variants have been introduced in 0.9.8. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely (Was: State of the project - input needed)
Andreas Tille wrote:
> What would you suggest to enhance the situation?
Each maintainer may be familiar with his pet patch system, but for
archive wide work I agree the current approach is a mess and makes
security updates painful. Since it's unlikely to change anytime soon,
each source packages, which uses something else than a plain diff.gz
(which can be fixed transparently), should be mandated to have a
/usr/share/doc/PACKAGE/README.NMU, which describes how to deal with
the relevant patch system, especially:
- Through which hoops do I have to jump to create a patch? (dpatch e.g.
is horribly counter-intuitive)
- Do I need to register the patch in 00list or another obscure place
or are all patches in debian/patches applied?
- If I have to patch a file, which is patched in an already existing
patch, how can I get a clean state to diff against?
(For dpatch and quilt this could be solved by adding a symlink to a
standard file provided.)
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#462740: ITP: demac -- A decoder for Monkey's Audio (APE) lossless files
William Pitcock wrote:
> demac has some bugs with v3.97 format files. I would recommend merging
> in patches from ffmpeg and making a seperate product.
Or rather avoid packaging demac at all and link the application
in question against libavcodec.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
Pierre Habouzit wrote: >> Fortify Source >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> This feature adds validation for internal C functions such as strcpy >> for buffer sizes known during compile time. While vulnerabilities in >> the functions it protects have become uncommon in high-profile apps, >> it will be useful for fringe packages we have in the archive. >>=20 >> This feature is present in glibc since version 2.5, and is enabled >> through the use of "-D_FORTIFY_SOURCE=3D2" and "-O2" or higher. >>=20 > > Well, -D_FORTIFY_SOURCE=3D2 is a severe performance loss in many > applications, and I wouldn't recommend activating it by default. =3D1 has > not the drawback with that regard though, but is less useful security > wise (though it catch many programmatic issues, and full archive rebuild > with -D_FORTIFY_SOURCE=3D1 would be worthwile independently of this). There are certainly performance trade-offs involved and the final selection of features will depend on the testing of the respective maintainers (testing should be eased by hardening-wrapper). hardening-wrapper makes it simple to enable/disable selective single features, if anyone wants to run specific benchmarks on the overhead, please post them to the Wiki. We're mostly trying to bootstrap a discussion here, the details on how to put this into effect archive-wide will depend heavily on the toolchain configuration proposal by Matthias Klose. Maybe "classes" of security-sensitivity of applications can be defined, which specify a set of selected options. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
Thomas Bushnell BSG wrote: > For my money, you blew it. You don't bootstrap a discussion by > presenting a pseudo-official email like the one you posted. But we can > get back to that discussion: cancel the email by saying "whoops, we're > not ready yet" and then having the discussion first. Of course we've discussed this in depth internally before before proposing it and there was no intention to make it sound "official". There is no need to become aggressive. To resolve potential confusions I've sent a clarifying followup. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moritz Muehlenhoff wrote: > The Debian archive is the biggest of all distributions and although > there's security support for all security issues being found, there's > still room for improvement and a need for increased resilience against > flaws not yet discovered. > > A group of people have been working on introducing advanced security > hardening features into our archive: > http://alioth.debian.org/projects/hardening/ > > We recommend to activate the following features in individual packages > for now and discuss how to enable them system-wide later. (Matthias > Klose proposed a mechanism in debian-devel, which could be used for > it: http://lists.debian.org/debian-devel/2007/12/msg00090.html). Concern was voiced that this proposal may sound like a call to maintainers to enable all these features directly. This was not our intention. At this point we mostly want to introduce the available solutions. Whether there will be an archive-wide global pre-selection of features and with which features will of course depend on the testing of the respective maintainers and discussions on debian-devel. Please participate in the discussion if you're intested in that matter. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHn7KTXm3vHE4uyloRAommAJwKyNlc4B/+Gkc8SsY4EuIoP3WzAACeN4XL Tych5TntCEobLJH+fKttpiI= =l7DO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
Kees Cook wrote: > Does anyone have any good test harnesses we can try this on? I'd be > more than happy to run them on some modern hardware. Video: mplayer with the -benchmark option in conjunction with -nosound and -vo. HTML rendering: Mike Hommey once blogged about benchmarking the ACID test: http://web.glandium.org/blog/?cat=17 Nexuiz: | To run the benchmark: start Nexuiz & open the console (`) issuing: | timedemo demos/demo1.dem The results will be stored in: | ~/.nexuiz/data/benchmark.log Not sure about XML benchmarks. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposalto introduce compiler options passed from dpkg-buildpackage
On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > Matthias Klose wrote: >> This is a proposal to introduce a common set of compiler options which >> can be set independently from the package, and passed/injected to the >> package build process. It was first discussed at the last UDS; a >> corresponding wiki page can be found at [1]. > > A change like that is more or less required for the planned introduction > of security hardening features. Since noone really objected to the change > outlined, I'd be interested in the way forward from here and what timeline > is planned to set the changes into effect. Matthias, what's the status? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
Riku Voipio wrote: >> In kernels that support text ASLR, programs compiled >> for PIE will gain full position randomization. > > For which architectures is text ASLR available? does it require > external kernel patches? PIE means considerable system overhead > and fatter binaries, especially for systems without large > caches. I'm only aware of x86 and amd64. I don't think it's necessary on other archs. Did you followup with upstream on the SSP problems we've seen on ARM? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
John Goerzen wrote: > However, I am concerned that is appears to be limited in scope to packages > that: > > * Are written in C or C++ > > * Can have hardening achieved through technical changes to the build process > > I think it is important to remember that other languages can have security > problems too, perhaps just as easy as these (shell). Sure, but we're trying to optimise for the common case here. Everyone is welcome to start systematic security enhancement efforts for other languages (like, checking all existing Python code for insecure sub process invocation or something similar). An important reason is that some features (SSP and FORTIFIED_SOURCE) allow us to lower the amount of needed work to fix security issues. There have been several vulnerabilities which are non-issues on e.g. RHEL5, which has both enabled. The ASLR changes are icing on the cake. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wnpp.debian.net sources released, security review wanted, plans for the future
Sebastian Pipping wrote: >> Not sure what you had in mind for a "feed". If you mean RDF/RSS of >> DSAs, there are two here: >> >> http://www.debian.org/security/ The recommended way is to subscribe to [EMAIL PROTECTED] > Is there a way to get notified of new security > bugs right when they are opened? You can install debsecan, which generates reports on open security issues and which includes BTS bugs tagged security as well. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposalto introduce compiler options passed from dpkg-buildpackage
On Mon, Feb 11, 2008 at 05:44:33PM +0100, Matthias Klose wrote: > Moritz Muehlenhoff writes: > > [This message has also been posted to gmane.linux.debian.devel.general.] > > On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > > > Matthias Klose wrote: > > >> This is a proposal to introduce a common set of compiler options which > > >> can be set independently from the package, and passed/injected to the > > >> package build process. It was first discussed at the last UDS; a > > >> corresponding wiki page can be found at [1]. > > > > > > A change like that is more or less required for the planned introduction > > > of security hardening features. Since noone really objected to the change > > > outlined, I'd be interested in the way forward from here and what timeline > > > is planned to set the changes into effect. > > > > Matthias, what's the status? > > thanks for the reminder; I did update the proposal and renamed the > environment variables to what Colin Watson did suggest. Bug #465282 > now has a patch for dpkg-architecture attached. That looks good to me. Maybe we should have individual default flags per architecture, so that features, which are buggy or not fully implemented on a given arch can be disabled so that the workarounds don't need to be done by the maintainers across several rules files? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposalto introduce compiler options passed from dpkg-buildpackage
Loïc Minier wrote: > On Thu, Feb 14, 2008, Frank Lichtenheld wrote: > > Hmm, I doubt that dpkg-dev should be the place to keep track of that. > > I mean, that probably depends on the version of gcc/g++/whatever used, > > so it's quite meaningless to make it dependent on the version of > > dpkg-dev you use. > > Should we have a new "default-flags" package or something which would > be the place where these flags are set? Perhaps queryable with: > get-default-flags --gcc > get-default-flags --ld > etc. Matthias, what about adding such a get-default-flags script into the gcc-defaults package? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
Steve Langasek wrote: >> The Security Team is now using Request Tracker to coordinate work >> and our RT processes have already been refined a lot. >> If you're a package maintainer working towards a security update, >> you're now encouraged to open a ticket directly. You will be kept in >> CC during the life time of the ticket. If you're opening a ticket for >> a security problem, which is not yet publicly known, e.g. if you've >> discovered it by yourself or if you have been contacted by upstream, >> please open a ticket in the "Security - Private" queue. These >> issues will only be visible by the Security Team. > >> If you're opening a ticket for a security problem which is publicly >> known, e.g. if it's announced on the project web site, please open a >> ticket in the "Security" queue. These issues will be visible publicly. > > As far as I can see, this announcement mail doesn't mention where the RT > instance is running, nor the means of opening a ticket in the appropriate > queue. Where is this information available? We're using the official rt.debian.org. Full details will be folded into the developer's reference soon. >> We're planning to improve our quality assurance process for security >> updates by providing a public security update beta test program in >> addition to the existing QA done for security updates. >> During the preparation of security updates, there's an inherent delay >> between the initial upload of the fixed packages and the time until >> the packages have been built on porter machines. This time gap will be >> used for a new security update beta program. The test program will be >> targeted at large installations, which install security updates in a >> test environment before installing them into the production >> environment. This test group will be initially limited. > > Is this meant to apply only to unembargoed security updates? AIUI, the > practice today is that for embargoed security updates, all of the binaries > are kept in the queue until they're ready for release; so I don't really see > a gap when the security update is public but the binary packages aren't > built? Yes, this is limited to non-embargoed security issues. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
On 2008-03-11, Don Armstrong <[EMAIL PROTECTED]> wrote: > On Sun, 09 Mar 2008, Moritz Muehlenhoff wrote: >> If you're opening a ticket for a security problem which is publicly >> known, e.g. if it's announced on the project web site, please open a >> ticket in the "Security" queue. These issues will be visible >> publicly. > > Is there any particular reason why we're duplicating this information > that should already be present in the bts as bugs with severity > serious tagged security marked found in a version in stable in RT? > > If there are some change to the BTS needed for the security team to > track the non-embargoed issues more easily, I'd be glad to make (or at > the very least discuss) them. > > From where I sit it seems non-ideal for both the security team and > maintainers (as well as anyone else who is interested) to put this > information in a system which isn't tied in strongly with the BTS or > otherwise is unable to track package versioning. This doesn't intend to duplicate information from the BTS. The RT queues even contain direct links to the BTS. RT is used to distribute work among the members of the security team and to keep pending issues more organized. RT mostly replaces sending to mail to [EMAIL PROTECTED] if a maintainer wants to assist in preparing a security update. Mail doesn't scale very well, so we've had occasional smaller issues being lost in the noise. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version numbering for security uploads of native packages
On 2008-03-16, Adam D. Barratt <[EMAIL PROTECTED]> wrote: > On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote: >> The current binNMU numbering scheme was selected explicitly to allow >> security uploads to sort later by numbering as >> +; e.g., 1.2-5.1+etch1. > > That makes sense, although doesn't seem to match current practice. Was > any consideration given as to where NMUs of native packages should sort? > (I realise that they're the only case that doesn't automagically dtrt > with respect to the numbering scheme). We'll adapt our practise to use +etchX for security updates. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A suggestion
On 2008-04-03, Mike Bird <[EMAIL PROTECTED]> wrote: > On Thu April 3 2008 03:03:51 Matthew Johnson wrote: >> On Thu Apr 03 11:54, Andrea Bolognani wrote: >> > And stable is not fine for a desktop in general, because it has outdated >> > packages which are not what a desktop user wants. >> >> _you_ may want more up to date packages, but a lot of people are >> entirely happy with etch on their desktop. For example, both me and my >> mother. >> >> I'd also go as far to say that most corporate Linux desktops, to pick >> another example, would welcome the lack of change for 18 months. > > Stable is a poor solution for desktops because it doesn't support > recent hardware. For a long time now we've had to run Testing > mixed with the Unstable versions of xserver-xorg.*, nvidia.*, and > linux-image.* in order to support recent video and audio chips. http://wiki.debian.org/EtchAndAHalf will solve that soon. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#471094: RFH: mantis
On 2008-04-03, Hilko Bengen <[EMAIL PROTECTED]> wrote: > Patrick Schoenfeld <[EMAIL PROTECTED]> writes: > >> as upstream is considering some changes in the upgrade path that will >> make upgrading with pure sql files quiet hard and they never really >> supported upgrading through pure sql files (and therefore dbconfig-common) >> I could need someone to help with maintaining mantis. > > Assuming that upstream is considering these changes for the 1.1 > release, you may want to consider renaming the current mantis package > to mantis-1.0 and starting with a separate mantis-1.1 package. Only one version should end up in Lenny, though. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GnuPG: Maintainer inactive?
Michael Banck wrote: > On Wed, Apr 16, 2008 at 02:19:12PM +0200, Kai Wasserbäch wrote: >> on the 1st of April I wrote an e-mail to James Troup offering my help in >> hunting >> down open bugs which are no longer present an thus enabling him to >> concentrate >> on packaging GnuPG 1.4.9. But his last action regarding this package is well >> over an year old and the only updates I can see in the PTS were made by the >> Security Team. And before I forget to write it: I didn't receive an answer. >> So my question is: Is James known to be inactive? Are there others currently >> on >> the task to get a new version (upstream has 1.4.9) into Debian? Is there >> anything I can help (I'm certainly not suitable as a maintainer for that >> package >> myself, because it's too essential to be entrusted to someone who is unknown >> to >> (nearly) all people on this list) with, e.g. by triaging bugs? > > I guess triaging bugs (i.e. marking bugs which have been fixed upstream > in newer versions as "fixed-upstream" or mention bugs which can be > closed already cause they are fixed in the current version in the > appropriate bug (CCing the submitter, so they can possibly close it > themselves) is always welcome, regardless of any other action or > non-action by the maintainer. gnupg is very important and unmaintained for all practical purposes. It should be hijacked and brought into shape for Lenny. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pwsafe and OpenSSL?
Daniel Burrows wrote: > I notice that pwsafe is linked against openssl. Is it affected by the > recent debacle and if so, how? Do I need to regenerate all my > randomized passwords, or somehow re-encrypt the pwsafe database? I've looked briefly into it: The Blowfish encryption key is constructed from a SHA1 built from an initial random value, two zero bytes and the passphrase. So if an unmodified database created using a broken libssl copy is exposed to an attacker, it's more open to brute forcing attempts, but still safe-guarded by the passphrase. Fortunately the random part is renewed whenever the database is saved. By my understanding - I don't use pwsafe myself - this should happen whever an entry is added or modified. Please double-check that with upstream and send a finalised version to [EMAIL PROTECTED], so that we can add it to http://www.debian.org/security/key-rollover/ once confirmed. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Joey Hess wrote: FWIW, I like the general idea of tracking upstream diverge with a bug. > Mike Hommey wrote: >> The BTS would also need something to make it easier to spot patches in a >> bug. Patch tracking is one of the few things bugzilla is not bad at, for >> instance. > > I guess you're talking about a way for the BTS allow downloading of the last > (or preferred) patch sent to a bug. And not just deciding when to set > the "patch" tag. That would be useful for the QA tool that checks if > divergence's patches match the debianised source. Dunno if it's > mandatory, the tool could also use heuristics, or try every attachment > that looks like a patch and see which, if any, match. BTS currently has two deficiencies compared to Bugzilla when it comes to handling patches: - No defined way to store patches (and fetching them automically) Some people add them as attachments, some people inline them in a mail, some send an archive etc. And some PHP people send full modified sources :-) - Bugzilla has the neat feature to mark a patch as obsoleting a previously posted bug, which is often very helpful in complicated bug with several rounds of review and fixups Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#538857: rocksndiamonds: post-installation fails
On Mon, Jul 27, 2009 at 09:15:00PM +0400, Dmitry E. Oboukhov wrote: > >> The site www.artsoft.org is (temporary?) down. Why do You think it > >> must be another way? Postinst returns error code because it can't > >> download resource. Other packages (for example msttcorefonts) have > >> the same behaviour. > > GLB> Do You think I shouldn't have report that problem? > I think this is site's problem, i considered a few packages which > download something from somewhere and all of them return errorcode > when downloading fail. > > Of course we can complain of something like: > - our provider provides us with bad connection; > - the website we have link on is down. > but does it refer to the specific package? Hmm... > > But I still don't know is this behavior is right. If the script > doesn't return failcode, somebody could post the bug like 'I had no > fail when I installed the package, but it doesn't work', even if he > had seen the error message. > > I Cc-ed the mail to debian-devel: may be somebody gives us advice. Again, as in the case of the broken rott download, the correct fix is to add support for the media files to game-data-packager instead of adding a postinst. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is it time to remove sun-java6?
On 2009-10-08, Barry deFreese wrote: > Hi folks, > > A few of us have been discussing the removal of sun-java6. It is > non-free, orphaned, buggy (including security bugs), and can generally > be replaced by openjdk. There are only three reverse depends left and > none of them directly depend on sun-java6 but instead dep on java6-runtime. > > There has also been some similar discussions in Ubuntu with some users > reporting that some web sites and packages don't work with openjdk but I > have not seen a lot of concrete proof. > > My personal feeling is that we either need to remove it or fix it up. > > Any thoughts? We should remove it, it'll be EOLed during the Squeeze time frame and noone can sensibly fix it. (It's not covered by official security support, though due to being non-free) Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
["Followup-To:" header set to gmane.linux.debian.devel.general.] On 2009-11-05, Kees Cook wrote: >> The majority of distributions does turn on these options during >> package build time, which IMO is the right thing to do. Debian >> should do the same. There's now Raphael's new framework in place >> which makes the injection of macros in dpkg-buildpackage in the >> environment obsolete. > > This would certainly be better than nothing, and better than the > hardening-wrapper package, but it would require that every package in > Debian be modified to respect external environments. Also, I think > having the compiler itself be hardened is the bigger win. If doko feels uncomfortable with appyling the patches, we should use the dpkg-buildpackage way (which I'm technically fine with). It also has the nice side effect that we get a central place where we can opt out architecture which don't implement a specific hardening feature. It also allows maintainers to specifically opt out in cases where they feel the overhead to be inacceptably high. (e.g., a number-crunching math application). > Out of curiosity, where can I and others find the documentation for the > dpkg-buildpackage environment framework? We should immediately add the > hardening options to it now for the packages that it will work on. See dpkg-buildpackage(1) in the section "ENVIRONMENT VARIABLES" What flags do you intend to enable? -Wformat, -Wformat-security, -D_FORTIFY_SOURCE=2 and -fstack-protector ? Could you file a bug against dpkg-dev? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: about gstreamer0.8 and python2.3 removal
Tshepang Lekhonkhobe wrote: [I wanted to evaluate gstreamer 0.8 this weekend anyway, due to the recent amount of newly discovered libavcodec vulnerabilities, thanks for raising it independantly; this save quite some time] >> > Pretty surprising. Was there a discussion in which this decision was >> > made or is this just the assumed position? >> >> <http://lists.debian.org/debian-devel/2006/12/threads.html#00131> > > I saw that thread which seemed to die off without a clear indication > of the decisions taken as regards removal, hence 'assumed' position: > One guy wants gst0.8 removed and another wants to keep it in due to > goobox, there's some arguments, and.. nothing (not even mails to > release or security team). > > This situation is similar to the GNOME 2.14 vs. 2.16 for Etch thing > that I only noticed accidentally, or perhaps some people assumed > everybody reads planet.debian.org and other DD blogs... An exception was granted because gst-ffmpeg is an important infrastructure package. However, this can hardly be said for gst-ffmpeg-0.8; muine and teatime have already been easily fixed and goobox seems dead upstream. (According to http://www.gnomefiles.org/app.php?soft_id=531 the last upstream release is from Nov 2005). I'll file an RC bug for hinting it out of testing. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling of (inactive) Debian Accounts
Jon Marler wrote:
> I have a question ... How do I keep my Debian maintainer status if I
> miss the vote?
A more relevant case are probably people, who don't care about the
annual time-drain aka DPL election.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
Tim Brown wrote: >> Nope since he that did not go to d-d. Maybe you can outline professional >> uses in the description like done in the previous answers? > > As to previous answers, verbatim: > > I'm packaging a bunch of security tools that I use in my job pen testing. (..) > companies using my packages, so I figured they'd be useful to the community. Which other tools do you intent to package? >> IANAL but there may be countries where distributing such a tool, with it's >> main/only purpose to break access restrictions, may not be legal (there was >> some discussion about this in Germany but I did not follow it closely). > > The upstream developer is German, I will discuss with him any due diligence > he > may have performed and report back (he's AFK for next week or so). The bill hasn't been decided yet. The current state of affairs can be found here: (German language only) http://dip.bundestag.de/extrakt/16/019/16019307.htm Several useful tools packages will no longer be distributable; but this only affects German mirror operators and CD vendors, not Debian at large. It's not yet clear, whether it will be illegal to test a security update with a reproducer exploit. Funnily, the BSI - the German government agency for IT security - provides a pen-testing CD with free software security tools for download: http://www.bsi.de/produkte/boss/index.htm They also have taste and run Debian on a part of their systems: http://www.bsi.de/produkte/erposs/index.htm Anyone with good connections to German government bodies running Debian (and there are quite many) should use their contacts to lobby against this bill. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The number of etch installations is rocketing...
Johannes Wiedersich wrote: > Presently the number of installations reported to popcon is about the > same as the number of subscriptions to debian-security-announce, but I > am sure there are many users of debian who don't read d-s-a and many > users, who have several -maybe hundreds- of installations and subscribe > only once! :-) I don't believe it's a useful metric: The two most popular security mailing lists (Bugtraq and full-disclosure) are subscribed to d-s-a and there are plenty of other multiplicators (CERTs, internal mailing lists, web sites). Plus, many people install security updates blindly. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wordpress packages
Russell Coker wrote: > Getting the entire collection of Wordpress plugins (or any significant > sub-set) audited for security issues seems quite unlikely. Getting a smaller > collection of plugins which are packaged for Debian audited in such a manner > would be much easier and therefore much more likely. In reality they'll be included unreviewed, the maintainer will lose interest half a year after the stable release and the security team will have to deal with all that junk every couple of months. So, don't do that. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#426069: ITP: spip -- website engine for publishing
Romain Beauxis wrote: > * Package name: spip > Version : 1.9.2b > Upstream Author : SPIP Development Team <[EMAIL PROTECTED]> > * URL : http://www.spip.net/ and > http://trac.rezo.net/trac/spip/ > * License : Mainly GPL and other open source licences > Programming Lang: PHP with some JS > Description : website engine for publishing > > SPIP's benefit consists in: > . > * managing a magazine type site i.e. made up mainly of >articles and news items inserted in an arborescence >of sections nested in each others. > * completely separating and distributing three kinds of tasks >over various players: the graphic design, the site editorial >input through the submission of articles and news items and >the site editorial management. > * spare the webmaster and all the participants to the life of >the site, a number of tedious aspects of web publishing as >well as the need to learn lengthy technical skills. >SPIP allows you to start creating your sections and >articles straight away. This was already in the archive and has been removed mostly for it's poor security track record. Re-introducing it is a very bad idea. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#426069: ITP: spip -- website engine for publishing
Romain Beauxis wrote: > However, I'll contact them and ask for their commitment to solving seciruty > issues, but I'm quite sure that the main issue remains in the hand of the > maintainer, to be able to update the package as soon as they fix anything.. It had too many security problems in 2006. We already have far too many buggy packages in the archive, security updates are not an infinite ressource. I recommend to upload to experimental and re-evaluate it's security history four months prior to Lenny freeze. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#428877: ITP: callweaver -- Community-driven open source PBX software
Santiago Ruano Rincón wrote: > CallWeaver is a community-driven vendor-independent cross-platform open > source PBX software project (formerly known as OpenPBX.org). It was > originally derived from Asterisk. Now it supports analog and digital > PSTN telephony, multi-protocol voice over IP telephony, fax, > software-fax, T.38 fax over IP and many telephony applications such as > IVR, conferencing and callcenter queue management. So, this is intended to replace asterisk? Given that the VoIP team fails to provide the necessary support for security updates even for Asterisk and given the steady flow of security issues in it, we can't have two versions in the archive. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Michael Vogt wrote: > unattended-upgrades comes with a default configuration that will only > apply security updates (but it can be configured in any way people > want) and it will do some careful checking to not upgrade packages > that require manual intervention bia conffile prompts. It will also > check that a security update does not bring in a new package from a > non-security source, not break the cache and offer logging/mail of > the changes to the administrator. It is designed to integrate nicely > with update-notifier and the apt cronjob. Unattended security upgrades are not supported; while we can typically fix security problems w/o requiring manual user interaction, we cannot guarantee it all cases. The user needs to read the DSA. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
Bastian Blank wrote: > Xen got a often used technique in the last two years. All of the large > distributions got some sort of support for it. Debian Etch have full > support for it. There was several requests of various people so I think > not providing at least a minimal support in Lenny is wrong. > > I think option 4 would be the solution which produces the least amount > of extra work and provides our users with support for there systems. I > would provide the necessary packages but I want an okay for that > solution from the security and the release team. Since there's now a sixth option - the forward-ported XenSource patch to SLES's 2.6.26 - could we test this patch before we decide on a plan? To me using the forward-ported SLES patch for Lenny and switching to pvops post-Lenny seems ideal. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: clamav
Stephen Gran wrote: > This one time, at band camp, Stephen Gran said: >> I'm looking for people to help with maintenance of clamav. > > So, I got a total of one reply to this RFH. I'm currently debating > whether or not to release clamav with lenny or orphan it. I don't think > I'm interested in taking it through the next stable release on my own, > so an orphan looks likely, but I'm interested enough to want to be part > of a team if anyone else is interested. If you're interested in seeing > it release, please contact me off list. I've mentioned it before, but it didn't come to any real conclusion: I think we should only support clamav through volatile.debian.org and not through the regular archive. It has happened twice that clamav became unusable through the lifecycle of a release (Sarge's version failed to parse malware signatures since later releases required more advanced engine features and Etch's version is unusably slow for the same reason #454587) and we shouldn't repeat this for a third time. Only providing current versions through volatile will also be less work than all the backporting that's currently being done. There're a few libclamav reverse-deps, which need to be adressed, though. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#496386: The possibility of attack with the help of symlinks in some Debian packages
Christian Perrier wrote: >> This is far below the quality I expect from a mass bug filing that's been >> reviewed by debian-devel. Mass bugfilings at RC severity need to be held to > > Even though I overread the thread when Dmitry posted his intent to > -devel, I feel like there was *no* strong agreement that this MBF was > really wished and welcomed. It is very welcome and I disagree with the complains voiced so far. Yes, the template is subobtimal, he didn't set a "security" tag, but most of the issues I've reviewed so far are genuine problems. There're certainly not more false reports than the "bogus ratio" of bugs filed by regular users. > I should also have added that I personnally strongly object to it for > three reasons: > > - timing wrt the release > - timing wrt the "half of the developers are VAC" status we generally > have in August So, what's the solution you propose instead? Issues lots of DSAs post-release? Keep them under the carpet? > It may sound like acting against the "we will not hide problems" item > in the Social Contract, but I wouldn't be shocked if *all* these RC > bugs are downgraded to important (I would even downgrade them to > wishlist, see the example that made Neil react). > > If I come on any such bug on packages I maintain or co-maintain, I > will immediately downgrade the bug report in such way, mentally > thanking the bug submitter for the extra work and ranting about yet > another nice method to delay the release. Let's be old-fashioned and fix things instead. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Volunteer needed for Iceape security updates in Lenny
A volunteer is needed to build and test the Iceape security updates in Lenny. Patches are provided through a patch set for each update round, but the Security Team and the Mozilla maintainers lack the ressources for the proper integration work. So if you use Iceape and want to continue to use it in Lenny please step forward and mail [EMAIL PROTECTED] and keep [EMAIL PROTECTED] CCed. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Robert Millan wrote: >> > > Has the current release team lowered the bar on Debian actually >> > > trying to follow the social contract? >> > >> > Yes, they have. >> >> What if, instead of ranting everywhere, you actually contributed code to >> fix these bugs? > > I did... You contributed one(!) - untested - patch for e100 and did nothing for the rest since beginning of August. These bugs were tagged "help" by the Debian Kernel Team since the same day you filed them. The same team, which is already heavily overworked and which already fixed/pruned lots of drivers with the 2.6.23-1 upload. If it were really important, why didn't you start with this directly after Etch release? Why didn't you do anything substantially since two and a half months? Where are your patches working on these issues upstream? If it is so important to you, why didn't you even notice that all this firmware separation work is already going on upstream led by David Woodhouse? (The same applies to Nathanael Nerode, who never did a thing to get all this resolved instead of pestering around) > ...but you missed the point. They're not wishlist bugs. If they were, I > wouldn't care much about them. Well, bugs don't get magically fixed. You didn't do anything substantially about them, so you can hardly complain. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug Sprint results (draft)
Stefano Zacchiroli wrote: >=2E.. hence, given that Lenny hasn't been release yet, when are we gonna > make another one? :) Let's make it a Beer Sprint. The winners receive a package with the local brew from the people who didn't manage to fix their bugs. I'm offering German beer to five winners, just as Joss did for cookies. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#504758: gforge-plugins-extra ships security issues-prone code copies
Roland Mas wrote: > tag 504758 + help > The way I see it, there are three ways out: > > - prepare a new upload that doesn't contain this binary package, and > leave users with the task of getting the code from the source > package and installing it by hand; > > - ignore this bug for lenny, since one could argue that the code isn't > actually made operational by the mere installation of the package; > > - actually patch the code to use system-provided packages, and update > dependencies accordingly. This has already been done for some > libraries (Snoopy and FCKeditor), and it's not a huge task, but I > probably won't have time to tackle it before the lenny release > (real-life time constraints abound). Both the first and the second option seem fine. If you choose the second, please upload a package, which adds a README.security (or add it to README.Debian if present), which describes that these plugins need to be configured and maintained by the local admin. We'll than add it to the debtag list of packages not covered by security support. For Squeeze we can then switch to the system wide packages. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail and related packages in NEW
Neil Williams wrote: > It isn't just about choosing not to install it, it causes work for the > various teams in Debian - security, release, QA.=20 We've discussed this at the Security Team meeting in Essen and we don't have a problem with qmail being included in Lenny. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail and related packages in NEW
On 2008-11-29, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > >>> It isn't just about choosing not to install it, it causes work for the >>> various teams in Debian - security, release, QA.=20 >> We've discussed this at the Security Team meeting in Essen and we don't >> have a problem with qmail being included in Lenny. > > Are you aware that qmail and its related packages do have a LOT of code > duplication? Someone tried to reinvent a libc or something, and just > copies it into every package. One bug means fixing all those packages at > once. Which? AFAICS it has some portability layers and you typically need daemontools for djbware, but I don't see any horrible code copies. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gtk1.2/Imlib/gnome-lib packages (Long)
Barry deFreese wrote:
> Just in case anyone cares/is interested, here is some work I have been
> doing on packages using Gtk1.2, Imlib, gnome-libs, or any combination
> thereof.
Thanks.
Could you fold this into a page on wiki.debian.org, so that people
can add their specific solution attempts or actions? Such a useful
list will likely be lost in the noise in some weeks and through a
wiki it can be updated more easily.
Actually, it would be nice if we had a decicated cleanups/transitions
overview page on wiki.debian.org as a central starting point for
people who want to help out.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Etch and a half" ( was Re: Bugfix/hardware support updates to stable releases?)
Tim Hull wrote: > Anyway, I'm curious - is this still a legitimate consideration within > Debian? Yes. > If it were to be done, it would have to be December/Januaryish (any That's the plan. > Thus, one wouldn't HAVE to upgrade, but > new users and anyone standing to benefit from a new X/kernel (and possibly > some other bugfixes) would want to consider using the new "etch and a > half". That's the plan. > I think this idea would definitely benefit Debian - more people > would be able to use it, and it would remain quite stable while still > supporting the latest hardware. Yes. > However, I think it's worth consideration - in my > mind, this would fix Debian's greatest flaw Yes. Cheers, Moritz -- 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 wrote: > Surely packages.debian.org is not a good example of a site with > generally few Debian users. > > The scenario seems more likely to me on small non-technical sites that > only a few Debian unstable users are likely to visit. For special fun, > try browsing from an unusual architecture; that's in the user-agent > string too. http://linuxreviews.org/news/2005/01/28_0001/ Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Testing Security team
On 2007-10-15, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > > --MGYHOYXEY6WxJCY8 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Oct 15, 2007 at 11:29:16AM +0200, Stefano Zacchiroli wrote: >> So, question, do you want to have reports also of missing pieces of >> statically linked code snippets in that list? Yes, this list has always included apps linking statically. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enabling and installing of "risky" ("patented") codecs - made easy
Fabian Greffrath wrote: > You all know about the unsatisfying situation of some codec libraries > that are commonly called 'risky' or 'patented'; namely lame, xvid and > friends. While being perfectly free software on the one hand, licensed > under the GPL or LGPL, they are surrounded by a cloud of patent FUD or > even actual threat, which makes them unsuitable for Debian's main > section [0]. Nevertheless on the user's side there is a demand for those > codecs which can be whitnessed by the broad acceptance of unofficial > repositories [see: http://popcon.debian.org/unknown/by_inst ]. > Furthermore, there is nothing that might hold users back from using this > software in Europe, because IIRC software patents do not exist on this > continent. We should just create a separate archive like non-us, e.g. non-pat, which's primary host would reside somewhere where multimedia software patents are moot. (I suppose france would be alright, since debian- multimedia is hosted there). d-i should offer to add these sources. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Security Team
Adrian von Bidder wrote: ><http://blog.steve.org.uk/articles/2007/10/19/as-i-move-on-through-the-year= >>=20 > which is really a Bits from the Security Team. Full "Bits" will appear soon. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#447592: RFP: fckeditor -- text/file editor for PHP
Roland Mas wrote: > Nico Golde just contacted me about a problem found in the FCKeditor > code that's shipped in the Gforge package. Apparently, there's at > least one other package that ships this code (knowledgeroot), so the > code is effectively duplicated. It would be better for everyone if > that software was packaged independently, and others could just depend > on it. Indeed. karrigell and moin appear to include a copy as well. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Out-of-tree kernel module popularity
Ben Hutchings wrote: > >> Nevertheless on the user's side there is a demand for those=20 >> codecs which can be whitnessed by the broad acceptance of unofficial=20 >> repositories [see: http://popcon.debian.org/unknown/by_inst ].=20 > > > I didn't know that table existed! It seems like it would be useful to > aggregate statistics for out-of-tree kernel module packages by stripping > off the kernel version suffix. Here's what I came up with: Nice list! If anyone has some time, it would be valuable to work through the list and check, which of these have been merged into Linux mainline by now (e.g. several of the wifi drivers have) and report the missing ones to Greg Kroah-H's driver project: http://www.linuxdriverproject.org/twiki/bin/view He has 310 developers at hand, who are eager to merge potential out-of- tree drivers and such: http://www.kroah.com/log/ Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#448980: ITP: rt73-firmware -- firmware for Ralink USB wireless cards
On 2007-11-02, Ben Hutchings <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Ben Hutchings <[EMAIL PROTECTED]> > > > * Package name: rt73-firmware > Version : 1.8 > Upstream Author : Ralink Technology Corp > * URL : http://www.ralinktech.com/ralink/Home/Support/Linux.html > * License : proprietary > Programming Lang: 8051 assembly (but we only have the binary) > Description : firmware for Ralink USB wireless cards > > This is needed by wireless network cards handled by the rt73 and > rt73usb modules built from rt73-source and rt2x00-source respectively. What about adding it to the already existing firmware-nonfree source package? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposalto introduce compiler options passed from dpkg-buildpackage
Matthias Klose wrote: > This is a proposal to introduce a common set of compiler options which > can be set independently from the package, and passed/injected to the > package build process. It was first discussed at the last UDS; a > corresponding wiki page can be found at [1]. A change like that is more or less required for the planned introduction of security hardening features. Since noone really objected to the change outlined, I'd be interested in the way forward from here and what timeline is planned to set the changes into effect. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
