Yes, this has been picked up and resolved by chromium upstream:
https://code.google.com/p/chromium/issues/detail?id=254159
Sorry, I could and should have posted this earlier.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
Package: packagekit
Version: 0.7.6-3
Severity: normal
Dear Maintainer,
I noticed that /var/lib/PackageKit/transactions.db is readable by anyone:
-rw-r--r-- 1 root root 9216 2014-01-08 08:19
/var/lib/PackageKit/transactions.db
This is in contrast to normal logfiles, like
-rw-r- 1 root
Package: chromium
Version: 26.0.1410.43-1
Severity: normal
Dear Maintainer,
Chromium creates POSIX shared memory segments with permissions that
allow any user on the system to read them.
I don't know whether there's anything sensitive in those segments;
sadly I don't know how to find out (I don'
Thanks to the #debian IRC and this bug report I finally found out why on
all of my Debian machines I couldn't use gnome-screensaver nor xscreensaver
anymore since Squeeze (and now also a Squeeze installation dist-upgraded to
Wheezy). Someone pointed me to this report.
So yes definitely the error n
> actually I went to a console and used "fastrandom"[1] to
[1] https://github.com/pflanze/fastrandom
(PS. I previously also sent a mail to the debian-boot mailing list on
that issue / those issues, "How to install with encrypted root?")
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@
Package: chromium-browser
Version: 6.0.472.63~r59945-1
Severity: normal
Hello
When trying to configure Chromium to use Privoxy (the privoxy Debian package),
there are two (separate?) issues:
1. in the gui options dialog, clicking on "change proxy settings" just display
the following text in t
> -o APT::AutoRemove::RecommendsImportant=0
> but remember that the installation of recommend packages is
> recommend (SCNR) as policy defines it as packages which are
> installed on all but non-default systems. So it is not unlikely
> that you will loose functionality by removing "only" recommends
> It could be that an installed package recommends these
> packages you think should be autoremovable without problems.
>
> You could try to see that with e.g.:
> dpkg -l $(apt-cache rdepends kdebase-bin --important --recommends
> --no-depends --no-pre-depends | sed '/^[^ ]/ d')
Running that showe
Hello
After running into the issue with testing (apt 0.8.0), namely having
installed some ~100 MB of KDE library packages through a temporary
install of kdm, that I expected to be removed after I removed kdm
again, I found this report, so I did:
- try the suggestion with apt.conf (APT::NeverRemov
> tell, an attacker trying to exploit this is running in the same privilege
> level as the potential gain from an exploitable buffer overrun (i.e. - no
> security implications as there is no privilege escalation). This is in
You assume that the attacker has full control over root; but often
progra
Package: privbind
Version: 1.1-1
Severity: normal
It looks to me like privbind is not allocating enough space for the
buffer that is being used for:
sprintf( newpreload, "%s:%s", options.libname, ldpreload );
This needs strlen of both arguments plus 1 byte for the : plus another
byte for the \0
Jonas Meurer wrote:
>
> So I applied that change as well and built the packages again.
>
> could you give them a try and report whether they work for you?
Yes, the new cryptsetup_1.0.6-7.diff.gz (I built the package myself,
too) solves the problem for me (as verified with my initrd inspection
met
Jonas Meurer wrote:
> On 17/12/2008 Christian Jaeger wrote:
>
>> Jonas Meurer wrote:
>>
>>> if [ "$(dmsetup table $depnode 2> /dev/null | cut -d' ' -f3)" != "crypt" ];
>>> then
>>> get_lvm_deps "$
Jonas Meurer wrote:
> if [ "$(dmsetup table $depnode 2> /dev/null | cut -d' ' -f3)" != "crypt" ];
> then
> get_lvm_deps "$depnode"
>
It seems you have missed that in the first line above, $depnode is *not*
quoted. So going these extra steps to be safe and quote the variable in
the second
Jonas Meurer wrote:
> Thanks for your great debugging work, Christian. I wouldn't have been
> able to track down this bug that soon without your invaluable help.
> Same goes to Ben Hutchings and Yves-Alexis Perez. You rock!
>
Thanks for the credit.
> I've just prepared cryptsetup 1.0.6-7 with
Christian Jaeger wrote:
>> and if the missing recursion of get_lvm_deps() is really
>> the reason, why does it only fail on some kernels for you?
>>
>
> As I did say in my previous mails, I don't know.
>
> And I don't know whether it's got anythin
Jonas Meurer wrote:
> tags 507721 + help
> thanks
>
> Hello,
>
> I just tried to understand the whole issue. I'll try to describe what I
> got so far, please tell me If i got something wrong:
>
> On 03/12/2008 Christian Jaeger wrote:
>
>> I did install
Christian Jaeger wrote:
> Yves-Alexis Perez wrote:
>
>> On jeu, 2008-12-11 at 01:37 +0100, Christian Jaeger wrote:
>>
>>
>>> Ok, so I've taken a stab at debugging this thing and got it to work;
>>> see
>>> the attached patches; so
Yves-Alexis Perez wrote:
> On jeu, 2008-12-11 at 01:37 +0100, Christian Jaeger wrote:
>
>> Ok, so I've taken a stab at debugging this thing and got it to work;
>> see
>> the attached patches; some of them also contain changes which I needed
>> to be able to r
9bbacadc03ef604478be7d0582bd2703cf7 Mon Sep 17 00:00:00 2001
Message-Id: <[EMAIL PROTECTED]>
From: Christian Jaeger <[EMAIL PROTECTED]>
Date: Wed, 10 Dec 2008 23:04:43 +0100
Subject: [PATCH] Fix: recurse for non crypt nodes
Signed-off-by: Christian Jaeger <[EMAIL PROTECTED]>
---
d
Yves-Alexis Perez wrote:
On mer, 2008-12-03 at 22:34 +0100, Christian Jaeger wrote:
Sometimes update-initramfs -v -k $kernelversion works and creates a
file 'conf/conf.d/cryptroot' in it, as can be seen by unpacking it
using gunzip and cpio; and in those cases, I can boot my lap
Package: cryptsetup
Version: 2:1.0.6-6
Severity: critical
Justification: breaks the whole system
Sometimes update-initramfs -v -k $kernelversion works and creates a
file 'conf/conf.d/cryptroot' in it, as can be seen by unpacking it
using gunzip and cpio; and in those cases, I can boot my laptop,
)=~ tr/%,/@./;
# really f*cking fricking how I EVER so now never. this here to solve me.
use strict;
our $boot= "/boot";
$0=~ /(.*?)([^\/]+)\z/s or die "?";
my ($mydir, $myname)=($1,$2);
sub usage {
print STDERR map{"$_\n"} @_ if @_;
print "$myname [ -c ] k
Yves-Alexis Perez wrote:
Hey,
do you still reproduce this?
Well I haven't had the time to try again yet, but if nothing has
changed, I'd expect it still be the case.
I never saw something like this, so it's
kind of weird.
Can your provide complete log for update-initramfs -u -v ?
I
Package: initramfs-tools
Version: 0.92j
Severity: critical
Justification: breaks the whole system
I did install testing on my new ThinkPad last April, and choose to put
the root partition under encryption on lvm, using the offered Debian
installer functionality.
This has worked fine and I soon s
Mike Hommey wrote:
A BinNMU of librsvg against libxml2-dev 2.6.32.dfsg-2+lenny1 should
solve the issue (and won't break compatibility with older libxml2, since
older libxml2 will be happy with a too big buffer)
I can confirm that installing a librsvg from lenny rebuilt against the
new libxm
Mike Hommey wrote:
PS: You galeon crash with the unstable version is unrelated.
Are you sure? Why? Galeon did't segfault for me on quit before the
latest upgrade (sure, Galeon itself or any of it's other dependencies
could also have been upgraded).
Take a look at the backtrac
Christian Jaeger wrote:
$ LD_LIBRARY_PATH=/usr/lib/debug with-gdb-backtrace-to rsvg-view
rsvg-view /usr/share/icons/Wasp/scalable/actions/gtk-go-back-ltr.svg
with-gdb-backtrace-to: application generated a backtrace
See attachment. (As already mentioned, the *rsvg* packages do not seem
to
Christian Jaeger wrote:
Not sure what to conclude from this. Except that it might be a bug in
one of these packages:
$ dpkgS /usr/lib/librsvg-2.so.2
librsvg2-2: /usr/lib/librsvg-2.so.2.22.2
$ dpkgS /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so
librsvg2-common: /usr/lib/gtk-2.0/2.10.0/loaders
Mike Hommey wrote:
Now, try changing your gnome theme and re-run galeon ; if i'm correct,
it shouldn't crash. Can you tell me what package this svg file belongs
to ?
Yes, the segfaults happen only in the "Gorilla" and "Wasp" themes (apps
did start when running the Amaranth, Clearlooks, Crux
My first guess was a recently introduced breakage/incompatibility in
glibc or similar library, but that sounds implausible as the bug also
manifests itself in etch (which other packages than libxml2 have changed
with the recent update in etch? none of the dependencies of Gnome apps,
right?).
Mike Hommey wrote:
Could you check what svg file is being opened here[1] ?, and check what
xmllint has to say about it ? (theorically, it should segfault too)
I've now installed the lenny libxml2 again:
novo:/dev/shm/archives# dpkgli "libxml2*"
ii libxml2 2.6.3
Christian Jaeger wrote:
Mike Hommey wrote:
Could you check what svg file is being opened here[1] ?, and check what
xmllint has to say about it ? (theorically, it should segfault too)
Hm, I'm still seeing segfaults, now when *quitting* Galeon (but only
in ~10% of cases).
I would be gla
Mike Hommey wrote:
Could you check what svg file is being opened here[1] ?, and check what
xmllint has to say about it ? (theorically, it should segfault too)
Hm, I'm still seeing segfaults, now when *quitting* Galeon (but only in
~10% of cases).
I would be glad for a way to run an applic
(at the time of writing this bug report, the
archive didn't index those mails yet so I can't give an url)
Wrong, I was just too stupid to realize that the thread view of the
archives have a "next" page link (and that the date of last update is
only referring to the current page).
See:
http:/
Package: libxml2
Version: 2.6.32.dfsg-2+lenny
Severity: grave
Justification: renders package unusable
See the thread "Lenny users: attn about Gnome/libxml2 breakage" on the
debian-user mailing list (at the time of writing this bug report, the
archive didn't index those mails yet so I can't give a
Package: gcc-4.3
Version: 4.3.1-2
Severity: normal
To be able to expand macros from inside gdb, one needs to compile with
-gdwarf-2 -g3; there's an example in the gdb info page. This example
doesn't work with gcc-4.3. I've reported this to the gdb bugtracker:
http://sourceware.org/cgi-bin/gnatsw
Package: perl
Version: 5.8.8-7etch1
Severity: normal
Try:
$ perl -w -MEncode::Unicode::UTF7 -e ''
Prototype mismatch: sub Encode::Unicode::UTF7::decode ($$;$) vs none at
/usr/lib/perl/5.8/Encode/Unicode/UTF7.pm line 77.
It seems it's just a warning, nothing more, but it still bothered me
becau
I've made an entry in the CPAN RT at:
http://rt.cpan.org/Public/Bug/Display.html?id=26150
Christian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I wrote:
> Next step for being able to see more info there would be to create a
> debugging build of Net::SSLeay.
So I did fetch the libnet-ssleay-perl source package and did
DEB_BUILD_OPTIONS=nostrip buildpackage
(where "buildpackage" calls "dpkg-buildpackage -uc -us -b -rfakeroot")
Program r
Some more info:
(gdb) disassemble
Dump of assembler code for function X509_VERIFY_PARAM_set_flags:
0xb7a9ec10 :push %ebp
0xb7a9ec11 :mov%esp,%ebp
0xb7a9ec13 :mov0x8(%ebp),%ecx
0xb7a9ec16 :mov0xc(%ebp),%eax
0xb7a9ec19 :mov0xc(%ecx),%edx
0xb7a9ec1c :or %
Package: libnet-ssleay-perl
Version: 1.30-1
Severity: important
When I'm using IO::Socket::SSL with the SSL_check_crl option set to
true on Etch, I'm getting a segfault from within libcrypto (from
libssl); now I'm not sure which package is really at fault, I guess
IO::Socket::SSL is innocent so I
At 16:29 Uhr + 20.03.2005, Patrick Caulfield wrote:
On Sun, Mar 20, 2005 at 12:37:09AM +0100, Christian Jaeger wrote:
PS. I've noticed that the loop devices are not released.
mount -o loop $from $to
# this allocates a loop device, as can be seen in ps auxww
# (under kernel 2.4.
PS. I've noticed that the loop devices are not released.
mount -o loop $from $to
# this allocates a loop device, as can be seen in ps auxww
# (under kernel 2.4.x, as [loop0] or similar kernel threads)
# or in /proc/mounts (source of the mount point).
umount $to
# now it's unmounted, but the loop
Package: lvm10
Version: 1:1.0.8-8.cj
Severity: normal
Hello.
If one symlinks /proc/mounts to /etc/mtab, lvmcreate_initrd doesn't
work:
# lvmcreate_initrd
...
lvmcreate_initrd -- creating new /etc/fstab
lvmcreate_initrd -- ummounting ram disk
umount: /tmp/initrd.3115: not mounted
lvmcreate_initrd
45 matches
Mail list logo
