Bug#334616: yiff-server: runs as root and opens any file a client asks for
> The yiff server, by default, will run as the root user, even though it > only requires privileges to access the audio devices (/dev/dsp and > /dev/mixer), no effort is make by the package to create an specific user > and run the server as such. > [...] I agree that this is badly broken. Thanks for the report. Can you assist? (e.g., do you have a patch available?) I don't have access to a suitable machine at the moment (I'm moving home, starting new job, etc.). Otherwise, I'll tag this as needing help and do what I can on the project machines. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334616: yiff-server: runs as root and opens any file a client asks for
On Wed, 19 Oct 2005, Javier [UTF-8] Fern??ndez-Sanguino [UTF-8] Pe??a wrote: > I don't have a patch available, but I could write one that: > > a) modifies the postinst/postrm to create a 'yiff' user (might need to belong >to the 'audio' group too) > b) modifies the init script to run yiff-server as the 'yiff' user instead of > as >root > c) creates /var/run/yiff/ so that the pidfile can be created by the program >there (the directory should belong to 'yiff' so it needs to be created on >package installation by root) Those three points should fix the problem you've identified. I wouldn't worry about the other two bugs you filed -- I should be able to tidy those up within a few weeks (I hope!). > That would mitigate the risk a lot, another improvement, which might need to > change code in the source package include limiting file calls to only access > a given directory and reject absolute paths (i.e. those including a '/') > from client requests. That would prevent remote attacks to the server by > having it read files that a remote user would not have access otherwise. Probably not worth the effort right now: it's been previously suggested that the only depending package (searchandrescue) should use something else for its audio support. I might investigate that again. Alternatively, we could suggest this to upstream. Cheers, Phil.
Bug#334616: yiff-server: runs as root and opens any file a client asks for
On Thu, 20 Oct 2005, Javier [iso-8859-1] Fern?ndez-Sanguino Pe?a wrote: > tags 334616 patch > thanks Many thanks for the patch. For today and tomorrow, I have intermittent access to my dev machine, so I've looked over the patch, applied it and just now uploaded it. I think that this will be worth mentioning to the security team as a possible security update. I will copy the emails to you. Cheers, Phil.
Bug#337870: FTBFS (alpha): conflicting types for 'strlen'
Hi, On Fri, 16 Dec 2005, Lars Wirzenius wrote: Attached please find two patches. [...] Thanks for the patches. Hopefully, I should have my computers out of storage (following a job and house move) in the next few weeks, so I'll be able to clear this (and other) bugs then. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337870: FTBFS (alpha): conflicting types for 'strlen'
On Fri, 16 Dec 2005, Lars Wirzenius wrote: Attached please find two patches. [...] patch-2.txt includes the minimal fix, but includes fixes [...] Many thanks. The second patch seemed okay on my machine (I finally have my own machines back), and I'm just uploading the rebuilt package. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332937: searchandrescue: missing dependency on yiff-server
Hi, On Sun, 9 Oct 2005, Pierre THIERRY wrote: SAR needs yiff-server to be able to play sound, and thus should Recommend it. But it even doesn't Suggest it... Thanks for the bug report -- sorry for not replying before (due to job and house moves). The bug should be fixed; a new version is being uploaded right now. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345962: fvwm1: FTBFS: Build dependency on xlibs-dev
On Wed, 4 Jan 2006, Kurt Roeckx wrote: Your package still has a build dependency on xlibs-dev. This has been removed as announced on: http://lists.debian.org/debian-devel-announce/2005/11/msg00022.html This means your package is now failing to build. Thanks for the reminder -- it seems to have gone through the buildd's without problem. A fixed version should uploaded shortly. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370177: searchandrescue: FTBFS: cannot find -lXi
On Sat, 3 Jun 2006, Daniel Schepler wrote: Package: searchandrescue Version: 0.8.2-5 Severity: serious Tags: patch [...] I've attached a simple patch which fixes this by removing -lXi from the link line, which doesn't seem to actually be necessary. Thanks, I'll try to apply that soon. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372495: ACM bugs 372495 and 372496
On Fri, 9 Jun 2006, Yann Dirson wrote: There is no info about where this source was downloaded from. Ack. On Fri, 9 Jun 2006, Yann Dirson wrote: It does not seem easily possible to open a RTF file in common programs (eg. OOo) without copying it and uncompressing it first. I understand it takes less space that way, but what about using a format that is natively compressed (eg. OpenDocument), or ship an HTML version, that does not require to open a word-processor, and can be read by most browsers when gzipped ? I'll have a look at converting it to something saner -- it's the original upstream document. I'll probably convert it to PDF or PS (not sure if I can get HTML out of it), since it'll be useless as plain text. On Fri, 9 Jun 2006, Mohammed [UTF-8] Adnène Trojette wrote: tag 372495 patch Many thanks, I'll apply that shortly (once I've decided the best action wrt the RTF document). Cheers, Phil.
Bug#372903: fvwm1: ..upgrade fails on symlink typo? in post-install
On Mon, 12 Jun 2006, Arnt Karlsen wrote: Package: fvwm1 Version: 1.24r-50 Severity: critical Justification: breaks unrelated software [...] I'm a bit confused here -- which unrelated package was broken? The postinst clearly needs fixing. I'll look at it ASAP. Thanks, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366832: fvwm1: FTBFS with new X packages: Cannot find X11/bitmaps/gray
On Thu, 11 May 2006, Daniel Schepler wrote: Package: fvwm1 Version: 1.24r-49 Severity: serious From my pbuilder build log: [...] The X11/bitmaps/gray file is now in xbitmaps. Thanks. I'll try to fix that soon. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366832: Patch
On Fri, 19 May 2006, Matt Kraai wrote: Subject: Bug#366832: Patch [...] Many thanks -- I'll apply that as soon as I bring my unstable machine back up-to-date. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372903: Bug#375881: diff for 1.24r-50.1 NMU
On Wed, 28 Jun 2006, Steinar H. Gunderson wrote: Package: fvwm1 Version: 1.24r-50 Severity: normal Tags: patch Hi, Attached is the diff for my fvwm1 1.24r-50.1 NMU. Many thanks for your help! Sorry for not getting to it earlier I'll properly close the bugs when I next have reason to do an upload for fvwm1. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383367: Topal needs upstream work
Package: topal Version: 0.7.13.6-1 Severity: serious Tags: upstream Topal needs upstream changes to work properly with recent versions of gnupg. It shouldn't go back into testing until these fixes are made. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#196512: topal: Consider later gnat compiler and more architectures, maybe even Architecture: any
On Wed, 16 Aug 2006, Ludovic Brenta wrote: Justification: topal should not go back into testing until it build-depends on gnat (>= 4.1). Please change Architecture: to alpha amd64 hppa i386 ia64 kfreebsd-i386 s390 sparc powerpc These are the archs supported by gnat-4.1. Thanks, that shouldn't be a problem. (Although topal shouldn't go back in until some upstream changes are also made. I'll submit another bug for that.) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383429: libadasockets-dev: Ada spec and ali files in wrong directory
On Thu, 17 Aug 2006, Ludovic Brenta wrote: The development package, libadasockets-dev, must place the Ada spec [...] Thanks. I'll deal with this when I return to my dev machine in a week or so. (I'll deal with the architectures then, too.) Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383430: adasockets: must bump soname due to ABI change in compiler
On Thu, 17 Aug 2006, Ludovic Brenta wrote: Version: 1.8.4.7-3 Severity: serious Justification: ABI change requires a soname bump, per Debian policy Oops, thanks, will do. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383424: adasockets: static library compiled with -fPIC
On Thu, 17 Aug 2006, Ludovic Brenta wrote: Upstream's configury and make scripts create the shared library, libadasockets.la, with the dreaded rpath option. This is a violation of Debian Policy. Debian should patch the makefile or configury to not add the rpath. Thanks for spotting this. Do you have a patch already? I'll forward to upstream, anyway. Cheers, Phil. -- Phil Brooke PGP/GnuPG key: 1024D/50973B91 2000-12-19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383429: libadasockets-dev: Ada spec and ali files in wrong directory
On Thu, 17 Aug 2006, Ludovic Brenta wrote: The development package, libadasockets-dev, must place the Ada spec files in the directory /usr/share/ada/adainclude/adasockets, not in /usr/lib/adasockets, because they are platform-independent. [...and others...] Thanks for those. Looks like a general tidy-up is needed on this package. Cheers, Phil. -- Phil Brooke PGP/GnuPG key: 1024D/50973B91 2000-12-19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383440: adacgi: Ada spec and library information files in wrong directory
On Thu, 17 Aug 2006, Ludovic Brenta wrote: Since AdaCGI is a library, it must consist of two binary packages: libadacgi-dev and libadacgi1. No, I disagree. I see no benefit to users in making such Debian-specific changes. See end of email. The source package, adacgi, must build-depend on gnat (>= 4.1) (currently not versioned). Will do. libadacgi-dev must provide the Ada specs (cgi.ads and ustrings.ads) in the directory /usr/share/ada/adainclude/adacgi. Optionally, it may also provide the corresponding bodies (*.adb) (this is mandatory if these are bodies of generic units). Will do. libadacgi-dev must provide the Ada library information files (*.ali) in /usr/lib/ada/adalib/adacgi. These files must be read-only for all users; dh_fixperms knows about that and does the right thing (do not --exclude .ali files when calling it). Will do. libadacgi-dev must also provide a GNAT project file, /usr/share/ada/adainclude/adacgi.gpr. Will do. I'll see if upstream wants the .gpr file. libadacgi-dev must provide the static library, /usr/lib/libadacgi.a, and the symlink /usr/lib/libadacgi.so. The static library must contain object files compiled with -g. Disagree, as above. The examples can be in libadacgi-dev, but they must not be compressed; currently the file search.adb is compressed. Please pass -X.adb -X.ads -Xmakefile to dh_compress. This allows gnat to compile the examples directly. I'll either tar.gz or exclude them. libadacgi1 must provide the shared library, /usr/lib/libadacgi.so.1.6, with appropriate symlink (libadacgi.so.1). The shared library must contain object files compiled with -fPIC and WITHOUT -g. Disagree, as above. libadacgi1 must Depend on libgnat-4.1; this is normally done automatically by dh_shlibdeps. Disagree, as above. Since the files contained in the binary package adacgi do not conflict with the standard paths in the proposed -dev and library packages, it is not necessary that packages conflict with each other. However, libadacgi-dev should Replace adacgi. Not needed if I skip the related points. Finally: please revisit the lintian overrides, as they may not be necessary anymore. Both linda and lintian know about Ada libraries now. Will do. I'm happy to be convinced otherwise about (not) converting the package to multiple binaries. However, I don't see any significant benefit at this time. Do any other distributions do this to adacgi? I'll leave this bug at serious severity due to the build-depends point. Cheers, Phil. -- Phil Brooke PGP/GnuPG key: 1024D/50973B91 2000-12-19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413174: SEGFAULT when running acm
Hi, Thanks for the report. On Sat, 3 Mar 2007, andrea wrote: the segfault occurs when load acm -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) I don't have a machine with this architecture available to test. Are you willing and able to help debug the problem? Thanks, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413369: Patch
Hi Steve, Thanks for the patch. I'm very behind on a big (paid) work issue at the moment. If you're happy that the (corrected) patch fixes the problem, you're welcome to NMU it. Otherwise, I'll try to deal with it later this week. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
