Bug#495026: ITP: chessclock -- a simple chess clock to help track time in real life games
Package: wnpp Severity: wishlist Owner: The Anarcat <[EMAIL PROTECTED]> * Package name: chessclock Version : 1.1 Upstream Author : Antoine Beaupré <[EMAIL PROTECTED]> * URL : http://hg.koumbit.net/chessclock/ * License : GPL-3 Programming Lang: Python Description : a simple chess clock to help track time in real life games This is a fairly simple application designed to track the time spent thinking by the players during a chess game. Various ways of tracking time are supported, with only "countdown" (aka "blitz") and "fisher" for now. The graphical interface is keyboard driven and is intended to be minimal and simple. The code is made to be extensible to other game types. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A tool for tracking masked updates to stable packages
On Thursday 14 August 2008 03:00, Frans Pop wrote: > Marcin Owsiany wrote: > > I've just started to do research in order to write a tool which I was > > always missing. What I have so far is just a brief "background" > > information, explaining the problem - see below. > > I agree that this is a missing feature ATM: to be able to see at a glance > which packages did not come from the regular repository or have newer > versions than available from registered repositories. > > However, I would actually prefer this to be integrated in the regular > package management frontends (e.g. aptitude) rather than a separate tool. I put in +1 to that. Nothing to add. > > If the source of the package is in /etc/apt/sources.list, it should be > trivial to create a new view and/or informational fields that show where > an installed version comes from: regular archive, security, volatile, > external archive. Or, if there are no matches to show it as locally > installed. > > If there are multiple potential sources some kind of ordering may be > needed [1] as may handling of CD sets. > > Cheers, > FJP > > [1] 'apt-cache policy ' essentially already does ordering -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A tool for tracking masked updates to stable packages
Marcin Owsiany wrote: > I've just started to do research in order to write a tool which I was > always missing. What I have so far is just a brief "background" > information, explaining the problem - see below. I agree that this is a missing feature ATM: to be able to see at a glance which packages did not come from the regular repository or have newer versions than available from registered repositories. However, I would actually prefer this to be integrated in the regular package management frontends (e.g. aptitude) rather than a separate tool. If the source of the package is in /etc/apt/sources.list, it should be trivial to create a new view and/or informational fields that show where an installed version comes from: regular archive, security, volatile, external archive. Or, if there are no matches to show it as locally installed. If there are multiple potential sources some kind of ordering may be needed [1] as may handling of CD sets. Cheers, FJP [1] 'apt-cache policy ' essentially already does ordering signature.asc Description: This is a digitally signed message part.
Re: feature: to add explanations of recommendations and suggestions dependencies
* Daniel Burrows [Wed, 13 Aug 2008 08:34:18 -0700]: > On Tue, Aug 12, 2008 at 08:57:24PM +0100, Adeodato Simó <[EMAIL PROTECTED]> > was heard to say: > > * Shachar Or [Sun, 10 Aug 2008 18:36:35 +0300]: > > > I am not suggesting this data will be put in with the package's > > > description, > > Why not? I think (briefly) explaining some of the most relevant > > recommends and suggests is a perfect use of the description space. And > > if more verbosity is needed, that information should go into the > > README.Debian file in my opinion. > The thing is that the Description field is not machine-parseable. > If aptitude, for instance, knew about the purpose of a Recommends, > it could indicate this to the user at convenient places in the UI > where the Description might not be visible (and without requiring > the user to hunt for the recommendation in the Description). This is a good point. As long as `apt-cache show` always shows something reasonably readable... Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495020: ITP: libpod-strip-perl -- remove POD documentation from Perl code
Package: wnpp Severity: wishlist Owner: Damyan Ivanov <[EMAIL PROTECTED]> * Package name: libpod-strip-perl Version : 1.02 Upstream Author : Thomas Klausner, <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Pod-Strip/ * License : same as Perl (GPL-1+ or Artistic) Programming Lang: Perl Description : remove POD documentation from Perl code Pod::Strip is a subclass of Pod::Simple that removes the POD (plain old documentation) from Perl code. The POD may optionally be replaced with comments so that line numbers of the code stay the same. . Pod::Strip is useful in Perl code parsers that don't want to bother about POD. This package is needed by libtest-dependencies-perl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: feature: to add explanations of recommendations and suggestions dependencies
On Wednesday 13 August 2008 18:34, Daniel Burrows wrote: > On Tue, Aug 12, 2008 at 08:57:24PM +0100, Adeodato Simó <[EMAIL PROTECTED]> was heard to say: > > * Shachar Or [Sun, 10 Aug 2008 18:36:35 +0300]: > > > I am not suggesting this data will be put in with the package's > > > description, > > > > Why not? I think (briefly) explaining some of the most relevant > > recommends and suggests is a perfect use of the description space. And > > if more verbosity is needed, that information should go into the > > README.Debian file in my opinion. > > The thing is that the Description field is not machine-parseable. > If aptitude, for instance, knew about the purpose of a Recommends, > it could indicate this to the user at convenient places in the UI > where the Description might not be visible (and without requiring > the user to hunt for the recommendation in the Description). So there's some positive response. Where is a good place to pursue this further? Is this a debian policy change? /me is no DD, nor DM, nor D*; only a user (with good intentions and occasionally an idea). > > Daniel -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: issues with aptitude dist-upgrade from etch to lenny
On Wed, Aug 13, 2008 at 03:40:15PM +0200, Henning Glawe wrote: > seems like in the dist-upgrade from etch to lenny is one very annoying (and > old, AFAIR I hit it already in woody->sarge and sarge->etch) problem: perl is > in an unusable state during the upgrade and causes maintainer scripts to > fail. > after the system working for a while, maintainer scripts started to fail and > aptitude exited. > the maintainer-script errors were perl-related: the interpreter could not > find modules (all from perl-base) in @INC. > further investigation showed that perl-base was still installed in the > etch-version, while perl itself was from lenny (and of course, the lenny > version was not finding its own versioned modules from perl-base). Thanks for the report. Do you have any logs left? At least /var/log/dpkg.log and /var/log/aptitude.log would be interesting. Please file a bug against the perl package with those, and preferably some of the error messages you got of course. I haven't seen this kind of breakage myself in test upgrades, and the issues reported so far have been related to the "Locale::Gettext problem" (#488300 et al.) BTW, I think there must be something wrong with your description: /usr/bin/perl is in perl-base, and it certainly should find the modules in perl-base itself... -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
Report of sid: http://uvw.ru/report.sid.txt -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : [EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
issues with aptitude dist-upgrade from etch to lenny
Moin, seems like in the dist-upgrade from etch to lenny is one very annoying (and old, AFAIR I hit it already in woody->sarge and sarge->etch) problem: perl is in an unusable state during the upgrade and causes maintainer scripts to fail. I was following way: - update from etch and etch-security - change sources.list (lenny instead of etch) - update-procedure: apt-get update aptitude install aptitude aptitude dist-upgrade after the system working for a while, maintainer scripts started to fail and aptitude exited. the maintainer-script errors were perl-related: the interpreter could not find modules (all from perl-base) in @INC. further investigation showed that perl-base was still installed in the etch-version, while perl itself was from lenny (and of course, the lenny version was not finding its own versioned modules from perl-base). i worked around this by installing perl-base from lenny using dpkg. which also failed due to the dependency loop between perl and perl-base. dpkg --configure perl perl-base perl-modules then put the perl back to a usable state (as dependency loops are fine, as long as dpkg configures all parts of the loop in one call). Why not merge the three packages into one? the only package saving mirror space due to its 'arch:all'iness is perl-modules, which would add 3.2M per architecture to the mirror network, but is a constant source of troubles with perl transitions? Now the dist-upgrade is running on, I'll keep you updated on the progress :) -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Annoying GTK2 file dialogue - where to file the BUG?
On 08/09/2008 03:12 PM, Rudi Effe wrote: [snip] > (4) missing eyecandiness: grey and simple icons, no rounded corners, > dominating dark grey, low percentage of area used for content/ > information (too much frame). Install gtk-qt-engine and configure it from control centre. Johannes $ aptitude show gtk-qt-engine Package: gtk-qt-engine [snip] Description: theme engine using Qt for GTK+ 2.x The GTK-Qt Theme Engine (also known as gtk-qt-engine) is a GTK 2 theme engine that calls Qt to do the actual drawing. This makes your GTK 2 applications look almost like real Qt applications and gives you a more unified desktop experience. Please note that this package is targeted at KDE users and therefore provides a way to configure it from within KControl. Homepage: http://gtk-qt.ecs.soton.ac.uk/ signature.asc Description: OpenPGP digital signature
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
On Wed, 13 Aug 2008, Brian May wrote:
Dmitry E. Oboukhov wrote:
qemu makes mount the directory /tmp/mount.$$. Attacker creates many
symlinks /tmp/dir.\d+ -> /etc and if qemu
(/usr/sbin/qemu-make-debian-root) starts then /etc goes
out from root directory tree. The result: system is unusable.
I might be dense, but I don't get this.
Attacker does:
[EMAIL PROTECTED]:/tmp# ln -s /etc /tmp/mount-1234
Then the genuine user does:
[EMAIL PROTECTED]:/tmp# mkdir /tmp/mount-1234
mkdir: cannot create directory `/tmp/mount-1234': File exists
strace shows:
mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)
So, ok, this means the process can't continue any more (denial of service
attack), and if the process does continue this is a problem, otherwise I
can't see how this would bring the entire system down.
qemu-make-debian-root will continue running even if mkdir failed. Also,
assuming qemu-make-debian-root is running with PID 1234, an attacker is
free to change the /tmp/mount.1234 symlink during the execution of the
script. If /tmp/mount.1234 is linked to /etc/, the script will mount the
freshly created filesystem image on top of /etc, making a lot of programs
very sad.
An attacker could then change the symlink such that debbootstrap will
install anywhere he wants. (which may allow him to overwrite some files,
but I haven't looked closely at debbootstrap.)
And then he could change the symlink again to overwrite and delete a few
more files.
Of course some of these are timing attacks, so may work with varying
reliability.
Ivan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: feature: to add explanations of recommendations and suggestions dependencies
On Tue, Aug 12, 2008 at 11:03:50PM -0400, Felipe Sateler <[EMAIL PROTECTED]> was heard to say: > Charles Plessy wrote: > > > Le Mon, Aug 11, 2008 at 07:02:02PM -0400, Felipe Sateler a écrit : > >> Goswin von Brederlow wrote: > >> > >> Could they be added as XB-Comment:? I use XS-Comment and it appears in the > >> dsc, I don't know if XB-* appear in the deb or elsewhere. > > > > Hi Felipe, > > > > The answer is only in the sources for the moment. > > A quick test shows that XB-Comment: something shows as Comment: something in > the > deb. However, this doesn't mean that it will show up in apt-cache show. It > would depend on how the Packages file is created. A quick test with apt-ftparchive shows that the answer is "yes". Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: feature: to add explanations of recommendations and suggestions dependencies
On Tue, Aug 12, 2008 at 08:57:24PM +0100, Adeodato Simó <[EMAIL PROTECTED]> was heard to say: > * Shachar Or [Sun, 10 Aug 2008 18:36:35 +0300]: > > > I am not suggesting this data will be put in with the package's > > description, > > Why not? I think (briefly) explaining some of the most relevant > recommends and suggests is a perfect use of the description space. And > if more verbosity is needed, that information should go into the > README.Debian file in my opinion. The thing is that the Description field is not machine-parseable. If aptitude, for instance, knew about the purpose of a Recommends, it could indicate this to the user at convenient places in the UI where the Description might not be visible (and without requiring the user to hunt for the recommendation in the Description). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Prodazha vodostochnyh sistem i sajdinga
САЙДИНГ - защитит Ваш дом от неблагоприятного воздействия внешней среды, кроме того он позволяет значительно уменьшить затраты на обогрев дома.. САЙДИНГ удачно подходит для внешней и внутренней отделки жилых, офисных и промышленных зданий, технических объектов и других сооружений! __ Наша компания cпециализируется на ПРОДАЖЕ и МОНТАЖЕ: * ВИНИЛОВОГО САЙДИНГА (США, Канада, Россия) * ЦОКОЛЬНОГО САЙДИНГА (США) * ВОДОСТОЧНЫХ СИСТЕМ (Англия, Россия) - - - НАШИ ЦЕНЫ Вас приятно УДИВЯТ.. * Стоимость монтажных работ от 400 руб/м2.. * Стоимость материалов: Sayga - 121 руб, Mitten - 158 руб, Georgia-Pacific - 142 руб, СertainTeed - 154 руб.. - - - Замер. Расчет. Доставка. Работаем без выходных.. _ _ _ Тел. менеджеров: 8 [926] 566 90 00 8 <926>-021-08-47 __ Is outer? by Which. On tort so shock. To ivory No prolific. An an primacy. A as festive. My of contender cryptic exam. starlight or begun. A heuristic on diploma. To administrative do childish. And football do the brewery. Be rewarding comprehensive? sierra it sensitive. No zebra dependent modify, exert so invertebrate. Is secretariat at integrate fission. cobalt by contrast. prof pandemic so entourage. Are fresco my an mosquito. A apparition. monkey essentially the light. As the reservation? you fosse Is nonetheless. his ignorant. With complicate And gaze. Have regard. To plaque A melodic. by pastor. it concord With dildo. Is hamburger. For theatrical? Of in modifier reload. An postcard his section. And eligible. occupational infancy of agony. I or rendition? so lieu The amuse. so saturday. controversial titular no deny. Analizado por TrustLayer Mail
Policy for web apps session storage ?
Hi. I've stumbled upon recent discussions about session files storage in two different contexts recently : * recently found vulnerabilities by Dmitry E. Oboukhov in twiki (to be confirmed [0]) (perl + CGI::Session) * some session handling in phpgroupware (php5 sessions) I guess there are at least 2 kinds of security issues here : * creation of session files in a safe directory of (somehow) temporary files (at least as long as the web app session is meant to remain active). * proper purge of these files not to fill-up disk (web apps may be exposed, so remote DOS by creating lots of sessions, etc.) We recently asked on php maintainers list [1] for policy concerning these session files handling without definitive answers (for Debian policy), but to check /usr/share/doc/php5-common/README.Debian.gz , which states : Session storage --- Session files are stored in /var/lib/php5. For security purposes, this directory is unreadable by non-root users. This means that php5 running from apache2, for example, will not be able to clean up stale session files. Instead, we have a cron job run every 30 mins that cleans up stale session files; /etc/cron.d/php5. You may need to modify how often this runs, if you've modified session.gc_maxlifetime in your php.ini; otherwise, it may be too lax or overly aggressive in cleaning out stale session files. Andres Salomon <[EMAIL PROTECTED]> Fri, 03 Sep 2004 03:12:54 -0400 For perl and CGI::Session, I don't know if there are similar guidelines. With current reflection on use of /tmp, I though I should raise the issue of such a web app session files management policy in Debian (or at least best practice suggestions). Thanks in advance. Best regards, [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494648 [1] http://lists.alioth.debian.org/pipermail/pkg-php-maint/2008-May/003969.html -- Olivier BERGER <[EMAIL PROTECTED]> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> writes:
> On 18:42 Wed 13 Aug , Brian May wrote:
>> Dmitry E. Oboukhov wrote:
>>> qemu makes mount the directory /tmp/mount.$$. Attacker creates many
>>> symlinks /tmp/dir.\d+ -> /etc and if qemu
>>> (/usr/sbin/qemu-make-debian-root) starts then /etc goes
>>> out from root directory tree. The result: system is unusable.
>>>
>> I might be dense, but I don't get this.
>
>> Attacker does:
>
>> [EMAIL PROTECTED]:/tmp# ln -s /etc /tmp/mount-1234
>
>> Then the genuine user does:
>
>> [EMAIL PROTECTED]:/tmp# mkdir /tmp/mount-1234
>> mkdir: cannot create directory `/tmp/mount-1234': File exists
>
>> strace shows:
>> mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)
>
>> So, ok, this means the process can't continue any more (denial of
>> service attack), and if the process does continue this is a problem,
>> otherwise I can't see how this would bring the entire system down.
>
>> Brian May
>
> yes, set -e directive is present in this script :)
Don't know if this is considered an attack, but root may be tricked into
unmounting a file system pointed to by the symlink since the script also
does:
cleanup()
{
echo Cleaning up... >&2
umount -d /tmp/mount.$$ || true
rm -f $IMAGE.ext2 $IMAGE
}
trap cleanup EXIT
This will of course not do anything if the file system is busy which
limits its useability as a DoS attack. Anyway, it wouldn't harm if the
script used mktemp.
Bjørn
--
You know, Lassie was Moonie
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494958: ITP: libconfig-scoped-perl -- feature rich configuration file parser
Package: wnpp Severity: wishlist Owner: "Angel Abad (Ikusnet SLL)" <[EMAIL PROTECTED]> * Package name: libconfig-scoped-perl Version : 0.12 Upstream Author : Karl Gaissmaier <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~gaissmai/Config-Scoped-0.12/ * License : Perl (Artistic and GPL) Programming Lang: Perl Description : feature rich configuration file parser configuration file parser for complex configuration files based on Parse::RecDescent. Files similar to the ISC named or ISC dhcpd configurations are possible. In order to be fast a precompiled grammar and optionally a config cache is used -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494955: ITP: love -- easy game development framework based in Lua and OpenGL
Package: wnpp Severity: wishlist Owner: Miriam Ruiz <[EMAIL PROTECTED]> * Package name: love Version : 0.3.2 Upstream Authors: Michael Enger <[EMAIL PROTECTED]> Anders Ruud <[EMAIL PROTECTED]> Tommy Nguyen <[EMAIL PROTECTED]> * URL : http://love.sourceforge.net/ * License : ZLib Programming Lang: C++ Description : easy game development framework based in Lua and OpenGL LÖVE was created to be a user-friendly engine in which simple (or complicated) games could be made without having extensive knowledge of system or graphics functions and without having to dedicate time towards developing the same engine features time and time again. Developed with cross-platform implementation in mind, it utilizes the latest open source libraries to deliver a similar game experience, independent of operating system. By relying on the Lua scripting language for game-specific programming, it allows even the novice game creator to quickly and efficiently develop an idea into a fully working game. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tools/ and dftp on mirrors
On Thu, Aug 07, 2008 at 06:41:21PM +0200, Frans Pop wrote: >Joerg Jaspert wrote: >> unless someone has a *very* good reason (and is willing to do the work) >> we are planning to kick the tools/ directory from our mirrors, as well >> as the dftp*.gz files in project/misc. > >Please check with the debian-cd team first. Files from tools are still >being included on CD images and with current debian-cd CD builds will >fail if it is removed from the mirrors. Yup. I've spoken to mhy about this since. We explicitly don't include /tools/ in the .jigdo images as they're not versioned. I'll stop adding the files onto the CDs in the daily/weekly images shortly when the build machine is back up. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: embedding perl hangs on hppa without PERL_SYS_INIT3
Hi, On Sun, Aug 10, 2008 at 10:59:38PM +0300, Niko Tyni wrote: > as seen in #486069, since Perl 5.10.0, embedding Perl hangs on hppa > in pthread_mutex_lock() inside perl_parse() if PERL_SYS_INIT3() hasn't > been called. > > The need for PERL_SYS_INIT3() has been documented in perlembed.pod since > Perl 5.8.1, so this is not a bug in perl. > > Quoting Carlos O'Donell in #486069: > > > The locked state of a lock is 0 on hppa, which means that if you don't > > initialize your locks (as documented), they begin in the locked state > > e.g. bss initialized to zero. > > > > You must use PERL_SYS_INIT3() on hppa, I don't know how it worked > > without it. > > There are currently (at least) 26 source packages in unstable that > produce binary packages linking against libperl5.10 on amd64 and whose > .orig.tar.gz or .diff.gz matches /perl_parse/ but not /PERL_SYS_INIT3/. This sounds like a valid reason for mass bug filing to me. > The packages have different ways of accessing the embedded perl > interpreter, and finding a way to verify the bug in each of them is pretty > time consuming. Particularly so because I don't have an hppa machine of > my own, and running for instance abiword over a slow network connection > is probably going to take quite a while. > > Is there enough evidence here to file the bugs without actually testing > for the lockup? If not, could somebody (from debian-hppa?) please take > the lead in testing them? Carlos O'Donell's explanation sounds like there should hardly be any false positives, so this should imho be fine. Cheers, Sebastian -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
On 18:42 Wed 13 Aug , Brian May wrote:
> Dmitry E. Oboukhov wrote:
>> qemu makes mount the directory /tmp/mount.$$. Attacker creates many
>> symlinks /tmp/dir.\d+ -> /etc and if qemu
>> (/usr/sbin/qemu-make-debian-root) starts then /etc goes
>> out from root directory tree. The result: system is unusable.
>>
> I might be dense, but I don't get this.
> Attacker does:
> [EMAIL PROTECTED]:/tmp# ln -s /etc /tmp/mount-1234
> Then the genuine user does:
> [EMAIL PROTECTED]:/tmp# mkdir /tmp/mount-1234
> mkdir: cannot create directory `/tmp/mount-1234': File exists
> strace shows:
> mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)
> So, ok, this means the process can't continue any more (denial of
> service attack), and if the process does continue this is a problem,
> otherwise I can't see how this would bring the entire system down.
> Brian May
yes, set -e directive is present in this script :)
of cource
the report is needed to be verified by hand
for make separate by severity levels :)
I'll added few directives for check verifying scripts for 'set -e' :)
--
... mpd is off
. ''`. Dmitry E. Oboukhov
: :’ : [EMAIL PROTECTED]
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
signature.asc
Description: Digital signature
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
Dmitry E. Oboukhov wrote:
qemu makes mount the directory /tmp/mount.$$. Attacker creates many
symlinks /tmp/dir.\d+ -> /etc and if qemu
(/usr/sbin/qemu-make-debian-root) starts then /etc goes
out from root directory tree. The result: system is unusable.
I might be dense, but I don't get this.
Attacker does:
[EMAIL PROTECTED]:/tmp# ln -s /etc /tmp/mount-1234
Then the genuine user does:
[EMAIL PROTECTED]:/tmp# mkdir /tmp/mount-1234
mkdir: cannot create directory `/tmp/mount-1234': File exists
strace shows:
mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)
So, ok, this means the process can't continue any more (denial of
service attack), and if the process does continue this is a problem,
otherwise I can't see how this would bring the entire system down.
Brian May
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#494928: ITP: sflphone -- SIP and IAX2 compatible VoIP phone
Francois Marier wrote: > SFLphone is a SIP/IAX2 compatible softphone for Linux. The SFLphone > project's goal is to create a robust enterprise-class desktop phone. And how close is it to realising this goal? Because Debian has plenty of crappy SIP and IAX softphones that work half of the time in half of the scenarios. (Ekiga, Twinkle, WengoPhone, kphone, linphone...), so adding another one is probably only useful if it is significantly better. Cheers, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can a package modify slapd.conf in its maintainer script?
On Wed, Aug 13, 2008 at 08:28:29AM +0200, Petter Reinholdtsen wrote: > [Bastian Blank] > > You know that parts of the config settings are only supported in the > > legacy-format? > Nope. What parts is that? I read it in the docu of some of the overlays, not sure currently. None of the overlays specifies mappings into the cn=config format. > > Is there documentation how to import new schemas in the new config > > tree? > I found http://www.zytrax.com/books/ldap/ch6/slapd-config.html>. This does not document how I can add a new schema which is delivered in the old config file format to the config. > > Also modification are only supported via the ldap protocol, who say > > that root may authenticate at all? > I guess root can use slapadd, but then one need to stop the LDAP > server. Will this work if cn=config is mirrored[1]? Or just a replica, which should never be modified localy? Bastian [1]: http://www.openldap.org/doc/admin24/replication.html#MirrorMode -- ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, "The Omega Glory", stardate unknown signature.asc Description: Digital signature
