-key
This stricter checking is added in openssh 7.7. As a result of this stricter
check, I am
no longer allowed to login with this key. Imho this is too restrictive and
underscores
should be allowed.
The bug is fixed upstream here:
https://bugzilla.mindrot.org/show_bug.cgi?id=2851
Best Regards
Package: libstdc++6
Version: 5.1.1-9
Severity: grave
Justification: causes non-serious data loss
The postinst script of libstdc++6 attempts to remove all __pycache__ dirs
from /usr/share/gcc-4.9/python, but doesn't do this in a secure way.
If you accidentally had created files in /usr/share/gcc-4
Package: libimage-magick-perl
Version: 8:6.8.9.9-5
Severity: normal
The PerlMagick/quantum/Makefile.PL was using the wrong
magick/magick-baseconfig.h file. I've attached a patch to fix this problem.
Regards,
Bas van Sisseren
--
Bas van Sisseren
Quarantainenet
Description: Fix include
tting the new 'delayed_hash_gc' flag.
ps. Afaics, it is now also safe to remove all qtime_csenter()/qtime_csexit()
calls
in hash.c, but I'll leave that to the author of vde2 to verify that.
Regards,
Bas van Sisseren
-- System Information:
Debian Release: jessie/sid
APT
Package: less
Version: 436-1
Severity: minor
When searching for lines starting with some characters, less also sometimes
hilight parts which match the regexp, except for that they do not start at
the start of the line.
Searching itself is not effected. Searching for the previous or next matching
atement in the front, just all files are printed, user cyrus or not..
If another security update will be released for oldstable, I would really
like this fix. Without the fix, the upgrade took me more than 1.5 hours
downtime. With the fix, this will probably be only 5 minutes.
Regards,
Bas
Package: metacity-common
Version: 1:2.30.1-2
Severity: normal
Tags: patch
metacity aborts on an assertion when using more than 16 workspaces.
(workspace_names[i] != NULL)
See also:
https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/583847
According to this link, metacity allows max. 36 wo
Package: coreutils
Version: 7.1-1
Severity: normal
Since coreutils 7.1, the coreutils package contains a binary 'timeout'.
This conflicts with the package 'timeout', which contains an almost
identical utility 'timeout'.
A 'Conflicts: timeout' would be nice.
-- System Information:
Debian Release
Package: perl
Version: 5.10.0-13
Severity: normal
When system-calls are processed, all signals are enqueued until the next perl
instruction is executed. When the fork() system-call is processed, and the
parent receives a signal just before the fork() call, both the parent and the
child will proces
Package: bind9-host
Version: 1:9.5.0.dfsg-3
Followup-For: Bug #321132
'host -w aavso.org' works ok, but 'host -w aavso.org 10.20.30.40' still
fails:
$ host -w aavso.org 10.20.30.40
timer.c:721: INSIST(result == 0 || result == 2) failed.
Aborted
10.20.30.40 is a dummy ip address. I've tried sever
Package: librpc-xml-perl
Version: 0.59-1
Severity: normal
The RPC::XML package returns an error when encoding or decoding empty
strings of type base64.
Example code:
use strict;
use RPC::XML;
my $b64 = RPC::XML::base64->new('');
if ($RPC::XML::ERROR) {
print "xmlrpc error: ".$RPC::XML::ERR
Package: ntpdate
Version: 1:4.2.2.p4+dfsg-2
Severity: important
When after a reboot all interfaces are brought up, the
/etc/network/if-up.d/ntpdate script spawns a 'ntpdate &' for every
interface. With many interfaces and an incorrectly set hardware-clock,
this can result in a mayor time-shift:
Package: libfrontier-rpc-perl
Version: 0.07b4-3
Severity: normal
Tags: patch
When using Frontier::Client to call an XMLRPC method and the method
returned a fault, the fault is not readable when using 'use_objects':
Fault returned from XML RPC Server, fault code
Frontier::RPC2::Integer=SCAL
Package: xmlrpc-c
Version: 1.06.18-1
Followup-For: Bug #309954
The xmlrpc-c packages were probably built on a system without the
libcurl4-openssl-dev package. I think adding this package to the
source-dependencies should be enough.
(i've locally rebuilt the xmlrpc-c packages with the libcurl4-ope
'', and my test failed.
I've retested the library with:
my $encrypted = $crypt->encrypt("some data");
$encrypted = 'RandomIV'.$crypt->iv.$encrypted;
This worked without any problems, so scrap bugreport item 4 :)
--
Bas van Sisseren <[EMAIL PR
Package: libcrypt-cbc-perl
Version: 2.12-1sarge1
Severity: grave
Justification: renders package unusable
I've detected 4 problems with the security update of libcrypt-cbc-perl;
1. I'm using Crypt::CBC between several systems; the one system encrypts
data and the other decrypts data. In this secur
.
On Sat, 14 Jan 2006, Eric Dorland wrote:
Are you still seeing this with the 0.10 series?
* Bas van Sisseren ([EMAIL PROTECTED]) wrote:
On 10/08/05 23:39, Eric Dorland wrote:
* Bas van Sisseren ([EMAIL PROTECTED]) wrote:
Package: opensc
Version: 0.9.6-2
Severity: important
I'm using a
On 10/08/05 23:39, Eric Dorland wrote:
> * Bas van Sisseren ([EMAIL PROTECTED]) wrote:
>
>>Package: opensc
>>Version: 0.9.6-2
>>Severity: important
>>
>>
>>I'm using a recompiled ssh-agent with opensc support on debian unstable.
>>(using it for
Package: opensc
Version: 0.9.6-2
Severity: important
I'm using a recompiled ssh-agent with opensc support on debian unstable.
(using it for my cryptoflex e-gate 32k token)
With libopensc1 version 0.9.6-1 everything works perfectly:
(ssh-agent -d output:)
debug1: type 20
debug1: sc_get_keys call
19 matches
Mail list logo
