Thanks for the confirmation!
What name should I use for you in acknowledgments?
** Changed in: krb5 (Ubuntu)
Status: New => Confirmed
** Tags added: patch-accepted-upstream
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Also there's a proposed patch in https://github.com/krb5/krb5/pull/550
if you would be interested in testing that out.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1629370
Title:
PKINIT fails with
That is one possible workaround, but I don't have an easy way to test
this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1629370
Title:
PKINIT fails with PKCS#11 middlware that implements PKCS#1
Thanks. It seems that omitting the NULL would produce signatures that
don't interoperate (or would require additional code complexity in the
signature verifier). With default compilation options,
pkinit_crypto_openssl.c forces PKCS11 tokens to use CKM_RSA_PKCS, so
it's unlikely that this code
RFC 3447 seems somewhat ambiguous about whether the AlgorithmIdentifier
parameters (which consist of an ASN.1 NULL, DER-encoded as 05 00) must
be present in various situations. Cross-checking with various CMS RFCs
suggests that they are required when using EMSA-PKCS1-v1_5.
cms_signeddata_create()
** Description changed:
[Impact]
The nss_hesiod nsswitch module, which worked in previous releases, does
not work at all in Ubuntu 16.04. Enabling it causes NULL pointer
- dereferences in calls such as getpwuid().
+ dereferences in calls such as getpwuid(). This will prevent any user
+
Confirmed that 1.12+dfsg-2ubuntu5 from trusty-proposed fixes the bug on
amd64.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
Confirmed that 1.12+dfsg-2ubuntu5 from trusty-proposed fixes the bug on
amd64.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This problem is broader than slave KDCs; it can potentially affect any
write operation on a KDC with sufficiently many (more than a few
hundred) principals, causing database corruption or denial of service.
Altering the test case to create one principal per invocation of
kadmin.local shows that
** Summary changed:
- krb5 database propagation enters infinite loop
+ krb5 database operations enter infinite loop
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1347147
Title:
krb5
** Description changed:
- In some conditions, propagating a kerberos database to a slave KDC server or
performing other database operations can stall. As we've investigated the
issue, it looks like a database with more than a few hundred principals is very
likely to run into this issue.
+
Edited description to include text from Sam that was omitted when we
crossed edits.
** Description changed:
[Impact]
On krb5 KDC databases with more than a few hundred principals,
operations can enter an infinite loop in the database library. This
affects both read and write
This problem is broader than slave KDCs; it can potentially affect any
write operation on a KDC with sufficiently many (more than a few
hundred) principals, causing database corruption or denial of service.
Altering the test case to create one principal per invocation of
kadmin.local shows that
** Summary changed:
- krb5 database propagation enters infinite loop
+ krb5 database operations enter infinite loop
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1347147
Title:
krb5 database
** Description changed:
- In some conditions, propagating a kerberos database to a slave KDC server or
performing other database operations can stall. As we've investigated the
issue, it looks like a database with more than a few hundred principals is very
likely to run into this issue.
+
Edited description to include text from Sam that was omitted when we
crossed edits.
** Description changed:
[Impact]
On krb5 KDC databases with more than a few hundred principals,
operations can enter an infinite loop in the database library. This
affects both read and write
I confirm that the packages at
https://launchpad.net/~hartmans/+archive/ubuntu/ubuntu-fixes appear to
fix the problem for Trusty amd64, based on the test case in comment #1.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in
I confirm that the packages at
https://launchpad.net/~hartmans/+archive/ubuntu/ubuntu-fixes appear to
fix the problem for Trusty amd64, based on the test case in comment #1.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Test case:
On Ubuntu 14.04 on amd64, install krb5-admin-server and krb5-kdc.
kdb5_util -W -r T create -s
awk 'BEGIN{ for (i = 0; i 1024; i++) { printf(ank -randkey a%06d\n, i) } }'
/dev/null | kadmin.local -r T
For me, kadmin.local begins consuming nearly 100% CPU starting at
a000762. This
Test case:
On Ubuntu 14.04 on amd64, install krb5-admin-server and krb5-kdc.
kdb5_util -W -r T create -s
awk 'BEGIN{ for (i = 0; i 1024; i++) { printf(ank -randkey a%06d\n, i) } }'
/dev/null | kadmin.local -r T
For me, kadmin.local begins consuming nearly 100% CPU starting at
a000762. This
This is probably the same as bug 571572.
Technically the upstream patch is a workaround for a glibc bug. This is
probably deserving of an SRU for Precise.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
This is probably the same as bug 571572.
Technically the upstream patch is a workaround for a glibc bug. This is
probably deserving of an SRU for Precise.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Additional experimentation indicates that Raring has a partial fix to
glibc that results in the observed libkrb5 behavior of rdns=false
working as intended. SRUs are still a good idea for earlier Ubuntu
releases. See also bug 1057526 for the underlying glibc bug.
--
You received this bug
Additional experimentation indicates that Raring has a partial fix to
glibc that results in the observed libkrb5 behavior of rdns=false
working as intended. SRUs are still a good idea for earlier Ubuntu
releases. See also bug 1057526 for the underlying glibc bug.
--
You received this bug
I can see no obvious source code changes to the krb5 packages between
Quantal and Raring that would result in the observed behavior of
rdns=false functioning on stock Raring libkrb5-3 but not on Quantal.
It's possible that the underlying bug in glibc got fixed in the
meanwhile. I haven't
I can see no obvious source code changes to the krb5 packages between
Quantal and Raring that would result in the observed behavior of
rdns=false functioning on stock Raring libkrb5-3 but not on Quantal.
It's possible that the underlying bug in glibc got fixed in the
meanwhile. I haven't
I would strongly recommend SRUs for all supported releases, because this
is a high-impact bug for people who are deploying krb5 in environments
where they do not have tight control over their reverse DNS information.
Experience has shown that this type of hard-to-debug DNS interaction
leads to a
I would strongly recommend SRUs for all supported releases, because this
is a high-impact bug for people who are deploying krb5 in environments
where they do not have tight control over their reverse DNS information.
Experience has shown that this type of hard-to-debug DNS interaction
leads to a
There is some additional information and history in launchpad bug
571572, which this bug report might be considered a duplicate of.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1095757
There is some additional information and history in launchpad bug
571572, which this bug report might be considered a duplicate of.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1095757
Title:
krb5
Our fix in #6922 appears to itself have a bug; we believe that
http://krbdev.mit.edu/rt/Ticket/Display.html?id=7124 resolves it. If you
need a back port, http://krbdev.mit.edu/rt/Ticket/Display.html?id=7164
is for krb5-1.9.x, and
http://krbdev.mit.edu/rt/Ticket/Display.html?id=7184 is for
Our fix in #6922 appears to itself have a bug; we believe that
http://krbdev.mit.edu/rt/Ticket/Display.html?id=7124 resolves it. If you
need a back port, http://krbdev.mit.edu/rt/Ticket/Display.html?id=7164
is for krb5-1.9.x, and
http://krbdev.mit.edu/rt/Ticket/Display.html?id=7184 is for
As I mentioned in the upstream bug tracker
(http://krbdev.mit.edu/rt/Ticket/Display.html?id=7118), I suspect this
is an entropy shortage issue. (kadmind -W should force the use of weak
random data)
** Bug watch added: krbdev.mit.edu/rt/ #7118
As I mentioned in the upstream bug tracker
(http://krbdev.mit.edu/rt/Ticket/Display.html?id=7118), I suspect this
is an entropy shortage issue. (kadmind -W should force the use of weak
random data)
** Bug watch added: krbdev.mit.edu/rt/ #7118
Sam Hartman hartm...@debian.org writes:
Russ, I thought that they were listed in the admin info pages too.
however, while I see a bunch of examples, searching for the string hmac
in the sources to the admin guide, I don't actually find a complete list
of the encryption types anywhere.
Am I
Sam Hartman hartm...@debian.org writes:
Russ, I thought that they were listed in the admin info pages too.
however, while I see a bunch of examples, searching for the string hmac
in the sources to the admin guide, I don't actually find a complete list
of the encryption types anywhere.
Am I
Public bug reported:
On Lucid, shutdown -k with a time argument that is not now
broadcasts the first shutdown warning, then exits without doing anything
else. In particular, it does not enter the loop to issue subsequent
shutdown warnings. Running shutdown -k should do everything except the
Monestri mones...@gmail.com writes:
kprop is also broken:
13:24 safire strace kprop -r A.EXAMPLE.COM -P -f /tmp/db slave
13:24 safire connect(4, {sa_family=AF_INET, sin_port=htons(754),
sin_addr=inet_addr(172.24.3.72)}, 16) = 0
Clearly.. it's not even trying to connect on the port
Dave Walker davewal...@ubuntu.com writes:
One this is confirmed, the change (either with distro patches) or
upstream resolution that fixed this needs to be identified.
Upstream has no resolution for this problem as such; we implemented
IPv6 support for kpropd in krb5-1.9 based on the patch
Recent discussion on #krbdev suggests that this is actually (in part) a
glibc bug in getaddinfo(). With ai_flags=AI_CANONNAME and
ai_family=AF_INET, getaddrinfo() performs a PTR lookup anyway (contrary
to POSIX), effectively preventing a setting of rdns=false from being
effective. We have a
** Bug watch added: Debian Bug tracker #631557
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631557
** Also affects: krb5 (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631557
Importance: Unknown
Status: Unknown
--
You received this bug notification because you
This bug originates from a Debian patch to krb5-1.8 that adds IPv6
support to kpropd. The Debian version of krb5-1.9 doesn't have this
problem. It is probably not difficult to fix Debian's krb5-1.8 patch,
but this should probably be coordinated with the Debian maintainers.
--
You received this
** Bug watch added: Debian Bug tracker #631557
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631557
** Also affects: krb5 (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631557
Importance: Unknown
Status: Unknown
--
You received this bug notification because you
This bug originates from a Debian patch to krb5-1.8 that adds IPv6
support to kpropd. The Debian version of krb5-1.9 doesn't have this
problem. It is probably not difficult to fix Debian's krb5-1.8 patch,
but this should probably be coordinated with the Debian maintainers.
--
You received this
jean-yves chateaux jean-yves.chate...@sagemcom.com writes:
The errors are the results of MIT resolution to exclude DES/DES3 from
the supported enctypes (security reasons).
DES3 was not marked as weak. Neither was rc4-hmac (enctype 23).
The export-grade rc4-hmac-exp is enctype 24 and was marked
jean-yves chateaux jean-yves.chate...@sagemcom.com writes:
The errors are the results of MIT resolution to exclude DES/DES3 from
the supported enctypes (security reasons).
DES3 was not marked as weak. Neither was rc4-hmac (enctype 23).
The export-grade rc4-hmac-exp is enctype 24 and was marked
** Bug watch added: Debian Bug tracker #566223
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566223
** Also affects: krb5 (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566223
Importance: Unknown
Status: Unknown
--
kinit crash
** Bug watch added: Debian Bug tracker #566223
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566223
** Also affects: krb5 (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566223
Importance: Unknown
Status: Unknown
--
kinit crash
** Changed in: krb5 (Debian)
Importance: Unknown = Undecided
** Changed in: krb5 (Debian)
Status: Confirmed = New
** Changed in: krb5 (Debian)
Remote watch: Debian Bug tracker #566977 = None
** Changed in: krb5 (Debian)
Status: New = Fix Committed
--
Winbind failed to
** Changed in: krb5 (Debian)
Importance: Unknown = Undecided
** Changed in: krb5 (Debian)
Status: Confirmed = New
** Changed in: krb5 (Debian)
Remote watch: Debian Bug tracker #566977 = None
** Changed in: krb5 (Debian)
Status: New = Fix Committed
--
Winbind failed to
50 matches
Mail list logo
