Package: whois
Version: 5.3.0
The mkpasswd(1) binary is truncating passwords longer than 127-characters:
Unique password string for 126 characters:
$ printf 'a%.0s' {1..126} | mkpasswd -m SHA-512 -S '' -s
$6$$W.thEL8diDVRFeHWlFLX3uJQViSwuCRjGgQNzFHsGNmaRKC2op
re files that have been added to the archive in
> recent years in the correct stage. It also should produce trace files that
> contain more information that is useful for us.
>
> http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
I'll look at getting this setup,
It appears that this only affects the 64-bit packages. The 32-bit packages of
the same versions are not affected:
>>> import Tkinter
>>> tk = Tkinter.Tk()
>>> Tkinter._test()
(pops up a Tcl/Tk window with buttons to click)
--
. o . o . o . . o o . . . o .
. . o . o o
Package: python-tk
Version: 2.7.13-1
When trying to create a Tk Label object, Python Tkinter crashes. Here is the
a traceback of the error:
>>> import Tkinter
>>> tk = Tkinter.Tk()
>>> label = Tkinter.Label(tk, text="Testing")
Traceback (most recent call last):
File "", line
Package: python-pil
Version: 4.2.1-1
When using the text() function with the PIL ImageDraw module, if the text
contains a blankline (IE: "\n\n"), PIL crashes.
However, if horizontal whitespace exists in the blank line, the module will not
error out. But if the blank line is excactly "\n\n", witho
Package: bcrypt
Version: 1.1-8.1+b1
The bcrypt package is 15 years outdated, with no updates. The last update was
2002-09-13: https://sourceforge.net/projects/bcrypt/files/.
In addition, bug #700758 mentions that bcrypt does not use a secure form of
encryption, in that it uses the Blowfish algori
Package: dieharder
Version: 3.31.1-7
When testing the XOR generator with dieharder(1), the program segfaults:
% dieharder -g 207 -a
zsh: segmentation fault dieharder -g 207 -a
This generator is a listed generator, according to `-g -1':
% dieharder -g -1
#==
Package: kpcli
Version: 2.7-1
Severity: normal
kpcli uses rand() for its RNG, which is not cryptographically secure [0]. A
drop in replacement would be to use Math::Random::ISAAC [1] which provides a
rand() subroutine via the `libmath-random-isaac-perl' package, which should be
provided as a depen
Package: argon2
Version: 0~20160406-2
When argon2(1) is executed, it always produces an unsuccessful exit with exit
code 132, and the error message `Illegal instruction', regardless of options
passed. The expected password hash is never printed to STDOUT.
For example:
$ echo password | argon
Package: haveged
Version: 1.9.1-1
Severity: Important
haveged(8) is not honoring the DAEMON_ARGS variable in /etc/default/haveged
when the init system is systmed(8). This is due to the following configuration
file:
$ cat /etc/systemd/system/default.target.wants/haveged.service
[Unit]
Package: libvirt-bin
Version: 0.9.12-3
When viewing the contents of the /etc/libvirt/qemu/*.xml files, the UUID
strings should be conformant to RFC 4122, which states that the version
bit should be one of 1, 2, 3, 4, or 5 and the variant bit should be one of
8, 9, a, or b. However, I have the foll
Package: xtightvncviewer
Version 1.3.9-6.3
According to the vncviewer(1) manpage, "-user username" is a valid option
for logging in as another user than your current local login. However, when
trying to pass "-user username", an error is given, due to the non-zero
exit code. No useful information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Devon Stewart wrote:
>Hey! Are you still working on this? I was just about to try my hand at
>packaging
>it, but if you've got it covered that's fine too. My goal was to have
>Salt
>packaged by the time 1.0 ships, (having salt packaged also happens
Package: hashcash
Version: 1.21-1
According to the documentation, the hashcash binary supports the '-b
bits' switch and argument for calculating a hashcash token of the size
specified. The default size is 20 bits. The '-b' switch argument
supports an exact size, say '-b 40' for minting a 40 bit to
Package: base-passwd
Version: 3.5.22
System users with UID 1 through 99 should not have a default login shell
in /etc/passwd, as they are not interactive accounts. Even though the
password is disabled by default in /etc/shadow, it makes no sense to
have the login shell as /bin/sh.
The default log
On 05/15/2010 05:50 AM, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote:
>> This paragraph should be accompanied by something like:
>>
>> Instead of adding users to other users private groups (which has issues as
>> explained above) it is recommend to creat
On 05/15/2010 05:26 AM, Christoph Anton Mitterer wrote:
> On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
>> for regular users
> Would have to double check it,... but doesn't the current change also
> affect root?
This does, but root is also in his own UPG. If you add any user to the
root
On 05/13/2010 11:21 AM, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the base-files package:
>
> #581434: The default umask in Debian should be changed to '0002' to be fully
> compliant with user private groups
>
> It h
Package: login
Version: 1:4.1.4.2-1
First, a discussion about this bug on the debian-devel mailing list [1].
This affects unstable, testing and stable.
To summarize: Debian uses user private groups (UPG) by default. This
places each user on the system in their own default, private group, that
no
19 matches
Mail list logo
