On Tue, 2019 Aug 6 15:20-04:00, Salvatore Bonaccorso wrote:
>
> No I was refering to the bugs filled in the BTS, they were #926895,
> #931321 and #931320. We then cross reference those to/from the
> security-tracker as well. I added your bug as well later on.
I think what may have happened was t
On Sun, 2019 Aug 4 03:20-04:00, Salvatore Bonaccorso wrote:
>
> Sure it might have been overlooked, but pinging the existing bug would
> have been less overhead to now as well start tracking this one as well
> adjusting metadata etc. But no worries.
Just so that I understand, there was an existin
Hi Salvatore,
On Sat, 2019 Aug 3 09:32-04:00, Salvatore Bonaccorso wrote:
>
> As you can see from the security-tracker btw, for all three there are
> bugs filled already. So why a new bug for all three together? :)
The earliest CVE is nearly four months old, and patches already exist. I
filed th
Package: libxslt1.1
Version: 1.1.32-2
Severity: grave
The upstream version of LibXSLT shipped in Debian stable (1.1.32) has
the following three CVEs reported against it:
https://nvd.nist.gov/vuln/detail/CVE-2019-11068
https://nvd.nist.gov/vuln/detail/CVE-2019-13117
https://nvd.nist.go
On Sat, 2014 Sep 27 15:40+0200, Thijs Kinkhorst wrote:
>
> So am I right to conclude that this bug actually concerns the change
> that changes PermitRootLogin to without-password?
I believe that's the real issue, yes.
> I think changing this default makes sense from a security perspective
> as it
Well, sSMTP is my dumb forwarder of choice, and as the original
reporter appears to have moved on, and sSMTP has been dropped from
testing due to this bug, and no one else seems to care, it looks like
I'll have to step in.
Attached is a patch against the original 2.64 source that should address
th
failures;
logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.2 user=root
Anyway, the change comes from Debian bug #298138, which lay dormant for
over nine years before being wrapped up this past March.
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad ca
A new set of squeeze debian-installer images has appeared in the
repositories (dated July 6 for i386, July 10 for amd64), and with these,
the entire installation process functions flawlessly.
Bug #587570, I believe, can be closed. (I can't speak for bug #588183.)
--
To UNSUBSCRIBE, email to de
> Probably would be useful to open a bug against the debian-installer to
> get them to update their images? The relevant versions of e2fsprogs
> are now (finally!) migrated into testing...
Bug #587570.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsu
Package: debian-installer
Version: 20100211
Severity: grave
The installers are currently broken due to bug 583551, which prevents
mkfs.ext3 et al. from working. New images are needed, per tytso in
this message:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583551#117
Please ensure that th
Baruch, your debug-fu is impressive. I usually resort to Valgrind in cases
like these, and couldn't make heads nor tails of the logs; they were all
over the place.
Mark's 1.2 code is working beautifully for me, and so should the updated
.deb package. (I don't suppose that could be expedited int
Package: gbdfed
Version: 1.1-2
Severity: grave
I am running a Debian/etch system on amd64.
The program will map a window, and can even load a BDF font. As soon as I
attempt to edit a character, however, or read the online help---crash! I am
seeing not only segfaults, but also glibc complaints o
On Mon, 2006 Jul 31 13:47:21 -0300, Henrique de Moraes Holschuh wrote:
> >
> > Define "(un)suitable for UPS management." Does this definition include
> > most people's desktop systems?
>
> Suitable for UPS management:
> Load:
> Powers up when AC returns
> Can be
On Fri, 2006 Jul 28 16:12:35 -0300, Henrique de Moraes Holschuh wrote:
>
> There is no tradeoff without the hack, and the hack is only needed in
> hardware unsuitable for UPS management. Thus, it must be optional. It is
> dangerous to data and the hardware, so it should not be the default.
Defi
On Fri, 2006 Jul 28 14:46:47 -0300, Henrique de Moraes Holschuh wrote:
>
> 1. The UPS may take more than 15 minutes to shutdown the load. You cannot
> assume things like this, and you will cause data loss if you get it wrong:
> the power-off could come with the system fully online.
The time peri
15 matches
Mail list logo
