Hello Stefan,
I was revieweing your patch, and I was concerned about passing data.dptr
directly to crypt(). Are you sure it's safe? I cannot find any reference
in the db documentation as to whether or not the datum returned by
dbm_fetch is guaranteed to be NUL-terminated, but I believe it isn'
Package: libpam-modules
Version: 1.1.3-7.1
Severity: normal
Tags: security, patch
After hashing the user's password with crypt(), pam_userdb compares the
result to the stored hash case-insensitively with strncasecmp(). Hashes
are case-sensitive and must be compared in this way. Comparing a hash
Hi Stefan,
Thanks for r3esponding so quickly.
On 2013-12-04 11:56, Stefan Bühler wrote:
If the characters are not from this limited set, especially if the
first character is '$', then the Glibc crypt() expects '$' + id +
'$' + real-salt + '$'.
Glibc shouldn't require NUL-termination as long as
On 2015-08-19 16:13, Chris Lamb wrote:
So, I could reliably reproduce the failure yesterday in the following
case:
- System has fr_CH.UTF-8 generated
- LANG is not exported
- "fr_CH" exported as LC_MESSAGES (NB. no UTF-8 suffix)
However:
a) This prints a bunch of "perl: warning: Settin
On 2015-08-19 15:49, Niko Tyni wrote:
This package fails its test suite on the reproducible.debian.net
CI setup in the "second build", where the build environment is varied
as far as possible from the first one. The list of variations is at
https://reproducible.debian.net/reproducible.html
an
5 matches
Mail list logo
