Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

[Benjamin Kaduk]

On Sat, Feb 10, 2024 at 01:33:15PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> 
> there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that
> failed for arm64, armel and ppc64el:
> 
> https://buildd.debian.org/status/package.php?p=krb5
> 
> The error logs look very similar:
> *** Output of last command:
> Can't resolve hostname arm-conova-03

This is due more to the build environment than the test suite per se.  I am
pretty sure that there was a previous discussion of this but I could not
construct a search query to find it quickly (maybe Sam can do better than
me?).

In short, the test suite, as for the protocol itself, assumes that it can
resolve the server's hostname to an IP address; for the test suite the
server will be the local machine, and so this becomes an assumption that
what the "machine" (or container/etc.) thinks its hostname is will resolve
with the resolver on that machine.  In this case it looks like a bare name
(without domain) that is not localhost, and presumably a local resolver
with no search path set.

I do not remember whether the previous discussion reached a firm conclusion
about what can reasonably be expected from a build/test environment in this
regard.

-Ben

Bug#1060896: openafs-modules-dkms: module build fails for Linux 6.7: osi_file.c:178:42: error: 'struct inode' has no member named 'i_mtime'

[Benjamin Kaduk]

tags -1 + fixed-upstream patch
thanks

On Tue, Jan 16, 2024 at 10:30:40AM +0100, Andreas Beckmann wrote:
> Package: openafs-modules-dkms
> Version: 1.8.10-2
> Severity: important
> 
> Hi,
> 
> openafs-modules-dkms fails to build a module for Linux 6.7 that was just
> uploaded to experimental:

Thanks for the heads-up; upstream already has the needed patch queued up for
the next stable release.

-Ben

Bug#1059588: lintian: false positive missing-build-dependency-for-dh_-command for B-D-Indep

[Benjamin Kaduk]

Package: lintian
Version: 2.116.3
Severity: normal
X-Debbugs-Cc: ka...@mit.edu

I maintain openafs, which for some time has been reporting an error-level
diagnostic from lintian for missing-build-dependency-for-dh_-command ("dh_dkms
(does not satisfy dkms:any | dh-sequence-dkms:any) [debian/rules]").

Having done a little bit of looking, I currently think this is a false
positive, since the dh_dkms invocation is contained within the
override_dh_install-indep target, and dh-dkms is present in
Build-Depends-Indep.  (But maybe the reasoning cited in #901507 about 'clean'
usage applies?  I do not think it does, but could be missing something.)

I see the list of build_prerequisites_norestriction being built in
Debhelper.pm by a call to relation_norestriction(), and the documntation for
relation_norestriction() says that it ignores architecture restrictions and
build profile restrictions.  Given that Debhelper.pm treats both -arch and
-indep as possible "focus" values (i.e., equivalent levels of scope), it seems
to me that when compiling its list of build_prerequisites_norestriction, we
should ignore not only architecture restrictions but the -All vs -Indep
distinction.

I guess this would be a one-line patch (concatenate
relation_norestriction('Build-Depends-All') and
relation_norestriction('Build-Depends-Indep') but figure a bug report is a
better place to talk about what the correct behavior is than a pull request.

-Ben


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.8-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.41.50.20231227-1
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.22.2
ii  dpkg-dev1.22.2
ii  file1:5.45-2
ii  gettext 0.21-14
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.2
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.636-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1
ii  libsereal-encoder-perl  5.004+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.21-1
ii  libwww-mechanize-perl   2.17-1
ii  libwww-perl 6.72-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-6
ii  lzop1.04-2
ii  man-db  2.12.0-1
ii  patchutils  0.4.2-1
ii  perl 

Bug#1043131: Solution for kernel 6.5 with openafs 1.8.10-1 in debian

[Benjamin Kaduk]

Hi Gergely,

On Wed, Dec 20, 2023 at 04:26:55PM +0100, Gergely Riskó wrote:
> Hey all,
> 
> Yes, OpenAFS is always a pain to work with both on the server and the
> client side. :(
> 
> This time I think the client installation is harder than usual, we
> have to apply 5 patches.

Yes, there's a lot this time.
Thanks for putting together your stack -- I would have missed DirEntryFlex in
my first pass and thus panic'd my machine during testing.

-Ben

Bug#1019751: openafs-client: Instructions to setup a new cell is out of date on Debian 9 and possibly on newer versions

[Benjamin Kaduk]

On Wed, Sep 14, 2022 at 05:36:00PM +0100, Jose M Calhariz wrote:
> Hi
> 
> I am creating a new OpenAFS cell for testing purposes and found the
> the file README.server.gz with some instructions a bit out of date.
> This makes the new cell setup dificult to a inexperienced OpenAFS 
> sysadmin.
> 
> As I found a similar problem with OpenAFS in Debian 11.  I think this 
> bug is still relevant.

Yes, it is still relevant, thank you for reporting it.

> To setup the new cell I used this commands:
> 
> On krb server:
> 
> kadmin.local
> addprinc -randkey -e aes256-cts-hmac-sha1-96 afs
> ktadd -k /root/rxkad.keytab afs
> getprinc afs
> quit
> 
> On afs server:
> 
> mv rxkad.keytab /etc/openafs/server/rxkad.keytab
> touch /etc/openafs/server/KeyFile
> 
> 
> The touch KeyFile is to workaround a small bug in afs-newcell command,
> that still search for a old KeyFile with DES material.

I'm preparing an upload that attempts to update the documentation to use
afs/cell.name and the Kerberos interactions for rxkad-k5.
The documentation will include using `akeyconvert` (or `asetkey`) after
creating /etc/openafs/server/rxkad.keytab -- the postinst currently runs
akeyconvert but I had intended that to only be an aid for the rxkad-k5
transition rather than a permanent feature.

-Ben

Bug#1048470: openafs: Fails to build source after successful build

[Benjamin Kaduk]

On Sun, Aug 13, 2023 at 09:21:04PM +0200, Lucas Nussbaum wrote:
> Source: openafs
> Version: 1.8.10-1
> Severity: minor
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-sab-20230813 ftbfs-source-after-build
> User: debian...@lists.debian.org
> Usertags: qa-doublebuild
> 
> Hi,
> 
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).

I missed that part on first read and went straight to the build log, oops.
I do think I have seen this myself (but will retest locally to be sure);
my recollection is that there is just an empty .pc directory left over.
Is that something you've seen in other packages, with a known/best-practice
solution?

Thanks,

Ben

Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably, not the actual credential cache name

[Benjamin Kaduk]

Hmm, on my local machines (one running Debian, one running Ubuntu) I appear
to be seeing the expected default /tmp/krb5cc_%{uid} behavior.
I couldn't quite follow how your credentials were obtained; were they
perhaps obtained as part of the login process?  The PAM configuration might
well be relevant in that case.

-Ben

Bug#1010764: upstream fix

[Benjamin Kaduk]

tags 1010764 upstream fixed-upstream pending
thanks

On Wed, May 18, 2022 at 01:55:00AM +, Jeremy Stanley wrote:
> The fix for this appears to have merged upstream in January, so
> could probably be backported in Salsa:
> 
> https://gerrit.openafs.org/14882

Indeed, upstream has been getting the needed fixes for new linux versions
into git, but getting them actually into a release has been "probably next
week" for ... well, quite a few weeks.  I will go ahead and just take the
patches as debian patches for now, and my apologies for taking so long to
get to it.

-Ben

Bug#1009927: krb5: deprecated encryption type for master_key_type

[Benjamin Kaduk]

I'm pretty sure that changing the master key encryption type used for new
databases has basically no upgrade considerations and could be "just done".
Updating the encryption type for that key on existing databases will have
nontrivial upgrade considerations (and in fact will not be possible to do
automatically in a maintainer script in all cases).

It is even possible that we might drop that configuration stanza entirely
rather than just changing the encryption type, though we would want to more
thoroughly research the consequences of doing so before actually making
that change.

Thanks for the report, this is definitely something we should be taking
action on.

-Ben

On Wed, Apr 20, 2022 at 05:51:45PM -0300, Andreas Hasenack wrote:
> Package: krb5
> Version: 1.19.2-2
> Severity: normal
> 
> Dear Maintainer,
> 
> when creating a new realm using `krb5_newrealm`, the following warning
> is logged in /var/log/syslog:
> 
> Apr 20 20:43:16 kdc krb5kdc[3136]: Stash file /etc/krb5kdc/stash uses
> DEPRECATED enctype des3-cbc-sha1!
> 
> This comes from the kdc.conf template in
> /usr/share/krb5-kdc/kdc.conf.template which has "master_key_type =
> des3-hmac-sha1".
> 
> Maybe it's time to update that encryption type? The kdc.conf manpage
> says that the current default is "aes256-cts-hmac-sha1-96". The sample
> kdc.conf in the documentation at
> https://web.mit.edu/kerberos/krb5-latest/doc/admin/install_kdc.html#kdc-conf
> suggests just "master_key_type = aes256-cts".
> 
> I understand there may be important upgrade path considerations. Given
> all the care and precautions that are shown for migrating away from
> single DES in 
> https://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html,
> changing the default master key type for fresh installs might also
> require careful planning and thought, but at some point this process
> must start. And upstream is now flagging DES3 as deprecated already.
> 

Bug#1005404: Kernel modules fail to build with Linux 5.16 onward

[Benjamin Kaduk]

Hi Ben,

Thanks for detecting and reporting the build errors.
I'm a bit confused as to how this is "grave", though -- I would have
classified it as merely "serious" as for, e.g., 970258 and 995134.

For upstream, we went with a slightly different patch owing to the
unreliability of the linux version macros due to distros backporting many
patches --
https://github.com/openafs/openafs/commit/3daa6e97330d23ae46c4389e4041c61c1a1d76d9

I will take this as a trigger to package upstream 1.8.8.1 that includes the
fix.

-Ben

On Sat, Feb 12, 2022 at 10:53:31PM +0100, Ben Hutchings wrote:
> Source: openafs
> Version: 1.8.2-1+deb10u1
> Severity: grave
> Tags: patch upstream
> 
> The openafs modules fail to build, with the compiler reporting that
> "stdarg.h" is not found.
> 
> This is due to an intentional change in Linux 5.16 removing user-space
> headers from the kernel include path:
> .
> 
> Kernel code must use  instead of .
> 
> The attached patch fixes this and allows the build to complete.
> 
> Ben.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
> 'unstable'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

> From: Ben Hutchings 
> Date: Sat, 12 Feb 2022 22:25:47 +0100
> Subject: openafs: Fix  inclusion on Linux
> 
> There was an intentional change in Linux 5.16 removing user-space
> headers from the kernel include path:
> .
> 
> Kernel code must use  instead of .
> ---
> --- a/src/rx/rx_kcommon.h
> +++ b/src/rx/rx_kcommon.h
> @@ -145,6 +145,8 @@ typedef unsigned short etap_event_t;
>  /* if sys/systm.h includes varargs.h some versions of solaris have conflicts 
> */
>  # if defined(AFS_FBSD_ENV)
>  #  include "machine/stdarg.h"
> +# elif defined(AFS_LINUX26_ENV) && LINUX_VERSION_CODE >= 
> KERNEL_VERSION(5,16,0)
> +#  include 
>  # else
>  #  include "stdarg.h"
>  # endif

Bug#995134: dkms modules fail to build on 5.14.0, error: ‘TIF_IA32’ undeclared

[Benjamin Kaduk]

severity 995134 serious
tags 995134 upstream fixed-upstream pending
thanks

On Sun, Sep 26, 2021 at 05:07:44PM -0400, Ryan Kavanagh wrote:
> Package: openafs-modules-dkms
> Version: 1.8.6-5
> Severity: grave
> Justification: Renders package unusable
> 
> The openafs dkms modules fail to build on 5.14.0. I've attached
> /var/lib/dkms/openafs/1.8.6/build/make.log.

Thanks for the report.  Upstream OpenAFS 1.8.8 includes support for linux
kernels through 5.14, but since the upstream release came out during freeze
I didn't package it at the time.
Given the extra reminder, I'm happy to package it now.

Thanks,

Ben


signature.asc
Description: PGP signature

Bug#992607: CVE-2021-37750 in krb5: NULL dereference in authenticated FAST TGS request

[Benjamin Kaduk]

Package: krb5-kdc
Version: 1.15-1
Tags: security fixed-upstream

quoting from
https://github.com/krb5/krb5/commit/d775c95af7606a51bf79547a94fa52ddd1cb7f49

CVE-2021-37750:

In MIT krb5 releases 1.14 and later, an authenticated attacker can
cause a null dereference in the KDC by sending a FAST TGS request with
no server field.

Bug#991365: krb5: CVE-2021-36222

[Benjamin Kaduk]

Yes, I started working on an upload for buster, but got a bit sidetracked
since the 1.17-3+deb10u1 in the archive was not imported into the packaging
repo previously.

I expect to make progress today.

-Ben

Bug#991374: unblock: krb5/1.18.3-6

[Benjamin Kaduk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ka...@mit.edu

Please unblock package krb5

Upstream krb5 recently fixed a CVE in the KDC (server) process
whereby an unauthenticated request can trigger a NULL dereference.
The krb5 maintainer notes that systemd will restart the KDC if this
happens, but of course an attacker can send a flood of such crafted
packets and effectively DoS the process.

[ Reason ]
The NULL dereference is a service crash triggerable by a remote
unauthenticated attacker, and we should not have this DoS vulnerability in the
stable release.

[ Impact ]
An unpatched KDC is vulnerable to denial of service by an unauthenticated
remote attacker.

[ Tests ]
Upstream included a unit test to verify that a malformed packet does not crash
the KDC.  Upstream also has an extensive test suite that serves as a
regression test.

[ Risks ]
The risk here is pretty minimal; the issue stems from a function that was
written in an "if-ladder" style so that any operation that might write to
"retval" has to be wrapped in a conditional so that the operation is skipped
if an error had occurred previously.  The fix is to add such a "retval == 0"
check to a function call that takes a pointer to retval as a parameter and
writes to it, causing any previous errors in the function to be ignored.
(Upstream has since re-written the function to use a more robust coding style,
but that is not a minimal fix suitable for unblock.)

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock krb5/1.18.3-6
diff -Nru krb5-1.18.3/debian/changelog krb5-1.18.3/debian/changelog
--- krb5-1.18.3/debian/changelog2021-03-28 10:43:01.0 -0700
+++ krb5-1.18.3/debian/changelog2021-07-21 11:07:07.0 -0700
@@ -1,3 +1,10 @@
+krb5 (1.18.3-6) unstable; urgency=high
+
+  * Pull in upstream patch to fix CVE-2021-36222 (KDC NULL dereference),
+Closes: #991365
+
+ -- Benjamin Kaduk   Wed, 21 Jul 2021 11:07:07 -0700
+
 krb5 (1.18.3-5) unstable; urgency=medium
 
   * Update breaks on libk5crypto3 toward other internal libraries because
diff -Nru 
krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch
 
krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch
--- 
krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch
 1969-12-31 16:00:00.0 -0800
+++ 
krb5-1.18.3/debian/patches/0010-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch
 2021-07-21 11:06:53.0 -0700
@@ -0,0 +1,112 @@
+From: Joseph Sutton 
+Date: Wed, 7 Jul 2021 11:47:44 +1200
+Subject: Fix KDC null deref on bad encrypted challenge
+
+The function ec_verify() in src/kdc/kdc_preauth_ec.c contains a check
+to avoid further processing if the armor key is NULL.  However, this
+check is bypassed by a call to k5memdup0() which overwrites retval
+with 0 if the allocation succeeds.  If the armor key is NULL, a call
+to krb5_c_fx_cf2_simple() will then dereference it, resulting in a
+crash.  Add a check before the k5memdup0() call to avoid overwriting
+retval.
+
+CVE-2021-36222:
+
+In MIT krb5 releases 1.16 and later, an unauthenticated attacker can
+cause a null dereference in the KDC by sending a request containing a
+PA-ENCRYPTED-CHALLENGE padata element without using FAST.
+
+[ghud...@mit.edu: trimmed patch; added test case; edited commit
+message]
+
+(cherry picked from commit fc98f520caefff2e5ee9a0026fdf5109944b3562)
+
+ticket: 9007
+version_fixed: 1.18.4
+
+(cherry picked from commit c4a406095b3ea4a67ae5b8ea586cbe9abdbae76f)
+---
+ src/kdc/kdc_preauth_ec.c  |  3 ++-
+ src/tests/Makefile.in |  1 +
+ src/tests/t_cve-2021-36222.py | 46 +++
+ 3 files changed, 49 insertions(+), 1 deletion(-)
+ create mode 100644 src/tests/t_cve-2021-36222.py
+
+diff --git a/src/kdc/kdc_preauth_ec.c b/src/kdc/kdc_preauth_ec.c
+index 7e636b3..43a9902 100644
+--- a/src/kdc/kdc_preauth_ec.c
 b/src/kdc/kdc_preauth_ec.c
+@@ -87,7 +87,8 @@ ec_verify(krb5_context context, krb5_data *req_pkt, 
krb5_kdc_req *request,
+ }
+ 
+ /* Check for a configured FAST ec auth indicator. */
+-realmstr = k5memdup0(realm.data, realm.length, );
++if (retval == 0)
++realmstr = k5memdup0(realm.data, realm.length, );
+ if (realmstr != NULL)
+ retval = profile_get_string(context->profile, KRB5_CONF_REALMS,
+ realmstr,
+diff --git a/src/tests/Makefile.in b/src/tests/Makefile.in
+index 3f88f17..0ffbebf 100644
+--- a/src/tests/Makefile.in
 b/src/tests/Makefile.in
+@@ -158,6 +158,7 @@ check-pytests: unlockiter s4u2self
+   $(RUNPYTEST) $(srcdir)/t_cve-2012-1015.py $(PYTESTFLAGS)
+   $(RUNPYTEST) $(srcdir)/t_cve-2013-1416.py $(PYTESTFLAGS)
+   

Bug#991140: memory leak in krb5_gss_inquire_cred()

[Benjamin Kaduk]

It looks like the leak was independently(?) reported to upstream and fixed
in a somewhat different way, see
https://github.com/krb5/krb5/commit/593e16448e1af23eef74689afe06a7bcc86e79c7
.
The fix is marked for pullup to the stable branches, so it should get fixed
in Debian when we next import an upstream version.

-Ben

Bug#991365: krb5: CVE-2021-36222

[Benjamin Kaduk]

On Wed, Jul 21, 2021 at 07:13:49PM +0200, Salvatore Bonaccorso wrote:
> 
> On Wed, Jul 21, 2021 at 10:01:23AM -0600, Sam Hartman wrote:
> 
> About buster: Given the above we can fix via the upcoming point
> release for buster, I guess that can be enough in this case. What
> would happen if the unauthenticated user "hammers" with it the KDC
> which is then continously restarted, what would be the impact? Sorry
> for my ignorance.

I believe that given the relative network traffic flows, KDC startup time,
and systemd behavior, a dedicated attacker flooding the "bad" packets
towards a KDC would be able to effectively DoS the legitimate clients with
a relatively small outbound pipe.  It would not be a full DoS, since some
legitimiate requests would be handled, but the legitimate clients have a
well-behaved retry and backoff timer and it is easy for the attacker to win
the race.  Sites typically have multiple KDCs for redundancy, but they are
typically all discoverable by all clients, including the attacker.
Furthermore, if the KDC is crashing repeatedly on startup, my recollection
is that systemd will back off how quickly it is restarted and may
eventually disable the unit entirely.

The mitigating factor here is that an administrator would in theory be able
to detect the bad traffic and block it with a firewall, but that turns into
a cat and mouse game that a dedicated attacker will probably win.

Which, all together, might actually support serious after all rather than
important.

-Ben

Bug#991365: krb5: CVE-2021-36222

[Benjamin Kaduk]

On Wed, Jul 21, 2021 at 10:01:23AM -0600, Sam Hartman wrote:
> control: severity -1 important
> 
> Salvatore> The following vulnerability was published for krb5.
> 
> Salvatore> CVE-2021-36222[0]: | sending a request containing a
> Salvatore> PA-ENCRYPTED-CHALLENGE padata element | without using
> Salvatore> FAST could result in null dereference in the KDC which |
> Salvatore> leads to DoS
> 
> On a Debian system with systemd, the KDC will restart, significantly
> limiting the impact of this bug.
> I'm going to argue for important, although if you want to push to
> serious, I won't fight it.
> I'm busy with Family obligat scattered throughout the day ions, but it 
> sounded like Benjamin Kaduk
> might be available to help.

Yes, I have some time to help.
Given that Salvatore filed the report, I am assuming that this would
qualify for a security upload for stretch.  However, the upstream commit
claims that only krb5 1.16 and later are affected, so I will attempt to
check whether stretch is actually affected.

If I understand correctly given the current state of buster freeze, I will
need to upload the targeted fix to sid and request an unblock (as opposed
to being able to do a security upload).

-Ben

Bug#987690: marked as done (openafs-fileserver: Servers do not work with des3-cbc-sha1 keys)

[Benjamin Kaduk]

reopen 987690
thanks

This looks to be a typo in the changelog closer.

-Ben

On Mon, May 03, 2021 at 06:51:03PM +, Debian Bug Tracking System wrote:
> Your message dated Mon, 03 May 2021 18:48:29 +
> with message-id 
> and subject line Bug#987690: fixed in libass 1:0.15.0-2
> has caused the Debian Bug report #987690,
> regarding openafs-fileserver: Servers do not work with des3-cbc-sha1 keys
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 987690: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987690
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Tue, 27 Apr 2021 16:56:53 -0400
> From: Chaskiel Grundman 
> To: Debian Bug Tracking System 
> Subject: openafs-fileserver: Servers do not work with des3-cbc-sha1 keys
> 
> Package: openafs-fileserver
> Version: 1.8.2-1+deb10u1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> The servers in this release do not work when used with des3-cbc-sha1
> (enctype 16) keys. The requested size of the key is computed incorrectly
> as 21 bytes instead of 24, and authcon.c:_afsconf_GetRxkadKrb5Key rejects
> the key from the KeyFileExt. If the 3des key is the only one available,
> it is impossible to authenticate to the server, even with -localauth.
> 
> This has been fixed upstream (https://gerrit.openafs.org/#/c/14203/),
> but the patch is apparently not yet in any release
> 
> -- System Information:
> Debian Release: 10.9
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
> 'stable-debug'), (500, 'proposed-updates-debug')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages openafs-fileserver depends on:
> ii  debconf [debconf-2.0]  1.5.71
> ii  libc6  2.28-10
> ii  libhcrypto4-heimdal7.5.0+dfsg-3
> ii  libroken18-heimdal 7.5.0+dfsg-3
> ii  lsb-base   10.2019051400
> ii  openafs-client 1.8.2-1+deb10u1
> 
> Versions of packages openafs-fileserver recommends:
> ii  ntp  1:4.2.8p12+dfsg-4
> 
> Versions of packages openafs-fileserver suggests:
> pn  openafs-doc  
> 
> -- debconf information:
>   openafs-fileserver/thiscell: grand.central.org
>   openafs-fileserver/alpha-broken:

> Date: Mon, 3 May 2021 18:48:29 +
> From: Debian FTP Masters 
> To: 987690-cl...@bugs.debian.org
> Subject: Bug#987690: fixed in libass 1:0.15.0-2
> 
> Source: libass
> Source-Version: 1:0.15.0-2
> Done: Sebastian Ramacher 
> 
> We believe that the bug you reported is fixed in the latest version of
> libass, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 987...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Sebastian Ramacher  (supplier of updated libass package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Mon, 03 May 2021 20:25:05 +0200
> Source: libass
> Architecture: source
> Version: 1:0.15.0-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Multimedia Maintainers 
> Changed-By: Sebastian Ramacher 
> Closes: 987690
> Changes:
>  libass (1:0.15.0-2) unstable; urgency=medium
>  .
>* debian/patches: Apply upstream patches to improve handling of embedded
>  fonts (Closes: #987690)
>  - Fix crashes on some files with embedded fonts
>  - Fix use of embedded and memory fonts for libass users
> Checksums-Sha1:
>  141dbb7999fa42d68cfad0a729a6c4193a38070f 2098 libass_0.15.0-2.dsc
>  d8c86ae05761d933dcc818afa70ef4ed1c5d89d8 9664 libass_0.15.0-2.debian.tar.xz
> Checksums-Sha256:
>  8c2441f77c8dea309e10049f85cfac874c920aace3cfee7adae300a28886eb66 2098 
> libass_0.15.0-2.dsc
>  6f20d4776b5948bc5ff7edf5d996a8b5a04b7edb884d2cf1f848a677d0f403ed 9664 
> libass_0.15.0-2.debian.tar.xz
> Files:
>  09fe437893839f7139cd62be988c0fa1 2098 libs optional 

Bug#986702: openafs-fileserver: Upgrade from stretch broken (missing dependency)

[Benjamin Kaduk]

On Fri, Apr 09, 2021 at 03:29:48PM -0400, Chaskiel Grundman wrote:
> Package: openafs-fileserver
> Version: 1.8.2-1+deb10u1
> Severity: important
> 
> Dear Maintainer,
> While upgrading a system from stretch (9.9) to buster (10.9), I had a
> failure in this package:
> 
> Setting up openafs-fileserver (1.8.2-1+deb10u1) ...
> /var/lib/dpkg/info/openafs-fileserver.postinst: 24:
> /var/lib/dpkg/info/openafs-fileserver.postinst: akeyconvert: not found
> dpkg: error processing package openafs-fileserver (--configure):
>  installed openafs-fileserver package post-installation script
> subprocess returned error exit status 127
> dpkg: dependency problems prevent configuration of openafs-dbserver:
>  openafs-dbserver depends on openafs-fileserver; however:
>   Package openafs-fileserver is not configured yet.
> 
> dpkg: error processing package openafs-dbserver (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  openafs-fileserver
>  openafs-dbserver
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> It appears that this package needs to depend on openafs-krb5, or that
> the postinst needs to not attempt to convert the keys.

or only convert the keys if akeyconvert is available, yes.

Thanks, this is a good catch.

-Ben

Bug#985254: openafs-modules-dkms: Fails to build on -rt / non-HIGHMEM kernels

[Benjamin Kaduk]

On Mon, Mar 15, 2021 at 06:27:41AM +, Witold Baryluk wrote:
> Package: openafs-modules-dkms
> Version: 1.8.6-5
> Followup-For: Bug #985254
> X-Debbugs-Cc: witold.bary...@gmail.com
> 
> Actually after digging more, it is not due to HIGHMEM. In fact the
> kmap_atomic takes single argument since about kernel 3.13 on all
> configurations.
> 
> 
> The issue actually is somewhere else.
> 
> In config.log I found this:
> 
> The module compiles, however it doesn't link into .ko file:
> 
> FATAL: modpost: GPL-incompatible module conftest.ko uses GPL-only symbol 
> 'migrate_disable'
> 
> And that causes configure to think that the function is not one-argument.

Thanks for taking the time to make the report and follow-up with the
additional information.

However, IIRC it is "well known" (though I did not find good documentation
in a very quick search) that the -rt kernel has many interfaces that are
GPL-only that are not GPL-only in a standard kernel, and as such incurs
license complaints against the openafs kernel module.  I don't expect to be
able to do anything about this (other, perhaps, that documenting it
better), unfortunately.

-Ben

Bug#945506: Processed: dkms: export CC pointing to the kernels compiler

[Benjamin Kaduk]

Hi Andreas,

Thanks for filing 984929.
Do you have a sense for what the cutoff should be for trying to get 984929
resolved vs. just uploading a workaround in the dkms-consuming packages
(e.g., openafs)?

Thanks,

Ben

On Wed, Mar 10, 2021 at 01:09:06PM +, Debian Bug Tracking System wrote:
> Processing control commands:
> 
> > block 984862 with -1
> Bug #984862 [iptables-netflow-dkms] iptables-netflow-dkms: module wants to 
> build with gcc instead of kernel's compiler
> 984862 was not blocked by any bugs.
> 984862 was not blocking any bugs.
> Added blocking bug(s) of 984862: 984929
> > block 945506 with -1
> Bug #945506 [openafs-modules-dkms] openafs-modules-dkms: module wants to 
> build with gcc instead of kernel's compiler
> 945506 was not blocked by any bugs.
> 945506 was not blocking any bugs.
> Added blocking bug(s) of 945506: 984929
> > block 946497 with -1
> Bug #946497 [zfs-dkms] zfs-dkms: module wants to build with gcc instead of 
> kernel's compiler
> 946497 was not blocked by any bugs.
> 946497 was not blocking any bugs.
> Added blocking bug(s) of 946497: 984929
> 
> -- 
> 945506: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945506
> 946497: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946497
> 984862: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984862
> 984929: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984929
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 

Bug#982002: buster-pu: package openafs/1.8.2-1

[Benjamin Kaduk]

Hi Adam,

On Sat, Feb 06, 2021 at 02:40:02PM +, Adam D. Barratt wrote:
> On Fri, 2021-02-05 at 09:17 -0800, Benjamin Kaduk wrote:
> > On Fri, Feb 05, 2021 at 05:11:31PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Fri, 2021-02-05 at 08:38 -0800, Benjamin Kaduk wrote:
> > > > All upstream openafs releases from the 1.8.x series, prior to
> > > > 1.8.7,
> > > > contain a "time bomb" bug that activates when the unix epoch time
> > > > passes 0x6000 (Thu 14 Jan 2021 08:25:36 AM UTC).
> [...]
> > > Please feel free to upload, and we can look at processing the
> > > package
> > > after the point release is out of the way. I assume you'd
> > > appreciate a
> > > stable-updates release for the updated package, rather than waiting
> > > for
> > > the following point release?
> > 
> > Yes, that would be appreciated.
> 
> How does this sound as text for an announcement?
> 
> ===
> OpenAFS is an implementation of the Andrew File System, a distributed
> filesystem allowing cross-platform sharing of files among multiple
> computers.
> 
> An issue was discovered in the connection handling code which would
> lead to most connections between clients and servers failing, starting
> from January 14th, 2021 (when the UNIX timestamp reached 0x6000).
> This update resolves that issue.
> 
> If you use OpenAFS, we strongly recommend that you install this
> update.
> ===

That should work well.  Anything I might try to change in order to be more
precise would just add unnecessary detail, and this conveys the important
point.

Thanks again for your help with this,

Ben

Bug#982002: buster-pu: package openafs/1.8.2-1

[Benjamin Kaduk]

On Fri, Feb 05, 2021 at 05:11:31PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2021-02-05 at 08:38 -0800, Benjamin Kaduk wrote:
> > All upstream openafs releases from the 1.8.x series, prior to 1.8.7,
> > contain a "time bomb" bug that activates when the unix epoch time
> > passes 0x6000 (Thu 14 Jan 2021 08:25:36 AM UTC).
> 
> Given the statement "prior to 1.8.7", it would have been helpful to be
> explicit about the fact that the Debian package of 1.8.6-5 (in unstable
> and testing) contains the fixes.

Sorry.  upstream 1.8.7 is equivalent to debian 1.8.6-5 in this regard (I
prepared the debian version before the upstream release due to the delays
in the upstream CI machinery).

> [...]
> > Both AFS clients and AFS servers are affected.
> > Unpatched clients started after the cutover time are unable to
> > perform any filesystem access (the error "connection timed out" is
> > reported).
> > Unpatched file servers started after the cutover time are unable to
> > connect to protection servers and verify user group membership to
> > enforce ACLs, and are unable to connect to other file (volume)
> > servers to move volumes.
> > Unpatched database servers started after the cutover time are unable
> > to connect to each other, resulting in a breakdown of the ubik
> > distributed consensus protocol in deployments that use more than one
> > database server (three databaser servers is common).
> 
> The timing here is rather unfortunate. The next point release for
> buster is tomorrow, and it's far too late to get any additional changes
> in to that.
> 
> Please feel free to upload, and we can look at processing the package
> after the point release is out of the way. I assume you'd appreciate a
> stable-updates release for the updated package, rather than waiting for
> the following point release?

Yes, that would be appreciated.

> Having said that, there are presumably already a bunch of broken
> servers, given there was a kernel security update for buster recently
> and we're already a few weeks past the relevant timestamp. :-(

Salvatore did remind me of that, yes :(

I incurred some unfortunate delays in being able to actually test the
updated packages in a buster environment personally.

Thanks,

Ben

Bug#980115: connection failure when rx initialized after 08:25:36 GMT 14 Jan 2021

[Benjamin Kaduk]

On Wed, Feb 03, 2021 at 01:05:38PM -0800, Benjamin Kaduk wrote:
> > 
> > Do you still have this on your radar? While as discussed this is not a
> > DSA candidate a fix can be released out of order from a point release
> > via the stable-updates mechanism, and this would be defintively a
> > canddiate for it.
> 
> Yes, it's still on my radar but process has been slower than expected.
> In order to do testing in a real buster environment I had to re-create my
> VM infrastructure since I have gotten a new machine since I last did so.

The buster-pu request is #982002.

-Ben

Bug#982002: buster-pu: package openafs/1.8.2-1

[Benjamin Kaduk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ka...@mit.edu

[ Reason ]
All upstream openafs releases from the 1.8.x series, prior to 1.8.7,
contain a "time bomb" bug that activates when the unix epoch time
passes 0x6000 (Thu 14 Jan 2021 08:25:36 AM UTC).  The bug
(actually a combination of bugs) results in all outgoing Rx RPC
connections having a fixed connection ID value of 0x8002.
In addition to the problems caused by duplicate CIDs, this initial
value is also not even valid as the first CID for the first call on
a connection, so all RPC attempts time out and fail.
The combination of bugs includes insufficient initial randomness
(tv.sec ^ tv.usec) that overwrote an actual random initial value, code
to prevent signed integer overflow when incrementing the global "next CID"
value, and a separate change to convert the field in question to an
unsigned type.  (The changes were written and merged in a different order.)
After the cutover time, when an initial CID value is produced, it is
seen as being larger than the overflow threshold, and assigned to hold
what would be the smallest negative value.  That value, in turn, when
interpreted as an unsigned value, is also larger than the overflow threshold,
so successive updates produce the same value for the connection ID.

[ Impact ]
Both AFS clients and AFS servers are affected.
Unpatched clients started after the cutover time are unable to perform any
filesystem access (the error "connection timed out" is reported).
Unpatched file servers started after the cutover time are unable to connect to
protection servers and verify user group membership to enforce ACLs, and are
unable to connect to other file (volume) servers to move volumes.
Unpatched database servers started after the cutover time are unable to
connect to each other, resulting in a breakdown of the ubik distributed
consensus protocol in deployments that use more than one database server
(three databaser servers is common).

[ Tests ]
Rx RPCs are core to essentially all AFS operation, so running any activity
that goes over the network (including file system access, administrative
commands, and group modification commands) will exercise the code in question.
There are also automated tests that cover basic Rx behaviors, which failed
until the code was patched.
Significant manual testing has been done, with multiple sites running the
patched code in production, and I have performed targeted manual tests
with mixed environments (patched client, unpatched server, etc.) including
rolling back to the broken version to confirm that everything works with
the patched software and doesn't work with the unpatched software.

[ Risks ]
The changes are very targeted and easy to understand fixes.
Risks are, accordingly, limited, and the risks of not updating are
catastrophic (any process restart will introduce the broken condition).

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
There are two conceptual changes: removing the stale not-very-random initial
value to leave the actually random initial value, and removing the
signed-integer-overflow-detection code entirely, since unsigned integer
overflow will give the desired behavior.  The latter is split across two
patches, since an intermediate state was committed upstream during the crisis.

As additional context for the former change,
https://salsa.debian.org/debian/openafs/-/blob/debian/1.8.2-1/src/rx/rx.c#L591-604
highlights the current code's call to RAND_bytes() that is subsequently
overwritten by a "*slightly* random start time".


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru openafs-1.8.2/debian/changelog openafs-1.8.2/debian/changelog
--- openafs-1.8.2/debian/changelog  2018-09-11 22:53:43.0 -0700
+++ openafs-1.8.2/debian/changelog  2021-01-26 20:13:14.0 -0800
@@ -1,3 +1,10 @@
+openafs (1.8.2-1+deb10u1) buster; urgency=high
+
+  * Pull in upstream patches to fix outgoing connections after unix
+epoch time 0x6000 (Closes: #980115, #980116)
+
+ -- Benjamin Kaduk   Tue, 26 Jan 2021 20:13:14 -0800
+
 openafs (1.8.2-1) unstable; urgency=high
 
   * New upstream release 1.8.1.1:
diff -Nru 
openafs-1.8.2/debian/patches/0003-rx-rx_InitHost-do-not-overwrite-RAND_bytes-rx_nextCi.patch
 
openafs-1.8

Bug#980115: connection failure when rx initialized after 08:25:36 GMT 14 Jan 2021

[Benjamin Kaduk]

Hi Salvatore,

On Wed, Feb 03, 2021 at 09:39:25PM +0100, Salvatore Bonaccorso wrote:
> HI Benjamin,
> 
> On Mon, Jan 18, 2021 at 07:19:14PM -0800, Benjamin Kaduk wrote:
> > On Mon, Jan 18, 2021 at 06:04:39PM +, Jeremy Stanley wrote:
> > > Thanks for pulling this into unstable and testing! Is there any work
> > > in progress to fix it in stable as well? I took a quick peek in
> > > Salsa and didn't see any merge requests or an obvious branch for
> > > Buster's 1.8.2 (just the debian/1.8.2-1 tag).
> > 
> > It is a clear candidate to fix in stable, though the only concrete steps
> > I've been able to take so far are to confirm with the security team that it
> > is not a candidate for being fixed via a DSA.
> > 
> > The actual work of backporting the patches should be ~trivial, so the
> > process work of engaging with the release team will be the dominating
> > factor.
> 
> Do you still have this on your radar? While as discussed this is not a
> DSA candidate a fix can be released out of order from a point release
> via the stable-updates mechanism, and this would be defintively a
> canddiate for it.

Yes, it's still on my radar but process has been slower than expected.
In order to do testing in a real buster environment I had to re-create my
VM infrastructure since I have gotten a new machine since I last did so.

> The procedure would be the same as proposing the fix to be rleased in
> a point release, but mentioning to the SRM that the fix actually needs
> to go out sooner (should be clear from context here), and pushed via a
> SUA.
> 
> https://lists.debian.org/debian-devel-announce/2011/03/msg00010.html
> https://lists.debian.org/debian-stable-announce/
> https://wiki.debian.org/StableUpdates
> 
> I think this becomes now even more urgent as users will roll out the
> linux update released as DSA 4843-1 or latest at the 10.8 point
> release on weekend and make the issue more urgent.

I've put the needed packaging changes into the 'buster' branch at
https://salsa.debian.org/debian/openafs/ and know of a few sites that are
running packages using that code in production.  I've been able to do local
testing of the client-side functionality as well, and just need to test the
server functionality before I file the bug with the release team.

Thanks for checking in and the pointers for the process to follow!

-Ben

Bug#980115: connection failure when rx initialized after 08:25:36 GMT 14 Jan 2021

[Benjamin Kaduk]

On Mon, Jan 18, 2021 at 06:04:39PM +, Jeremy Stanley wrote:
> Thanks for pulling this into unstable and testing! Is there any work
> in progress to fix it in stable as well? I took a quick peek in
> Salsa and didn't see any merge requests or an obvious branch for
> Buster's 1.8.2 (just the debian/1.8.2-1 tag).

It is a clear candidate to fix in stable, though the only concrete steps
I've been able to take so far are to confirm with the security team that it
is not a candidate for being fixed via a DSA.

The actual work of backporting the patches should be ~trivial, so the
process work of engaging with the release team will be the dominating
factor.

-Ben

Bug#980115: connection failure when rx initialized after 08:25:36 GMT 14 Jan 2021

[Benjamin Kaduk]

Package: openafs-client
Version: 1.8.2-1
Severity: grave
Control: clone -1 -2
Control: reassign -2 openafs-fileserver

The Rx RPC stack requires a connection identifier for each new connection a
system initiates.  In 2014 support to generate the initial identifier
randomly was added to the core Rx implementation (instead of relying on the
security layer to do so), but code that attempted to use the current system
time as part of a not-very-random initialization was not removed at that
time.  When the unix epoch time is later than 0x6000, that stale
initialization interacts with a bug in code designed to avoid signed
integer overflow when incrementing the global conneciton ID counter,
resulting in the connection ID of 0x8002 being used for all
connections, leading to connection failure due to the collision.  This
renders all clients and servers started after 14 Jan 2021 08:25:36 UTC
unusable.

Bug#972969: openafs-modules-dkms: Does not build on bullseye with kernel 5.9.1

[Benjamin Kaduk]

Hi Robert,

On Mon, Oct 26, 2020 at 07:08:41PM +0100, Robert Senger wrote:
> Package: openafs-modules-dkms
> Version: 1.8.6-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> DKMS fails to build module on bullseye with kernel 5.9.1

It turns out that I prepared a 1.8.6-4 a couple days ago to fix this but
failed to actually upload it.  Thanks for the reminder to push it up; it
should be appearing in sid shortly.

-Ben

Bug#970258: Same on sid

[Benjamin Kaduk]

tags 970258 fixed-upstream
thanks

On Wed, Sep 16, 2020 at 09:27:30AM +0200, Malte Eggers wrote:
> I'm (unsurprisingly) experiencing the same problem on sid. This appears to be 
> the relevant section of the make.log

Indeed, this is not surprising -- the patches for kernel 5.8 compatibility
haven't made it into an upstream release yet, and will need to be
cherry-picked in.

Thanks,

Ben

Bug#969376: openafs-client: Openafs cache erros on the logs

[Benjamin Kaduk]

On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote:
> Package: openafs-client
> Version: 1.8.6-1~dsi10+1
> Severity: normal
> 
> I am using a private backport of openafs from testing.  On this server I
> am getting multiples strange errors about openafs cache.  This server
> is different in that it runs apache to serve personal web pages and every
> web page runs under a different openafs user.  So is normal for this
> server to be simultaneuous running code under 100 or 200 different openafs 
> users.
> 
> The an example of errors on the logs are:
> 
> afs: disk cache read error in CacheItems slot 350195 off 28015620/3520 
> code -4/80
> afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; 
> failing with an i/o error
> 
> I am not certain this types of errors are to be ignored and there have
> been reports of problems accessing openafs files.  I am using this bug
> report to collect more information about this cache errors and the
> possibility of being an indication of important errors with the openafs
> cache code.

This error message is supposed to indicate that a read from the cache
filesystem got EIO, which in turn is supposed to indicate a physical
problem with the drive.  That said, I'm not going to jump to conclusions
and try to blame your drive, as there are several other things that could
be coming into play.

While the log message itself is pretty old, there's been a lot of work
recently to more accurately report EIO in error conditions (mostly instead
of ENOENT, since returning ENOENT can cause that to get cached at the VFS
layer and produce strange user-visible behavior).

Having a lot of users present makes me suspect that the credentials used by
the kernel to read/write the cache file are not being saved/restored
properly, and indeed we recently merged to 1.8.x (not in a release yet)
https://gerrit.openafs.org/14082 and https://gerrit.openafs.org/14099 which
improve such credentials management.

My recommendation would be to try pulling in those two patches to your
build before proceeding to try to trace the source of the EIO.

Thanks for the report!

-Ben

Bug#968104: openafs-client: Upgrade of openfs-client break until reboot

[Benjamin Kaduk]

Hi Jose,

Sorry that I missed this when it first came in.
A couple notes inline, if you still remember much about the original
report...

On Sat, Aug 08, 2020 at 06:32:07PM +0100, Jose M Calhariz wrote:
> Package: openafs-client
> Version: 1.8.6-1~dsi10+1
> Severity: normal
> 
> Hi,
> 
> I have made a "private backport" of openafs software from bullseye to
> buster.  So this means is the first time for me that I am upgrading 
> openafs client 1.8.x on live systems.  Where in the past this worked 

To clarify: are you upgrading from 1.6.x to 1.8.x, or merely updating from
one 1.8.x version to a newer 1.8.x version?

> without problems for openafs 1.4 and 1.6, now the openafs client stops
> working and I need to do a reboot.
> 
> What I am requesting is that if possible to do a live upgrade of the
> software and the client does not stop working even if it is necessary 
> to work with the old software until a reboot.

What you are requesting is what is supposed to happen, so I'm unpleasantly
surprised to hear that it is not happening.

Once I hear back about the problematic scenario I can try to reproduce in a
local VM.

Thanks,

Ben

Bug#926321: openafs: FTBFS on arm64

[Benjamin Kaduk]

tags 926321 moreinfo
thanks

On Sat, Apr 06, 2019 at 10:10:57AM -0500, Benjamin Kaduk wrote:
> Hi Paul,
> 
> On Wed, Apr 03, 2019 at 01:06:08PM +0100, Paul Martin wrote:
> > Source: openafs
> > Version: 1.6.20-2+deb9u2
> > Severity: normal
> > Tags: patch, ftbfs, stretch
> > 
> > It would be nice if openafs were to be available on ARM64 architecture 
> > in Debian Stretch and Ubuntu Bionic.
> > 
> > The OpenStack Infrastructure project in particular would benefit from 
> > this package suite being available.
> 
> Thanks for the report (and patch).
> 
> I think I remember it being a conscious decision around the time of
> upstream's 1.8.0 to only bring arm64 support into Debian alongside 1.8.0
> (i.e., for buster), and I thought that's because upstream had needed more
> changes than just the sort you have in these patches.  But presumably your
> systems are working with just the posted patches, so I'll try to take a
> closer look at what actually happened with upstream and refresh my memory
> of the situation.
> 
> That said, I don't know how the SRMs feel about this sort of change.
> Did you consider using a backported 1.8.2-1 from buster?  (I don't have
> much time for working on the Ubuntu packaging;
> https://launchpad.net/~openafs/+archive/ubuntu/stable?field.series_filter=zesty
> may be an option for you there.)

Hi Paul,

Did you manage to resolve the situation here in some way?
I fear that the passage of time may have overtaken events, here...

Thanks,

Ben

Bug#966881: openafs: FTBFS: ld: vlib.a(volume.o):./src/vol/volume.c:128: multiple definition of `vol_io_params'; ihandle.o:./src/vol/ihandle.c:81: first defined here

[Benjamin Kaduk]

tags 966881 fixed-upstream
thanks

On Mon, Aug 03, 2020 at 10:04:57AM +0200, Lucas Nussbaum wrote:
> Source: openafs
> Version: 1.8.6-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200802 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > gcc  -Wl,-z,relro -L/usr/lib/x86_64-linux-gnu/heimdal 
> > -L/usr/lib/x86_64-linux-gnu/heimdal -g -O   -Damd64_linux26  
> > -DFSSYNC_BUILD_SERVER -DFSSYNC_BUILD_CLIENT -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -g -O   -I/<>/src/config 
> > -I/<>/include -I. -I.   -I/usr/include/heimdal   -o volscan 
> > volscan-main.o vol-info.o physio.o ihandle.o \
> > /<>/lib/libcmd.a vlib.a /<>/lib/util.a 
> > /<>/lib/libdir.a /<>/lib/librx.a 
> > /<>/lib/libafshcrypto_lwp.a /<>/lib/liblwp.a 
> > /<>/lib/libsys.a /<>/lib/libacl.a 
> > /<>/lib/libopr.a -lroken -lresolv  
> > /usr/bin/ld: vlib.a(volume.o):./src/vol/volume.c:128: multiple definition 
> > of `vol_io_params'; ihandle.o:./src/vol/ihandle.c:81: first defined here
> > /usr/bin/ld: vlib.a(daemon_com.o):./src/vol/daemon_com.c:49: multiple 
> > definition of `V_BreakVolumeCallbacks'; 
> > vlib.a(fssync-server.o):./src/vol/fssync-server.c:83: first defined here
> > gcc -fPIC   -g -O2 -fdebug-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -g -O   
> > -I/<>/src/config -I/<>/include -I. -I.   
> > -I/usr/include/heimdal   -o X11windows.o -c X11windows.c
> > collect2: error: ld returned 1 exit status

Looks like fallout from -fcommon being on by default, and is fixed in
upstream (to appear in 1.8.7).  We can pull in the relevant patches until
then, of course.

-Ben

Bug#964027: incompatible with kernel 5.7.0: ERROR: modpost: "__pagevec_lru_add" [...] undefined!

[Benjamin Kaduk]

tags 964027 pending fixed-upstream
thanks

On Tue, Jun 30, 2020 at 12:48:41PM -0400, Ryan Kavanagh wrote:
> Package: openafs-modules-dkms
> Version: 1.8.6~pre1-3
> Severity: grave
> Justification: package is not compatible with the current kernel
> 
> The package cannot successfully be installed under 5.7.0-1-amd64.
> The build fails with:

Upstream 1.8.6, released yesterday, will support the 5.7 kernel.

Thanks for the report,

Ben

Bug#959064: ignition-transport FTBFS in testing.

[Benjamin Kaduk]

On Thu, Apr 30, 2020 at 03:40:30AM +0100, peter green wrote:
> On 29/04/2020 17:47, Jochen Sprickerhof wrote:
> >
> > What I found up to now:
> >
> > - pkg-config=0.29.2-1:
> >
> >   $ pkg-config --cflags-only-I libzmq
> >   -isystem /usr/include/mit-krb5 -I/usr/include/pgm-5.2
> >
> > - Whereas pkg-config=0.29-6 (or pkgconfig):
> >
> >   $ pkg-config --cflags-only-I libzmq
> >   -I/usr/include/pgm-5.2
> >
> > So the recent update of pkg-config has a new behaviour, introduced in
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=97337
> >
> So to clarify the situation as I now understand it (it took me a couple of 
> readings of the mail for it to sink in)
> 
> The behavior of pkg-config has changed so that --cflags-only-I now lets 
> through "-isystem" as well as "-I"
> 
> This lets though a -isystem parameter with a space which was previously 
> suppressed (not because it had a space but because it was a -isystem 
> parameter rather than a -I parameter)

I did not actually know that -isystem would still work with*out* the space!

> And the space in said parameter breaks cmake.
> 
> > Changing -isystem /usr/include/mit-krb5 to -isystem/usr/include/mit-krb5 
> > works in the .pc file(s) works around this but man gcc indicates that a 
> > space after -isystem seems fine as well.
> >
> Investigating further it seems that the use of -isystem in krb5 and the space 
> after it are the results of a Debian patch (upstream uses -I with no space). 
> So it seemed to me that the expedient way to fix the build failure was just 
> to change the krb5 patch and that this would actually reduce the delta from 
> upstream. I went ahead and did that in Raspbian. A debdiff should appear soon 
> at https://debdiffs.rapsbian.org/main/k/krb5/

FWIW we have to have this krb5 patch in Debian because we divide our
headers into krb5-multidev (which can coexist with the other major krb5
implementation, heimdal), and libkrb5-dev that installs symlinks in the
global location.  Our pkg-config files have to work with the -multidev
variant, which has the headers in a non-default path, but we still need
them treated as system headers, hence this patch.

I think it would be appropriate to open a wishlist bug against krb5 so we
remember to change this the next time we do an upload.

-Ben

Bug#956358: openafs-modules-dkms: piuparts failure on package installation

[Benjamin Kaduk]

severity 956358 important
tags 956358 + moreinfo
thanks

On Fri, Apr 10, 2020 at 11:30:10AM +0300, Adrian Bunk wrote:
> 
> https://piuparts.debian.org/sid/source/o/openafs.html
> 
> ...
>   Loading new openafs-1.8.6pre1 DKMS files...
>   It is likely that 4.19.0-8-amd64 belongs to a chroot's host
>   Building for 5.4.0-4-amd64
>   Building initial module for 5.4.0-4-amd64
>   Error! Bad return status for module build on kernel: 5.4.0-4-amd64 (x86_64)
>   Consult /var/lib/dkms/openafs/1.8.6pre1/build/make.log for more information.
>   dpkg: error processing package openafs-modules-dkms (--configure):
>installed openafs-modules-dkms package post-installation script subprocess 
> returned error exit status 10
>   Processing triggers for libc-bin (2.30-4) ...
>   Errors were encountered while processing:
>openafs-modules-dkms
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

The package installs cleanly and successfully builds the kernel module on a
freshly installed sid VM.
Attempting to run piuparts locally in that same VM (without the package
installed, not that it should matter) "succeeds" (but does not seem to
actually build a kernel module.

How can I find out more about the contents of the
/srv/piuparts.debian.org/slave/basetgz/sid_amd64.tar.gz indicated in the
indicated piuparts log?

Thanks,

Ben

Bug#952799: openafs: [INTL:it] Italian translation of debconf messages

[Benjamin Kaduk]

On Sat, Feb 29, 2020 at 02:17:49PM +0100, Beatrice Torracca wrote:
> Package: openafs
> Severity: wishlist
> Tags: patch l10n
> 
> Hi.
> 
> Please find attached the Italian translation of openafs debconf messages
> 
> 
> Please include it in your next upload.

Thanks, Beatrice, I will do so.

-Ben

Bug#948307: openafs-modules-dkms: Compile of the module fails for kernel 5.3.15

[Benjamin Kaduk]

On Sun, Feb 09, 2020 at 09:53:26AM +, Witold Baryluk wrote:
> Package: openafs
> Followup-For: Bug #948307
> 
> Dear Maintainer,
> 
> The 1.8.5-1 fails to compile with kernel 5.3.0-2-amd64:
> 
> Setting up openafs-modules-dkms (1.8.5-1) ...
>   Loading new openafs-1.8.5 DKMS files...
>   It is likely that 4.19.0-6-amd64 belongs to a chroot's host
>   Building for 5.3.0-2-amd64
>   Building initial module for 5.3.0-2-amd64
>   Error! Bad return status for module build on kernel: 5.3.0-2-amd64 (x86_64)
>   Consult /var/lib/dkms/openafs/1.8.5/build/make.log for more information.
>   dpkg: error processing package openafs-modules-dkms (--configure):
>installed openafs-modules-dkms package post-installation script subprocess 
> returned error exit status 10

Can you post (a subset of) the dkms make.log somewhere?
As I have said previously, openafs-1.8.5-1 is working find with the
5.4.0-3-amd64 kernel for me locally.

Thanks,

Ben

Bug#946520: FTBFS on ppc64el

[Benjamin Kaduk]

On Tue, Dec 10, 2019 at 03:03:02PM +0100, Frédéric Bonnard wrote:
> Package: src:openafs
> Version: 1.8.5-1
> 
> --
> 
> Dear maintainer,
> thanks for enabling ppc64el. It seems some more changes are needed for
> openafs to build properly :
> https://buildd.debian.org/status/fetch.php?pkg=openafs=ppc64el=1.8.5-1=1572239330=0
> 
> Here is a merge request that does the job here :
> https://salsa.debian.org/debian/openafs/merge_requests/2

Thanks for the patch, and heads-up.  It seems my salsa notification
settings needed some adjustment, too...

N.B. that upstream has dealt with osconf.m4 slightly differently
(https://gerrit.openafs.org/13980) but the idea is the same.

I'll get this in the next upload.

-Ben

Bug#945506: openafs-modules-dkms: module FTBFS for Linux 5.3.0-2-amd64

[Benjamin Kaduk]

On Tue, Dec 10, 2019 at 01:19:11PM +0100, Andreas Beckmann wrote:
> Please check my reply on #946497 which is about the same problem in
> zfs-dkms. Perhaps both of you find a solution that will work for the two
> packages.

Thanks for the pointer.

I think that having dkms set CC/etc. appropriately is probably the
architecturally cleanest solution (as dkms actually knows what kernel is
being built for), and am willing to try to dig into how that might happen,
time permitting.

That said, I have pretty severe time demands these days so can only get a
couple days of solid development time per month (split among several
projects); would you mind if I dropped the severity of this bug to prevent
autoremoval from testing while that work proceeds?

Thanks,

Ben

Bug#945506: openafs-modules-dkms: module FTBFS for Linux 5.3.0-2-amd64

[Benjamin Kaduk]

Hi Andreas,

On Tue, Nov 26, 2019 at 02:38:21AM +0100, Andreas Beckmann wrote:
> Package: openafs-modules-dkms
> Version: 1.8.5-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> openafs-modules-dkms/sid fails to build the kernel module for the
> current kernel (5.3.0-2-amd64) in a minimal sid chroot with
> linux-headers-amd64 installed:
> 
>   Setting up openafs-modules-dkms (1.8.5-1) ...
>   Loading new openafs-1.8.5 DKMS files...
>   It is likely that 5.2.14 belongs to a chroot's host
>   Building for 5.3.0-2-amd64
>   Building initial module for 5.3.0-2-amd64
>   Error! Bad return status for module build on kernel: 5.3.0-2-amd64 (x86_64)
>   Consult /var/lib/dkms/openafs/1.8.5/build/make.log for more information.
>   dpkg: error processing package openafs-modules-dkms (--configure):
>installed openafs-modules-dkms package post-installation script subprocess 
> returned error exit status 10
>   Processing triggers for libc-bin (2.29-3) ...
>   Errors were encountered while processing:
>openafs-modules-dkms
> 
> make.log contains:
> 
> DKMS make.log for openafs-1.8.5 for kernel 5.3.0-2-amd64 (x86_64)
> Fri Nov 15 21:42:48 UTC 2019
> checking for gcc... no
> checking for cc... no
> checking for cl.exe... no
> configure: error: in `/var/lib/dkms/openafs/1.8.5/build':
> configure: error: no acceptable C compiler found in $PATH
> See `config.log' for more details
> 
> So the sources are looking for "gcc" while they should get the correct
> compiler to use from the kernel headers ... the module must be built
> with the same compiler version as the kernel itself, which is not
> neccessarily the system default "gcc", and for Debian it's always a
> versioned gcc-N. (The linux-headers- packages transitively
> depend on the correct versioned gcc package.)

I think I need some help to figure out the best thing to do here.
For background, openafs is portable to a wide variety of OSes including
Linux, Solaris, several BSDs, macOS, and AIX, and uses a kernel module to
provide the network filesystem client functionality.  The configure script
does of course conditionalize its checks based on detected OS, but with my
upstream hat on I'm pretty skeptical of encoding any distro-specific checks
that would involve querying the dpkg database.

(I'm also not sure I properly understand the need to use the exact same
compiler as the base kernel -- is the calling convention ABI really going
to change regularly?  But feel free to treat that as an aside, as it's not
unreasonable to expect)

So, are you just saying that configure should be looking for various gcc-N
while searching for a compiler, or are you saying that the debian packaging
needs to be chasing the dpkg database for the kernel in question to find
the appropriate compiler, and hardcoding that as the CC argument to
configure?  (This is of course more exciting since the actual kernel module
build for openafs-modules-dkms does not occur at package build time, and
the package also produces a package with module sources for non-dkms
builds.)

Your insight would be greatly appreciated.

Thanks,

Ben

Bug#941658: Build openafs on other ppc64el

[Benjamin Kaduk]

On Thu, Oct 03, 2019 at 03:03:55PM +0200, Frédéric Bonnard wrote:
> Package: src:openafs
> Version: 1.8.4~pre1-1
> 
> --
> 
> Dear maintainer,
> is there any reason that openafs isn't built on ppc64el(maybe linux-any) ?
> I tested on ppc64el and with minor modifications (arch verifications in
> debian/sysname and debian/module/sysname), it built well.

I think the only reason is that I forgot to add it to debian/control after
upstream merged the necessary bits :(

Thanks for the reminder; I should be able to include that in the next
upload.

-Ben

Bug#935771: openafs-modules-source: Tries to use missing cc-wrapper with ctfutils installed

[Benjamin Kaduk]

On Sun, Aug 25, 2019 at 10:04:30PM -0400, Aaron M. Ucko wrote:
> Package: openafs-modules-source
> Version: 1.8.4~pre1-1
> Severity: normal
> 
> Attempting to build modules from openafs-modules-source (or,
> presumably, -dkms) with ctfutils installed fails because the build
> system tries to use .../src/config/cc-wrapper, which is unavailable
> here.  (In a full source tree, configure would have generated it from
> .../cc-wrapper.in.)
> 
> AFAICT, these utilities would provide little or no actual benefit
> here, at least on Linux, so I'd suggest explicitly doing without them
> by configuring --without-ctf-tools.
> 
> Could you please take a look?

Sure, and thanks for the report -- upstream made this change in
https://gerrit.openafs.org/13487 to let Solaris use the CTF information
(i.e., dtrace, if I understand correctly) in userspace as well as the
kernel, and just applying the change globally was by far the easiest
integration in the build system.  (It wasn't limited to Solaris so as to
not artificially limit any other OS that might gain the requisite
CTF/dtrace support, e.g., FreeBSD.)

I'd be vaguely curious if you wanted to drop in the cc-wrapper from a full
source tree and see if it produced anything useful, though I agree that
just configuring with --without-ctf-tools would be a fine workaround for
now.

Thanks for the report,

Ben

Bug#934758: DKMS module fails to build for linux 5.2.0-2

[Benjamin Kaduk]

severity 934758 important
tags 934758 + fixed-upstream pending
thanks

On Wed, Aug 14, 2019 at 09:53:40AM -0400, Ryan Kavanagh wrote:
> Package: openafs-modules-dkms
> Version: 1.8.2-1
> Severity: grave
> Justification: renders package unusable
> 
> The openafs DKMS module fails to build for Linux kernel 5.2.0-2.
> This renders openafs unusable. I have attached the build log containing
> the error messages, in particular, it seems to have something to do
> with:

Yes, the fast-moving Linux KPIs have changed interfaces used by OpenAFS and
the 1.8.2 in Debian is stale.  I plan to package 1.8.4pre1 this week, which
should take care of this.

Thanks,

Ben

P.S. The 5.2.0 kernel is pretty unusable on my machine for other reasons,
mostly graphics-related, and I had to boot into 4.19.

Bug#934236: openafs-fileserver: postinst uses asetkey, but the package does not depend on openafs-krb5

[Benjamin Kaduk]

On Thu, Aug 08, 2019 at 03:16:31PM +0200, Arne Nordmark wrote:
> Package: openafs-fileserver
> Version: 1.8.2-1
> Severity: normal
> 
> The stanza
> 
> if [ -r /etc/openafs/server/rxkad.keytab ] ; then
> akeyconvert
> fi
> 
> in the postinst will fail if openafs-krb5 is not installed or is of version 
> 1.6.
> 
> This happens for example when doing a partial upgrade from stretch to buster 
> using apt-get upgrade.
> 
> A dependency on openafs-krb5 should be added to the package.

Thanks for the report; this is quite clearly a bug in the maintainer
script.
I will think a bit about whether it is better to leave the akeyconvert
invocation in openafs-fileserver and make it conditional on akeyconvert's
presence, add the openafs-krb5 dependency, or move the call to the
openafs-krb5 maintainer script.  Adding the hard dependency would break a
property that the original packaging split had as a strong requirement,
though the incentive to have that requirement is probably much smaller now
that it was originally.

-Ben

Bug#932000: In testing

[Benjamin Kaduk]

On Tue, Jul 23, 2019 at 12:09:29PM -0700, Felix Lechner wrote:
> On Tue, Jul 16, 2019 at 8:07 AM Greg Hudson  wrote:
> >
> > Candidate patch here:
> 
> Thank you. The update works great, although I now have problems with
> idmap not working on a kerberized NFSv4 mount.
> 
> I write with hesitation. A week has passed and many other packages
> were likewise updated. My idmap issue could not be related to cipher
> suites in krb5, could it?

It's hard to come up with many scenarios in which they could be related.
The only remotely plausible one that comes to mind is if the idmapd is
somehow using a different keytab (or libkrb5) than the core NFS server, but
I don't remember the architecture working like that.

-Ben

Bug#910344: libgssapi-krb5-2: conffiles not removed

[Benjamin Kaduk]

On Fri, Jul 05, 2019 at 07:25:26PM +0300, Martin-Éric Racine wrote:
> It is very much expected to be resolved.

Expected by whom?

> Please see:
> 
> https://manpages.debian.org/wheezy/dpkg/dpkg-maintscript-helper.1.en.html

I read most of this; it gives some general guidance that conffiles should
be removed from disk in the usual case, as well as details about good ways
to achieve that goal.
In this case, the maintainer of the package (Sam) has expressed a desire to
not remove the file.  Is there policy that overrides the maintainer's
discretion, here?

-Ben

Bug#931819: Remove weak_crypto code

[Benjamin Kaduk]

On Wed, Jul 10, 2019 at 04:05:39PM -0400, Sam Hartman wrote:
> Hi.
> In krb5 1.17-4, DES is entirely removed.
> 
> src/aklog/aklog.c makes it look like openafs still requires
> des-cbc-crc.  If so, please upgrade this bug to RC.
> Kaduk thinks that's probably not the case though.
> 
> If not, please consider removing the weak_crypto code at this point.

https://gerrit.openafs.org/13689 has the first step at getting rid of
the weak crypto code (disable it by default and require opt-in if
there are stragglers using it).

-Ben

Bug#910344: libgssapi-krb5-2: conffiles not removed

[Benjamin Kaduk]

On Fri, Jul 05, 2019 at 06:35:20PM +0300, Martin-Éric Racine wrote:
> 
> This issue is still not resolved in Buster, which is scheduled to become the 
> new STABLE release tomorrow.

To me the bug history implies that it is not expected to be resolved, ever.
Do you think otherwise?  If so, what could be added to the bug history to
make that state of affairs more clear?

Thanks,

Ben

Bug#926321: openafs: FTBFS on arm64

[Benjamin Kaduk]

Hi Paul,

On Wed, Apr 03, 2019 at 01:06:08PM +0100, Paul Martin wrote:
> Source: openafs
> Version: 1.6.20-2+deb9u2
> Severity: normal
> Tags: patch, ftbfs, stretch
> 
> It would be nice if openafs were to be available on ARM64 architecture 
> in Debian Stretch and Ubuntu Bionic.
> 
> The OpenStack Infrastructure project in particular would benefit from 
> this package suite being available.

Thanks for the report (and patch).

I think I remember it being a conscious decision around the time of
upstream's 1.8.0 to only bring arm64 support into Debian alongside 1.8.0
(i.e., for buster), and I thought that's because upstream had needed more
changes than just the sort you have in these patches.  But presumably your
systems are working with just the posted patches, so I'll try to take a
closer look at what actually happened with upstream and refresh my memory
of the situation.

That said, I don't know how the SRMs feel about this sort of change.
Did you consider using a backported 1.8.2-1 from buster?  (I don't have
much time for working on the Ubuntu packaging;
https://launchpad.net/~openafs/+archive/ubuntu/stable?field.series_filter=zesty
may be an option for you there.)

-Ben

Bug#910344: libgssapi-krb5-2: conffiles not removed

[Benjamin Kaduk]

On Fri, Oct 05, 2018 at 08:01:04AM +0800, Paul Wise wrote:
> 
> The recent upgrade did not deal with obsolete conffiles properly.
> Please use the dpkg-maintscript-helper support provided by
> dh_installdeb to remove these obsolete conffiles on upgrade.
> 
> https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
> https://manpages.debian.org/man/1/dh_installdeb
> 
> This bug report brought to you by adequate:
> 
> http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
> 
> $ pkg=libgssapi-krb5-2 ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' 
> $pkg | grep obsolete
> libgssapi-krb5-2:amd64: obsolete-conffile /etc/gss/mech.d/README
>  /etc/gss/mech.d/README 27e753ba1dc72900d2892b8efef6e35e obsolete

How is this not a dup of #868121 (with additional discussion linked
therefrom)?

-Ben

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Benjamin Kaduk]

I think I am experiencing the same issue as Thomas Maaß, though I am
not convinced that it is the same behavior as the initial report.
Namely, sometimes the display does not turn on when light-locker should be
prompting for a password (I think I have seen this both when returning from
hibernation and after a "normal" lock-screen event when the machine should
still be running), though other times the display does turn on.
Switching to a text terminal and returning causes the display to activate,
whereupon things function as expected.

I'll try to file a separate report tomorrow with reportbug unless informed
otherwise.

-Ben

Bug#908616: OpenAFS security release

[Benjamin Kaduk]

On Tue, Sep 11, 2018 at 10:02:20PM +0200, Salvatore Bonaccorso wrote:
> Hey!
> 
> On Tue, Sep 11, 2018 at 02:30:51PM -0500, Benjamin Kaduk wrote:
> > Source: openafs
> > Version: 1.6.9-2+deb8u7
> > Tags: security
> > Severity: serious
> > 
> > OpenAFS upstream released security releases 1.6.23 and 1.8.2 today, fixing:
> > http://openafs.org/pages/security/OPENAFS-SA-2018-001.txt
> > http://openafs.org/pages/security/OPENAFS-SA-2018-002.txt
> > http://openafs.org/pages/security/OPENAFS-SA-2018-003.txt
> > 
> > No CVEs have been assigned yet.
> 
> Would it be possible, that you with both your maintainers and upstream
> part could request accordingly CVEs via http://cveform.mitre.org/ (and
> then loop back the assignment here once got those).

OPENAFS-SA-2018-001 is CVE-2018-16947.
OPENAFS-SA-2018-002 is CVE-2018-16948.
OPENAFS-SA-2018-003 is CVE-2018-16949.

-Ben

Bug#908616: OpenAFS security release

[Benjamin Kaduk]

Source: openafs
Version: 1.6.9-2+deb8u7
Tags: security
Severity: serious

OpenAFS upstream released security releases 1.6.23 and 1.8.2 today, fixing:
http://openafs.org/pages/security/OPENAFS-SA-2018-001.txt
http://openafs.org/pages/security/OPENAFS-SA-2018-002.txt
http://openafs.org/pages/security/OPENAFS-SA-2018-003.txt

No CVEs have been assigned yet.

-Ben

Bug#897535: openafs: FTBFS: dh_auto_test: make -j1 test VERBOSE=1 returned exit code 2

[Benjamin Kaduk]

(ditto)

On Wed, May 30, 2018 at 11:18:11AM -0500, Benjamin Kaduk wrote:
> (resetting autoremoval timer)
> 
> On Fri, May 11, 2018 at 12:44:01PM -0500, Benjamin Kaduk wrote:
> > ping?
> > 
> > I cannot reproduce locally either on bare metal or in schroot.
> > 
> > -Ben
> > 
> > On Fri, May 04, 2018 at 09:15:51AM -0500, Benjamin Kaduk wrote:
> > > Hi Lucas,
> > > 
> > > On Wed, May 02, 2018 at 10:52:53PM +0200, Lucas Nussbaum wrote:
> > > > 
> > > > During a rebuild of all packages in sid, your package failed to build on
> > > > amd64.
> > > > 
> > > > Relevant part (hopefully):
> > > > > rx/perf.ok
> > > > > volser/vos-man..ok
> > > > > volser/vos..FAILED 5
> > > > > bucoord/backup-man..ok
> > > > > kauth/kas-man...ok
> > > > > 
> > > > > Failed Set Fail/Total (%) Skip Stat  Failing Tests
> > > > > -- --    
> > > > > 
> > > > > volser/vos1/6 17%00  5
> > > 
> > > Unfortunately the upstream build system does not capture verbose
> > > test output for display in case of failure, but from the test number
> > > we can deduce that what is failing is that an outputted list of
> > > addresses does not match the expected string:
> > > char expecting[] = 
> > > "10.0.0.0\n10.0.0.1\n10.0.0.2\n10.0.0.3\n10.0.0.4\n"
> > >
> > > "10.0.0.5\n10.0.0.6\n10.0.0.7\n10.0.0.8\n10.0.0.9\n"
> > >"10.0.0.10\n10.0.0.11\n10.0.0.12\n10.0.0.13\n"
> > >"10.0.0.14\n10.0.0.15\n";
> > > 
> > > I note that this test is disabled when the system's hostname
> > > resolves to a loopback address because those addresses are forbidden
> > > from being entered into the database as fileserver addresses, but
> > > even when I change my local configuration to avoid that, I still
> > > cannot reproduce the test failure locally.
> > > 
> > > I surmise that the AWS machine may be getting assigned a 10/8
> > > address as its primary address, and perhaps that would interfere
> > > with some of what the test is doing.  Do you happen to know more
> > > about the network configuration on the AWS systems used for these
> > > autopkgtests?
> > > 
> > > Thanks,
> > > 
> > > Ben

Bug#897535: openafs: FTBFS: dh_auto_test: make -j1 test VERBOSE=1 returned exit code 2

[Benjamin Kaduk]

(resetting autoremoval timer)

On Fri, May 11, 2018 at 12:44:01PM -0500, Benjamin Kaduk wrote:
> ping?
> 
> I cannot reproduce locally either on bare metal or in schroot.
> 
> -Ben
> 
> On Fri, May 04, 2018 at 09:15:51AM -0500, Benjamin Kaduk wrote:
> > Hi Lucas,
> > 
> > On Wed, May 02, 2018 at 10:52:53PM +0200, Lucas Nussbaum wrote:
> > > 
> > > During a rebuild of all packages in sid, your package failed to build on
> > > amd64.
> > > 
> > > Relevant part (hopefully):
> > > > rx/perf.ok
> > > > volser/vos-man..ok
> > > > volser/vos..FAILED 5
> > > > bucoord/backup-man..ok
> > > > kauth/kas-man...ok
> > > > 
> > > > Failed Set Fail/Total (%) Skip Stat  Failing Tests
> > > > -- --    
> > > > 
> > > > volser/vos1/6 17%00  5
> > 
> > Unfortunately the upstream build system does not capture verbose
> > test output for display in case of failure, but from the test number
> > we can deduce that what is failing is that an outputted list of
> > addresses does not match the expected string:
> > char expecting[] = "10.0.0.0\n10.0.0.1\n10.0.0.2\n10.0.0.3\n10.0.0.4\n"
> >"10.0.0.5\n10.0.0.6\n10.0.0.7\n10.0.0.8\n10.0.0.9\n"
> >"10.0.0.10\n10.0.0.11\n10.0.0.12\n10.0.0.13\n"
> >"10.0.0.14\n10.0.0.15\n";
> > 
> > I note that this test is disabled when the system's hostname
> > resolves to a loopback address because those addresses are forbidden
> > from being entered into the database as fileserver addresses, but
> > even when I change my local configuration to avoid that, I still
> > cannot reproduce the test failure locally.
> > 
> > I surmise that the AWS machine may be getting assigned a 10/8
> > address as its primary address, and perhaps that would interfere
> > with some of what the test is doing.  Do you happen to know more
> > about the network configuration on the AWS systems used for these
> > autopkgtests?
> > 
> > Thanks,
> > 
> > Ben

Bug#897535: openafs: FTBFS: dh_auto_test: make -j1 test VERBOSE=1 returned exit code 2

[Benjamin Kaduk]

ping?

I cannot reproduce locally either on bare metal or in schroot.

-Ben

On Fri, May 04, 2018 at 09:15:51AM -0500, Benjamin Kaduk wrote:
> Hi Lucas,
> 
> On Wed, May 02, 2018 at 10:52:53PM +0200, Lucas Nussbaum wrote:
> > 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> > 
> > Relevant part (hopefully):
> > > rx/perf.ok
> > > volser/vos-man..ok
> > > volser/vos..FAILED 5
> > > bucoord/backup-man..ok
> > > kauth/kas-man...ok
> > > 
> > > Failed Set Fail/Total (%) Skip Stat  Failing Tests
> > > -- --    
> > > 
> > > volser/vos1/6 17%00  5
> 
> Unfortunately the upstream build system does not capture verbose
> test output for display in case of failure, but from the test number
> we can deduce that what is failing is that an outputted list of
> addresses does not match the expected string:
> char expecting[] = "10.0.0.0\n10.0.0.1\n10.0.0.2\n10.0.0.3\n10.0.0.4\n"
>"10.0.0.5\n10.0.0.6\n10.0.0.7\n10.0.0.8\n10.0.0.9\n"
>"10.0.0.10\n10.0.0.11\n10.0.0.12\n10.0.0.13\n"
>"10.0.0.14\n10.0.0.15\n";
> 
> I note that this test is disabled when the system's hostname
> resolves to a loopback address because those addresses are forbidden
> from being entered into the database as fileserver addresses, but
> even when I change my local configuration to avoid that, I still
> cannot reproduce the test failure locally.
> 
> I surmise that the AWS machine may be getting assigned a 10/8
> address as its primary address, and perhaps that would interfere
> with some of what the test is doing.  Do you happen to know more
> about the network configuration on the AWS systems used for these
> autopkgtests?
> 
> Thanks,
> 
> Ben

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Benjamin Kaduk]

On Tue, May 08, 2018 at 09:28:08AM -0400, Sam Hartman wrote:
> Benjamin> Now, we have getrandom(), which is a great API and is
> Benjamin> pretty much exactly what you want (again, at least in this
> Benjamin> worldview).  IIUC Ted says that you should "just use
> Benjamin> getrandom" for your entropy needs and not worry about
> Benjamin> /dev/*random.  I don't know whether he takes a stance on
> Benjamin> the GRND_RANDOM flag, though.
> 
> And I think that's fine for kadmind.
> I think there's a very real practical question about whether you want
> the KDC to fail to start if your RNG is not seeded.
> Having your KDCs be unavailable from a cold start of an environment is a
> really big thing.

I'll note that the original user report seems to have involved a
virtual machine running on Xen; my general expectation is that
bare-metal KDCs will get enough entropy from device attachment and
network traffic for long blocking to not be an issue.
Enterprise-scale deployments that use virtualized KDCs are likely to
have proper randomness pass-through devices installed, so I suspect
that the number of sites that are at any significant risk of being
affected will be a pretty small percentage.

Do you think we should raise the question on upstream's mailing
list?

-Ben

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Benjamin Kaduk]

On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote:
> On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote:
> 
> There are basically three "strengths" of random numbers available now:
> 
> Weak:   /dev/urandom
> Medium: getrandom(flags=0)
> Strong: /dev/random, getrandom(flags=GRND_RANDOM)
> 
> k5_get_os_entropy() has switched from weak/strong depending on the
> "strong" flag to always medium.  I think what you actually want is
> medium/strong.

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 amounts of random output
with no need to track "entropy depletion" or similar (emphasis on
fully-seeded).  So the question (for them) is not "strong" or
"weak", but rather "fully seeded" or "not seeded yet".  In this
worldview, if you have to choose between /dev/random and
/dev/urandom, (1) /dev/random is the only thing that actually
provides the guarantee you want, but (2) /dev/random is incredibly
painful for using "all the time", so you're tempted to use
/dev/urandom for cases where it's "less important", like session
keys, but reserve /dev/random for times when you really care about
the "fully seeded" property, like long-term keys.  When those were
the only choices, the 'strong' flag made sense.

Now, we have getrandom(), which is a great API and is pretty much
exactly what you want (again, at least in this worldview).  IIUC Ted
says that you should "just use getrandom" for your entropy needs and
not worry about /dev/*random.  I don't know whether he takes a
stance on the GRND_RANDOM flag, though.

Anyway, I mention this all in the hope that we can just drop this
line or discussion and let upstream krb5 decide what properties they
want from a CSPRNG, and not try to revisit that design.


To answer Sam's questions, in the above worldview, the right answer
for the KDC and the right answer for kadmind are the same -- just
use getrandom().  It provides the output of a high-quality CSPRNG,
and is guaranteed to block until fully seeded.  In this worldview,
the cryptographic quality of the (fully seeded) urandom pool is more
than adequate, so there's no need to ever pass GRND_RANDOM.

I'm certainly open to having krb5 ship a proof-of-concept
wait-for-entropy.service in unstable for a while, though it seems
like something better suited for libc or systemd core for the long
term.

If we need to for stretch, it would presumably be easy enough to
just add a stanza to the KDC's unit file to increase the timeout
(though how do we know what sort of timeout is "long enough"?).

> I'm going to start a discussion on debian-release, as we need to
> coordinate a solution across multiple packages.

Thanks, I'm glad someone with more time than me has already started
getting the right thing done.

> Jann Horn suggested improving systemd-random-seed.service so that it
> actually credits entropy after feeding saved random bits into the RNG. 
> But this will require some care to ensure we never use the same random
> bits twice (including on multiple systems built from the same system
> image).

Indeed, that's in the general case a rather hard problem.

-Ben


signature.asc
Description: PGP signature

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Benjamin Kaduk]

On Sun, May 06, 2018 at 07:05:56PM -0700, Russ Allbery wrote:
> Benjamin Kaduk <ka...@mit.edu> writes:
> > On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
> >> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
> 
> >>> Arguably more preferable would be to have a systemd target that
> >>> indicates the RNG is seeded, and then krb5 could have its KDC service
> >>> depend on this "RNG-available" service.  So far as I know, no such
> >>> service currently exists, so again, there would need to be some
> >>> sytsemd effort (potentially in cooperation with the kernel) to provide
> >>> such a service.
> 
> >> Yes, that certainly seems like a good approach.
> 
> > Do you know who would be the right person to talk to about getting
> > that work done?
> 
> This seems trivial enough that the krb5-kdc package could just ship this
> service for now and gauge interest.  I think all you'd need is a program
> that called getrandom() and then exited when it returned, run via systemd
> as a Type=oneshot service that krb5-kdc depends on and with a reasonable
> timeout.

I think that's what it would look like, yes.  It's less clear that
putting it in krb5-kdc would actually do anything to gauge demand,
but I suppose I could be wrong.

-Ben

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Benjamin Kaduk]

On Sun, May 06, 2018 at 08:43:13PM +0100, Ben Hutchings wrote:
> On Sun, 2018-05-06 at 14:02 -0500, Benjamin Kaduk wrote:
> > Hi Ben,
> > 
> > On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> > > I've cloned this bug as #898073 and reassigned that to krb5.
> > > 
> > > krb5 is using the new(ish) getrandom() system call to read random bits,
> > > with the code comment "This ensures strong randomness while only
> > > blocking during first system boot."
> > > 
> > > While this is a regression, the kernel is only doing what krb5 was
> > > asking for (whereas previously it could wrongly provide weak random
> > > bits).
> > > 
> > > We might still revert this change in the kernel temporarily.  However,
> > > the krb5 developers need to decide what they really want, and if that's
> > > strong randomness then they need to configure the service to allow for
> > > a longer delay at boot.
> > 
> > I read through the history on #898073 and am still not sure I have
> > the backstory quite right.  This is what it sounds like has
> > happened:
> > 
> > The kernel in stable has for some time provided a getrandom() system
> > call that provided "weak" (more on this later) random numbers for
> > some time after startup, though did eventually converge to "strong"
> > randomness after some time (a few minutes?).  The kernel 4.9.88-1
> > upload fixed the bug that getrandom() could provide "weak" output
> > (since getrandom() is supposed to block until strong output is
> > ready), and this in turn caused the krb5 KDC to block at boot until
> > the RNG was ready, blocking long enough that systemd timed out the
> > unit and marked it as failed.  We're now talking about the proper
> > way to improve the situation.
> 
> Right.
> 
> > If the above is correct, I'm not yet sure that I see a krb5-specific
> > bug.  It is definitely true that krb5 is specifically requesting the
> > getrandom() semantics of blocking until the RNG is fully seeded, but
> > krb5 is hardly expected to be the only consumer of getrandom().  As
> > such, why should krb5 be responsible for increasing the systemd
> > timeout at boot -- could not systemd be responsible for increasing
> > the default timeout to allow for entropy seeding as used by multiple
> > applications?
> 
> How would systemd determine which systems require this?

I didn't have anything in mind other than globally increasing the
default timeout.

> > Arguably more preferable would be to have a systemd
> > target that indicates the RNG is seeded, and then krb5 could have
> > its KDC service depend on this "RNG-available" service.  So far as I
> > know, no such service currently exists, so again, there would need
> > to be some sytsemd effort (potentially in cooperation with the
> > kernel) to provide such a service.
> 
> Yes, that certainly seems like a good approach.

Do you know who would be the right person to talk to about getting
that work done?

> > To rephrase in a different way, "getrandom() is a system service,
> > and the system's init system should not penalize other services for
> > using system services -- why should the onus of adapting be placed on
> > individual consumers of that system service?"
> > 
> > 
> > Back to the "weak" random numbers.  How weak are we talking about?
> 
> If I'm reading the code correctly, the previous condition for
> successful return of getrandom() (without the GRND_RANDOM flag) was
> that at least 64 bits of raw random data have been added to the random
> pool.  The raw random data might come from a high quality hardware
> random number generator but might be much weaker.  The current
> condition is that at least 128 bits of entropy have been added (based
> on a conservative estimate of entropy).

Thanks for sharing your interpretation.  Hmm, 64 bits is not very
much (e.g., 64^W56-bit single-DES keys are brute-forceable at
relatively low cost, these days), though I don't have a sense for
what the weakest source that could be used is.  It's of course not
just as simple as the first 64 bits, since other input is
continually added, but it sounds like there is some
larger-than-normal-security-margin chance that an attacker could
reproduce a key that was generated on a user system.  It sounds like
we should try to get some additional eyes on this.

> > The krb5 KDC and kadmind are used (among other things) to generate
> > shared symmetric keys, used to encrypt and authenticate traffic over
> > the network.  Some of these keys are long-lived, and a

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Benjamin Kaduk]

Hi Ben,

On Sun, May 06, 2018 at 06:56:08PM +0100, Ben Hutchings wrote:
> I've cloned this bug as #898073 and reassigned that to krb5.
> 
> krb5 is using the new(ish) getrandom() system call to read random bits,
> with the code comment "This ensures strong randomness while only
> blocking during first system boot."
> 
> While this is a regression, the kernel is only doing what krb5 was
> asking for (whereas previously it could wrongly provide weak random
> bits).
> 
> We might still revert this change in the kernel temporarily.  However,
> the krb5 developers need to decide what they really want, and if that's
> strong randomness then they need to configure the service to allow for
> a longer delay at boot.

I read through the history on #898073 and am still not sure I have
the backstory quite right.  This is what it sounds like has
happened:

The kernel in stable has for some time provided a getrandom() system
call that provided "weak" (more on this later) random numbers for
some time after startup, though did eventually converge to "strong"
randomness after some time (a few minutes?).  The kernel 4.9.88-1
upload fixed the bug that getrandom() could provide "weak" output
(since getrandom() is supposed to block until strong output is
ready), and this in turn caused the krb5 KDC to block at boot until
the RNG was ready, blocking long enough that systemd timed out the
unit and marked it as failed.  We're now talking about the proper
way to improve the situation.

If the above is correct, I'm not yet sure that I see a krb5-specific
bug.  It is definitely true that krb5 is specifically requesting the
getrandom() semantics of blocking until the RNG is fully seeded, but
krb5 is hardly expected to be the only consumer of getrandom().  As
such, why should krb5 be responsible for increasing the systemd
timeout at boot -- could not systemd be responsible for increasing
the default timeout to allow for entropy seeding as used by multiple
applications?  Arguably more preferable would be to have a systemd
target that indicates the RNG is seeded, and then krb5 could have
its KDC service depend on this "RNG-available" service.  So far as I
know, no such service currently exists, so again, there would need
to be some sytsemd effort (potentially in cooperation with the
kernel) to provide such a service.

To rephrase in a different way, "getrandom() is a system service,
and the system's init system should not penalize other services for
using system services -- why should the onus of adapting be placed on
individual consumers of that system service?"


Back to the "weak" random numbers.  How weak are we talking about?
The krb5 KDC and kadmind are used (among other things) to generate
shared symmetric keys, used to encrypt and authenticate traffic over
the network.  Some of these keys are long-lived, and an
insufficiently random long-lived key could have rather disasterous
consequences for deployments unlucky enough to have generated them.
Are we looking at a repeat of the openssl RNG fiasco where piles of
ssh keys and TLS certificates had to be regenerated?  If there's a
real issue here of weak randomness, we may need to publicize this
issue much more widely.

Thanks,

Ben


signature.asc
Description: PGP signature

Bug#897535: openafs: FTBFS: dh_auto_test: make -j1 test VERBOSE=1 returned exit code 2

[Benjamin Kaduk]

Hi Lucas,

On Wed, May 02, 2018 at 10:52:53PM +0200, Lucas Nussbaum wrote:
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > rx/perf.ok
> > volser/vos-man..ok
> > volser/vos..FAILED 5
> > bucoord/backup-man..ok
> > kauth/kas-man...ok
> > 
> > Failed Set Fail/Total (%) Skip Stat  Failing Tests
> > -- --    
> > 
> > volser/vos1/6 17%00  5

Unfortunately the upstream build system does not capture verbose
test output for display in case of failure, but from the test number
we can deduce that what is failing is that an outputted list of
addresses does not match the expected string:
char expecting[] = "10.0.0.0\n10.0.0.1\n10.0.0.2\n10.0.0.3\n10.0.0.4\n"
   "10.0.0.5\n10.0.0.6\n10.0.0.7\n10.0.0.8\n10.0.0.9\n"
   "10.0.0.10\n10.0.0.11\n10.0.0.12\n10.0.0.13\n"
   "10.0.0.14\n10.0.0.15\n";

I note that this test is disabled when the system's hostname
resolves to a loopback address because those addresses are forbidden
from being entered into the database as fileserver addresses, but
even when I change my local configuration to avoid that, I still
cannot reproduce the test failure locally.

I surmise that the AWS machine may be getting assigned a 10/8
address as its primary address, and perhaps that would interfere
with some of what the test is doing.  Do you happen to know more
about the network configuration on the AWS systems used for these
autopkgtests?

Thanks,

Ben

Bug#887857: jessie-pu: package openafs/1.6.9-2+deb8u6

[Benjamin Kaduk]

On Sun, Feb 18, 2018 at 08:18:48PM +, Adam D. Barratt wrote:
> Control: tags -1 + pending
> 
> Uploaded and flagged for acceptance.

Thanks!

> On a side note, the diff as uploaded reverts a couple of bug closures
> from the previous security upload:
> 
>  openafs (1.6.9-2+deb8u6) jessie-security; urgency=high
>  
> -  * CVE-2017-17432: remote triggered Rx assertion failure (Closes: #883602)
> +  * CVE-2017-17432: remote triggered Rx assertion failure
>    * CVE-2016-4536: information leakage from OpenAFS clients
>    * CVE-2016-9772: information leakage from directory objects
> -(Closes: #846922)

I've added them back in version control, sorry for the regression.

-Ben

Bug#886799: openafs-modules-dkms: install fails with compile error "implicit declaration of function 'inode_change_ok'"

[Benjamin Kaduk]

On Thu, Jan 25, 2018 at 09:21:48AM -0800, deb...@lewenberg.com wrote:
> 
> The patch you provide works fine with jessie and the 1.6.9 source 
> packages. However, I cannot get it to work with wheezy.
> 
> I compile the openafs source package against wheezy and the compilation 
> completes without error and creates a bunch of  .deb files. But when I 
> try to install the patched openafs-modules-dkms on a 3.2.0-5 wheezy 
> kernel I get the same error as before:
> 
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:
>  
> In function 'osi_UFSTruncate':
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:195:5:
>  
> error: implicit declaration of function 'inode_change_ok' 
> [-Werror=implicit-function-declaration]
> 
> Has anyone successfully compiled and installed 1.6.9 on a 3.2.0-5 wheezy 
> machine?

I have one running, yes.  I put my progress so far into the
soon-to-be-non-canonical packaging repo at
https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/log/?id=refs/heads/wheezy
and asked on debian-lts about the procedure for getting it into
wheezy, since this is not technically a security update
(https://lists.debian.org/debian-lts/2018/01/msg00079.html).

How are you building your packages that are failing to build a DKMS
module?

-Ben

Bug#886799: fixing openafs kernel module for security updated kernel

[Benjamin Kaduk]

The SRU request for jessie is in #887857.

I don't think there is a way to get a fix into jessie-backports, so
I think we will need to remove openafs-modules-source and
openafs-modules-dkms from jessie-backports and pull the version from
buster into jessie-backports-sloppy (which will be a trip through
NEW and require a DD sponsor, since I'm only a DM).

I'm still looking at wheezy.

-Ben

Bug#887857: jessie-pu: package openafs/1.6.9-2+deb8u6

[Benjamin Kaduk]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

The recent kernel update in jessie-security with meltdown/spectre remediation
measures introduced some minor ABI changes that cause the version of the openafs
kernel module in jessie to be unable to compile.  More recent upstream versions
of openafs do compile against this kernel, so I need to backport the appropriate
build fixes in order to make openafs-modules-source and openafs-modules-dkms
usable in jessie again.  (The version in jessie-backports is also broken,
not that that is directly relevant here.)

I attach a debdiff with the needed patches, and I have tested the resulting
package in a jessie VM with the latest kernel from jessie-security.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru openafs-1.6.9/debian/changelog openafs-1.6.9/debian/changelog
--- openafs-1.6.9/debian/changelog  2017-12-08 20:59:25.0 -0600
+++ openafs-1.6.9/debian/changelog  2018-01-20 11:48:09.0 -0600
@@ -1,3 +1,11 @@
+openafs (1.6.9-2+deb8u7) jessie-proposed-updates; urgency=high
+
+  * Apply upstream patches needed to fix kernel module build against
+linux 3.16.51-3+deb8u1 kernels after security update-induced ABI changes.
+(Closes: #886719)
+
+ -- Benjamin Kaduk <ka...@mit.edu>  Sat, 20 Jan 2018 11:48:09 -0600
+
 openafs (1.6.9-2+deb8u6) jessie-security; urgency=high
 
   * CVE-2017-17432: remote triggered Rx assertion failure
diff -Nru 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
--- 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
   1969-12-31 18:00:00.0 -0600
+++ 
openafs-1.6.9/debian/patches/0023-Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
   2018-01-20 11:46:01.0 -0600
@@ -0,0 +1,57 @@
+From: Mark Vitale <mvit...@sinenomine.net>
+Date: Thu, 20 Oct 2016 00:49:37 -0400
+Subject: Linux 4.9: inode_change_ok() becomes setattr_prepare()
+
+Linux commit 31051c85b5e2 "fs: Give dentry to inode_change_ok() instead
+of inode" renames and modifies inode_change_ok(inode, attrs) to
+setattr_prepare(dentry, attrs).
+
+Modify OpenAFS to cope.
+
+Reviewed-on: https://gerrit.openafs.org/12418
+Tested-by: BuildBot <build...@rampaginggeek.com>
+Reviewed-by: Benjamin Kaduk <ka...@mit.edu>
+(cherry picked from commit 8aeb711eeaa5ddac5a74c354091e2d4f7ac0cd63)
+
+Change-Id: I7f08c57b7f61465a1ea1806f52f77bd65084
+Reviewed-on: https://gerrit.openafs.org/12480
+Tested-by: BuildBot <build...@rampaginggeek.com>
+Reviewed-by: Mark Vitale <mvit...@sinenomine.net>
+Reviewed-by: Stephan Wiesand <stephan.wies...@desy.de>
+Tested-by: Stephan Wiesand <stephan.wies...@desy.de>
+(cherry picked from commit 8efca09a5daa3cfc08d0d86e2fb48c9b8d1b270a)
+---
+ acinclude.m4 | 3 +++
+ src/afs/LINUX/osi_file.c | 4 
+ 2 files changed, 7 insertions(+)
+
+diff --git a/acinclude.m4 b/acinclude.m4
+index 80a05b7..e1cdc8c 100644
+--- a/acinclude.m4
 b/acinclude.m4
+@@ -947,6 +947,9 @@ case $AFS_SYSNAME in *_linux* | *_umlinux*)
+AC_CHECK_LINUX_FUNC([set_nlink],
+[#include ],
+[set_nlink(NULL, 1);])
++   AC_CHECK_LINUX_FUNC([setattr_prepare],
++   [#include ],
++   [setattr_prepare(NULL, NULL);])
+AC_CHECK_LINUX_FUNC([sock_create_kern],
+[#include ],
+[sock_create_kern(0, 0, 0, NULL);])
+diff --git a/src/afs/LINUX/osi_file.c b/src/afs/LINUX/osi_file.c
+index b83f736..d6c0fd6 100644
+--- a/src/afs/LINUX/osi_file.c
 b/src/afs/LINUX/osi_file.c
+@@ -184,7 +184,11 @@ osi_UFSTruncate(struct osi_file *afile, afs_int32 asize)
+ newattrs.ia_ctime = CURRENT_TIME;
+ 
+ /* avoid notify_change() since it wants to update dentry->d_parent */
++#ifdef HAVE_LINUX_SETATTR_PREPARE
++code = setattr_prepare(file_dentry(afile->filp), );
++#else
+ code = inode_change_ok(inode, );
++#endif
+ if (!code)
+   code = afs_inode_setattr(afile, );
+ if (!code)
diff -Nru 
openafs-1.6.9/debian/patches/0024-LINUX-Debian-Ubuntu-build-regression-on-kernel-3.16..patch
 
openafs-1.6.9/debian/patches/0024-LINUX-Debian-Ubuntu-build-regression-on-kernel-3.16..patch
--- 
openafs-1.6.9/debian/

Bug#887663: [openafs] [INTL:de] Updated German translation for debconf

[Benjamin Kaduk]

Hi Erik

On Fri, Jan 19, 2018 at 08:46:11PM +0100, Pfannenstein Erik wrote:
> Hi Ben,
> 
> thanks for pointing this out, but I can't find any changes between the 
> revision I attached to my report and 1.8.0-pre4 (apart from the ones I made).

Oh, sorry for making you do the extra work, but thanks for
double-checking.

> I guess we can stick to it.

Sounds good.

-Ben


signature.asc
Description: PGP signature

Bug#887663: [openafs] [INTL:de] Updated German translation for debconf

[Benjamin Kaduk]

On Thu, Jan 18, 2018 at 10:24:40PM +0100, Pfannenstein Erik wrote:
> Package: openafs
> Version: 1.6.21-3

Thanks for the update.  We did recently take a big update, to
1.8.0~pre4-1, if you have a chance to look at the changes it
introduced.

-Ben


signature.asc
Description: PGP signature

Bug#886768: Processed: Looks pretty RC to me

[Benjamin Kaduk]

On Sun, Jan 14, 2018 at 06:45:08PM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > severity 886768 serious

Could you say a bit more about why you feel that all binary packages
from src:openafs should be subject to autoremoval when only the
functionality of openafs-modules-dkms and openafs-modules-source is
affected?

Thanks,

Ben

Bug#887018: fails to compile against linux 3.16+63+deb8u1

[Benjamin Kaduk]

reassign 887018 src:openafs
severity 887018 important
merge 886719 887018
retitle 886719 meltdown/spectre kernel (old)stable-security kernel breaks 
openafs module
thanks

On Fri, Jan 12, 2018 at 09:29:52AM -0600, Chad Seys wrote:
> Package: openafs-modules-dkms
> Version: 1.6.18.2-1~bpo8+1
> Severity: grave
> 
> Hello,
>   With linux version 3.16+63+deb8u1 openafs-modules-dkms fails to compile.
>   Attached is the make.log from the build attempt.

Hi Chad,

Yes, the meltdown/spectre kernel patch broke the kernel API and
openafs will need to pull in the needed patch from a later upstream
version than is avilable in (old)stable.  This has already been
noted several times, but a proper fix will take some time, as it
must go through the stable release update process, get preapproval,
etc.  It might be easier to use the package from buster as an
interim workaround.

-Ben

Bug#886799: fixing openafs kernel module for security updated kernel

[Benjamin Kaduk]

Hi folks,

Thanks for all the interest and proposed patches.
I just want to note that the openafs fix will need to go through as
a SRU (Stable Release Update), which requires preapproval from the
stable release managers, and will not actually appear in
stable/oldstable until the next point release.  (It will be
available in the relevant proposed-updates pocket before then.)  So,
I would recommend a temporary workaround of a local build or just
using the packages from buster until the SRU is available.

-Ben

Bug#886799: openafs-modules-dkms: install fails with compile error "implicit declaration of function 'inode_change_ok'"

[Benjamin Kaduk]

On Tue, Jan 09, 2018 at 02:40:23PM -0800, Adam Lewenberg wrote:
> Package: openafs-modules-dkms
> Version: 1.6.9-2+deb8u4~bpo70+1
> Severity: important
> 
> After upgrading wheezy kernel to 3.2.0-5-amd64 openafs-modules-dkms could not 
> rebuild 
> OpenAFS kernel module.
> 
> Here is the error message:
> 
>  CC [M]  
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.o
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:
>  In function 'osi_UFSTruncate':
> /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:187:5:
>  error: implicit declaration of function 'inode_change_ok' 
> [-Werror=implicit-function-declaration]

So the security update for meltdown/spectre changed the kernel ABI?
That's kind of unfortunate; usually Ben tries pretty hard to avoid
doing so.

I don't have much of a jessie environment floating around, so it
will probably be a bit before I can track down exactly which patches
to pull in from upstream to address this.  It also looks like an
updated version in -backports is unlikely to help; would you be
interested in a -backports-sloppy as a faster interim option?

Thanks for the report.

-Ben

Bug#886696: openafs: FTBFS on alpha: rx/event #8 and rx/perf #3 failed

[Benjamin Kaduk]

Hi Aaron,

On Mon, Jan 08, 2018 at 08:14:11PM -0500, Aaron M. Ucko wrote:
> Source: openafs
> Version: 1.8.0~pre4-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> User: debian-al...@lists.debian.org
> Usertags: alpha
> 
> Hi, Ben (and whoever else maintains openafs in Debian these days).
> 
> As you may have noticed, the latest build of openafs for alpha
> (admittedly not a release architecture) encountered two test suite
> failures:
> 
>   Failed Set Fail/Total (%) Skip Stat  Failing Tests
>   -- --    
> 
>   rx/event  1/8 12%00  8
>   rx/perf   1/4 25%01  3
>   
>   Failed 2/704 tests, 99.72% okay, 1 test skipped.
>   Files=23,  Tests=704,  109.00 seconds (3.61 usr + 2.26 sys = 5.87 CPU)
>   Makefile:24: recipe for target 'check' failed
> 
> I don't have additional details, but perhaps you can reproduce the
> problem on a porter box.
> 
> Could you please take a look?

Somehow I thought that porterbox access was annoying to get for a
non-DD DM (such as myself).

The rx event subsystem got a lot of attention before 1.8.0pre3 (and
was failing tests on some release architectures previously), but we
thought it was supposed to be in good shape; it's surprising to see
that there is still a test failure.  (I have no idea about the
rx/perf issue.)

I supsect it will be hard to make progress on this without the
involvement of someone with porterbox (or other box) access...

-Ben

Bug#884550: [Pkg-xfce-devel] Bug#884550: regression(?) in greeter-hide-users=true behavior

[Benjamin Kaduk]

On Sun, Dec 17, 2017 at 04:28:36PM +0100, Yves-Alexis Perez wrote:
> On Sat, 2017-12-16 at 09:40 -0600, Benjamin Kaduk wrote:
> > After my latest upgrade/reboot, the behavior of lightdm has changed.
> > Previously, on fresh boot and lock screen I would be
> > presented with a username/password entry dialog with empty username,
> > empty password, and focus on username.  The new behavior has
> > username pre-populated and focus on password.  (Is this more likely
> > to be lightdm-gtk-greeter or lightdm itself?)
> 
> Yes, lightdm-gtk-greeter changed behavior with 2.0.3: it pre-fills the
> username when the screen is locked with the current logged-in user (not sure
> of the behavior when multiple users are locked).

Doing this for locked screen seems pretty defensible; I don't log
out or boot up cleanly enough to notice the behavior for
non-lock-screen cases.

> > My understanding is that greeter-hide-users=true is intended to not
> > give any indication of the valid users on the machine, whether
> > currently/previously logged in or not.  (If I am in error here,
> > please accept my apologies and close the report.)  I think I am
> > using an unmodified stock debian config,
> 
> Not sure about upstream stance on this, but I configured the Debian default to
> be a bit privacy-conscious and not expose every username just by booting the
> system. I'm not overly concerned with the lock screen (afair xscreensaver did
> the same thing before we switched to light-locker), but if it's a concern to
> you I can propagate this to upstream.

I think my main concern is just knowing with some confidence that I
should retrain my muscle memory/expectations; I don't think there's
a need to forward the issue to upstream just on my behalf.

Thanks for the explanation,

Ben

Bug#884550: regression(?) in greeter-hide-users=true behavior

[Benjamin Kaduk]

Package: lightdm-gtk-greeter
Version: 2.0.3-1

After my latest upgrade/reboot, the behavior of lightdm has changed.
Previously, on fresh boot and lock screen I would be
presented with a username/password entry dialog with empty username,
empty password, and focus on username.  The new behavior has
username pre-populated and focus on password.  (Is this more likely
to be lightdm-gtk-greeter or lightdm itself?)

My understanding is that greeter-hide-users=true is intended to not
give any indication of the valid users on the machine, whether
currently/previously logged in or not.  (If I am in error here,
please accept my apologies and close the report.)  I think I am
using an unmodified stock debian config,

root@prolepsis:~# lightdm --show-config
   [Seat:*]
   A  greeter-session=lightdm-greeter
   A  greeter-hide-users=true
   A  session-wrapper=/etc/X11/Xsession

   Sources:
   A  /usr/share/lightdm/lightdm.conf.d/01_debian.conf
   B  /etc/lightdm/lightdm.conf


My latest upgrade went from 2.0.2-1 to 2.0.3-1, but the previous
upgrade cycle did not involve a reboot, if that would have been
necessary to get the 2.0.2-1 version running.

Thanks,

Ben

Bug#884420: openafs: kernel NULL pointer dereference under Linux 4.14

[Benjamin Kaduk]

On Thu, Dec 14, 2017 at 08:38:49PM -0500, Aaron M. Ucko wrote:
> Source: openafs
> Version: 1.6.22-2
> Severity: important
> Tags: upstream
> 
> Thanks for looking into #884276.  The module now builds successfully,
> but encounters an Oops on load, as detailed below.  The issue appears
> to be that 0005-afs-fix-kernel_write-kernel_read-arguments.patch adds
> a conditional definition of KERNEL_READ_OFFSET_IS_LAST but then
> consults LINUX_KERNEL_READ_OFFSET_IS_LAST (with a leading LINUX_),
> which is never defined.  Indeed, configure reports
> 
>   checking whether offset is the last argument to kernel_read... yes

Thanks for the report and diagnosis; I've submitted
https://gerrit.openafs.org/12808 at upstream for this issues and
should have a new version uploaded soon.
Sorry for introducing the bug; I guess I didn't actually test on as
new of a kernel as I thought I did.

-Ben

Bug#884276: openafs-modules-dkms: module FTBFS

[Benjamin Kaduk]

tags 884276 pending upstream fixed-upstream
thanks

Hi Andreas,

Upstream has a fix queued, but it got bumped by last week's security
release (1.6.22) and the release containing it is not out yet.
But it's easy enough to pull the patches in locally until that
happens.

Thanks,

Ben

Bug#883916: openafs: [INTL:ru] Updated Russian translation of debconf template

[Benjamin Kaduk]

tags 883916 pending
thanks

Hi Lev,

On Sat, Dec 09, 2017 at 03:25:12PM +0500, Lev Lamberov wrote:
> 
> Dear Maintainer,
> 
> please find attached the updated Russian debconf translation for openafs.

Thanks!  I've put it into our version control so it should appear in
the next upload.

-Ben

Bug#883602: OPENAFS-SA-2017-001: Rx assertion failure from insufficient input validation

[Benjamin Kaduk]

Source: openafs
Version: 1.6.1-3+deb7u7
Tags: security upstream fixed-upstream pending
Severity: important

Upstream OpenAFS released security advisory OPENAFS-SA-2017-001
today; insufficient validation of data contained in Rx ack packets
leads to the use of an invalid MTU value, ultimately leading to an
assertion failure and application crash or kernel BUG.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Benjamin Kaduk]

On Sun, Nov 19, 2017 at 07:07:45PM -0500, Sam Hartman wrote:
> 
> Why do you want to replace krb5-config with pkg-config?
> That seems like a good option if we can sell upstream on the idea, but
> something requiring more thought otherwise.

I believe we can consider upstream sold.

pkg-config is the de facto standard for how to do this sort of
thing, and there is no need for krb5 to be its own special snowflake
anymore.  pkg-config also gives more reasonable behavior with
private libraries and static linking, if I remember correctly.

-Ben

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Benjamin Kaduk]

On Mon, Nov 13, 2017 at 10:51:10AM -0800, Russ Allbery wrote:
> 
> I'm not sure how best to fix this other than no longer using krb5-config
> and shipping a pkgconfig script or something.  One could move the
> krb5-config script into an architecture-specific directory, but that just
> moves the problem to a different area (how to find the right krb5-config
> script to use).

Upstream started shipping a pkgconfig script a couple releases ago.
I forget whether we do and/or need to patch it to match our configuration.

-Ben

Bug#871698: upstream patch

[Benjamin Kaduk]

On Sun, Oct 29, 2017 at 01:02:56PM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> On Fri, Oct 27, 2017 at 08:25:04PM -0500, Benjamin Kaduk wrote:
> > I think upstream actually did the backport earlier today, already.
> 
> I retitled the bug (Red Hat has assigned a CVE for the issue
> (https://bugzilla.redhat.com/show_bug.cgi?id=1504045) (and added tag
> security).

Red Hat uses this code in their KDC, but for upstream and Debian it's
only used in the kinit(1) client, with a user-specified input certificate,
so upstream (and I) believe that no CVE is needed for our usage.

-Ben

Bug#871698: upstream patch

[Benjamin Kaduk]

I think upstream actually did the backport earlier today, already.

-Ben

Bug#871698: upstream patch

[Benjamin Kaduk]

tags 871698 upstream pending
thanks

Upstream has committed a patch to use dynamic allocation to master at
https://github.com/krb5/krb5/pull/707 .
The backport is not entirely trivial, but we should be able to get
a version in (whether our own or upstream's) fairly soon.

-Ben

Bug#859297: upstream pull request for openssl1.1 in node

[Benjamin Kaduk]

Just noting that David Benjamin has put together a pull request for upstream
at https://github.com/nodejs/node/pull/16130 .

-Ben

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

[Benjamin Kaduk]

I am inclined to just put it in unstable and not backport, but
created the bug to see if the security team felt otherwise.

If you look at the pull request history for the upstream commit,
it seems that it was languishing there for a while before getting
merged, as well.

-Ben

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

[Benjamin Kaduk]

Package: libgssapi-krb5-2
Version: 1.15-1
Tags: security

Upstream has committed a change that causes libgssapi-krb5 to not
automatically free a security context when an error is encountered on
the second or subsequent call to gss_init_sec_context() or
gss_accept_sec_context(), as this is frequently unexpected by
application code and could lead to a double-free situation.

Bug#868121: libgssapi-krb5-2: obsolete conffile left behind

[Benjamin Kaduk]

On Mon, Jul 17, 2017 at 04:35:24PM +1000, Paul Wise wrote:
> 
> Sounds like a file that should not have been placed in /etc and
> should be removed from /etc during upgrades.

Some further discussion about the role of this file is in #861218
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861218#15 in particular).
Though, I haven't thought/researched much about how policy applies
in this particular case.

-Ben


signature.asc
Description: PGP signature

Bug#868121: libgssapi-krb5-2: obsolete conffile left behind

[Benjamin Kaduk]

On Sun, Jul 16, 2017 at 12:53:18PM +1000, Paul Wise wrote:
> On Wed, 12 Jul 2017 04:53:35 -0400 Sam Hartman wrote:
> 
> > I'm not actually sure I particularly want it removed from the system.
> 
> Policy indicates that old conffiles should be removed on upgrade:

It's not really clear that this file constitutes either a conffile
or a configuration file -- it contains information that is globally
true (not site- or host-specific), does not affect the operation of
a program, and is not intended to be modified by the system administrator.

-Ben


signature.asc
Description: PGP signature

Bug#865962: openafs-fileserver: Periodic restarts configured in BosConfig causes bosserver to be shut down

[Benjamin Kaduk]

On Mon, Jun 26, 2017 at 12:08:29PM -0500, Benjamin Kaduk wrote:
> 
> This does seem likely to be an issue with the systemd integration, yes.
> (Not using the weekly restarts, I didn't observe it in testing.)
> 
> Thanks for the report; I'll take a look.

It seems that any ReBozo action (re-exec bosserver) will cause systemd
to think that bosserver has successfully exited, since the re-exec will
call daemon() again, and the parent process will then exit(0).  systemd
(as configured by openafs-fileserver.service) does not follow the fork,
and does not know to track the new child.  It thus thinks that the
service has stopped cleanly.

openafs-fileserver.service has an ExecStop that runs bos shutdown,
so systemd *does* run that, which terminates cleanly the new child
bosserver (and the managed services).

It seems likely that the cleanest solution will be to convert
the unit file to use the -nofork argument to bosserver.

-Ben

Bug#865962: openafs-fileserver: Periodic restarts configured in BosConfig causes bosserver to be shut down

[Benjamin Kaduk]

On Mon, Jun 26, 2017 at 09:26:01AM +0200, Arne Nordmark wrote:
> Package: openafs-fileserver
> Version: 1.6.20-2
> Severity: normal
> 
> Dear Maintainer,
> 
> This Sunday morning, the bosserver process on all stretch machines was found 
> to have stopped.
> 
[snip]
> 
> The reason why a restarttime entry is present is lost in the mists of time, 
> but might well have been a default setting once.

It was the default for a long time, yes.

> Using the bos command to restart bosserver manually gives the same result:
> 
> # bos restart -server localhost -bosserver -localauth
> 
> causes bosserver to shut down, again with the same log entry.
> 
> This is definitely a regression compared to jessie.
> As I interpret the log entry, a signal 15 is sent from the outside.
> The most obvious difference (compared to jessie) is the presence of a systemd 
> unit file in the stretch version.
> Is systemd process control clashing with how bos tries to restart itself?

This does seem likely to be an issue with the systemd integration, yes.
(Not using the weekly restarts, I didn't observe it in testing.)

Thanks for the report; I'll take a look.

-Ben

Bug#863260: kstart: k5start does not recognize network changes

[Benjamin Kaduk]

On Wed, May 24, 2017 at 11:44:12AM -0700, Russ Allbery wrote:
> 
> Kai Wohlfahrt  writes:
> 
> > Package: kstart
> > Version: 4.2-1
> > Severity: important
> > Tags: upstream
> 
> > Dear Maintainer,
> 
> > The k5start program repeats attempts to contact the KDC server if it is
> > unavailable. However, it continues to fail if a new network is
> > available.
> 
> > Steps to reproduce:
> > - Disable network interface
> > - Run k5start (e.g. k5start -f /etc/krb5.keytab -K 10 -u host/jason -k 
> > test.tkt)
> > - Enable network interface
> 
> > I expect to see the error below repeated until the network comes back
> > up, and then it should stop:
> 
> > k5start: error getting credentials: Cannot contact any KDC for realm 
> > 'MY.REALM.NAME'
> 
> > Instead, I continue to get errors until I stop the k5start
> > process. Starting it again after the network is available shows no
> > errors and gets the ticket correctly.
> 
> k5start just calls krb5_get_init_creds_*, so if something is being
> inappropriately cached, this would be a bug in the underlying Kerberos
> library (rather than in kstart).  Reassigning accordingly.

I could not reproduce this behavior using any of 'ifconfig 
down', adding loopback routes to all configured KDCs, or modifying
the profile (KRB5_CONFIG pointing to a custom path) to use
inaccessible KDC addresses as a way of making the KDC inaccessible.
The 'ifconfig  down' method requires manual intervention to
restore a default route after bringing the interface back up,
though.

(Code inspection also did not find a place where such caching would
occur, though of course there are probably some places I didn't
look.)

Kai, can you confirm that you can reproduce and that have proper
network connectivity (DNS resolution, ping, etc.) during the case
where k5start continues to be unable to contact any KDCs?

Also, is krb5.conf or DNS being used to locate KDCs (not that this
appears to matter).

-Ben

Bug#861651: krb5-kdc: Samba moving to MIT, needs version 1.15.1

[Benjamin Kaduk]

On Tue, May 02, 2017 at 10:12:35AM +0100, Rowland Penny wrote:
> 
> Samba is moving to MIT kerberos instead of Heimdal. Unless the version of MIT 
> is raised to 1.15.1, it will become impossible to create an AD DC on Debian 
> when Samba 5.0.0 is released and that may be sooner than you think. 
> All the major work to use MIT has been done, so the next Samba release is 
> likely to be version 5.0.0

We expect to have krb5 1.15.1 in sid shortly after stretch releases;
it did not seem worth taking immediately upon the krb5 release given
the potential for headaches if updates are needed for stretch prior
to stretch's release.

-Ben

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

[Benjamin Kaduk]

It seems like an /etc/gss/mech.d/README-- (or similar)
would alleviate the technical problems with having a single file
named README, and would be glob-able for consuming software that is
adapted to know about a broader convention.  It would, of course, be
slightly confusing to users even if there is only one file with such
a naming scheme, let alone two with identical contents.

Would such a scheme be preferable to removing the README entirely
for buster?

-Ben

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

[Benjamin Kaduk]

Hi Helmut,

On Wed, Apr 26, 2017 at 06:52:58AM +0200, Helmut Grohne wrote:
> Package: libgssapi-krb5-2
> Version: 1.15-1
> Severity: serious
> Justification: violates policy section 8.2
> 
> libgssapi-krb5-2 is a shared library package and contains
> /etc/gss/mech.d/README. The latter filename does not depend on the
> soname of the library and thus does not change when the soname changes.
> Thus the package will not be coinstallable a newer soname of the same
> library and make system upgrades unnecessarily difficult. This violates
> the first sentence from policy section 8.2, which is a must:
> 
> | If your package contains files whose names do not change with each
> | change in the library shared object version, you must not put them in
> | the shared library package.
> 
> This actually causes problems today, due to a related bug in dpkg, which
> does not properly support conffiles in m-a:same packages (#861217).

Thanks for the report, and sorry that it is causing problems.
I think we will need to discuss the best option given that stretch
is frozen and there is at least one other bug that would be nice to
fix for stretch outstanding (#860767, currently fixed in
experimental).

-Ben

Bug#859243: please include tmpfiles.d snippet for OTP rundir

[Benjamin Kaduk]

On Sat, Apr 01, 2017 at 02:30:22AM +0300, Timo Aaltonen wrote:
> Package: krb5-otp
> Severity: wishlist
> 
> Hi,
> 
> Freeipa server includes a socket-activated daemon for OTP, and it
> listens to {/var}/run/krb5kdc/DEFAULT.socket. But /run/krb5kdc is not
> available, so AIUI it should be created by adding a tmpfile to krb5-otp
> like on Fedora:
> 
> debian/krb5-otp.tmpfile:
> d /var/run/krb5kdc 0755 root root

Happy to do this, though I expect it will wait until after the
stretch freeze.

-Ben

Bug#855366: possible patch for #855366, needs expert review

[Benjamin Kaduk]

On Fri, Feb 17, 2017 at 11:21:49AM +0100, Sergio Gelato wrote:
> I'm testing the attached patch. So far it seems to work, although it should
> really be reviewed by someone more familiar with kernel development history.
> 
> (I looked at the implementation of file_dentry() in 4.6 and simplified
> it to account for the lack of d_real() support in older kernels. My main
> worry is that I may be missing some corner cases that apply to older
> kernels but were no longer of concern by the time file_dentry() was added.)

Sorry for the delay -- it's been a pretty crazy week.

Thanks for pulling this together; at first glance it seems
reasonable, so I'll go ahead and submit it to upstream's gerrit
instance on your behalf.  (It can get some more review there, then
get merged to master and pulled back onto the 1.6 branch, though
we'll probably pick it into Debian earlier, of course.)

-Ben

Bug#760099: apt-listchanges: Incorrectly assumes that binary packages from the same source share NEWS files

[Benjamin Kaduk]

This bug report has been quiet for some time; does that imply that the
status quo is that I should assume that de facto I can only use the
toplevel NEWS.Debian and not binary-package-specific NEWS files?

I ask because openafs is putting out a new major release (currently
in experimental) and the source package produces both client and
server packages; server administrators must take a step on upgrade
that clients don't care about, so I wanted to only display the NEWS
for servers.  Unfortunately, servers tend to also have the client
installed for administration, and I have a report that upgrading
all the packages together fails to display the server NEWS entry.

Thanks,

Ben