This bug is fixed upstream for glibc 2.19:
commit b957ced8890a4438c8efe2c15e5abf4e327f25cf
Author: Andreas Schwab
Date: Tue Oct 15 10:21:13 2013 +0200
Don't use gethostbyaddr to determine canonical name
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Here's a recently filed upstream bug report with a test program, some
analysis of what goes wrong, and a candidate fix from me:
http://sourceware.org/bugzilla/show_bug.cgi?id=15218
Note that the bug only happens with ai_family=AF_INET (or in some cases
with ai_flags containing AI_ADDRCONFIG, I as
Upstream issue entry: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8554
Upstream fix:
https://github.com/krb5/krb5/commit/bc7594058011c2f9711f24af4fa15a421a8d5b62
This bug will also be fixed in the krb5 1.15.1 and krb5 1.14.5 patch
releases.
This ought to work, but there might be something going wrong with
routing socket updates.
Because krb5kdc implements a UDP service, it needs to either use
IPv4/IPv6 pktinfo support, or bind to specific interfaces instead of the
wildcard address, in order to send replies from the same address as it
I do not understand the kernel behavior reflected in this trace
output. For fd 3 (principal.ok), we see:
fcntl64(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=6950411022381350912}) = -1 EINVAL (Invalid argument)
fcntl64(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_s
This appears to be gnu libc bug 20251, which does not appear to have
been fixed yet:
https://sourceware.org/bugzilla/show_bug.cgi?id=20251
We will explore workarounds. I have opened a ticket in our database to
track the issue:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8474
>From what I can tell, _LARGEFILE_SOURCE only seems to provide prototypes
for fseeko() and ftello(). I assume Sam means building such that off_t
is 64 bits, which I think requires defining _FILE_OFFSET_BITS=64.
off_t doesn't appear in any public krb5 header file, so there shouldn't
be any direct
Here is the upstream master branch commit to work around this libc bug:
https://github.com/krb5/krb5/commit/65110210b75d38908cdd84cb202cf013ccf6ed0e
It will make its way onto the 1.14 branch and into a future 1.14 patch
release.
On 9/12/23 03:01, Paolo Greppi wrote:
This may well be a doxygen bug, can anybody tell if there is any pattern?
I believe this is a deliberate behavior change in Doxygen 1.9.7, made to
address a problem affecting a different doxygen-to-RST converter:
https://github.com/doxygen/doxygen/pull
Of possible interest: I filed this as "serious" because it prevents
Ubuntu and Debian bash packages from coexisting in the same apt
repository.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: sbuild
Version: 0.57.4-1
Severity: important
Tags: patch
If you supply the --make-binNMU option to sbuild, you get an error:
Can't modify non-lvalue subroutine call at /usr/share/perl5/Sbuild/Options.pm
line 132.
This is because of a buggy conversion of the relevant code to a new
style
Package: hesiod
Version: 3.0.2-16
Hi. I've released a new version of the Hesiod library at
ftp://athena-dist.mit.edu/pub/ATHENA/hesiod, containing minor fixes
and enhancements. Please consider upgrading the Debian package when
you have time. The new version contains a couple of new functions,
i
I found some minor problems, but also a major one: in the kpropd
standalone support, you appear to open potentially multiple listener
sockets in the loop over the getaddrinfo() results, but only accept on
the last one.
Greg Hudson
MIT Kerberos Consortium
--
To UNSUBSCRIBE, email to debian
6ONLY socket
option in order to get v4-mapped connections to a v6 socket.
Greg Hudson
MIT Kerberos Consortium
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
This should be fixed in upstream by r24977.
I also asked Ken why the code was trying AF_INET first, and he didn't
really remember, but theorized that maybe it was to avoid making
unwanted lookups. It seems like an odd place to worry about that
given that locate_kdc is responsible for a lot m
I think gss_krb5int_set_allowable_enctypes() should filter out invalid
enctypes, and only fail if no enctypes remain after filtering. The
current logic would also fail if the kernel supported an enctype which
libkrb5 did not (e.g. if the kernel gained support for the aes-sha2
enctypes, and someone
Candidate patch here:
https://github.com/krb5/krb5/pull/954
On Mon, 7 May 2018 18:28:01 -0500 Benjamin Kaduk wrote:
> At high risk of opening up the RNG debate that I did not want to
> revisit, the current stance of upstream krb5 seems to fall into what
> I'll call the "Schneier worldview", that a fully-seeded
> well-designed CSPRNG can produce arbitrary a
On Fri, 04 Jan 2019 15:54:01 -0500 Sam Hartman wrote:
> There are no thread support changes between 1.16.1 and 1.16.2.
> There is one ccache related change which I'll include below related to
> memory ccaches.
> Do you know what type of credential cache is being used here?
krb5_mcc_start_seq_get
On Fri, 4 Jan 2019 19:24:52 -0500 Greg Hudson wrote:
> krb5_mcc_start_seq_get() is in the traceback, so the memory cache change
> is a clear candidate for the bug. I can't find anything wrong with the
> code, though. From the stack trace, there appears to be a memory ccache
>
Package: libsasl2-modules
Version: 2.1.28+dfsg-10
The Debian patch 0029-Load-OpenSSL3-legacy-provider-digestmd5.patch
introduces a memory leak into plugins/digestmd5.c:init_rc4(). It adds a
call to:
cipher = EVP_CIPHER_fetch(ossl3_ctx->libctx, "RC4", "");
but does not free the result wi
21 matches
Mail list logo
