Bug#329271: Ping
Just checking to see if this issue will be addressed soon (in sarge as well as in testing/unstable)? Security bugs are very important to resolve as quickly as possible! Thanks, micah signature.asc Description: Digital signature
Bug#329271: PONG! (was: Re: Bug#329271: Ping)
On Thu, 05 Jan 2006, José Luis Tallón clickity clacked: micah wrote: Just checking to see if this issue will be addressed soon (in sarge as well as in testing/unstable)? Indeed... as soon as i manage to get Bacula 1.38 to link properly (currently finishing packaging) Then, i will backport the changes to 1.36.2, for Sarge. Great! Security bugs are very important to resolve as quickly as possible! I know.. it's just that i don't have that much time. I understand, this was more for you if you had forgot. :) Micah signature.asc Description: Digital signature
Bug#346223: FTBFS on hppa in debian/rules
Micah Anderson schrieb am Friday, den 06. January 2006: Right, older versions of upstream did not support hppa (or other many other architectures). This has changed with the upstream version and I'm in the process of sorting these out so that the utilities are built with the right syscalls for the architectures it now does support. I neglected to mention that the version that is in unstable right now doesn't have the proper syscall code for hppa and mips, so although your package will build, it wont work as you expect. The version I am preparing has updated syscalls. Micah signature.asc Description: Digital signature
Bug#305449: Does this work now?
Hello, I am just checking in to see if you ever got this issue resolved? Micah signature.asc Description: Digital signature
Bug#346334: util-vserver should ship testme.sh and testfs.sh
tag 346334 +pending thanks Kilian Krause schrieb am Saturday, den 07. January 2006: Upstream always advertised testme.sh and testfs.sh to verify a working setup. Maybe they could even be tailored into a vserver-check-install but at least they should be shipping in examples/ for offline use. I agree, could even be a reportbug hook so that the information is automatically included. This will take some thinking because the scripts can be invoked in different ways depending on what you need and what kernel you are running (or if you are running the legacy code). Additionally the testfs.sh is a destructive test, so finding a way to do that without destroying anything will take careful thought. I'll include these scripts in the examples/ folder in the next upload and work on making them more automatic. Micah signature.asc Description: Digital signature
Bug#344156: backupninja: trac handler fails when $src is not immediate parent directory of $repo
tag 344156 +pending Brad, Thanks for this report, and the patch! I'm putting together a 0.9.2 release and will include this fix with it. Micah Brad Fritz wrote: Package: backupninja Version: 0.9.1-1 Severity: normal Tags: patch The track handler assumes the repository directories ($repo) are immediate subdirectories of the source directory ($src) when it executes mkdir to create the temporary directory. In other words, a trac repository in /trac/foo works fine, but if the repository is in /trac/foo/bar, trac-admin hotcopy fails because the mkdir created $tmp instead of $tmp/foo . The attached patch fixed the problem for me. Also attached is a before and after debug output. --Brad -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-20050918-686-skas3-v8.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages backupninja depends on: ii dialog1.0-20051107-1 Displays user-friendly dialog boxe ii gawk 1:3.1.5-1 GNU awk, a pattern scanning and pr ii mawk 1.3.3-11 a pattern scanning and text proces backupninja recommends no packages. -- no debconf information --- /tmp/trac 2005-12-20 08:47:24.0 -0500 +++ /usr/share/backupninja/trac 2005-12-20 08:48:14.0 -0500 @@ -14,14 +14,15 @@ do repo=`dirname $repo` -# Just make the $tmp dir, not $tmp/$repo -ret=`mkdir -p $tmp 21` +# Just make the parent directory for $tmp/$repo +parentdir=`dirname $tmp/$repo` +ret=`mkdir -p $parentdir 21` code=$? if [ $ret ]; then debug $ret fi if [ $code != 0 ]; then - error command failed mkdir -p $tmp + error command failed mkdir -p $parentdir fi ret=`trac-admin $src/$repo hotcopy $tmp/$repo 21` boxer:~# backupninja -d --run /etc/backup.d/40-boxer.trac Info: starting action /etc/backup.d/40-boxer.trac (because of --now) Debug: yes Debug: Command failed: [Errno 2] No such file or directory: '/backup/boxer/scheduled/trac.tmp.bun/./foo/bar' Hotcopying /trac/foo/bar to /backup/boxer/scheduled/trac.tmp.bun/./foo/bar ... Error: command failed -- trac-admin /trac/./foo/bar hotcopy /backup/boxer/scheduled/trac.tmp.bun/./foo/bar Error: because of earlier errors, we are leaving trac backups in /backup/boxer/scheduled/trac.tmp.bun instead of /backup/boxer/scheduled/trac.bun Error: finished action /etc/backup.d/40-boxer.trac: ERROR Debug: send report to root Info: FINISHED: 1 actions run. 0 fatal. 2 error. 0 warning. boxer:~# patch /usr/share/backupninja/trac /tmp/trac.patch patching file /usr/share/backupninja/trac boxer:~# backupninja -d --run /etc/backup.d/40-boxer.trac Info: starting action /etc/backup.d/40-boxer.trac (because of --now) Debug: yes Debug: Hotcopying /trac/foo/bar to /backup/boxer/scheduled/trac.tmp.bun/./foo/bar ... Hotcopy done. Info: finished action /etc/backup.d/40-boxer.trac: SUCCESS Debug: send report to root Info: FINISHED: 1 actions run. 0 fatal. 0 error. 0 warning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330824: I dont believe this bug was acted on properly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 reopen 330824 thanks The original bug suggests that you move the plain-text files (including python and perl scripts) from /usr/lib/subversion to /usr/share/subversion. This you accomplished in 1.2.3dfsg1-1. However, the other suggestion that was put forth in the bug report was: BTW: Maybe you can move the example files to /u/s/d/s-tools/example/ This did not happen with any of the example files with 1.2.3dfsg1-1, they all still appear in /usr/share/subversion/hook-scripts. Instead, what did happen was that hot-backup.py, a perfectly good script, was moved to /usr/share/doc/subversion-tools/examples. It seems to me that the hot-backup.py script should be restored to its original useful place (as a script that some backup programs use), and the example files that are in /usr/share/subversion/hook-scripts be actually moved to /usr/share/doc/subversion-tools/examples. Thanks! micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbEbR9n4qXRzy1ioRAgWIAKCjDMoHBNCze8vCxwIkChlSnEPkxQCggXlm 6NzG/GGmO0i/ooytp/Mok9M= =1NWB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336994: backupninja: incorrect path for HOTBACKUP in example.svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I believe that the move of that hot-backup.py script to this location was done erroneously. See my response to #330824. Micah Charles Fry wrote: Package: backupninja Version: 0.9-1 Severity: normal The HOTBACKUP set in example.svn is no longer correct, in new versions of subversion-tools. Now the script was moved to: /usr/share/doc/subversion/examples/hot-backup.py.gz and as such is hardly fit to be called directly. Perhaps backupninja should simply include an executable copy of hot-backup.py. Charles -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (90, 'testing'), (80, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages backupninja depends on: ii dialog1.0-20050306-1 Displays user-friendly dialog boxe ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii mawk 1.3.3-11 a pattern scanning and text proces -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbEdj9n4qXRzy1ioRAsTOAKCcZWv/578SN623hvtA+zUic4loEgCfXfrG z3xW6M2UuEMO8ZwZwxNi0h8= =7Z1O -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330824: I dont believe this bug was acted on properly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Samuelson wrote: severity 330824 wishlist retitle 330824 disagreement about example scripts thanks [micah] BTW: Maybe you can move the example files to /u/s/d/s-tools/example/ Thanks so much for not changing the severity there. Back-handed passive-agressive statements are not productive, but instead provoke angry responses, but lets not get angry. I believe that we can discuss this in a rational way, discussing the technical details, rather than resorting to flaming. Please believe me when I say that I re-opened this bug not to spite you or to flame you, but because it seemed as if it wasn't actually fixed. I'm sorry if my message came across in any other way, it was not intended to be so. I guess you believe this is release-critical. I require a bit of convincing on that score. I almost tagged this one wontfix just now, but I'll give you a chance to rebut first. If you will allow me to rephrase this in a different way, Why did you not change the severity of the bug when you reopened it? Do you think that it is still release-critical? Actually the reason why I did not change the severity of the bug was because I did not even look at it from the beginning, I assumed the original bug was set to a severity level that made sense, and because I felt as if the bug had not been acted on that the original severity level probably still applied. Had I noticed that it was set to such a high severity level, then I probably would have noted that in my response, suggesting that it probably should be lowered. However, I am not a huge fan of changing the severity of someone else's bug, on someone else's package, I prefer to instead suggest that it be changed, rather than barge in and do it myself. My guess is that the release-critical nature of the original severity of the bug was due to the FHS violation, which was actually fixed. So I agree that the severity should be lowered, and I apologize for overlooking this. This did not happen with any of the example files with 1.2.3dfsg1-1, they all still appear in /usr/share/subversion/hook-scripts. Many of the files there are usable in situ. Moved to the examples directory, they wouldn't be (thanks to Policy about gzip). I'm not interested in breaking people's repositories arbitrarily, which is what would happen if people *are* using these things in situ. If I break someone's repository with a svn upgrade I want to at least have a good reason. This makes a lot of sense. I was not aware that the example files are actually usable in situ. I only saw that the bug was closed and the example files were not moved as the bug suggested. This was an indication to me that the bug report had not been acted on properly. If you had sent a message to the report clarifying this, it would have helped and I would not have thought that the issue had been overlooked. It seems to me that the hot-backup.py script should be restored to its original useful place (as a script that some backup programs use) Did you read NEWS.Debian.gz? The other script affected is /usr/lib/subversion/hot-backup.py, which has now moved into /usr/share/doc/subversion/examples. It was never a supported executable (or it would live in /usr/bin). It is also no longer needed, because svnadmin hotcopy now includes the same functionality. Please use svnadmin hotcopy instead. Somehow I missed this, my apologies. Seems odd to include this at all if it is unsupported. Additionally, the examples/ directory seems like a strange place to put scripts, but nevertheless, thats up to you. Knowing this and the details about the .example files convinces me that this bug actually should be closed. I'm sorry to have bothered you. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbOf59n4qXRzy1ioRAsekAJ9RoalwcpuLhoX6PxRtlY6aejMe3wCfd1vz yHZmEUV+0bU/62mxkRE9Jiw= =Ct2k -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335966: backupninja: ninjahelper doesn't ask installation of rdiff-backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ilya Korolev wrote: Package: backupninja Version: 0.9-1 Severity: important When I create a new backup task in ninjahelper, it doesn't ask me to install rdiff-backup package. So, when I test run of this task, I have the following error: Actually the ninjahelper does ask you to install rdiff-backup on your local machine, but you also need it installed on the remote machine to get it to work. I'm working on adding functionality to detect this and automatically install rdiff-backup on the remote machine if you want to avoid this problem. micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbRx59n4qXRzy1ioRAuRBAJ4kq0glPJa59Ak10Yjc/iTXCha88gCdHULf n5Yc+5J5wy7FvlzfpoRWsOo= =xEwq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337954: Remote rdiff: Can't connect, test succeeds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ahmad Khayyat wrote: Package: backupninja Version: 0.9-1 backupninja -t -n succeeds, but scheduled backups don's. They produce the message: *failed* -- /etc/backup.d/90.rdiff == fatal errors from /etc/backup.d/90.rdiff == Fatal: Can't connect to dest-host as dest-user. Does the error really say dest-host as dest-user, or was this a substitution that you did? I noticed that the helper script uses dsa while I'm using rsa. Anyway, I can ssh without a password and backupninja -n completes the backup successfully. Note that I have a passphrase for my keys but I'm using an agent (ssh-add) so that I can ssh without any prompts or passwords. I don't want to have an empty passphrase. If you have a passphrase on your key, then scheduled backups are going to somehow need to get that passphrase from you during the backups... micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDb4Wz9n4qXRzy1ioRAvy6AJ9asqO5WXJdSYRx0n1sI8pM2ct+RwCgnZ4x adTxTs97pnZPz/2t/9XtrJg= =4gzg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337954: Remote rdiff: Can't connect, test succeeds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ahmad Khayyat wrote: 1. That was my substituation.. consider those as variables. 2. Is there any means by which I can provide the passphrase to the scheduled backups? It seems that thay do not run in the current logged-in session, otherwise they could have used the session's ssh agent. I've only done it via ssh-keys and passwordless logins to unpriviledged remote users. The only way a cronjob could use your ssh-agent is if it was launched from a shell that was created after the agent was launched. Cron stuff generally runs as root however, so you would have to have a ssh-agent for root and restart crond after you've ran ssh-agent to get it to work, but this is really weird. Really, this is the point of public keys... create an unpriviledged user on the backup machine that can only execute the rdiff-backup commands via ssh authorized_keys and it should be fine. micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDb9GN9n4qXRzy1ioRAiZxAJwN8/cHzaM9ik0tD4O6BvX/WWzIhQCgkZ8D FOrGkQJhKCFnk4sSVV/cFHs= =05GX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343277: [Vserver] Re: Bug#343277: util-vserver: wrong call to colorize in functions
forwarded https://savannah.nongnu.org/bugs/index.php?func=detailitemitem_id=15281 thanks The Anarcat wrote: On Wed Dec 14, 2005 at 06:36:21PM +0100, Ola Lundqvist wrote: As I said, it's trivial, benign, but should be fixed and I don't know where else to report this. If you found this bug using the debian package, you should file it with the Debian BTS. The reason is because the package maintainer may have made changes to the upstream code and would know best if this is a local debian issue, or actually an upstream issue. If the package maintainer determines that this is not a Debian bug, then he/she files a bug in the upstream tracker, tags the Debian bug as forwarded with a link to the upstream submitted bug (which I have done above), and then keeps track of the fix upstream. I suggest you also file this upstream. See http://linux-vserver.org/ or just simply send an email to vserver@list.linux-vserver.org describing this. Actually, it typically should be the Debian maintainer who does this as the maintainer knows how to do this properly, and should be actively cultivating a relationship with upstream so that communication happens properly. Addtionally, filing this particular bug is not done by sending an email to the vserver mailing list, as Enrico (who maintains the upstream tools) may or may not follow the list. Even if he does, he should not be unnecessarily burdened with needing to file a bug in the proper bug tracker so that he can remember to fix it later. The bug tracker for util-vserver is located here: https://savannah.nongnu.org/bugs/?group=util-vserverfunc=browseset=open The proper way to go about this is to browse through the open issues before submitting a duplicate bug. i was kind of expecting you to do this, but I can do it.. :) Let's just CC the list... Just CC'ing the list is like tossing something out, you dont know if someone will pick it up and unless you intend to track this issue and follow-up to find out where the issue is at, it will just be left up to chance. Filing a bug in the tracker will keep the issue around until it is dealt with. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343277: [Fwd: [bug #15281] wrong call to colorize in functions]
Original Message Subject: [bug #15281] wrong call to colorize in functions Date: Fri, 23 Dec 2005 16:36:24 +0100 From: XeRO [EMAIL PROTECTED] To: Micah Anderson [EMAIL PROTECTED], XeRO [EMAIL PROTECTED], [EMAIL PROTECTED] References: [EMAIL PROTECTED] Follow-up Comment #1, bug #15281 (project util-vserver): Patch for this already submitted, see patch #4714 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=15281 ___ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343467: Patch available
tag 343467 +patch thanks There is a patch available to fix this vulnerability in apache-2.0 here: http://issues.apache.org/bugzilla/attachment.cgi?id=17200 Micah signature.asc Description: Digital signature
Bug#343466: Patch available
tag 343466 +patch thanks Patch available to fix this issue on apache-1.3 here: http://issues.apache.org/bugzilla/attachment.cgi?id=17199 signature.asc Description: Digital signature
Bug#330733: twiki: INCLUDE function allows arbitrary shell command execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sven,
I have not attempted to reproduce this in the debian package, I'm
tracking known vulnerabilities with the testing-security team. When I
see a new CVE id assigned to a package and no bugs filed on that package
regarding that CVE, and no entries in the changelogs noting that it has
been fixed, I tend to believe that it hasn't been because it is a rare
package maintainer who has security issues fixed before they are
discovered or announced.
Additionally, the advisory indicates that the version in debian
(20040902-3) is affected, as the only versions it indicates are safe is
the TWikiRelease01Sep2004 patched with Florian Weimer's
UncoordinatedSecurityAlert23Feb2005 patches. Without any indication in
the BTS or in changelogs, I assume that the package is affected because
the version numbers typically are very good indicators. Admittedly, you
could very well have addressed this issue, and I have a feeling that you
have as Florian is very active in Debian. If so, I'd be happy to know
that, and we can close this bug, so I can note it in the
testing-security database.
Unfortunately, if I had to try every exploit, even those without
published exploits, for every CVE assigned, there would be a net loss. I
understand that this means this is an annoyance to you to get a grave
bug report for something that you may have addressed, however it ends up
being a good thing because then we know for sure, and can better track
vulnerabilities in Debian. It is better to be asked once if this is an
issue and have it properly noted, than for Debian to not pay attention
to anything at all and be riddled with security holes.
micah
Sven Dowideit wrote:
excellent.
Micah, did you manage to reproduce this in the debian package at all?
you see, the debian package is significantly more secure than the
upstream version, and as you've marked it as grave, I presume that you
have found a way to make it happen. (as when I had a go, i did not get
the exploit (i got a unhelpful, but correct error message invalid
number argument at /usr/share/perl5/TWiki.pm line 3339.)
could you please either tell me how to reproduce the problem in the
current debian package, or close it?
Cheers
Sven
Micah Anderson wrote:
Package: twiki
Version: 20040902-3
Severity: grave
Tags: security
Justification: user security hole
A new security bug in twiki showed up today:
http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithInclude
An attacker is able to execute arbitrary shell commands with the
privileges of the web server process. The TWiki INCLUDE function
enables a malicious user to compose a command line executed by the
Perl backtick (`) operator.
The rev parameter of the INCLUDE variable is not checked properly for
shell metacharacters and is thus vulnerable to revision numbers
containing pipes and shell commands. The exploit is possible on
included topics with two or more revisions.
Example INCLUDE variable exploiting the rev parameter:
%INCLUDE{ Main.TWikiUsers rev=2|less /etc/passwd }%
The same vulnerability is exposed to all Plugins and add-ons that use
TWiki::Func::readTopicText function to read a previous topic revision.
This has been tested on TWiki:Plugins.RevCommentPlugin and
TWiki:Plugins.CompareRevisionsAddon.
If access to TWiki is not restricted by other means, attackers can use
the revision function with or without prior authentication, depending
on the configuration.
The Common Vulnerabilities and Exposures project has assigned the name
CAN-2005-3056 to this vulnerability. Please include this number in any
changelogs fixing this.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDQeLS9n4qXRzy1ioRAh14AJ94XXJC7UaX0vlpo+VIOqr+qRHM0QCfYf1Q
9ftwzksPFsreIMdvPx4Du2A=
=Khzi
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330733: twiki: INCLUDE function allows arbitrary shell command execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Does this mean that the twiki (20040902-3) in Debian is not vulnerable
and this bug report can be closed?
Micah
Sven Dowideit wrote:
while I think its very reasonable for you to send along these
advisories, and even doing so as a BTS bug wothout testing them
I think its incredibly rude to do so without saying that you have not
tested it out.
please, if you enter a bug report, tell the maintainer what you have or
have not done, that way they can deal more appropriatly with the issue
(in the cases where the core issue has been dealt with (thanks to
Florian!) I'm very busy helping out upstream, and i'm sure this
situation _should_ apply to others (i object to the number of debian
maintainers that are not appropriatly active upstream)
however, other than my rant :) thanks for the notification, its
important (i'm still notifying people now)
Sven
micah wrote:
Sven,
I have not attempted to reproduce this in the debian package, I'm
tracking known vulnerabilities with the testing-security team. When I
see a new CVE id assigned to a package and no bugs filed on that package
regarding that CVE, and no entries in the changelogs noting that it has
been fixed, I tend to believe that it hasn't been because it is a rare
package maintainer who has security issues fixed before they are
discovered or announced.
Additionally, the advisory indicates that the version in debian
(20040902-3) is affected, as the only versions it indicates are safe is
the TWikiRelease01Sep2004 patched with Florian Weimer's
UncoordinatedSecurityAlert23Feb2005 patches. Without any indication in
the BTS or in changelogs, I assume that the package is affected because
the version numbers typically are very good indicators. Admittedly, you
could very well have addressed this issue, and I have a feeling that you
have as Florian is very active in Debian. If so, I'd be happy to know
that, and we can close this bug, so I can note it in the
testing-security database.
Unfortunately, if I had to try every exploit, even those without
published exploits, for every CVE assigned, there would be a net loss. I
understand that this means this is an annoyance to you to get a grave
bug report for something that you may have addressed, however it ends up
being a good thing because then we know for sure, and can better track
vulnerabilities in Debian. It is better to be asked once if this is an
issue and have it properly noted, than for Debian to not pay attention
to anything at all and be riddled with security holes.
micah
Sven Dowideit wrote:
excellent.
Micah, did you manage to reproduce this in the debian package at all?
you see, the debian package is significantly more secure than the
upstream version, and as you've marked it as grave, I presume that you
have found a way to make it happen. (as when I had a go, i did not get
the exploit (i got a unhelpful, but correct error message invalid
number argument at /usr/share/perl5/TWiki.pm line 3339.)
could you please either tell me how to reproduce the problem in the
current debian package, or close it?
Cheers
Sven
Micah Anderson wrote:
Package: twiki
Version: 20040902-3
Severity: grave
Tags: security
Justification: user security hole
A new security bug in twiki showed up today:
http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithInclude
An attacker is able to execute arbitrary shell commands with the
privileges of the web server process. The TWiki INCLUDE function
enables a malicious user to compose a command line executed by the
Perl backtick (`) operator.
The rev parameter of the INCLUDE variable is not checked properly for
shell metacharacters and is thus vulnerable to revision numbers
containing pipes and shell commands. The exploit is possible on
included topics with two or more revisions.
Example INCLUDE variable exploiting the rev parameter:
%INCLUDE{ Main.TWikiUsers rev=2|less /etc/passwd }%
The same vulnerability is exposed to all Plugins and add-ons that use
TWiki::Func::readTopicText function to read a previous topic revision.
This has been tested on TWiki:Plugins.RevCommentPlugin and
TWiki:Plugins.CompareRevisionsAddon.
If access to TWiki is not restricted by other means, attackers can use
the revision function with or without prior authentication, depending
on the configuration.
The Common Vulnerabilities and Exposures project has assigned the name
CAN-2005-3056 to this vulnerability. Please include this number in any
changelogs fixing this.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDQoQ49n4qXRzy1ioRAq3qAJ0Unv67KRVRhspysHwYVSPMcgREXQCgnErl
dQYbLhUMHN1nVASNCDzWAew=
=Ew1E
-END PGP
Bug#160579: Suggestion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I suggest that you communicate with the upstream developers to help you isolate a patch... or ask them to release a version that fixes this problem. Perhaps this article will help: http://www.slashcode.com/slash/04/12/20/1946225.shtml?tid=11tid=5tid=4 Or posting to the forums? Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDQotH9n4qXRzy1ioRAkHZAKC2RBUDczeY/2G+Xwwe51M+uLlnHwCeL0Iz nzJEOpRC4cSjuDbzaAhgI34= =tpZ5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
These bug reports are very confusing, I am performing my own tests to
help clarify.
Andrew Lee wrote:
The VCI shouldn't be none if you have setup /dev/loop4 correctly, I
did same thing and got same errors when I forgot to setup the /dev/
loop4 after a reboot.
No, VCI: none (unknown) is fine in 2.4 because 2.4 has no VCI info.
Here is what I did for create a loopback file and the run losetup:
# dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
# losetup /dev/loop4 1gb.testfs
Note: I have other loopback files running on /dev/loop{0,1,2,3}
already, so I use /dev/loop4 in my case.
The following is the results of my tests:
For all tests the following packages need to be installed:
xfsprogs jfsutils reiserfsprogs reiser4progs util-vserver
(0.30.204-5sarge2 unless otherwise noted)
Procedure is to do:
1. # dd bs=1024k count=1024 if=/dev/zero of=/home/1gb.testfile
2. # losetup /dev/loop4 /home/1gb.testfile
3. # mkdir /mnt2
On 2.6 kernels the following switches were used to test:
4. # ./testfs.sh-0.09 -vv -D /dev/loop4 -M /mnt2
Test 1:
Sarge kernel 2.6.8 (2.6.8-16) with debian package kernel-patch-vserver
(debian package version: 1.9.5.3, kernel patch:
patch-2.6.8-15-vs1.9.5.x-4.diff.gz) applied on an i386 machine.
Results:
All the tests succeed on ext2/ext3/reiserfs, the following fail:
xfs: 103, 106, 113, 115, 117
jfs: 104, 114, 121, 122, 123, 124
Test 2:
Sarge kernel 2.6.8 (2.6.8-16) with debian kernel-patch-vserver (debian
package version: 1.9.5.4 (not in sarge), kernel patch
patch-2.6.8-15-vs1.9.5.x-5.diff.gz) applied on an i386 machine.
Results:
Exactly the same as the results from Test 1
Test 3:
Sarge kernel 2.4.27 (2.4.27-10) with the debian kernel-patch-vserver
(debian package version: 1.9.5.3, kernel patch
patch-2.4.27-9-vs1.2.10-2.diff.gz) applied on an i386 machine.
Results:
ext2/ext3 failures: 103, 104, 106, 109, 114, 121, 122, 124
xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124
reiserfs failures: 103, 104, 106, 109, 114, 118, 119, 121, 122, 124
jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121,
122, 123, 124
Note: Bertl says this is a failure with the util-vserver tools, so I
perform the test again with util-vserver .208 from unstable:
Test 4:
Sarge kernel 2.4.27 (2.4.27-10) with the debian kernel-patch-vserver
(debian package version: 1.9.5.3, kernel patch
patch-2.4.27-9-vs1.2.10-2.diff.gz) applied on an i386 machine. Using
util-vserver tools from unstable (0.30.208-2)
ext2/ext3 failures: 104, 106, 114, 122, 124
xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124
reiserfs failures: 104, 106, 114, 118, 119, 122, 124
jfs failures: 102, 103, 104, 106, 109, 112, 113, 114, 116, 118, 119,
121, 122, 123, 124
Micah
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDQwmG9n4qXRzy1ioRAsSXAJ9Y8qjKsK/xYDXBcYWWgrh9TC761QCfdo/0
WhPUbXCtnk/DR+RZiCL7vNs=
=39eq
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332193: util-vserver: vc_create_context(): Function not implemented
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: util-vserver Version: 0.30.204-5sarge2 Severity: important Tags: patch As it turns out the 208 util-vserver tools don't properly fall back to VCMD_ctx_create_v0 if the main one doesn't work, this occurs if you use these tools with the 1.9.5 kernel patch (and possibly the 1.2 as well). The result is things such as the following: # vcontext --create --xid 42 true vcontext: vc_create_context(): Function not implemented The normal working call looks like this: vserver(VCMD_09,1[0], 42) but util-vserver 208 shows: vserver(VCMD_09,1[1], 42) The fix for this is in the following diff (should be applied on top of fix02): http://vserver.13thfloor.at/Experimental/delta-0.30.208-fix02-fix03.diff Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDQzdm9n4qXRzy1ioRAlYmAKCI6Q6rqewbuIRtnfexiAFN6QdOhQCggMjF h94nEXikz5sjuF6gjjfXyBk= =5QJE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330627: Gentoo had an advisory for this
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have verified that the check_update.sh script in Debian is not vulnerable to this. This was fixed up stream and we are running the latest upstream version. micah Moritz Muehlenhoff wrote: Hi, there has been a Gentoo advisory about insecure temp files in rkhunter, which got assigned CAN-2005-1270: http://www.gentoo.org/security/en/glsa/glsa-200504-25.xml So please check, whether the mentioned check_update.sh script is vulnerable in the Debian package as well. Cheers, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDQ/9B9n4qXRzy1ioRArRMAJ9lrosJf/xOfrb0ANb9xzVhMiozvACfXMXE CglG87Y8Nap1yKdrnnSuxng= =D0rP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332193: util-vserver: vc_create_context(): Function not implemented
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ola Lundqvist wrote: Hello On Tue, Oct 04, 2005 at 10:16:06PM -0400, micah wrote: Package: util-vserver Version: 0.30.204-5sarge2 Severity: important Tags: patch Do this apply to sarge as well? You wrote that it affects version 0.30.204-5sarge2 but give a patch for 0.30.208. This is the result of reportbug reporting the version that I had installed on the system that i was writing the bug from, not the one I was testing. This is only related to 0.30.208. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDR+GN9n4qXRzy1ioRAhhMAJ9aU3NhsfFalGj2ljPMcX2zv7/DJACfVs8Y SFMl+pvKdk6ytAKOosukR/Q= =zDE3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329087: kernel-patch-vserver: be able to do chroot escape
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can confirm this. Works on debian kernel 2.4.27 with applied patch: Virtual private servers and security contexts (vserver), from package kernel-patch-ctx, version 2:1.2.10-1 What debian kernel-source revision are you using? Also, you are using the package kernel-patch-ctx? Is this sarge? Because there is no kernel-patch-ctx in sarge, only kernel-patch-vserver. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDScXQ9n4qXRzy1ioRAqwSAJ90FICC35IO2HIZEOukNs+gEaIR+QCdEQq7 VY8m+SbCir8qVOP+Q/mGYZo= =sY8u -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329090: util-vserver: barrier not working, but chroot escape does
No, these issues are not present in 2.6 (using the debian 2.6.8 and the debian kernel-patch-vserver, both from sarge). I am trying to find out if this is a kernel problem with the debian 2.4.27 kernel in sarge, or a vserver patch problem. micah Hello To me it would be good to know if any of these issues are valid if you use 2.6 kernel and patch from sarge? Regards, // Ola On Thu, Oct 13, 2005 at 07:00:27PM +0800, Andrew Lee wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Micah, Thank you for your tests, I have downloaded the testfs-0.11.sh and did the similar tests as yours to help confirm the results. Test #1 Using all debian sarge componants: kernel-source: 2.4.27-10 (debian sarge) util-vserver: 0.30-204-5sarge2 (debian sarge) kernel-patch: 1.9.5.3 (debian sarge) 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your tests show. Conclusion: either the fixes to testfs caused error 114 and 124 to go away, or you have a different kernel-source or kernel-patch applied. Either try again with testfs.sh-0.11 or install the latest sarge kernel source and kernel-patch-vserver as those versions are all that matter here. I am using all deian sarge componats, all the same version as yours, and then did the testfs.sh-0.11 by this way(I've setup a loopback file on /dev/loop0 already), before start the testfs.sh-0.11, I confirmed the barrier has proper setup(I also did this in my other tests later): # ls -lda /var/lib/vservers d- 8 root root 4096 Oct 13 15:37 /var/lib/vservers/ # showattr -d /var/lib/vservers/ - ---BU-- /var/lib/vservers/ # lsattr -d /var/lib/vservers - ---t- /var/lib/vservers # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl Linux 2.4.27-10vserver-confirm i686/0.30.204 VCI: none (unknown) - --- testing ext2 filesystem ... [000]. xattr related tests ... [101]. [102]. [103]* [104]* [106]* [108]. [109]* [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119]. [121]* [122]* [123]. [124]. [199]. - --- testing ext3 filesystem ... [000]. xattr related tests ... [101]. [102]. [103]* [104]* [106]* [108]. [109]* [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119]. [121]* [122]* [123]. [124]. [199]. Same fails as you got, and I guess Bertl forgot to change the version in the script, so the script is still showing [V0.10]. I also tested the exploit: # ./rootesc Exploit seems to work. =) # And then I can be able to access the host, for example, I can see the vserver's config file on host: # ls -ald /etc/vservers /var/lib/vservers/ drwxr-xr-x 4 root root 4096 Sep 22 14:10 /etc/vservers d- 8 root root 4096 Oct 13 15:37 /var/lib/vservers/ Test #2 Using only debian sarge util-vserver: kernel-source: 2.4.31 (upstream) util-vserver: 0.30-204-5sarge2 (debian sarge) kernel-patch: 1.2.10 (upstream) 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed using all debian sarge componants in test #1. Conclusion: based on the results from this test, and the previous, it is clear that the debian kernel source and the debian kernel patch dont make a difference here Same here, I am using the vanilla kernel 2.4.31(from kernel.org) vserver patch 1.2.10 (upstream) util-vserver: 0.30-204-5sarge2 (debian sarge) ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl Linux 2.4.31-vs1.2.10 i686/0.30.204 VCI: none (unknown) - --- testing ext2 filesystem ... [000]. xattr related tests ... [101]. [102]. [103]* [104]* [106]* [108]. [109]* [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119]. [121]* [122]* [123]. [124]. [199]. - --- testing ext3 filesystem ... [000]. xattr related tests ... [101]. [102]. [103]* [104]* [106]* [108]. [109]* [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119]. [121]* [122]* [123]. [124]. [199]. Same result as you got, seems the testfs #1 and #2 shows no difference, but the exploit works on #1's setup, not on #2. # ./rootesc cd ..: Permission denied chmod: Operation not permitted cd ..: Permission denied chmod: Operation not permitted (alternating a few times) then the false: Exploit seems to work. =) (because it always shows this line, actually it failed, but nobody bothered to fix up the exploit bug) Test #3 Using debian sarge componants with upstream util-vserver: kernel-source: 2.4.27-10 (debian sarge) util-vserver: 0.30-208+fix03 (upstream) kernel-patch: 1.9.5.3 (debian sarge) Only test 106 fails... Not 104, 114, 122 or 124. Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go away or you have a different kernel-source or kernel-patch applied, try with testfs.sh-0.11 to see, or just try with a current sarge kernel and patch since that is all that matters here. In your test #3, you used the 0.30-208+fix03 from upstream, and I am
Bug#335679: bittornado: Missing help on allowed_list behaviour (bttrack)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can you provide more details of what this option should be? All I have for this option is what is provided in the command: - --allowed_list arg only allow downloads for hashes in this list (hex format, one per line) (defaults to '') Micah Leonardo Boselli wrote: Package: bittornado Severity: normal such option present in progra source is not documented. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-1-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bittornado depends on: ii python2.3.5-2An interactive high-level object-o -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDXjLM9n4qXRzy1ioRAmdOAJ92GA385cguTl55L07Szy6CDLF04wCgknuI mIAZbXFC01nAWzeSwyLD7BE= =1FRK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328707: kernel-source-2.4.27: Compile fails
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Björn Andersson wrote:
{standard input}: Assembler messages:
{standard input}:737: Error: suffix or operands invalid for `mov'
{standard input}:738: Error: suffix or operands invalid for `mov'
{standard input}:832: Error: suffix or operands invalid for `mov'
{standard input}:833: Error: suffix or operands invalid for `mov'
{standard input}:874: Error: suffix or operands invalid for `mov'
{standard input}:875: Error: suffix or operands invalid for `mov'
{standard input}:877: Error: suffix or operands invalid for `mov'
{standard input}:889: Error: suffix or operands invalid for `mov'
distcc[25163] ERROR: compile process.c on localhost failed
make[2]: *** [process.o] Error 1
I believe this has to do with the new binutils in unstable.
I had this same problem and solved it by changing my symlink for
/usr/bin/gcc to point to gcc-3.3 instead of 4.0 for the duration of the
2.4 compile. Clearly this isn't the best solution, but its a work-around.
micah
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDYsHF9n4qXRzy1ioRAvbyAKCU14dsR62N3G2bIJ+zvH7A5SfvrwCcDKXs
dahly/oFQTjuwQuq/obkm6c=
=H4PT
-END PGP SIGNATURE-
Bug#329090: util-vserver: barrier not working, but chroot escape does
: 103, 104, 106, 109, 121, 122 (note: same as test #1) xfs failures: 103, 104, 106, 109, 114, 115, 117, 121, 122, 124 (note: same as test #1) reiserfs failures: 103, 104, 106, 109, 118, 119, 121, 122 (note: same as test #1) jfs failures: 103, 104, 106, 109, 112, 113, 114, 116, 118, 119, 121, 122, 123, 124 (note: same as test #1) Conclusion: All tests had the same results as test #1 the conclusion reached originally still holds: it is clear that the debian kernel source and the debian kernel patch dont make a difference here Test #3 Using debian sarge componants with upstream util-vserver: kernel-source: 2.4.27-10 (debian sarge) util-vserver: 0.30-208+fix03 (upstream) kernel-patch: 1.9.5.3 (debian sarge) ext3 failures: 106 xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124 reiserfs failures: 106, 118, 119 jfs failures: 102, 103, 104, 106, 108, 109, 112, 113, 114, 116, 118, 119, 121, 122, 123, 124 Test #4 Using all upstream componants: kernel-source: 2.4.31 (upstream) util-vserver: 0.30-208+fix03 (upstream) kernel-patch: 1.2.10 (upstream) ext3 failures: 106 (note: same as test #3) xfs failures: 103, 104, 106, 114, 115, 117, 121, 122, 124 (note: same as test #3) reiserfs failures: 106, 118, 119 (note: same as test #3) jfs failures: 102, 103, 104, 106, 108, 109, 112, 113, 114, 116, 118, 119, 121, 122, 123, 124 (note: same as test #3) Conclusion: using *all* upstream pieces, the same failures occur when using debian kernel source and kernel patch. This leads me to believe that either the upstream kernel source is broken, the upstream linux vserver patch is broken, or most likely the testfs is not working properly for these tests. So my conclusion is that where you build the binary (if it is a i386 machine) do not give any difference from a security point of view. I agree, your test results show no difference, I dont believe this has anything to do with it. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDTas39n4qXRzy1ioRAu9hAJoD9VmatLu5KqHy4/yKAcs8HlgjAACgpI7U DFzIQiA+iFtN608yD4MRnzE= =0HBa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314678: Please try the newest util-vserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 314678 +moreinfo thanks I believe that this bug is the same as #332193 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332193), which was resolved with the most recent upload of util-vserver version 0.30.208-3. Please try that utility version to see if this makes the error go away. Thanks, Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDTeD+9n4qXRzy1ioRAkStAKCnJofOkrTzBw7eOr8Li+6divo+KwCghWbR 2mDS22ac1sbf0aCbKt3GzQk= =V7Np -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334236: Closing this bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As it seems that this issue had to do with an incorrect php.ini include_path definition, I am closing this bug. Micah Hi, It had just: include_path = ; UNIX: /path1:/path2 Windows: \path1;\path2 setting it to .:/usr/share/php:/usr/share/pear seems to have caused bamboo to start working, thanks! Note that phpmyadmin, imp/horde/etc and have all been working fine on this box. A lot of the configs were migrated over from a woody box that was in turn upgraded from a potato box however, this system does have a bit of cruft on it. thanks, regards, Duncan On Sun, 2005-10-16 at 11:39 -0700, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Basic bamboo test install according to the README.Debian fails with php path errors: Fatal error: main(): Failed opening required 'filter.php' (include_path='') in /usr/share/bamboo/filters/text2html.php on line 3 and Fatal error: main(): Failed opening required 'topnav.php' (include_path='') in /usr/share/bamboo/decorators/editor/template.php on line 1 That is very odd. I am not sure how you will be able to run any php code if your include_path is set to ''. What is the value of include_path in your /etc/php4/apache/php.ini? I believe the package defaults (at least they used to be) was to leave this value commented out, which used the compiled-in default: include_path = .:/usr/share/php:/usr/share/pear Try adding that to your php.ini and see what happens. -elijah - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDUyTl9n4qXRzy1ioRAoDlAJ4xNNihoPcJxCQm35SJNy0A0HYzGwCfQgGO 2DAgisBIBuqNS4IwW8Y3YG8= =OIDB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303077: Fix for FTBS
tag 303077 pending thanks We have a fix for the FTBS, need to test it out and then will upload shortly. Micah
Bug#431709: I'm seeing this as well
I'm running an up-to-date sid and when I try to run amarok and twinkle I get the floating point exception. Here is the output of /usr/share/bug/xserver-xorg-core/script 31 Script started on Sat 07 Jul 2007 08:04:51 PM MDT Contents of /var/lib/x11/X.roster: xserver-xorg /etc/X11/X target does not match checksum in /var/lib/x11/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 13 2006-08-13 21:34 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1736280 2007-07-04 23:32 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 3702 2006-12-06 09:11 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section ServerLayout Identifier Default Layout Screen Default Screen 0 0 InputDeviceGeneric Keyboard InputDeviceConfigured Mouse InputDeviceSynaptics Touchpad EndSection Section Files # path to defoma fonts FontPath /usr/share/fonts/X11/misc FontPath /usr/X11R6/lib/X11/fonts/misc FontPath /usr/share/fonts/X11/cyrillic FontPath /usr/X11R6/lib/X11/fonts/cyrillic FontPath /usr/share/fonts/X11/100dpi/:unscaled FontPath /usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath /usr/share/fonts/X11/75dpi/:unscaled FontPath /usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath /usr/share/fonts/X11/Type1 FontPath /usr/X11R6/lib/X11/fonts/Type1 FontPath /usr/share/fonts/X11/100dpi FontPath /usr/X11R6/lib/X11/fonts/100dpi FontPath /usr/share/fonts/X11/75dpi FontPath /usr/X11R6/lib/X11/fonts/75dpi FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Load i2c Load bitmap Load ddc Load dri Load extmod Load freetype Load glx Load int10 Load type1 Load vbe EndSection Section Extensions Option Composite Enable Option Render Enable EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device /dev/input/mice Option Protocol ExplorerPS/2 Option Emulate3Buttons true EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEvents true Option Device /dev/psaux Option Protocol auto-dev Option HorizScrollDelta 0 EndSection Section Monitor Identifier Generic Monitor Option DPMS EndSection Section Device Identifier ATI FireGL Mobility T2 Driver fglrx Option MonitorLayout NONE, AUTO Option NoTV no Option TVStandard NTSC-M Option TVHSizeAdj 0 Option TVVSizeAdj 0 Option TVHPosAdj 0 Option TVVPosAdj 0 Option TVHStartAdj 0 Option TVColorAdj 0 Option GammaCorrectionI 0x Option GammaCorrectionII 0x Option VideoOverlay on Option OpenGLOverlay off BusID PCI:1:0:0 EndSection Section Screen Identifier Default Screen Device ATI FireGL Mobility T2 MonitorGeneric Monitor DefaultDepth 24 SubSection Display Depth 15 Modes1400x1050 EndSubSection SubSection Display Depth 16 Modes1400x1050 EndSubSection SubSection Display Depth 24 Modes1400x1050 ViewPort 0 0 # initial origin if mode is smaller than desktop EndSubSection EndSection Section DRI Mode 0666 EndSection
Bug#329411: Making this two bugs
clone 329411 -1 retitle -1 Suggestion: add debconf question thanks I have cloned this bug so that there are two separate issues to resolve. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328501: phpmyadmin: CAN-2005-2869
Piotr Roszatycki wrote: On Thursday 22 of September 2005 16:29, micah wrote: Piotr, I notice that you fixed some of these issues in your most recent unstable upload, but the others which you identify below were not included... at least its not obvious from the unstable changelog, I assume that its the four more vulnerabilities reported and fixed directly in phpMyAdmin's CVS? They are all fixed in 2.6.4 release. Try to grep on XSS for ChangeLog available at http://cvs.sourceforge.net/viewcvs.py/phpmyadmin/phpMyAdmin/ChangeLog?rev=2.1272view=auto I didn't describe them in changelog for unstable release, beacuse the upstream did not describe, too. The sarge backported package is described verbosely, beacuse the fixes are provided carefully in separated patches. It would be nice to note these in unstable (especially CAN numbers) in the future, as those of us doing testing-security track these sorts of things and will continue to ping you asking you about this sort of thing because it is not obvious in the changelog. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330627: rkhunter daily cron script is open to symlink attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 330627 +pending severity 330627 critical thanks I believe the correct severity level is critical, not grave as security bugs are supposed to be rated according to: * affects a user that installs a package: critical * affects a user that has executed a binary, allowing compromising userdata, taking over account, etc.: grave * affects build-process, or generally annoying: important In any case, a new package is on its way now, the package is currently only in unstable. micah Michael Stone wrote: On Thu, Sep 29, 2005 at 02:00:12AM +0200, Thomas Prokosch wrote: $RKHUNTER --cronjob --report-warnings-only /tmp/$$ If I am not mistaken this command poses a security risk for the system because it allows a symlink attack. Definately, it should be fixed ASAP. It doesn't look like it's in stable though, so not DSA will be needed. Mike Stone -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDOzYA9n4qXRzy1ioRAhNmAJ0X6feD1K711AnlplWQk/mgFkPSqgCfeYan CxFKGWcdS29ZcNb1AdvmEhU= =jBKI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330627: rkhunter daily cron script is open to symlink attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 severity 330627 grave thanks I'm sorry, I inadvertantly miscategorized the bug as critical in the previous message because I thought this was related to the package installation. This bug does not affect users on installation, only on running the cronjob. $RKHUNTER --cronjob --report-warnings-only /tmp/$$ If I am not mistaken this command poses a security risk for the system because it allows a symlink attack. Using the following commands instead would solve the problem: OUTFILE=`mktemp ` || exit 1 $RKHUNTER --cronjob --report-warnings-only $OUTFILE Thanks for the report, however, this causes other breakage in the cronjob, because elsewhere in the script references /tmp/$$: if [ $(stat -c %s /tmp/$$) -ne 0 ]; then cat /tmp/$$ | mail -s [rkhunter] Daily run root fi rm -f /tmp/$$ So a more complete fix would be: - -$RKHUNTER --cronjob --report-warnings-only /tmp/$$ - -if [ $(stat -c %s /tmp/$$) -ne 0 ]; then - - cat /tmp/$$ | mail -s [rkhunter] Daily run root + OUTFILE=`mktemp` || exit 1 +$RKHUNTER --cronjob --report-warnings-only $OUTFILE +if [ $(stat -c %s $OUTFILE) -ne 0 ]; then + cat $OUTFILE | mail -s [rkhunter] Daily run root fi - - rm -f /tmp/$$ + rm -f $OUTFILE Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDOzps9n4qXRzy1ioRAvDmAJ9Ww5JjbC2dxb9ZhcEiqqn25NYDiACeLqdL uoYQybBEcH7pGdklOIC2piw= =EhrL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328209: util-vserver: Does not work on powerpc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Lee wrote: Andrew Lee wrote: Dear Ola, Thanks for the upload. I have found util-vserver 0.30.208-2 on incoming.d.o, I will give it a try on my powerpc right now. -Andrew Very unfortunately, I tested failed with this: http://incoming.debian.org/util-vserver_0.30.208-2_powerpc.deb The vserver syscall#: changed to 273/default So made all tools in the util-vserver couldn't work, eg: vserver-stat vs_new_s_context():Funtion not implemented and even this doesn't work: showattr -d /var/lib/vservers vc_get_iattr():Function not implemented I will try to build util-vserver from source to see if I can reproduce this. This sounds like a mismatched toolchain problem. I had this same problem when I had a kernel installed that was compiled with an older version of gcc, and then installed util-vserver_0.30.208-2 which had been compiled with the newer gcc4.0. What kernel revision are you running and what vserver patch? What gcc did you use to compile your kernel? It looks like when you recompiled util-vserver with the gcc you have installed it started to work, this says to me that there is something out of date there. micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPEia9n4qXRzy1ioRAvr0AJ44o6NtKmY9aJqpixdAnx0Yg9+aPACeLHdG ISCRWwX1QPwxZT0Fvk34a8w= =GfKs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329087: kernel-patch-vserver: be able to do chroot escape
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 329087 +moreinfo thanks Andrew Lee wrote: I found the kernel-patch-vserver and util-vserver in sarge can not pass the testfs.sh script[1] which provide by upstream author. Please tell me how you run this script and what failures you get, also this is a destructive test, correct? After some more tests, upstream author discoveryed this is a security hole. Here is what I did in my test: # ls -lda /var/lib/vservers//.. Did you first mkdir /var/lib/vservers/? I assume you did, otherwise you will get an error that does not exist. Although perhaps is supposed to be a vserver? I will continue assuming that is the case. d- 8 root root 4096 Sep 19 19:46 /var/lib/vservers//../ You would only get a trailing slash if you actually did: # ls -lda /var/lib/vservers//../ # showattr -d /var/lib/vservers//.. ---BU-- /var/lib/vservers//.. This is not what I get on my i386 system: # showattr -d /var/lib/vservers//.. - ---bui- /big/vservers//.. # lsattr -d /var/lib/vservers//.. ---t- /var/lib/vservers//.. Also I do not get this on my system: # lsattr -d /var/lib/vservers//.. - - /big/vservers//.. Please tell me what architecture you are running, what kernel version you are running, which kernel patch you are running and how you applied and compiled the kernel. Additionally, did you setup the chroot barrier properly? ssh into a guest and then starting the root exploit[2] inside a guest now gives: Exploit seems to work. =) sshing into a guest on my system and running that root exploit gives: mkdir baz: Permission denied chroot baz: No such file or directory And then I can be able to access the host, can be able to read /etc/shadow and can be able to create /test.txt in the host. I think you may have set something up incorrectly, or perhaps the util-vserver tools did not set the chroot barrier properly. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPF559n4qXRzy1ioRAkawAKCtdYHVQnVTeQW2WHUtpZkz7JjRQwCfc3De m8UymU8COYdr8/8axxPJ01g= =gWzU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329087: kernel-patch-vserver: be able to do chroot escape
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micah wrote: ssh into a guest and then starting the root exploit[2] inside a guest now gives: Exploit seems to work. =) sshing into a guest on my system and running that root exploit gives: mkdir baz: Permission denied chroot baz: No such file or directory I did not realize that you have to ssh into the guest as *root* to run this rootesc binary. If I do that I get the result: Exploit seems to work. =) And then I can be able to access the host, can be able to read /etc/shadow and can be able to create /test.txt in the host. However, I am *not* able to access the host, I cannot read /etc/shadow, nor can I create /test.txt in the host. I am going to try and speak with Bertl about this to try and narrow down the issue. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPGHS9n4qXRzy1ioRAvQ7AKCiLGEqM0PJS/XxWQpaozo3V7w87gCgjgAw Dqv5VL72cLm3J/WLL1Cz7E0= =jPNa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329087: kernel-patch-vserver: be able to do chroot escape
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When I said this: This is not what I get on my i386 system: # showattr -d /var/lib/vservers//.. - ---bui- /big/vservers//.. This was expected because this was actually a symlink, if I perform the showattr on the actual directory I get this: # showattr -d /big/vservers//.. - ---Bui- /big/vservers//.. Which means that the barrier is set. Also, the rootesc.c code is dumb and says the exploit works all the time when it doesnt, on any 2.6 setup with namespaces its going to say that when it isn't actually successful. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPGxO9n4qXRzy1ioRAqDrAJ9VeAcKwiXJknYbAhsw3UFh+V5RDwCfTsIu Vu072njgt8weQ2Xyo/ibATc= =LHQq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330693: rkhunter: postinst-script depends on in-place flag of sed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 330693 +pending thanks i know that this package is currently in sid and will never go to sarge, not to speak of woody; however, since the use of new features of sed (i guess, -i was introduced with sed-4.0 and woody is using sed-3.1) is the only reason why i cannot install the package on older systems, i would highly appreciate if this could be changed. I dont think it is wise to begin making changes to a package to support an unsupported distribution, because there are quite possibly a number of other things that will also need to be changed. It is also quite difficult to continue to package something taking into account older versions that aren't supported. It is very easy for you to fix this problem on your own system. However, I am a little suspicious of in-place sed -i commands, so I think we will be fixing this soon. anyhow, looking through the postinst script, i also noticed that you are checking for the existance of a file named $CF, but then you are manipulating a file named $DF is this a typo (or is it just my ignorance off the postinstall-process)? if so, i guess this bug-report should have a higher priority than minor This is a typo and is now fixed in SVN, to be uploaded soon. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPHID9n4qXRzy1ioRAjMMAJwLB8fs+seG6FsUIEgdNIE8ukDokACePYUK AClfycgTXnKaa+KYgmlQ0+c= =JUPG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319817: ftp.debian.org: Please remove openmosix and kernel-patch-openmosix
Stephen Frost wrote: * Jeroen van Wolffelaar ([EMAIL PROTECTED]) wrote: The kernel patch itself might actually be workable enough for unstable but I'm afraid the userspace is pretty much missing still and some things have been moved to userspace that are reasonably important (such as load balancing across the cluster). I'd rather it not be removed from unstable (the only thing it's in, after all), but mainly because I'd rather not have to go through the NEW queue again when I feel the 2.6 patches/userspace are suitable to package for unstable. Sounds like this should be in experimental instead. I suppose if Micah just can't stand it I could package and upload the 2.6 stuff soon, but I'd rather wait till it's a bit more developed/stable. I'm not sure if uploading something that is *more* alpha is the right way to go. I'm not sure what you mean by if Micah just can't stand it, but I'm detecting some hostility and provocation. I meant no hostility at all in submitting this, I am sorry if it came across that way, and I apologize if you felt I was acting that way, I must have not communicated affectively. I only reported this bug after doing secure-testing work, finding the security problem in the package, speaking to you about it following through on the conversation by asking debian-QA their thoughts. You made it clear that you weren't interested in maintaining the package and didn't see the need to even file for its removal or adoption and even suggested that I do so myself, indeed my interpretation was that you felt that anyone other than you should do it since you couldn't be bothered. This isn't about what I can or can't stand, its about what Debian users can stand and what QA can stand. It seemed the right thing to do after your comments, the debian-QA approval, and the security problem. I'm sorry if doing so has caused you consternation, I was sincerely not trying to do so. Micah, it's appreciated when making such type of requests to X-Debbugs-Cc the maintainer in question. Aww, but then I'd get to comment on it and I might ruin his little vendetta/pity party. Your implication that I avoided adding that tag on purpose in order to sneak around your comments is an interesting accusation, and I'm sorry if anything I've said has caused you to assume that I have dont this out of a vendetta/pity party (not sure what that means), but I can tell you truthfully that it was not done to subvert your comments, it was simply not appended out of my own ignorance that it existed. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324167: Please mention in changelog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, When you fix this, please mention the CAN numbers fixed in the upload changelog. This helps the testing-security team track these. Additionally, if a fix for openvpn in testing is blocked by other elements, please contact the testing-security team for aid in getting a DTSA and the fix moved into testing. Thanks, micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDD7O19n4qXRzy1ioRApGYAJ0ee16UGZkcrx4X/IPsOzhlTSRFgQCcDGYQ tgCtsfJsJLfHDAg1cDw/rHo= =MJrl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328022: bittornado-gui: Fails to remove file in bin/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just installed bittornado and bittornado-gui in a fresh chroot and then did an apt-get --purge remove bittornado-gui and I do not have that dangling symlink. Do you have bittorrent also installed? Micah Justin Pryzby wrote: Package: bittornado-gui Version: 0.3.11-4 Severity: normal File: /usr/bin/btcompletedirgui usr/bin/btcompletedirgui is presently an indirectly broken symlink: $ ls -l /usr/bin/btcompletedirgui lrwxr-xr-x 1 root root 34 Sep 21 2004 /usr/bin/btcompletedirgui - +/etc/alternatives/btcompletedirgui $ ls -l /etc/alternatives/btcompletedirgui lrwxr-xr-x 1 root root 36 Sep 21 2004 /etc/alternatives/btcompletedirgui - +/usr/bin/btcompletedirgui.bittornado which is nonextant. I have: ii bittornado 0.3.11-4 pn bittornado-gui none -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDKxqL9n4qXRzy1ioRAjlcAJ9E+j20WHIcWVpPVAn5T9X4NHUjkwCggZdC ZN/8IjtCrEc3SAFvdqgMim0= =jB59 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328632: [Logcheck-devel] Bug#328632: Please include README.logcheck-database.gz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie L. Penman-Smithson wrote: On Wed, 2005-09-14 at 21:35 -0400, Micah Anderson wrote: man (8) logcheck says: For hints on how to maintain rules, see README.logcheck-database.gz, but this file is not included in /usr/share/doc/logcheck. It's included in the logcheck-database package upon which logcheck depends on. Then the man page should be changed from: For hints on how to maintain rules, see README.logcheck-database.gz. to: For hints on how to maintain rules, see /usr/share/doc/logcheck-database/README.logcheck-database.gz. because /usr/share/man/man8/logcheck.8.gz is included in the logcheck package, not the logcheck-database package and when you man logcheck you are expecting that file to appear in /usr/share/doc/logcheck because its the man page for logcheck, not logcheck-database. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDKyyu9n4qXRzy1ioRAhHEAJ0UYQDFnlMTkoyZKDnbCQwHCjTjrwCeLyvm +3Pkbur4CeSOqz6YTIOapnM= =waSA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329411: Suggestion: add a daily cronjob
Francois Marier wrote: Package: rkhunter Version: 1.2.7-11 Severity: wishlist How about running the cronjob every day instead of every week? I would personally want to know as soon as possible if someone rooted my machine. I agree, its nicer to know sooner. So unless it takes a really long time to run rkhunter, I would suggest that the weekly cronjob be run every day instead. Perhaps the signature database update could be run once a week and the system scan be run daily. This could be configurable. Also, I would also like to suggest that you add debconf question like the one in chkrootkit that enables the cronjob with users having to manually edit a config file. A good suggestion as well. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323026: bittornado: Crash's on checking incomplete files on vfat paritions
This looks like you are running a very old kernel (2.4.18), Debian doesn't support this kernel any longer as it has some significant problems. Can you upgrade to one of the Debian 2.4.27 kernels for your architecture and retry this on a vfat partition to see if this still occurs? Micah Package: bittornado Version: 0.3.11-4 Severity: normal While checking the half-downloaded file on vfat partition,bittornado crashes with the following stack trace. The download files seems to have a incomplete or empty clusters, so to solve this problem I did a fsck on the target partition or move this half-downloaded file a ext2 partition and restart the bittornado application. ~~ Aug 14 13:39:41 box kernel: invalid operand: Aug 14 13:39:41 box kernel: CPU:0 Aug 14 13:39:41 box kernel: EIP: 0010:[apm:__insmod_apm_O/lib/modules/2.4.18-1-k6/kernel/arch/i386/ker+-21 4787/96]Tainted: P Aug 14 13:39:41 box kernel: EFLAGS: 00010287 Aug 14 13:39:41 box kernel: eax: 284ff800 ebx: c5d06040 ecx: 0009 edx: Aug 14 13:39:41 box kernel: esi: 001427fc edi: c3a7b420 ebp: c857f600 esp: c3dcde70 Aug 14 13:39:41 box kernel: ds: 0018 es: 0018 ss: 0018 Aug 14 13:39:41 box kernel: Process btdownloadcurse (pid: 1771, stackpage=c3dcd000) Aug 14 13:39:41 box kernel: Stack: 0a00 c9863000 000284ff c3dcdec4 c26abc30 c012fdc1 c5d06040 001427fc Aug 14 13:39:41 box kernel:c3a7b420 0001 0850 c9863000 000284ff cb4038dc cb19dc40 c9863000 Aug 14 13:39:41 box kernel:c8282f60 0200 001427fc 0800 c3a7b420 cb19dc9c cc055576 c013048e Aug 14 13:39:41 box kernel: Call Trace: [__block_prepare_write+177/716] [apm:__insmod_apm_O/lib/modules/2.4.1 8-1-k6/kernel/arch/i386/ker+-780938/96] [cont_prepare_write+354/496] [apm:__insmod_apm_O/lib/modules/2.4.18-1 -k6/kernel/arch/i386/ker+-214868/96] [apm:__insmod_apm_O/lib/modules/2.4.18-1-k6/kernel/arch/i386/ker+-208540 /96] Aug 14 13:39:41 box kernel: [apm:__insmod_apm_O/lib/modules/2.4.18-1-k6/kernel/arch/i386/ker+-214868/96] [ generic_file_write+1108/1720] [apm:__insmod_apm_O/lib/modules/2.4.18-1-k6/kernel/arch/i386/ker+-214610/96] [a pm:__insmod_apm_O/lib/modules/2.4.18-1-k6/kernel/arch/i386/ker+-214644/96] [sys_write+149/224] [system_call+5 1/64] Aug 14 13:39:41 box kernel: Aug 14 13:39:41 box kernel: Code: 0f 0b b8 fb ff ff ff eb 58 8b 83 98 00 00 00 0f b7 90 cc 00 ~~ -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.18-1-k6 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages bittornado depends on: ii python2.3.5-3An interactive high-level object-o Versions of packages bittornado recommends: ii mime-support 3.34-1 MIME files 'mime.types' 'mailcap -- no debconf information
Bug#321659: util-vserver: New fixes are available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ola Lundqvist wrote: Hello On Thu, Aug 18, 2005 at 11:33:31PM -0500, Micah Anderson wrote: Package: util-vserver Version: 0.30.208-1 Followup-For: Bug #321659 Hi Ola, Thanks for updating to .208! Of course a day or so after you update, there are new fixes available. Can you remove the fix01.diff that you applied, and apply these instead: http://vserver.13thfloor.at/Experimental/UTIL-VSERVER/delta-0.30.208-kheaders.diff this patch updates the kernel (vserver) headers to vs2.0 http://vserver.13thfloor.at/Experimental/UTIL-VSERVER/delta-0.30.208-shiny7.diff this patche replaces the old, broken alternative syscall implementation with the new extensively tested one (this fixes a problem with gcc4.x builds) These fixes include all the fixes in fix01, as well as these additional fixes. Do that mean that I have to remove the fix01 patch before applying this? Yes, these diffs include everything that fix01 has, and more. So remove fix01, and apply these in its place. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBexp9n4qXRzy1ioRAigZAJ90MZ3H/7AYJUkVMemVT3FLBVi94QCglv6A m/1G0QJngsg0wtuSfJTw8M8= =yqso -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321659: util-vserver: Please upgrade to latest toolset
Ola Lundqvist wrote: Hello On Sat, Aug 06, 2005 at 01:19:42PM -0500, Micah Anderson wrote: Package: util-vserver Version: 0.30.207-9 Severity: wishlist Version 0.30.208 fixes a significant number of problems, and works more properly with the newer patches. I'll upgrade to the latest version. Do you have a pointer to the exact problems? Just want to make sure that version 207 enter testing first. That is fix the build issues on some arches. The fixes between .207 and .208 are several months in the making, the best way to see all the details would be to get the latest tarball and look at the Changelog file. Lots of small bug fixes... some security fixes to the capability system (CAP_AUDIT stuff and the default behavior is to assume unknown capabilities are insecure); the barrier-code has been adjusted to work properly with the 1.2.10 patch. The code has been updated to work with the newer available patches more cleanly (in the headers etc.). Some build-time enhancements, such as checking to see if a context is already active before starting a build, removing a failed built vservers (unless an argument is passed), resulting in less cruft laying around; numeric xids are supported in vserver-info; syscalls are updated to newest versions, debootstrap status information enhanced. Some legacy problems were resolved, chroot code was enhanced I can't remember everything that I've seen go by in the CVS tree, but it is commonly said on the IRC channel that the .208 version is a vast improvement over .207 and whenever people come in for help and it is found out that they are using the debian packaged .207, they are immediately told to go compile and install .208. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321659: [Fwd: Re: [Vserver] [Release] Stable 2.0]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am forwarding this message to the debian bug ID related to updating the util-vserver tools to the latest version. Ola, please be sure to apply the patch that Herbert provides for util-vserver to fix some additional known issues. micah Herbert Poetzl wrote: please check the patch(es) I provide against util-vserver 0.30.208, as they will either extend functionality or fix known issues ... http://www.13thfloor.at/vserver/s_rel26/v2.0/patch-0.30.208-fix01.diff.bz2 (for now) TIA, Herbert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC9/Zb9n4qXRzy1ioRAuUFAJ91R499Tu+4YzGlmzWAcMPOU26CzACfeHUM rSoktoRSQHkCDORkOMNDy2g= =etSm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293650: getting to know you
Hire, i !am here sitting in the internet caffe. Found your email and decided to write. I might be coming to youar placea in 14 days, so I decided to email !you. May be we can meet? I am 25 y.o. girl. I have a piacture if you want. No need to areply he!re as this is not my email. Write me at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365680: I have requested a CVE assignment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have requested a CVE assignment for this vulnerability, and will send it on as soon as it is obtained. Please include this reference in any changelog resolving this issue so that it can be appropriately tracked. There is no CVE assigned yet as far as I know. I don't know, if the security team requires this. Yes, it is required for DSAs, and for tracking issues. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEV41H9n4qXRzy1ioRAsNEAJ42NM4+aDK/IeHFXIq662nz8GkYvwCeLYvv zHX7nGwuG1i3V4DrH2q0PPc= =usJH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#221457: metting you
Hi, Hope I am not writing to wrong address. I am nice, pretty looking girl. I am planning on visiting your town this month. Can we meet each other in person? Message me back at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356642: Upstream added
Just a quick note to let you know that upstream has added this to their os.dat file, so it will appear in the next release. Micah signature.asc Description: Digital signature
Bug#605951: this breaks rxvt-unicode compatibility
As of version 9.09-3, urxvt uses TERM=rxvt-256color as suggested Pierre. However, the terminfo for rxvt-256color is provided by the ncurses-term package, therefore rxvt-unicode should recommend ncurses-term. Its not that simple. Now that TERM=rxvt-256color for rxvt-unicode, when you login to a lenny machine you pretty much are unable to do anything interesting: mi...@swift:~$ top 'rxvt-256color': unknown terminal type. mi...@swift:~$ arg. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578157: and another!
Also I noticed that upstream released 0.3.17 this week. And it looks like 0.3.18 is now there... Jumping on the bandwagon here, but without any time myself to help in the packaging effort :P micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#448638: any progress on i2p?
Hi, , | I would love for it to be non-native, but the only way I have been able | to do that is by following the workaround at the bottom of bug 580804: | | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580804 ` Did you see the follow-up posts on debian-mentors to your sponsorship request? Specifically, this one, which details how to do it: http://lists.debian.org/debian-mentors/2010/11/msg00478.html micah -- pgpxS8RsyJ8b3.pgp Description: PGP signature
Bug#597222: agreed
I think that Clint was confused when he wrote the content of that bug. He asked me about the folder patch, then filed that bug, and then pointed me to the bug report. If anyone has the skillz, making the minor changes to the patch to support folder: probably isn't too hard, and it would be great if someone was able to do that! I haven't been able to accomplish this myself. micah -- pgppvY1hyZm7p.pgp Description: PGP signature
Bug#572277: pstree
I agree that this is the same as 562645, i've merged them. Regarding a pstree, this is what it looks like: init─ ├─nagios-statd───nagios-statd Not particularly useful information unfortunately... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474087: Tested and NMU'ing 2
As part of the fun at the NYC BSP, I decided to try and fix this issue. I built this package, with the patch that Simon McVittie submitted. I then asked someone to test this on a system with ipmi and it seemed to work fine: aromatase:/var/temp# pkg-config --libs OpenIPMIpthread -pthread -lOpenIPMIpthread -lOpenIPMIutils -lOpenIPMI aromatase:/var/temp# aromatase:/var/temp# pkg-config --exists OpenIPMIpthread aromatase:/var/temp# echo $? 0 aromatase:/var/temp# I'm uploading this as a NMU, in the delayed-5 queue. Thanks everyone! micah pgpBFqX6cNWJQ.pgp Description: PGP signature
Bug#568061: sqlite3: New Upstream Release 3.6.22
Package: sqlite3 Version: 3.6.21-2 Severity: wishlist -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564820: ITP: libpam-barada -- PAM module to provide
Hey Andrew, any progress on this?
it was written specifically with Android devices in mind.
There are many HOTP client out there[1]. Is it really android specific
in any way? I suggest dropping that sentence.
The piece that would be put in Debian is not Android specific, but there
is a companion application that goes along with barada that is for
Android.
Also, you say that there are many HOTP clients out there, but I have not
found any easy ones such as this one for Debian. Also your URL you cite
is a 404:
[1] http://rcdevs.com/products/openotp/tokens.php
There is companion software which runs on Android, so that your
^^ ${your phone}
Is that true? Maybe this libpam-barada works for other HOTP clients,
with different client software on other phones, but this is the text
From the upstream and unless someone is able to determine that it works
on non-android phones, it seems a little too soon to generalize it.
I suppose this new RFC is more secure than plain old OTP/OPIE (?). In
any case, the package could include those 2 keyword for `aptitude
search`
I think the existence of OTP in HTOP will cause aptitude to find
it. OPIE is just another OTP implementation, just like HOTP is, so I'm
not sure if it needs to be listed, but I wouldn't care if someone did.
micah
pgpKSHa7nv5Lo.pgp
Description: PGP signature
Bug#564820: HOTP
I would suggest that the PAM architecture is better suited to providing only _one_ factor of authentication per plugin. Does this module really implement two factors? If not, you probably shouldn't claim that it does. Have you read the HOTP RFC[0]? micah 0. http://tools.ietf.org/html/rfc4226 -- It is no measure of health to be well adjusted to a profoundly sick society. - J Krishnamurti pgpaRrJ6SH21S.pgp Description: PGP signature
Bug#569894: nmap: New upstream version 5.21
Package: nmap Version: 5.00-2 Severity: wishlist Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214200348.28308.2774.report...@defiant
Bug#570190: subcommander: should build depend on fl-cow = 0.6-4
Package: subcommander Version: 2.0.0~b5p1-1 Severity: minor Tags: patch Since the patch to libflcow.so is hardcoded in the rules file, you should depend on the package version with that path. diff -u subcommander-2.0.0~b5p1/debian/control subcommander-2.0.0~b5p1/debian/control --- subcommander-2.0.0~b5p1/debian/control +++ subcommander-2.0.0~b5p1/debian/control @@ -4,7 +4,7 @@ Maintainer: Robert Luberda rob...@debian.org Build-Depends: debhelper ( 7.0.0), quilt (= 0.46), libqt4-dev (= 4.4), libx11-dev, libboost-dev|libboost1.39-dev, libapr1-dev, libdb-dev, libsvn-dev, - libssl-dev, xsltproc, docbook-xsl, autotools-dev, dpkg-dev (= 1.13.19), automake, fl-cow + libssl-dev, xsltproc, docbook-xsl, autotools-dev, dpkg-dev (= 1.13.19), automake, fl-cow (= 0.6-4) Standards-Version: 3.8.3 Homepage: http://subcommander.tigris.org/
Bug#568562: dojo: New upstream release 1.4.1
Package: dojo Severity: wishlist Thanks -- System Information: Debian Release: squeeze/sid -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540328: README
Looking at the INSTALL file, and the README in /usr/share/doc/rabbitmq-server, it seems like the README contains the top part of that INSTALL file, but not the rest. The README looks like this: Please see http://www.rabbitmq.com/build-server.html for build instructions. For your convenience, a text copy of these instructions is available below. Please be aware that the instructions here may not be as up to date as those at the above URL. === but then there is nothing below. It seems like the README file is supposed to contain what is in the INSTALL document. If the INSTALL contains nothing useful for Debian installations, and it is going to be removed, then the README should also be removed, since it is pointless how it is. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543638: Any progress?
I notice that there hasn't been any progress on this bug since it was originally reported back in August. Any chance that this will be fixed, its a bit ugly to have to hack the initscript to make these changes. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575347: mantis: New upstream version 1.2.0
Package: mantis Version: 1.1.8+dfsg-4 Severity: wishlist This might also fix Bug #569686 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575463: miro: New Upstream Version 3.0
Package: miro Severity: wishlist http://ftp.osuosl.org/pub/pculture.org/miro/src/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571044: Seeing this with debconf prompts
I'm also seeing a similar problem, but outside of D-I, just with normal package upgrades: http://micah.riseup.net/shots/shot-2010.02.23-11.49.38.png As you will notice, the cancel button is quite amazing. pgp3vRmOBgqd5.pgp Description: PGP signature
Bug#577753: phpmyadmin: New Upstream Version 3.3.2
Package: phpmyadmin Version: 4:3.3.1-1 Severity: wishlist Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577616: Update to xml file
Please use the attached xml file as an update to the one previously sent by Daniel. The changes in this version provide a corrected instructionsURL and updates the clientConfigUpdate to reference the xml from the standard location for autoconfiguration as described at: https://developer.mozilla.org/en/Thunderbird/Autoconfiguration#Configuration_server_at_ISP thanks! micah pgpggnWl2Z1iN.pgp Description: PGP signature riseup.net.xml Description: XML document
Bug#575347: mantis: New upstream version 1.2.0
I was wondering if anyone was going to get to this soon. If it gets into Debian this week, I can sync to Ubuntu for Lucid. Thanks. On 03/24/2010 10:32 PM, Micah wrote: Package: mantis Version: 1.1.8+dfsg-4 Severity: wishlist This might also fix Bug #569686 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575347: Need help?
Sorry, I forgot to mention in the last message that I'm willing to help also if anything is needed. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578799: vlc: New upstream 1.0.6 bug fix release
Package: vlc Severity: wishlist Upstream Changes list: Changes between 1.0.5 and 1.0.6: Access: * Fix crash on FTP URI with no file path Decoders/Packetizers: * Fix overflows in A/52, DTS, MPEG Audio and subtitles support Demuxers: * Update LUA script for Youtube pages * Fix crashes in AVI, ASF and Matroska files * Fix crashes on malformatted ZIP archives * Fix crashes and leaks in the FFmpeg/avformat plugin * Fix crash on invalid XSPF playlist X11 port: * Partial Xlib threading fixes More complete fixes are available in VLC 1.1.0. Please update! Interfaces: * Fix crash (use after free) in Qt4 bookmarks * Fix a few crashes in Qt4 playlist Translations: * Simplified Chinese, Estonian, French, Japanese, Korean, Spanish, Swedish and Walloon translations updated * Sinhala translation started Removed modules: * RTMP input and output are removed due to security problems. Please update to VLC 1.1.0 which provides an FFmpeg-based RTMP input if needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575347: New upstream version 1.2.1
retitle 575347 New upstream version 1.2.1 thanks No longer as urgent for me since Lucid is released already, but it might be good to get into squeeze. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557314: Confirmed: not needed
I just installed the redmine package, and I did not need the libgit-ruby package to get git repository support. I would suggest that this plug be closed, unless there is further information from the submitter. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504805: Work around
Eventually I stumbled on a way to keep my machines from restarting, its not a great solution, but it stops me from having to deal with the failure on a daily basis. I think that anyone else who is having this problem can do this and it will work. Obviously this is not the right solution, but it works until we can get a fix. First I made sure this was set: /etc/xen/xend-config.sxp: (dom0-cpus 0) Then I pinned individual physical CPUs to specific domU's, once pinned, the problem stops. What does that mean? Well, Xen does this wacky thing where it creates virtual CPUs (VCPUs), each domU has one of them by default (but you can have more), and then it moves physical CPUs between those VCPUs depending on need. So lets say you have four CPUs, and a domU. That domU has one VCPU by default. That VCPU could actually have the physical CPU 0, 1, 2, 3 all servicing it to provide that VCPU, even at the same time. I found somewhere that this can be a performance hit, because it needs to figure out how to deal with this and switch contexts. I also read that it could cause some instability (!), so pinning the physical CPUs so they don't move around seemed to solve this. The pinning does not stick across reboots, so it has to be done again if the system is rebooted, and it isn't really possible to set this in a startup script, at least I don't think so. So how do you do this? If you look at 'xm vcpu-list' (which annoyingly isn't listed in 'xm help') you will see the CPU column populated with a random CPU, depending on scheduling, and then the CPU Affinity column all say 'any cpu'. This means that any physical CPU could travel between them, and would, depending on the scheduling. Once you pin things, then the individual domU's are set to have specific CPU affinities, so the CPUs don't 'travel' between them, and magically the crash stops. So an example: r...@shoveler:~# xm vcpu-list NameID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 1 -b- 283688.8 any cpu Domain-0 0 1 1 --- 39666.3 any cpu Domain-0 0 2 1 r-- 49224.4 any cpu Domain-0 0 3 1 -b- 75591.1 any cpu kite 1 0 3 -b- 71411.8 any cpu murrelet 2 0 0 -b- 47.2 any cpu test 3 0 0 r-- 342182.3 any cpu So we want to fix that final column using 'xm vcpu-pin' (also a command not listed in 'xm help'): Usage: xm vcpu-pin Domain VCPU|all CPUs|all Set which CPUs a VCPU can use. r...@shoveler:~# xm vcpu-pin 0 0 0 r...@shoveler:~# xm vcpu-pin 0 1 0 r...@shoveler:~# xm vcpu-pin 0 2 0 r...@shoveler:~# xm vcpu-pin 0 3 0 r...@shoveler:~# xm vcpu-pin 1 0 1 r...@shoveler:~# xm vcpu-pin 2 0 2 r...@shoveler:~# xm vcpu-pin 3 0 3 r...@shoveler:~# xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 1 -b- 283700.3 0 Domain-0 0 1 1 r-- 39669.6 0 Domain-0 0 2 1 -b- 49227.4 0 Domain-0 0 3 1 -b- 75596.2 0 kite 1 0 3 -b- 71415.3 1 murrelet 2 0 0 -b- 472237.8 2 test 3 0 0 r-- 342182.3 3 And voila, no more crashes... :P micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576387: LSB dependencies
In addition to the sysv priorities, there is also the LSB dependencies that newer init systems use. I don't think you'd want to setup any dependencies there, since it doesn't apply to all cases: 1) while you might have ekeyd and egd on the same system, we don't know that egd is configured to point at the local ekeyd 2) egd shouldn't depend on stunnel because it's not always going to be configured to use stunnel I think that is what the Should-Start keyword in the header is for actually: Should-Start: boot_facility_1 [boot_facility_2...] * defines the facilities that if present should start before the service provided by the script. Nevertheless, the script can still start if the listed facilities are missing. This allows for weak dependencies which do not cause the service to fail if a facility is not available. Consider using virtual facility names as described below if adequate. Which means that it would make sense to have Should-Start headers, but not Required-Start headers. This of course only solves the problem for the newer dependency-based init systems, it shouldn't be the solution for the start priority issue for other init systems. micah pgpBmPIu0Gz6y.pgp Description: PGP signature
Bug#598136: Not quite fully enabled yet
reopen 598136 found 598136 4.4.1-5 thanks Thanks so much for the quick turn-around in enabling the --enable-test-vectors compile-time option! However, there is one thing still missing to make it work. By adding that compile-time option, a new shared library is generated called libstrongswan-test-vectors.so. This is not being installed by the package. Easy fix though, just add this line to debian/libstrongswan.install usr/lib/ipsec/plugins/libstrongswan-test-vectors.so*usr/lib/ipsec/plugins/ micah -- pgpN8PtdUsIAD.pgp Description: PGP signature
Bug#598138: stripped?
Looking at the output again: invalid 'libstrongswan' file size: 152796 bytes, expected 617722 bytes that looks like libchecksum.so has embedded the sizes of the non-stripped libraries. Then the debian build process goes and strips them, reducing their size to a much smaller number than what is embedded. I'm not sure what the right solution to that is, either don't strip the libraries, so the sizes match, or strip them and then embed the sizes in the libraries. m pgpzLaiL7Gco5.pgp Description: PGP signature
Bug#560860: This would be good to enable
It looks like it just would be a change to the configure flags... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585745: Please drop timeout binary package
Package: timeout Version: 1.19-1 Severity: important This binary package was removed in bug 570997, but the source still builds it. -- System Information: Debian Release: squeeze/sid -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586503: transmission: New upstream version available (2.00)
Package: transmission Version: 1.93-2 Severity: wishlist http://www.transmissionbt.com/ Transmission 2.00 (2010/06/15) ¶ All tickets closed by this release All Platforms ¶ * Local Peer Discovery for finding peers on the local network * Optimize download requests for the bandwidth available * Smarter heuristics when deciding the order to connect to peers * Faster verification of local data * Faster startup * Support more blocklist file formats * Use IEC standard units (KiB, MiB, GiB) instead of (KB, MB, GB) * Better handling of 404 tracker errors Mac ¶ * Compact View replaces Minimal View, taking up considerably less space * Show an Add Transfer window when adding magnet links * Resume All now ignores finished transfers * Allow trackers to be pasted into the Create Window * European Portuguese localization * Removed Traditional Chinese localization because of lack of localizer GTK+ ¶ * New filterbar to filter by tracker, private/public, etc. * Compact View replaces Minimal View, taking up considerably less space * Show the Torrent Options dialog when adding magnet links * Set Location now supports moving multiple torrents at once * The Properties window now fits on low resolution screens * Add favicon support to the Properties dialog's Tracker tab Qt ¶ * Show the Torrent Options dialog when adding magnet links * Show all active trackers in the tracker display list * Show file sizes in the file tree * Added a confirm dialog when removing torrents * Properties and torrent options no longer jump around while editing * Allow setting locations for remote sessions * Miscellaneous UI fixes Daemon ¶ * Let users specify a script to be invoked when a torrent finishes downloading * Better support for adding per-torrent settings when adding a new torrent * Optional pidfile support * Option to start torrents paused * Option to delete .torrent files from watch directory Web Client ¶ * The context menu now works when multiple rows are selected * Show ETA for seeding torrents that have a seed ratio set -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid-backports'), (500, 'lucid') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-22-generic (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages transmission depends on: pn transmission-cli none (no description available) pn transmission-common none (no description available) pn transmission-gtk none (no description available) transmission recommends no packages. transmission suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588299: miro: New Upstream Version 3.0.2
Package: miro Version: 3.0.1-0ubuntu2 Severity: wishlist I believe the new version 3.0.2 fixes bug 499652 as well. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589792: instantbird: Please package version 0.2 of Instantbird
Package: instantbird Severity: wishlist Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590006: doctrine: Include option php ini include for Doctrine
Package: doctrine
Version: 1.2.2-1
Severity: wishlist
Tags: patch
It would be nice to include a php ini file for sysadmins to easily enable
doctrine to be incuded in apps. I've set this to be disabled by default.
-- System Information:
Debian Release: squeeze/sid
APT prefers lucid-updates
APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500,
'lucid-backports'), (500, 'lucid'), (300, 'lucid-proposed')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-23-generic (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages doctrine depends on:
ii php55.3.2-1ubuntu4.2 server-side, HTML-embedded scripti
ii php5-cli5.3.2-1ubuntu4.2 command-line interpreter for the p
ii php5-mysql 5.3.2-1ubuntu4.2 MySQL module for php5
ii php5-sqlite 5.3.2-1ubuntu4.2 SQLite module for php5
doctrine recommends no packages.
diff -Nru doctrine-1.2.2/debian/doctrine.ini doctrine-1.2.2/debian/doctrine.ini
--- doctrine-1.2.2/debian/doctrine.ini 1969-12-31 18:00:00.0 -0600
+++ doctrine-1.2.2/debian/doctrine.ini 2010-07-22 16:17:09.0 -0500
@@ -0,0 +1,3 @@
+[Doctrine]
+; include_path=${include_path} :/usr/share/php/Doctrine/lib
+
diff -Nru doctrine-1.2.2/debian/install doctrine-1.2.2/debian/install
--- doctrine-1.2.2/debian/install 2010-07-19 02:20:34.0 -0500
+++ doctrine-1.2.2/debian/install 2010-07-22 16:15:32.0 -0500
@@ -1,3 +1,2 @@
Doctrine-*/lib usr/share/php/Doctrine
-
-
+debian/doctrine.ini etc/php5/conf.d
Bug#590232: sqlite3: Please package sqlite 3.7.0
Package: sqlite3 Severity: wishlist Thanks. -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid-backports'), (500, 'lucid'), (300, 'lucid-proposed') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-24-generic (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages sqlite3 depends on: ii libc6 2.11.1-0ubuntu7.2 Embedded GNU C Library: Shared lib ii libreadline6 6.1-1 GNU readline and history libraries ii libsqlite3-0 3.6.22-1 SQLite 3 shared library sqlite3 recommends no packages. Versions of packages sqlite3 suggests: pn sqlite3-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569894: nmap: New upstream version 5.21
Just poking to see if we can get this updated :) Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550279: kvpnc-0.93-1 requires pkg-kde-tools = 0.5.0
Package: kvpnc Version: 0.9.3-1ubuntu1 Severity: important Justification: fails to build from source This version of the package has debhelper kde added which was added to pkg-kde-tools in 0.5.0, but there is not a requirement on pkg-kde-tools 0.5.0 I removed the debhelper kde line and it still built fine. -- System Information: Debian Release: squeeze/sid APT prefers karmic-updates APT policy: (500, 'karmic-updates'), (500, 'karmic-security'), (500, 'karmic-backports'), (500, 'karmic') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-12-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kvpnc depends on: ii kdebase-runtime 4:4.3.2-0ubuntu1 runtime components from the offici ii kdelibs54:4.3.2-0ubuntu3 core libraries for all KDE 4 appli ii libc6 2.10.1-0ubuntu15 GNU C Library: Shared libraries ii libgcc1 1:4.4.1-4ubuntu7 GCC support library ii libgcrypt11 1.4.4-2ubuntu2 LGPL Crypto library - runtime libr ii libqt4-dbus 4.5.2-0ubuntu6 Qt 4 D-Bus module ii libqt4-network 4.5.2-0ubuntu6 Qt 4 network module ii libqt4-qt3support 4.5.2-0ubuntu6 Qt 3 compatibility library for Qt ii libqt4-svg 4.5.2-0ubuntu6 Qt 4 SVG module ii libqt4-xml 4.5.2-0ubuntu6 Qt 4 XML module ii libqtcore4 4.5.2-0ubuntu6 Qt 4 core module ii libqtgui4 4.5.2-0ubuntu6 Qt 4 GUI module ii libstdc++6 4.4.1-4ubuntu7 The GNU Standard C++ Library v3 ii menu2.1.41ubuntu1generates programs menu for all me ii module-init-tools 3.10-3 tools for managing Linux kernel mo ii net-tools 1.60-23ubuntu1 The NET-3 networking toolkit ii psmisc 22.7-1 utilities that use the proc file s kvpnc recommends no packages. Versions of packages kvpnc suggests: ii iptables1.4.4-1ubuntu1 administration tools for packet fi pn openct none (no description available) pn opensc none (no description available) ii openssl 0.9.8g-16ubuntu3 Secure Socket Layer (SSL) binary a pn openswannone (no description available) pn openvpn none (no description available) ii pptp-linux 1.7.2-3 Point-to-Point Tunneling Protocol pn racoon none (no description available) ii vpnc0.5.3-1 Cisco-compatible VPN client pn xl2tpd none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623252: stable update of apt-show-versions?
I've been bit by this issue in squeeze, systems that depend on
apt-show-versions to know about upgrades were not upgrading to stable
point releases because of this.
I think that package should be updated in stable-updates itself.
I asked the backports admins about getting it in backports, and they
said that the right course of action is to get it into stable-updates
and they think that it could be put in faster than waiting for the next
stable point release.
For a stable-update I suspect we can only apply the relevant fix, which
is this if I am not mistaken (from svn diff -r51:52):
--- trunk/apt-show-versions (revision 51)
+++ trunk/apt-show-versions (revision 52)
@@ -561,7 +561,7 @@
$pkgfile =~ s{.*/}{};
return undef if ($pkgfile eq 'status');
# Sort according to length so we make the most specfic match
-foreach (keys %releasenames) {
+foreach (sort { length($b) = length($a) } keys %releasenames) {
return $_ if ($_ eq substr($pkgfile, 0, length($_)));
}
# As package file has no release file, create a fallback %releasenames
If you need help with this, I am happy to help. I do think that this
should be fixed soon as there have been a number of stable updates, and
I suppose that if I do not hear a response in a few days I'll upload to
a DELAYED queue.
micah
pgpwJH78qYY9H.pgp
Description: PGP signature
Bug#659392: debdiff
Attached is a debdiff against the squeeze version to fix imp4. Micah -- pgp8jwqHXvSry.pgp Description: PGP signature imp4_4.3.7+debian0-2.2.debdiff Description: Binary data
Bug#668454: ping?
I've noticed that twisted 13.0.0 is available in Debian, but the latest version is now 13.1.0 - any plans to update that soon? thanks! micah pgptRb4IBtJKE.pgp Description: PGP signature
Bug#719424: puppet-common: Please change the dependency from libaugeas-ruby to ruby-augeas
Hi, Laurent Bigonville bi...@debian.org writes: libaugeas-ruby is now a transitional package that pulls ruby-augeas. Hm, actually libaugeas-ruby just does: Depends: libaugeas-ruby1.9.1 and libaugeas-ruby1.9.1 depends on libaugeas0 and that does not depend on ruby-augeas. The dependency should be adjusted to install directly ruby-augeas. From what I see here, ruby-augeas is just the source package. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719424: puppet-common: Please change the dependency from libaugeas-ruby to ruby-augeas
Laurent Bigonville bi...@debian.org writes: Le Mon, 12 Aug 2013 14:02:44 -0400, micah mi...@debian.org a écrit : Hm, actually libaugeas-ruby just does: Depends: libaugeas-ruby1.9.1 and libaugeas-ruby1.9.1 depends on libaugeas0 and that does not depend on ruby-augeas. The dependency should be adjusted to install directly ruby-augeas. From what I see here, ruby-augeas is just the source package. Sorry, I had an outdated package list that wasn't showing me ruby-augeas as an actual binary package. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720050: monkeysign: -u should take full fingerprint
Antoine Beaupré anar...@anarcat.ath.cx writes: On 2013-08-17 18:16:59, Micah Anderson wrote: You can pass the full fingerprint, including spaces, to monkeysign for the key to be signed. However, if you try to do this for -u, then it gets rather confused and only takes the first 4 characters and then assumes the remainder is a key that should be signed (an invalid key that it will fail to find). This is a limitation of the optparse library - the number of arguments to an option is hardcoded, I believe. Logically, the commandline parser needs to know how many arguments after `-u` it needs to eat and pass to that option, and since we want to accept single uids, it seems to me we can't accept space-separated fingerprints there. I know it's inconsistent, but it's a limitation with the commandline parser built into python. The new argparse library supports variable length arguments, but that requires porting: Thanks for the explanation! http://docs.python.org/2/library/argparse.html#nargs So for now, use a single userid or (non-space-separated) fingerprint. (Or is monkeysign -u choking on (non-space-separated) fingerprints?) Nope, it is just choking on the space-separated ones. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719021: Being a pest
Hi, I'm wanting to be a nice pest about the progress of dovecot 2.2. The 2.1.7 stuff has made it all the way back to squeeze-backports now, so it seems pretty much settled down. I'm looking to build a new set of servers, and want to work with the newer dovecot, so I'm wondering if you have made any progress here? I've started to do some work importing upstream's 2.2 releases, and was wondering if I was duplicating work before I spent more time on this? thanks! micah pgpe_2IF0u4Vn.pgp Description: PGP signature
Bug#719021: Being a pest
micah mi...@debian.org writes: I'm wanting to be a nice pest about the progress of dovecot 2.2. The 2.1.7 stuff has made it all the way back to squeeze-backports now, so it seems pretty much settled down. I'm looking to build a new set of servers, and want to work with the newer dovecot, so I'm wondering if you have made any progress here? I've started to do some work importing upstream's 2.2 releases, and was wondering if I was duplicating work before I spent more time on this? Well, I forgot that I had already spent time on getting 2.2.1 in place, so I just went ahead and refreshed things up to 2.2.5, with an update to pigeonhole and then pushed a branch called debian/2.2.5, which could become master if you were ok with it. pgphL2aF_DyXD.pgp Description: PGP signature
Bug#720049: monkeysign: Make it easier to see what the email text will be
Antoine Beaupré anar...@anarcat.ath.cx writes: Can you try this patch? diff --git a/monkeysign/ui.py b/monkeysign/ui.py index ef2b7f6..6c24fe6 100644 --- a/monkeysign/ui.py +++ b/monkeysign/ui.py @@ -344,8 +344,8 @@ expects an EmailFactory email, but will not mail if nomail is set self.warn(_(\ not sending email to %s, as requested, here's the email message: -%s) % (msg.mailto, msg)) - +%s) % (msg.mailto, msg.create_mail_from_block(msg.tmpkeyring.export_data(msg.keyfpr + class EmailFactory: email generator If it does what you want I'll create a cleaner interface and factor this into 1.1. With that patch I see the unencrypted text of the mail, but it is still base64 encoded, so this patch has removed one step of the process, but for a regular human decoding base64 is probably not ideal. micah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
