Bug#1065702: krb5-kdc: uninstallable due to hard-coded dependency on libverto-libev1 | libverto-libevent1,

[Sam Hartman]

> "Steve" == Steve Langasek  writes:


Steve> Hi Sam,

Steve> I've run into a problem with openldap not being
Steve> bootstrappable for the time_t transition because it
Steve> build-depends on krb5-kdc, and krb5-kdc is uninstallable on
Steve> arm* because of a hard-coded dependency on libverto-libev1 |
Steve> libverto-libevent1.  Both of these library packages have
Steve> changed names so are now libverto-libev1t64 and
Steve> libverto-libevent1t64.  I don't know why these need to be
Steve> hard-coded, but if they do they need to be updated, because
Steve> they conflict with the shlibdeps-generated dependency on
Steve> libverto1t64.

So, libverto1t64 is just a plugin framework.  It does not actually
contain a binding to an event loop.
If you don't have one of the concrete implementations installed, nothing
works.
Originally I uploaded libverto1t64 with a dependency on the libev
implementation.  That created a circular dependency and people asked if
I could move the dependency to krb5-kdc so I did.

Will upload fixed krb5 sometime this weekend.

--Sam

Bug#1065017: unuser: error while loading shared libraries: libpam.so.0

[Sam Hartman]

> "Christoph" == Christoph Anton Mitterer  writes:
Christoph> Do you happen to know whether there's anything needed in
Christoph> terms of clean up for people who had already upgraded
Christoph> now? Like manually doing whatever was done via the
Christoph> runuser?

I think that so long as libpam0g 1.5.3-5 installs cleanly, it will be
fine.
I think that the runuser is from debian-security-support and is run on
every upgrade, so you should be good there.

I tried to make the revert work either if you didn't have libpam0t64 at
all or if you did, but we're more focused on people who never upgraded.

If you do run into breakage, we'll work with you to find a solution.

--Sam

Bug#1065088: pam 1.5.3-5 not suitable because pam_userdb is missing

[Sam Hartman]

package: pam
version: 1.5.3-5
severity: serious

This version of pam drops pam_userdb which can break systems that use
pam_userdb in their configuration.  Long term we do want to split it out
and possibly drop.  However, this change is purely for the time_t
transition and will be reverted.

This version of pam is not suitable for testing.

Bug#1065017: unuser: error while loading shared libraries: libpam.so.0

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> I believe pam will have to be reverted and implemented as
Helmut> dual ABI instead.

I'm not very comfortable with this approach.
The tentative patch did not fill me with confidence; my gut is that it
was not as robust as an approach that libraries like libc6  took, and
unfortunately I do not have enough experience with the internals of
libc6 and various multi-ABI approaches across the years to have
confidence either way.
I could use some help from someone who has approached this sort of issue
and deployed changes like this in production.

Steve and I agreed to revert the rename  on IRC, effectively accepting
the ABI break because it doesn't matter for the archive.
We may look at better solutions when we have a bit of time.

--Sam


signature.asc
Description: PGP signature

Bug#1065011: libpam0t64 competes for libpam.so.0 symlink against libpam0g (breaks debootstrap)

[Sam Hartman]

I wanted to briefly summarize an irc conversation we had on
#debian-devel for anyone reading this bug.

In general, we want to get rid of libpam0g as soon as possible, because
you cannot have both libpam0g and libpam0t64 installed at the same time.
Steve is working on a series of NMUs to make that possible on arches
where  the ABI has actually changed.
On arches where the ABI is the same, libpam0t64 provides libpam0g, so we
can get rid of libpam0g today.

--Sam

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

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> It might be relevant that according to #972151, arm-conova-03
Simon> (and perhaps other *-conova-* buildds?) is IPv6-only, with no
Simon> IPv4 addresses or routes other than loopback (not even via
Simon> NAT).

Simon> I believe there is consensus that we consider "localhost
Simon> resolves to 127.0.0.1" to be a reasonable thing to demand
Simon> from all buildds as part of the build-essential interface.

Simon> I am unsure whether there is consensus that "the result of
Simon> gethostname() resolves to some address of the local machine"
Simon> is also a reasonable thing to demand from all buildds as part
Simon> of build-essential: /etc/hosts typically makes this true, but
Simon> is not *guaranteed* to do so. On Linux, packages can ensure
Simon> that it happens by build-depending on libnss-myhostname
Simon> [linux-any], if necessary.

Simon> However, even with both of those, if the krb5 test suite (or
Simon> protocol) is resolving the local hostname with AF_INET
Simon> (IPv4-only), and with either AI_ADDRCONFIG or NULL hints,
Simon> then that will not yield any results on an IPv6-only system
Simon> for the reasons discussed in #952740 and related bug reports.

Krb5 is very v6-happy.
So, you're suggesting that I fix this by build-depending on
libnss-myhostname [linux-any] assuming tests are enabled?
If so, that's easy.
(I don't remember the order of build profiles and architecture
specifications in a build depends but can go look that up.

Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> pam seems difficult: | extern time_t
Helmut> pam_misc_conv_warn_time; /* time that we should warn user */
Helmut> | extern time_t pam_misc_conv_die_time; /* cut-off time for
Helmut> input */

Helmut> We cannot symbol-version these in a reasonable way. All we
Helmut> could do is ask upstream for a real soname bump. We have a
Helmut> slight advantage here: On little endian (such as armhf), we
Helmut> can extend this to 64bit and 32bit accesses will continue to
Helmut> work for small values. However, doing this to m68k would
Helmut> break horribly. I also couldn't find any in-Debian users of
Helmut> these symbols (super merely vendors pam source), so just
Helmut> bumping it and accepting breakage (Guillems option 1) might
Helmut> be worth a go?

Steve and I are unaware of usage in Debian either.

--Sam


signature.asc
Description: PGP signature

Bug#1062802: libpam0t64: file loss during upgrade due to /usr-move DEP17

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> pam also runs in to /usr-move breakage. This one looks


FYI, I have some time scheduled to deal with this tomorrow morning
US/Mountain (late in the day for Europe).

Bug#1054228: pam FTBFS: No series file found

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> pam fails to build from source in unstable, because quilt no
Helmut> longer recognizes the QUILT_PATCHES_DIR variable and
Helmut> therefore does not find a series file. Renaming it to
Helmut> QUILT_PATCHES fixes the build.

I applied your patch, and it broke everything.  Shame on me for not
testing, but I think your analysis is wrong.  As far as I can tell
dh_quilt_patch sets QUILT_PATCHES from QUILT_PATCH_DIR, which is what
pam's debian/rules sets.

In particular, your patch causes dh_quilt_patch to think there are no
patches and to apply no patches.

All this mess will go away with the PAM 1.5.3 packaging: I'm moving to a
normal debian/patches and dpkg will handle things.

Can I get you to look at this in more depth and help me understand

1) Whether the buildhs in unstable are really broken (I think they are
not)

2) What was broken about your builds that caused you to raise the issue.


signature.asc
Description: PGP signature

Bug#1052863: krb5: FTBFS: dh_auto_test: error: cd build && make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

[Sam Hartman]

control: severity -1 normal
> "Lucas" == Lucas Nussbaum  writes:

Lucas> Hi,

Lucas> During a rebuild of all packages in sid, your package failed
Lucas> to build on amd64.


Lucas> Relevant part (hopefully):


So, according to the build log, the make check failed because it could
not contact a KDC on the local system.  The krb5 build is more sensitive
to the environment on which it is built thanks to 1017763.  In
particular, I believe it will require that getaddrinfo(gethostname())
work, an that address is a valid address for contacting the local host.
It will also require that a service can bind to that address and be
contacted from within the build.  In addition, it requires various
capabilities related to access to the keyring; I find that debspawn's
containers do not have sufficient capabilities to run make check.

It appears all these attributes are satisfied by the build hosts.
So, unless I'm violating some written policy somewhere, my claim is that
this is all good.
That said, I realize this is an area where things are underspecified,
and I'd be happy to engage with debian-policy or the TC to  further
refine what builds are allowed to do if you think that something krb5 is
doing is not reasonable.

I suspect this is a case where your build environment does not mirror
the buildds enough for the tests to succeed, but I'm leaving the bug
open for your input.

--Sam

Bug#1051523: Doxygen changes breaks krb5 documentation build

[Sam Hartman]

> "Tianyu" == Tianyu Chen  writes:


Tianyu> During a local rebuild of krb5, your package failed to
Tianyu> build.

So, I'm guessing this is related to the upgrade in Debian from doxygen
1.9.4 to 1.9.8.

The krb5 build process uses doxygen to generate an xml representation of
the documentation from a bunch of C header files.  Then it uses a pile
of python scripts which haven't seen much love since the days of python2
to turn that documentation into rst, and then includes it in a sphinx
document.

It expects all the doxygen to be in a file called krb5_8hin.xml.
Unfortunately the new doxygen is breaking up the sources into a bunch of
different files and including  elements to refer to them rather
than  elements including their definition.  And so the python
doesn't find the definitions of the documented functions and the build
fails because not many rst files are generated.

I am hoping for help at this point.
I'll continue to look into it, but I'm not familiar with the innards of
doxygen, nor the xml parser that the krb5 python is using.


signature.asc
Description: PGP signature

Bug#1035494: moonshot-trust-router: fails to purge - command deluser in postrm not found

[Sam Hartman]

> "Andreas" == Andreas Beckmann  writes:
Andreas> The fix should be easy: your package is using adduser or
Andreas> deluser from the adduser package, which is only priority
Andreas> important. Using useradd or userdel from the passwd package
Andreas> (priority required) should fix this problem.
Well, and also essential: yes.

I don't think I want to switch adduser over in the postinst because that
would require thinking too much about the  semantics and I suspect
longterm, moonshot-trust-router wants to use sysusers.
But using userdel sounds reasonable for bookworm.
Thanks for noticing the issue.

Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

control: severity -1 normal

> "Cyril" == Cyril Brulebois  writes:


Cyril> serious & wontfix make for a strange combination…

Yeah, my bad for dropping the ball.
My intent with wontfix was to create a pause and better understand the
issue.
As I understand it,

* On first install, pam_namespace will require an explicit daemon-reload
before it can be started.
However pam_namespace requires explicit administrator configuration

* We don't want pam_namespace to be started automatically, so it's great
that it isn't today

* it's possible that on upgrade or remove it might not be stopped.
That's not a bug today but will be next time the code for the namespace
helper service changes.

None of that sounds RC to me.
Not even important, although I can see an argument either way there and
would be happy to stand aside (or even do the work) if Steve thinks we
should fix this.

I'm very uncomfortable moving files between / and /usr especially in an
essential package.
Between the issues Simon has documented over the years with libraries
and the dpkg aliasing bugs, we've managed to hurt ourselves with this a
number of times.
I *think* this situation is safe.
But when I read the freeze policy, none of the issues mentioned above
justify a change this late in the release process.

I definitely do not think we could undo the  change if we make it until
dpkg fixes the aliasing bug.
The suggestion in Lauren't initial bug report that it would be
appropriate to undo this change after the bookworm release really
frustrated me.
It displayed a complete lack of understanding of the dpkg aliasing
issues,
and I didn't manage to overcome that frustration enough to look at this
issue again until your mail prompted me.
Thanks for that.

If I've mischaracterized the severity of the potential harm above, let
me know.
I don't want a broken pam, but I also consider this kind of move
moderate risk.

--Sam

Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

control: tags -1 wontfix

> "bigon" == bigon   writes:

bigon> It seems that your package libpam-modules-bin is shipping
bigon> files (.service, .socket or .timer) in
bigon> /usr/lib/systemd/system.

I think we're talking about pam_namespace.service.
I don't think dh_installsystemd has anything to do for that file because
it has no Install section.
What harm is caused by pam_namespace.service being in /usr/lib/systemd?


bigon> debhelper?  As soon as debhelper is supporting (not until
bigon> bookworm+1 aka Trixie) you will be able to move them back to
bigon> the newer location.

Um, no doing that before dpkg is fixed to deal with aliasing could
potentially be a really bad idea.

Again, what harm is caused by pam_namespace.service being in
/usr/lib/systemd/system?
How is this a bug?

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Theodore" == Theodore Ts'o  writes:


Theodore> So enabling what may be convenient, but ultimately an
Theodore> anti-pattern is something that hopefully in the long-term
Theodore> Debian should be trying to *avoid*.

That's certainly true.
I am not entirely convinced that using current rather than guest tools
for image building is an anti-pattern.
You've been working on filesystems for a long time; I've been working on
various image building projects since my first watchmaker project at
MIT.

I can understand the arguments about why it's an anti-patern, but I can
also understand why it may be the correct answer.
I'd love to have that discussion with you some time, although preferably
not on a bug like this, and I'm not entirely sure my thoughts are
organized enough for a large mailing list discussion.

I think that discussion is clearly well beyond the scope of what the RT
needs to make an immediate decision here.


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> Below is my attempt to give an overview of the situation,
Adrian> feel free to amend/correct if anything is missing or wrong.


I believe your summary is correct and includes the issues I am aware of.
I believe I am following things enough that I have confidence in that
conclusion.

Thanks much.


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

Replying off list, because I don't think it matters much for the RT
discussion.

> "Russ" == Russ Allbery  writes:
Russ> Yes, I'm probably understating the difficulty of making this
Russ> change in practice inside image building software as it's
Russ> currently constructed.

Russ> My concern about changing mkfs options is that I worry that
Russ> this would be a constantly-changing target that has to be
Russ> synchronized across multiple pieces of software that are not
Russ> currently well-aligned with file system development.

Sadly, supporting a new distribution in image building software is a
constantly changing target that requires small tweaks all the time.


Carthage has a function debian_container_to_vm that uses FAI  to turn a
directory tree into a VM image.
For bookworm, we end up needing to deal with systemd-resolved getting
split.
There was also some change in recent memory related to
apt-transport-https and when it was needed.

It's mostly small stuff, but you end up having a series of tweaks for
the guest system, no matter how much you wish you didn't.

There are similar tweaks at the debootstrap level, at the FAI level, and
even in the container frontends to a small extent.

I absolutely agree mkfs compatibility options would be great, but
chasing down how to call mkfs is par for the course.

I haven't looked much at vmdb2 because I disagree with the design
philosophy, but I think it has tweaks too.

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
>> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
>> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>> > > ...  > > Reasons: > > ...  > > - - the change makes it
>> impossible to create filesystems with this version of > >  
>> e2fsprogs and then run a grub-install from a target system that
>> does not cope > >   with that feature; basically breaking the
>> debootstrap method of installing > >   Debian or Ubuntu onto a
>> server (violating #4 of the Debian social contract) > > ...  > >
>> Instead, turning on this feature should be postponed for the next
>> release cycle > > where a proper transition can be done.  > > ...
>> > 
>> > Daniel, you are contradicting yourself when claiming that a
>> change that > would allegedly violate the Debian social contract
>> could be done in the > next release cycle.
>> 
>> Actually, I'm not.  ...

Adrian> If not being able to install bullseye from bookworm is a
Adrian> violation of the Debian social contract, then the same
Adrian> rationale applies to not being able to install bullseye from
Adrian> trixie being a violation of the Debian social contract.

I don't think that arguing about whether this is a social contract
violation makes a lot of sense.
It seems fairly clear there is not a consensus about that.

But if we're going to do that, I suggest that Adrian is putting words
into Daniel's mouth a bit.
Daniel has said he believes this situation violates the Social Contract
#4, but has not explained why.
Adrian has taken one interpretation.
I'll propose another: "This violates the social contract because we are
not prioritizing our users.  Prioritizing users requires that we give
them notice of incompatible changes."
I personally think that prioritizing users requires no such thing, and
that this change is not a violation of the SC.
But you don't need to take the straw man position Adrian is assuming
Daniel implies to believe this is a SC violation.

But seriously, let's give up the whole is this an SC violation part of
the discussion and move on with constructive aspects:

* The RT has asked to understand the impact of the change.

* Several people have proposed better documentation because it's clear
  that user (and image builder) expectations are not aligned with
  filesystem maintainer expectations.

* Anyone could prepare patches to image building software to use mkfs
  options that will work with bullseye.  You could also try to prepare
  patches to run mkfs out of a chroot or container of the guest OS for
  the image.  I appreciate Russ strongly favors this solution, but as
  someone who has dug into image building tools a fair bit over the
  years, I think there are significant complexity and performance
  downsides to that approach.  I also think that changing the mkfs
  options is more likely to get an unblock than changing the structure
  of how the tool works.
  
  
  
* People could try to judge consensus on debian-devel or debian-policy
  about whether we want a stability guarantee ?+/- 1 release on issues
  like this.  My suspicion is that you will not find a consensus, and
  that if the RT decides they don't want this change in bookworm, Ted
  will change the defaults, and if the RT is unwilling to block, we're
  left with documentation.

I think all the above is more productive than arguing about whether this
is or is not an SC violation.


signature.asc
Description: PGP signature

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Sebastian" == Sebastian Ramacher  writes:

Sebastian> To better understand the impact of this change, I was
Sebastian> wondering which tools / image builders in the archive
Sebastian> would be affected by this change.  I've cloned the bug to
Sebastian> vmdb2, but what about others?

It will affect fai-diskimage in the fai package..
I believe that's used by the cloud team (or was) to create cloud images;
I don't know if their use case is affected, because I don't know what OS
they use to create what images.

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

>>>>> "Theodore" == Theodore Ts'o  writes:

Theodore> On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>> 
>> I.E. I think your question of "for how long" has a very simple
>> answer based on our history: if we care about stability in this
>> instance it's for +/-1 Debian release.
>> 
>> I'm struggling trying to figure out whether we should commit to
>> that stability.

Theodore> I recogniuze that there are precedents that go in both
Theodore> directions.  We have *never* required that shared library
Theodore> linkages created in Debian N work in Debian N-1.  Sure,
Theodore> there are workarounds that you can use (e.g., compiling
Theodore> with -static), but I've listed workarounds for mke2fs as
Theodore> well.

For what it's worth, I don't think the shared library situation is at
all analogous.
We've basically decided that we care about shared libraries as they
interact with packages, and we've invented a whole bunch of dependency
logic to deal with them.
Which is to say we've explicitly turned shared libraries into a special
case.

You argue about shared libraries for non-packaged binaries.
I think we mostly don't care about that, and again, I think that's at
least a generally recognized thing that came out of our focus on
packages and package dependencies.

Which is to say that I think shared libraries are such a special case in
Debian you cannot use them to argue for or against anything else.

You make some good arguments based on other things.  I just don't want
us using shared library handling as a precedent for anything other than
shared libraries, so I am arguing against it.

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Sam Hartman]

> "Theodore" == Theodore Ts'o  writes:
 the answer to your "how long" is that packages
>> should also work with the kernel from the previous and the kernel
>> from the next Debian release.

Theodore> This isn't a problem with the kernel.

I don't think that was Adrian's point.
I think Adrian was making an analogy and suggesting that filesystems
made by bookworm should be usable by bullseye and by the release after
bookworm--usable by the bootloaders etc.
Or at least that would be a reasonable thing to do based on stability
guarantees we've made in other cases.

I.E. I think your question of "for how long" has a very simple answer
based on our history: if we care about stability in this instance it's
for +/-1 Debian release.

I'm struggling trying to figure out whether we should commit to that
stability.
I do find this change after the transition freeze to be kind of late.  I
understand it's not a traditional transition.
But for example you're not leaving a lot of time for asking programs
like vmdb2 or fai-diskimage to adjust how they call fsck.
If you made this change a few months ago, it would be reasonable to file
bugs against those packages and ask them to adjust how they call
mkfs.ext4.

I want to stress that I'm not  affiliated with the release team; my
opinion here has no official weight.
But I would ask you to consider that it is kind of late to make  a
change in the required filesystem features for bookworm and suggest a
more orderly process would be to make the change in the next release and
give packages that need to build vm images a chance to adjust.

I also think it would be reasonable for the project to decide we care
about this stability, and that we want bullseye grub to work with a
filesystem made on sid.
I understand you do not support that stability decision.


signature.asc
Description: PGP signature

Bug#1028451: 2nd DisplayPort doesn't get video

[Sam Hartman]

> "Moritz" == Moritz Mühlenhoff  writes:
Moritz> Not moving to 6.1.x (which is most likely the next Linux
Moritz> kernel LTS) is by far a worse regression since it applies to
Moritz> every single Debian system.

Moritz> As a community distro without paid, full time kernel
Moritz> maintainers we can't just randomly stick to an older kernel
Moritz> tree and decide to assess/backport hundreds of patches sent
Moritz> to stable@ every week.

I think we're all agreed on that point.
What we can do is delay the release if we have a serious enough bug that
is not fixed yet.
I think what people are saying on this bug is that this issue is serious
enough it should be considered as a release blocker---something that
could actually delay the release.

From where I sit, thinking about what I've deployed in the last five
years, I agree with that analysis: this *might* be serious enough to
delay the release until there is a fix.
Given that  we can't stick on 6.0, I think we should try to get this
into testing as soon as possible so we can see how big of an impact it
is in practice.
I don't like to see testing broken, but I like to see stable broken in
serious ways even less.
And so I'd recommend we see  how badly this is going to hurt us.


signature.asc
Description: PGP signature

Bug#460232: Please clarify license

[Sam Hartman]

> "Bastian" == Bastian Germann  writes:

Bastian> The main license does not have a GPL version. However,
Bastian> there are several files licensed under specific (L)GPL
Bastian> versions and also other licenses included.  Debian Policy
Bastian> requires to document every contained license.

Bastian> I have attached a machine-readable copyright file that
Bastian> should have most licenses.

I've reviewed your machine readable copyright file and agree that it
 is  a significant improvement over the previous copyright file.
 I will commit.
 We can continue to improve going forward.
 

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Sam Hartman]

> "Salvatore" == Salvatore Bonaccorso  writes:

Salvatore> We were originally thinking so (and Moritz added krb5 to
Salvatore> the DSA needed list), as at least for 32bit architectures
Salvatore> it might be possible to go beyond denial of service and
Salvatore> potentially leading to remote code execution. But if your
Salvatore> assesment on the issue makes you confident it's not DSA
Salvatore> worthy we can re-evaluate.

So, looking at the code and the upstream advisory, it looks like the
information exposure vulnerability with cross-realm trust applies to
64-bit arches too.

Anyway I've fixed for unstable.
I  have a proposed fix for bullseye on the bullseye branch of
https://salsa.debian.org/debian/krb5.
Can you take a look and see if I did that right?  Do you want me to
upload that, or would you rather upload to the security queue?


signature.asc
Description: PGP signature

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Sam Hartman]

>>>>> "Salvatore" == Salvatore Bonaccorso  writes:
Salvatore> Thanks for sharing the analysis. Can you prepare debdiff
Salvatore> for bullseye-security accordingly, so we can release an
Salvatore> update via a DSA?

diff --git a/debian/changelog b/debian/changelog
index d6eaa38262..60fb20b347 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+krb5 (1.18.3-6+deb11u3) bullseye-security; urgency=high
+
+  * Integer overflows in PAC parsing; potentially critical for 32-bit
+KDCs or when cross-realm acts maliciously; DOS in other conditions;
+CVE-2022-42898, Closes: #1024267
+
+ -- Sam Hartman   Thu, 17 Nov 2022 12:41:46 -0700
+
 krb5 (1.18.3-6+deb11u2) bullseye; urgency=medium
 
   * Use SHA256 as Pkinit CMS Digest, Closes: #1017995
diff --git a/debian/patches/0014-Fix-integer-overflows-in-PAC-parsing.patch 
b/debian/patches/0014-Fix-integer-overflows-in-PAC-parsing.patch
new file mode 100644
index 00..04dbfd4788
--- /dev/null
+++ b/debian/patches/0014-Fix-integer-overflows-in-PAC-parsing.patch
@@ -0,0 +1,104 @@
+From: Greg Hudson 
+Date: Mon, 17 Oct 2022 20:25:11 -0400
+Subject: Fix integer overflows in PAC parsing
+
+In krb5_parse_pac(), check for buffer counts large enough to threaten
+integer overflow in the header length and memory length calculations.
+Avoid potential integer overflows when checking the length of each
+buffer.  Credit to OSS-Fuzz for discovering one of the issues.
+
+CVE-2022-42898:
+
+In MIT krb5 releases 1.8 and later, an authenticated attacker may be
+able to cause a KDC or kadmind process to crash by reading beyond the
+bounds of allocated memory, creating a denial of service.  A
+privileged attacker may similarly be able to cause a Kerberos or GSS
+application service to crash.  On 32-bit platforms, an attacker can
+also cause insufficient memory to be allocated for the result,
+potentially leading to remote code execution in a KDC, kadmind, or GSS
+or Kerberos application server process.  An attacker with the
+privileges of a cross-realm KDC may be able to extract secrets from a
+KDC process's memory by having them copied into the PAC of a new
+ticket.
+
+(cherry picked from commit ea92d2f0fcceb54a70910fa32e9a0d7a5afc3583)
+
+ticket: 9074
+version_fixed: 1.20.1
+
+(cherry picked from commit b99de751dd35360c0fccac74a40f4a60dbf1ceea)
+---
+ src/lib/krb5/krb/pac.c   |  9 +++--
+ src/lib/krb5/krb/t_pac.c | 18 ++
+ 2 files changed, 25 insertions(+), 2 deletions(-)
+
+diff --git a/src/lib/krb5/krb/pac.c b/src/lib/krb5/krb/pac.c
+index 950beda..1b9ef12 100644
+--- a/src/lib/krb5/krb/pac.c
 b/src/lib/krb5/krb/pac.c
+@@ -27,6 +27,8 @@
+ #include "k5-int.h"
+ #include "authdata.h"
+ 
++#define MAX_BUFFERS 4096
++
+ /* draft-brezak-win2k-krb-authz-00 */
+ 
+ /*
+@@ -316,6 +318,9 @@ krb5_pac_parse(krb5_context context,
+ if (version != 0)
+ return EINVAL;
+ 
++if (cbuffers < 1 || cbuffers > MAX_BUFFERS)
++return ERANGE;
++
+ header_len = PACTYPE_LENGTH + (cbuffers * PAC_INFO_BUFFER_LENGTH);
+ if (len < header_len)
+ return ERANGE;
+@@ -348,8 +353,8 @@ krb5_pac_parse(krb5_context context,
+ krb5_pac_free(context, pac);
+ return EINVAL;
+ }
+-if (buffer->Offset < header_len ||
+-buffer->Offset + buffer->cbBufferSize > len) {
++if (buffer->Offset < header_len || buffer->Offset > len ||
++buffer->cbBufferSize > len - buffer->Offset) {
+ krb5_pac_free(context, pac);
+ return ERANGE;
+ }
+diff --git a/src/lib/krb5/krb/t_pac.c b/src/lib/krb5/krb/t_pac.c
+index ee47152..ccd1653 100644
+--- a/src/lib/krb5/krb/t_pac.c
 b/src/lib/krb5/krb/t_pac.c
+@@ -431,6 +431,16 @@ static const unsigned char s4u_pac_ent_xrealm[] = {
+ 0x8a, 0x81, 0x9c, 0x9c, 0x00, 0x00, 0x00, 0x00
+ };
+ 
++static const unsigned char fuzz1[] = {
++0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00,
++0x06, 0xff, 0xff, 0xff, 0x00, 0x00, 0xf5
++};
++
++static const unsigned char fuzz2[] = {
++0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00,
++0x20, 0x20
++};
++
+ static const char *s4u_principal = "w2...@acme.com";
+ static const char *s4u_enterprise = "w2k8u@a...@acme.com";
+ 
+@@ -646,6 +656,14 @@ main(int argc, char **argv)
+ krb5_free_principal(context, sep);
+ }
+ 
++/* Check problematic PACs found by fuzzing. */
++ret = krb5_pac_parse(context, fuzz1, sizeof(fuzz1), );
++if (!ret)
++err(context, ret, "krb5_pac_parse should have failed");
++ret = krb5_pac_parse(context, fuzz2, sizeof(fuzz2), );
++if (!ret)
++err(context, ret, "krb5_pac_parse should have failed");
++
+ /*
+  * Test empty free
+  */
diff --git a/debian/patches/series b/debian/patches/series
index c02427759f..a62749cd49 100644
--- a/debian/

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Sam Hartman]

> "Salvatore" == Salvatore Bonaccorso  writes:
>> Will fix for unstable tomorrow.

Salvatore> Thank you.

>> I'm still trying to understand the practical impact.  Do you
>> think you're going to want to issue a DSA for stable?

Salvatore> We were originally thinking so (and Moritz added krb5 to
Salvatore> the DSA needed list), as at least for 32bit architectures
Salvatore> it might be possible to go beyond denial of service and
Salvatore> potentially leading to remote code execution. But if your
Salvatore> assesment on the issue makes you confident it's not DSA
Salvatore> worthy we can re-evaluate.

I strongly encourage a DSA.
There's the 32-bit issue, but I'm also concerned about what happens if
there is a cross-realm trust.
I think the issue is that with cross-realm trust you may be able to get
the KDC to produce a  PACcontaining out-of-bounds memory  and send it out.
And then if you have a service that can decrypt that PAC, look at that
memory, possibly including tservice keys.
So it may lead to an entire realm compromise.
What I can't entirely tell is whether that's limited to 32-bit
architectures or whether you could potentially have that happen on
64-bit architectures.

Either way that's really bad.


signature.asc
Description: PGP signature

Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing

[Sam Hartman]

> "Salvatore" == Salvatore Bonaccorso  writes:
Salvatore> Hi,

Salvatore> The following vulnerability was published for krb5.

Salvatore> CVE-2022-42898[0]: | integer overflows in PAC parsing

Salvatore> If you fix the vulnerability please also make sure to
Salvatore> include the CVE (Common Vulnerabilities & Exposures) id
Salvatore> in your changelog entry.

Will fix for unstable tomorrow.
I'm still trying to understand the practical impact.
Do you think you're going to want to issue a DSA for stable?


signature.asc
Description: PGP signature

Bug#1006509: moonshot-trust-router: diff for NMU version 3.5.4+1+nmu1

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> Dear maintainer,

Adrian> I've prepared an NMU for moonshot-trust-router (versioned as
Adrian> 3.5.4+1+nmu1) and uploaded it to DELAYED/2. Please feel free
Adrian> to tell me if I should cancel it.

This NMU looks good to me.  Feel free to accelerate it if you like, or
feel free to leave in delayed/2.



signature.asc
Description: PGP signature

Bug#998361: pam FTBFS

[Sam Hartman]

> "Johannes" == Johannes Schauer Marin Rodrigues  writes:

Johannes> Hi,

Johannes> our CI runs for the DPKG_ROOT tests failed today because
Johannes> pam FTBFS. I rebuilt pam locally in a fresh sbuild chroot
Johannes> without any modifications and arrived at the same build
Johannes> failure. I attached the log. I also put the error message
Johannes> at the end of this mail. Some investigation suggests that
Johannes> for some reason PAM_USERTYPE_UIDMIN is set to the empty
Johannes> string by configure. Also interestingly I was not able to
Johannes> reproduce this problem by building the package outside of
Johannes> a chroot nor when building it under mmdebstrap. The
Johannes> problem only shows when building it inside an sbuild
Johannes> chroot. I thus suspect that it will also FTBFS on the
Johannes> buildds and mark this bug as serious.

I did initial investigation of the source, and there's nothing odd going
on there with the configure script.
So, this one is going to be strange and probably isn't pam's fault.

I think the bug is appropriate, but it wouldn't surprise me if the fix
is somewhere other than pam, because the configure script looks quite
normal.

I just wanted to write and confirm that source inspection doesn't show
anything obvious.
I don't have sbuild set up locally (I moved to debspawn a few months
ago), but I'll go do that and try to reproduce.

Bug#997960: Debspawn deletes anything mounted in a container

[Sam Hartman]

Package: debspawn
Version: 0.5.0-1
Severity: serious
Justification: Significant data loss

I used debspawn interact to  interactively explore what I needed to do to get a 
new upstream package building.
To make that easier, I mounted my source trees and debian working environment 
in the container.

On exit, debspawn deleted everything.
In retrospect, I can understand why this is, but it's pretty hostile to the 
developer.
I might be alone, but I find it very helpful to mount various things into 
containers when exploring why things don't work.

My recommendation would be to check for bind mounts and make sure they can be 
unmounted before cleaning up.
A fix that would have worked in my case but that may not generally be good 
enough would have been to restrict the container deletion to one-file-system.




-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (200, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
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 debspawn depends on:
ii  debootstrap1.0.123
ii  python33.9.2-3
ii  python3-toml   0.10.1-1
ii  systemd-container  247.3-6
ii  zstd   1.4.8+dfsg-2.1

Versions of packages debspawn recommends:
ii  build-essential  12.9
ii  devscripts   2.21.4

Versions of packages debspawn suggests:
ii  sudo  1.9.5p2-3

-- no debconf information

Bug#993044: libxcrypt breaks existing password hashes

[Sam Hartman]

package: libxcrypt
version: 1:4.4.22-1
severity: serious
justification: breaks login

See bug #992848.
Because of the way libpam0g calls libxcrypt any existing sha256 hash
will be rejected at login as expired.
I'm going to fix this in pam using the linux-pam upstream fix, but
libxcrypt should not migrate to testing before the fixed pam is in
testing.

This bug is intended to block that migration.
Feel free to do something else that blocks the migration.
If this bug is still open when libpam migrates, I'll close it.


signature.asc
Description: PGP signature

Bug#991365: krb5: CVE-2021-36222

[Sam Hartman]

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.
If not, I'll have some time and be back to general availability by
Sunday.
--Sam

Bug#990412: Clone and fix in PAM too

[Sam Hartman]

control: clone -1 -2
control: retitle -2 mis-merge in patches prevents reading /lib/security
control: reassign -2 pam
control: found -2 1.4.0-1
control: severity -2 important
control: severity -1 serious

Steve said that it was not an intentional change to prevent finding pam
modules in /lib/security.  Steve also points out that /lib/security may
be used by software not in Debian.

The cloned bug will track reintroducing the feature based on Hideki's
patch.
I still believe there is a (probably RC) bug in PAM modules that don't
use multiarch paths.
In particular, if the user installs any application that edpends on PAM
and is not of the native architeture, things will break if there are
modules in /lib/security.
So, libpam-yubico and other PAM modules still need to get fixed, but we
will work to fix the regression in PAM too.


signature.asc
Description: PGP signature

Bug#990412: pam: Regression - it won't search /lib/security

[Sam Hartman]

> "Steve" == Steve Langasek  writes:

Steve> For the record, I did not intentionally drop those lines,
Steve> this was a matter of a mis-merge.

Okay, if it was a miss-merge, let's see if we can fix.
I'm reasonably busy this morning but will try to prepare something later
today based on the patch Hideki proposed.
I know I'm going to phrase the changelog entry differently, but will
credit Hideki and use that patch as a starting point.

Bug#990412: pam: Regression - it won't search /lib/security

[Sam Hartman]

> "Hideki" == Hideki Yamane  writes:
>> I think Steve is quite familiar with multiarch and while he
>> hasn't commented yet I'm assuming he dropped those patch lines as
>> part of removing unnecessary upstream deltas.

Hideki>  I want his comment, too.

Okay, let's hold off until Steve speaks up then.
Meanwhile, I definitely think we should fix libpam-yubico any other PAM
modules we ideftify.
PAM modules need to be multi-arch so that if any non-native application
calls libpam, it works.
So there's at least an important if not serious bug in not having
multi-arch:same for a PAM module.


signature.asc
Description: PGP signature

Bug#990412: pam: Regression - it won't search /lib/security

[Sam Hartman]

> "Hideki" == Hideki Yamane  writes:

control: tags -1 -patch -pending
I NACK this proposed NMU.

This many years after multiarch, I think it is entirely reasonable for
PAM to drop support for non-multiarch paths at the transition between
buster and bullseye.
As I said earlier in the bug, I'm happy to add breaks on libpam-yubico
or other packages as necessary.
I think Steve is quite familiar with multiarch and while he hasn't
commented yet I'm assuming he dropped those patch lines as part of
removing unnecessary upstream deltas.

I think you failed to read my comments in the 990412 bug log before
Merging and reassigning.





signature.asc
Description: PGP signature

Bug#990412: pam: PAM doesn't appear to be reading /lib/security

[Sam Hartman]

> "Rowan" == Rowan Wookey  writes:

Rowan> Fair enough, I couldn't find any docs on the policy of
Rowan> /lib/security or any news on it not being scanned in
Rowan> Bullseye, is there something about that somewhere?

I don't know.
I had mostly been not paying attention to PAM but it looked like Steve
was getting a bit behind and he accepted an offer of help.
So, I was not tracking when this change got made.
It may well be we should document this is release notes.

Bug#990412: pam: PAM doesn't appear to be reading /lib/security

[Sam Hartman]

control: reassign -1 libpam-yubico
control: severity -1 grave
control: retitle -1 pam_yubico fails to install module in multiarch path
control: found -1 2.23-1

> "Rowan" == Rowan Wookey  writes:

Rowan> It appears that in Bullseye pam isn't checking /lib/security.


Rowan> The libpam-yubico package installes a module in /lib/security
Rowan> which when configured without an absolute path pam errors
Rowan> with:

I think that's a bug in the other package.
The issue is that /lib/security is not a multiarch path.
And so I cannot have both an i386 and amd64 version of the module
installed at the same time.
By this point, we really ought to be supporting multiarch.

I'm happy to add breaks relationships in pam on broken modules that
don't provide multiarch paths,
but I'd consider this a grave bug on a module that only installs in
/lib/security at this point.


signature.asc
Description: PGP signature

Bug#985739: libkrb5-3: libkrb5 requires undefined symbol from libk5crypto during upgrade from buster to bullseye

[Sam Hartman]

control: tags -1 confirmed

I haven't explicitly reproduced this, but based on the description I am
confident this is an issue.

What happened is that  upstream dropped an internal symbol
krb5int_c_combine_keys that is used by the old library.
So once libk5crypto3 is upgraded, libkrb5-3 breaks.

Interestingly it looks like libkrb5-3 from version 1.18 will work fine
with the old libk5crypto3.
A breaks relationship would certainly make things better.
I'm not 100% sure it's good enough if krb5 is effectively in the
pseudo-essential set.

I asked on IRC and was confused by the answers I got.
So I'm investigating.

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Sam Hartman]

> "Martin" == Martin Schurz  writes:

Martin> I have added pam_tally to common-auth and the upgrade did
Martin> not stop when installing the new libpam-modules. I believe
Martin> the regex is missing these files, since it does not contain
Martin> a "-" in the permitted characters.

Will fix.

Martin> While testing I also noticed, that pam-auth-update gives
Martin> some errors on my system. These come from line 710-714 of
Martin> the script. Upon further checking I found, that the script
Martin> does not handle commented lines. We use "# ..." comments at
Martin> the start of our pam-configs.  Is that an intented use-case
Martin> or should we add an exception to pam-auth-update to filter
Martin> comment lines?

Not part of this bug; too late for bullseye.

Martin> And some final nitpick: It seems I mistyped a capital T
Martin> (line 21) into the text templates and this got copied over.


Nod, a translator caught this; will fix.

Thanks for all your help.

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Sam Hartman]

In adapting your first patch, I narrowed things down a bit.
I search /etc/pam.d files containing only a-z0-9A-Z, which I believe
should catch all the active pam.d files but not editor backups, .pam-new
files and the like.
I also specifically recommend looking at pam_faillock.

--Sam

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Sam Hartman]

OK, I've started implementing.
First, I confirmed that pam_tally appears to work with the new pam
library.
So, blocking the upgrade at libpam-modules's preinst is a sane thing to
do.

I then implemented the attached patch which goes and looks for enabled
profiles that include modules we don't like and turns them off.

I next need to implement a patch to pam-auth-update to keep  profiles
with modules we don't like from coming back.

And then I need to adapt your first patch to just search /etc/pam.d.

I hope to work on these items tomorrow.

>From 7b55d6b81ce58d2aa866f7be83fd6167f02ad256 Mon Sep 17 00:00:00 2001
From: Sam Hartman 
Date: Wed, 24 Feb 2021 14:29:53 -0500
Subject: [PATCH] debian/libpam-modules.preinst|templates: pam_tally 
 deprecation

* Add a facility to detect enabled profiles that contain a particular module

* If a profile contains an enabled module that is being removed,
  remove that profile and warn the user.

* Use this to pam_tally and because of how the string search works pam_tally2
---
 debian/changelog|  7 +++
 debian/libpam-modules.preinst   | 33 -
 debian/libpam-modules.templates |  9 +
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index daa8e6bc..376b0ab5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pam (1.4.0-5) unstable; urgency=medium
+
+  * Remove profiles containing pam_tally or pam_tally2 since we no longer
+build them.
+
+ -- Sam Hartman   Wed, 24 Feb 2021 14:11:06 -0500
+
 pam (1.4.0-4) unstable; urgency=medium
 
   * Document in README.source how to avoid multi-arch problems with documentation, Closes: #851650
diff --git a/debian/libpam-modules.preinst b/debian/libpam-modules.preinst
index 3a86a8fb..3102b6a6 100644
--- a/debian/libpam-modules.preinst
+++ b/debian/libpam-modules.preinst
@@ -4,8 +4,39 @@ set -e
 
 . /usr/share/debconf/confmodule
 
+
+handle_profiles_with_removed_modules() {
+removed_modules="$1"
+profiles=""
+modules=""
+test -x /usr/sbin/pam-auth-update ||return 0
+test -r /var/lib/pam/auth ||return 0
+for module in $removed_modules; do
+new_profiles=$( perl -nle 'BEGIN {$removed = shift;} /^Module: (.*)$/&&($profile = $1); /^[^#]*$removed/&&$profile&&($profiles{$profile} = 1); END {print join("\n",keys %profiles) if %profiles;}' \
+$module \
+/var/lib/pam/auth /var/lib/pam/account \
+/var/lib/pam/password /var/lib/pam/session \
+/var/lib/pam/session-noninteractive)
+if [ "$new_profiles" != "" ]; then
+modules="$modules $module"
+profiles="${profiles}${new_profiles}"
+fi
+done
+profiles=$( echo "$profiles" |sort |uniq)
+if [ "$profiles" != "" ]; then
+db_reset libpam-modules/profiles-disabled
+db_subst libpam-modules/profiles-disabled modules "$modules"
+db_input critical libpam-modules/profiles-disabled ||true
+db_go ||true
+pam-auth-update --remove $profiles
+fi
+}
+
+
+
 if dpkg --compare-versions "$2" lt-nl 1.4.0-2; then
-	db_version 2.0
+db_version 2.0
+handle_profiles_with_removed_modules pam_tally 
 
 	if pidof xscreensaver xlockmore >/dev/null; then
 		db_input critical libpam-modules/disable-screensaver || true
diff --git a/debian/libpam-modules.templates b/debian/libpam-modules.templates
index b928751e..491bc5c1 100644
--- a/debian/libpam-modules.templates
+++ b/debian/libpam-modules.templates
@@ -7,3 +7,12 @@ _Description: xscreensaver and xlockmore must be restarted before upgrading
  authenticate to these programs.  You should arrange for these programs
  to be restarted or stopped before continuing this upgrade, to avoid
  locking your users out of their current sessions.
+
+Template: libpam-modules/profiles-disabled
+Type: error
+_Description: PAM Profiles with Deprecated Modules Disabled
+ Your system had PAM profiles enabled with the ${modules} PAM
+ modules. These modules have been removed from PAM. Leaving these PAM
+ profiles enabled would prevent users from accessing your system. As a
+ result, these profiles have been disabled.
+ 
\ No newline at end of file
-- 
2.29.2

Bug#976156: libapache-mod-auth-kerb probably shouldn't be released in its current form

[Sam Hartman]

package: libapache-mod-auth-kerb
severity: serious
version: 5.4-2.4
tags: security
justification: unmaintained with security weaknesses

Hi.  As part of a recent krb5 transition, I took a look at
libapache-mod-auth-kerb.
As part of that transition, libapache-mod-auth-kerb was removed from
testing.
I think that in its current state, that's a good idea.
So I'm opening a serious bug as Kerberos maintainer, questioning whether
libapache-mod-auth-kerb uses Kerberos securely.
If someone is going to step up and agree to spend real time maintaining
libapache-mod-auth-kerb, and they choose to downgrade this bug, I have
no objection.
What I don't want to see happen is the package continue to be vaguely
unmaintained and be released in its current form.

There are better replacements for  this package already in Debian.
My recommendation would be that for spnego authentication use
libapache2-mod-auth-gssapi.
For basic authentication use PAM and libpam-krb5 or libpam-sss.

The two biggest security issues I see are:

1) Vulnerable to dictionary attacks because  of old Kerberos API usage.
Kerberos as designed is vulnerable to dictionary attacks.  There is a
mechanism called timestamp (or encrypted challenge) preauthentication in
which  the client rather than the KDC produces the attackable quantity.
That way, you need to observe an exchange with a legitimate user in
order to attack a password.
libapache-mod-auth-kerb supports that.
However if you can observe exchanges between the webserver and KDC, you
can attack the passwords.

Modern Kerberos has a facility called FAST  that prevents this type of
dictionary attack by encrypting the entire Kerberos exchange.
Libapache-mod-auth-kerb does not support FAST because it does not use
the right APIs to provide an armour ticket to the Kerberos library.

2) Rather than using the verify_init_creds API within the Kerberos
library, libapache-mod-auth-kerb open-codes its own initial credentials
verification API based on old code extracted from the Kerberos library.
I am concerned that this code may have been improved and enhanced in
security relevant ways in the many years since it was extracted.
I'd recommend this be audited.

3) Replay cache usage.  The code currently doesn't provide a replay
cache for SPNEGO tokens.
I am not sure this is a good idea, and comments in the code indicate it
is a security problem.
It's a bit tricky.  It's quite possibly the case that replay caches are
not needed provided that TLS is used for the HTTP connection, and that
the cost of replay caches is too high.

I think this should be audited, and either the comments in the code
explaining that not using replay caches are a security problem replaced
with an explanation of why they are not (or turn on the replay cache).
The bugs in MIT Kerberos 1.3 that made replay caches problematic are not
an issue in 2020.

Again, I'm happy if someone steps up to spend significant effort
modernizing and maintaining the package and wants to downgrade this bug.
Be aware that you probably end up becoming upstream as well.


signature.asc
Description: PGP signature

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Sam Hartman]

control: tags -1 pending

I've uploaded to delayed/3, using your minimal patch.

Thanks.


--Sam

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Sam Hartman]

control: tags -1 patch

Here's a patch that I believe will get libapache-mod-auth-kerb working
with the latest krb5.  I'll go upload a krb5 that fixes the breaks
relationship.

I'd appreciate it if someone who actually uses libapache-mod-auth-kerb
will test this patch.
If it gets tested, I'll NMU.  If not, I'll ask the release team to
remove libapache-mod-auth-kerb from testing.

I apologize for the vcs churn in the patches.



patch
Description: Binary data


signature.asc
Description: PGP signature

Bug#975344: libkrb5-3: ABI breakage in 1.18: krb5_rc_resolve_full missing

[Sam Hartman]

control: reassign -1 libapache2-mod-auth-kerb
control: found -1  libapache2-mod-auth-kerb/5.4-2.4
control: retitle -1  FTBFS with krb5 1.18: significant use of internal
APIs and data structures
control: affects -1 libkrb5-3

Hi.
Kerberos 5 1.18 significantly refactors the replay cache implementation.
Unfortunately, if you take a look at src/mit-internals.h in the
mod-auth-kerb sources, you'll find that the functioning of mod-auth-kerb
depends on several internal APIs and internal data structures including
the donot_replay structure and the  APIs related to replay cache
resolution.

I appreciate the comments about the bugs in krb5 1.3 that lead to this
situation, but I'll note that krb5 1.3 hasn't been in Debian since 2005.
It's sort of unfortunate that things haven't been fixed on the
libapache2-mod-auth-kerb side in the intervening 15 years:-)


This is definitely going to require changes on the
libapache2-mod-auth-kerb side.


signature.asc
Description: PGP signature

Bug#962470: krb5: binary-all FTBFS

[Sam Hartman]

Thanks.
I am in the middle of fixing.
Apologies I didn't get a fix uploaded before you filed a bug.

Bug#944714: moonshot-trust-router ftbfs during rebuilds for libevent 2.1.7

[Sam Hartman]

control: tags -1 patch

> "peter" == peter green  writes:

peter> Tags 944714 +patch Thanks.

peter> The easy fix here is to remove -Werror, in the long term of
peter> course migration to a non-deprecated type should be
peter> considered but that is IMO an issue for upstream not Debian.

I'm associated enough with upstream that I'll just fix correctly.
Thanks though.

Bug#944714: moonshot-trust-router ftbfs during rebuilds for libevent 2.1.7

[Sam Hartman]

Acknowledged.
DPL is taking up all my Debian time at the moment.
It's not the end of the world if moonshot-trust-router falls out of
testing, but hopefully I'll get to this before it happens.
It's almost certainly simple.

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Michael" == Michael Biebl  writes:

Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
Michael>  wrote:

>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing them to run desktoppy kind of software
>> without systemd).  As discussed it seems that this C/R/P is
>> needed to implement the approach which was agreed between the
>> elogind and systemd maintainers.


Michael> I very much disagree with this summary.

Michael> In [1] I clearly expressed that I did not like this
Michael> approach of having a libelogind0 which replaces
Michael> libsystemd0.

That's actually not how I read that discussion.

I read you as grumblingly accepting the necessity of libelogind0 after
Mark explained that it was necessary because of the upstream design.

I suspect I'm not the only one who honestly read what you said as
accepting elogind0 even though it was not your preference.
Michael> I think the best option is still the one I outlined in [1],
Michael> i.e. getting rid of libelogind0 completely in Debian and
Michael> simply ensure that elogind works in combination with
Michael> libsystemd0.

That's inconsistent with the design of elogind.
Mark explored doing that in this bug and outlined why that doesn't work.

Summarizing for those less familiar with libsystemd0 than Michael:
libsystemd0 splits its interface to systemd across a number of things.
A lot of it is in a dbus API.
However, it also assumes a certain structure of how cgroups are layed
out.

Elogind does implement the dbus APIs in question.
However elogind lays out cgroups differently.
So key functionality does not actually work if you use libsystemd0 iwth
elogind.
Asking the Debian elogind maintainer to redesign elogind seems like kind
of a tall ask.

I agree that using libsystemd0 only would be a great option *if it
worked*

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Mark" == Mark Hindley  writes:

Mark> Sam, Since I cannot get a working and robust dpkg-divert
Mark> solution, I feel the need to revisit the validity of these
Mark> concerns.

I'd like to push back on the phrasing here.
What i'm hearing is that after spending a couple of weeks exploring ways
to meet these concerns, you'd now like to push back on whether they are
a good idea in the first place.
That seems dismissive both of Julien's concerns and the engineering
effort you and others have spent exploring what the valid options are.
I agree with you that it's time to go back and revisit whether these
concerns are requirements that we can meet.
But that's exactly because you've spent time working to address the
concerns.  In particular:

* You have explored and documented why libelogind0 needs to be a
  different implementation than libsystemd0: while its API and perhaps
  DBUS interface is the same, its cgroup interface is very different.

* You have explored options for maintaining libsystemd0 and libelogind0
  co-installable and described problems with those approaches: namely
  that there is a significant period on every upgrade where libsystemd0
  will be used rathen than libelogind.  That period will depend on how
  many packages are being unpacked before triggers get run.


I haven't responded to your text because I disagree with your premis.
You seemed to be trying to show that no problem could exist.  Since the
concern raised explicitly included problems caused by our incomplete
understanding of what apt's dependency resolver will do, that's a really
hard thing to do, and I'd expect that if you went down that path it
would involve formal proofs and some model of apt's behavior.

Instead, I think you've done the work to argue that you have the best
option anyone has come up with.  You've explored the other options Simon
and Michael have suggested and explained why they won't work.
You've worked with the Apt developers to resolve the concrete problem
that Simon had with your approach.
In your testing you are not able to  produce particularly bad
situations.

I think it is fair to ask Julien as the bug submitter to engage here
either by coming up with new options that none of us have explored or by
coming up with specific problems. Alternatively it would be reasonable
for him to ask someone else who has more time to dedicate to this issue
to step in.


In general, we expect maintainers to respond to RC bugs within two
weeks.
I think that in a situation like this it would be reasonable to expect
Julien to respond within two weeks as well.
However, for your information, DSA is having some significant hardware
challenges and I think he is very involved in that.
I'd recommend being very receptive to a specific request for more time.

Assuming no response, I think it would be reasonable for you to close
the bug after the timeout arguing that you have considered the issues
he brought up, considered alternative designs, and articulated why this
is the best option.

I won't lie: there are various ways politics  can happn at that point.

I have a couple roles in this:

1) facilitating communications.

2) I'm an experienced Debian Developer.  I'm giving you advice on what
is reasonable process in handling an RC bug.  I don't have any DPL
powers in that regard; other DDs may disagree with me.  If you want to
double check my recommendations with other developers that wouldn't be
bad.  If other developers pop up here, considering their input would be
a good idea.


3) I cannot review specific Release Team decisions.  I do have a role in
reviewing whether the release team is using a reasonable process and
talking to release team members or release managers when I have concerns
about that.  Ultimately, I can ask the project to review a release team
decision if I think the process is unreasonable.  (I have the technical
power to ask the project to review a decision in other circumstances,
but I would be much more reluctant to use that power in a situation
where I thought the process was reasonable than in a situation where I
thought it was not.)

--Sam

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Thorsten" == Thorsten Glaser  writes:

Thorsten> On Wed, 25 Sep 2019, Mark Hindley wrote:
>> libelogind0 can be coninstalled with libsystemd0. However, it is
>> fragile because the file that needs to be diverted out of the way
>> is libsystemd.so.0.26.0 (the actual library file, not a symlink)
>> otherwise ldconfig will still find it and create
>> symlinks. However, AFAICS dpkg-divert doesn't accept wildcards
>> and so if the minor soversion is bumped and a new version of
>> libsystemd0 is installed, the new file is installed without a
>> divert and ldconfig redirects the symlink.

Thorsten> dpkg-divert also has a small period in which neither is
Thorsten> available.  I don’t like this approach.

Is that only when adding a diversion or when upgrading a diverted file
each time?

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

>>>>> "Mark" == Mark Hindley  writes:

Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
>> Foo-package depends on the latest libsystemd0.  I'm running
>> unstable or testing.  The latest libsystemd0 isn't building on my
>> arch yet.  But elogind is simpler and has build fine on my arch.
>> I install foo-package and suddenly end up with libelogind0
>> instead of libsystemd0
>> 
>> This is probably a problem.  Libsystemd0 and libelogind0 probably
>> behave differently and you probably do care which one you have.
>> The specific problems depend on what init system I have, on
>> whether I have elogind running or systemd-logind, etc.  But it's
>> probably not a good situation.

Mark> I believe we have guarded against exactly this already because
Mark> libelogind0 conflicts with systemd, so you couldn't change
Mark> from libsystemd0 to libelogind0 on a systemd install without
Mark> removing the running systemd (which won't happen).

Well, we've guaranteed that you won't succeed.
With the apt fix, we've guaranteed  that the dependency order will be
respected for removal.

But I think it's still possible to get an incredible mess of your
systemd.
There's no guarantee that systemd removal will happen early in the
process.


Mark> Anyway, I am happy to try to work up a dpkg-divert solution if
Mark> that is likely to be more acceptable.

I don't know if it will be.
I'm trying to be a facilitator here and make sure all sides understand
each other.

So, the advantage of the dpkg-divert approach seems to me to be that if
you never turn it on, it can't hurt you.
So, for example, if you do more than install a package to trigger it, it
could be very safe for the systemd user.

Even if you trigger from the elogind postinst, that's probably OK so
long as very little hard depends on elogind.

The disadvantages are:

1) Making sure you never get into a situation where you try to boot
systemd with libelogind0.  Assuming you can dpkg-divert a symlink, you
can presumably manage the /sbin/init link, but you cannot stop someone
from init=/bin/systemd with libelogind0 as libsystemd0.  Although
systemd doesn't actually link to libsystemd0, so perhaps that's not
quite as bad as I thought, although I'm sure it isn't good..  (You may
not need to stop this: it's a disadvantage, and sometimes the chosen
solution has disadvantages).

2) There was FUD about dpkg-divert being inappropriate for critical
system functions.  I don't know whether this is still true or how big of
a deal it is.  But for example if things are in an inconsistent state on
upgrade between unpack phase and configure phase, that might be a
disadvantage.  Basically, I think it's probably fine if the initial
diversion has some fragility (where if your system crashes at that one
point, recovery is hard).  I think it's less amazing if every time you
upgrade systemd, elogind or similar, there is fragility.


Really at this point we need someone who is not you or I to speak up.

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

Hi.
I've looked a bit at the systemd code as compared to the elogind code.

One of the major reasons that libsystemd0 cannot be used as a
replacement for libelogind0 is that elogind does not have compatible
cgroup naming.
The systemd (and elogind) libraries  do some operations over dbus.
But other operations are done directly.  For example to look and see
what session a pid is in, the library will look at the cgroups of the
pid.
Similarly to see whether a particular pid belongs to a uid, it looks at
the cgroup naming.

If you take a look at src/basic/cgroup-util.c in the elogind sources and
take a look at what is #if 0'd you can see the naming differences.

I don't know what would happen if  you built a elogind that used systemd
naming.  I don't know what the next hurtle would be.


--Sam

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Mark" == Mark Hindley  writes:


>> If we are going to use c/r/p libsystemd0, is there some way we
>> can limit the potential damage to people who have positively
>> indicated that they want to run a non-default init system?  One
>> of the concerns is what happens if apt decides somehow that it
>> wants to install libelogind0 when you don't expect it.

Mark> I have to admit I don't understand this fear. libsystemd0 is
Mark> just a way of talking to a running systemd process. If systemd
Mark> is not running and PID 1 libsystemd0 APIs generally return non
Mark> fatal errors. So by running a non-default init, libsystemd0 is
Mark> only there to satisfy dynamically loaded symbols at
Mark> runtime. Otherwise it is basically non functional. libelogind0
Mark> is the same if elogind isn't running.

Foo-package depends on the latest libsystemd0.  I'm running unstable or
testing.  The latest libsystemd0 isn't building on my arch yet.  But
elogind is simpler and has build fine on my arch.  I install foo-package
and suddenly end up with libelogind0 instead of libsystemd0

This is probably a problem.
Libsystemd0 and libelogind0 probably behave differently and you probably
do care which one you have.
The specific problems depend on what init system I have, on whether I
have elogind running or systemd-logind, etc.
But it's probably not a good situation.


The concern is there might be other cases where the dependency resolver
gives you an answer that is inappropriate for your environment.  We're
not sure we have confidence we can enumerate and think about all these
situations.


This is less likely with things like mail-transport-agent because the
dependencies are closer to their usage, or because the size of the
interacting parts of the dependency graph are smaller.

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Sam Hartman]

> "Mark" == Mark Hindley  writes:

Mark> Julian,
Mark> On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote:
>> > I don't think it's reasonable to ship this package with C/R/P >
>> libsystemd0.
>> 
>> I understand that you don't like it. However, for libelogind0 to
>> export the same symbols as libsystemd0 so that it could C/R/P
>> libsystemd0 was the agreed solution to bug #923244.
>> 
>> Do you have another suggestion as to how we could have resolved
>> that? Other solutions were discounted at the time.
>> 
>> > I think it opens you (and, more importantly, users) up to
>> issues like > #934491.  Even if #935910 were to be fixed in the
>> package manager > in > bullseye, it would still mean libelogind0
>> couldn't ship with > the C/R/P > until bullseye+1.
>> 
>> I think it seems likely from discussions on #debian-dpkg that
>> #935910 will be fixed in APT and #934491 can be addressed by
>> adding Breaks: << fixed APT.

Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that
Mark> installed I can no longer reproduce #934491. The APT
Mark> maintainers have said that adding a Breaks for the fixed
Mark> version of apt is not useful.

Normally in a situation like this we would wait until the next stable
release for depending on the change in apt.
It's a bit complicated because it is a bug, but Julian's idea that we
need to wait until bullseye+1 to depend on this apt fix is not an
unreasonable approach.



Mark> I have tried the approach suggested by Laurent of using
Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs
Mark> to function correctly.
What trouble did you run into?


Mark> Are there any outstanding issues that you would like me to
Mark> address to resolve this bug?

So, I think I understand Julian's issues better after trying to write my
bits from the DPL mail.
You haven't really tried to address them at all.
His issue is that we have a long history of trouble with apt and c/r/p
being used this deep in the dependency chain.
So, he's arguing that you have a high bar (possibly infinitely high) for
using that approach.

Ultimately he wants you to produce a solution where multiple init
systems can be coinstalled and where you don't need a conflicts.

I think you've explored some of that design space and have a feel for
why some of that is unattractive.
As an example, if you have systemd installed, it might be running.  The
combination of systemd running and libelogind0 being the systemd library
is unfortunate.  Trying to boot systemd in that configuration (using
libelogind0) would presumably be quite fatal.

So, the next question is why libelogind0 needs to exist.  That is why
can't you just use libsystemd0 with elogind?
What I've heard so far is "It doesn't work."
Why doesn't it work?  How hard would it be to make it work?
Would that be better for Debian than using c/r/p?
And the answer to some of these might be "we don't know and we don't
have anyone who can find out."
That is a fine answer to give, although it might also be fine for the
release team to say that they want that analysis before committing to
something dangerous like c/r/p libsystemd0.

But even if we understand why libelogind0 is needed, then why do we need
c/r/p libsystemd0?
Could we do something with dpkg-divert?  Would that be better?

If we are going to use c/r/p libsystemd0, is there some way we can limit
the potential damage to people who have positively indicated that they
want to run a non-default init system?
One of the concerns is what happens if apt decides somehow that it wants
to install libelogind0 when you don't expect it.
It might be better to have some init-chooser app where you had to
explicitly decide you wanted to opt into a non-default init before it
was possible to get into a situation where libsystemd0 was provided by
libelogind0.
I don't see how to make that work; I'm just brainstorming.

I think it is reasonable for you to expect Julien to be constructively
engaged in the discussion, to find someone else who will constructively
engage and take ownership of his position, or for the bug to close.  At
one level Julien is frustrated: you haven't been addressing his core
issue of the design choice to use c/r/p libsystemd0 and to not have
multiple inits coinstallable.  But at another level Julien has stalled
your project for multiple months, and if we're going to do that we need
to be prepared to engage in trying to actually solve the problem.  I
think some of the frustration here may stem from you not knowing how to
respond to his issue.  You don't have a design without c/r/p libsystemd0
that meets your needs.  And so you've been focusing on trying to solve
the things you could, hoping that would be enough.  Where as a great way
to engage with an issue like this is to explain why Julien is asking you
to do something hard and ask him to work with you to find 

Bug#940034: elogind and the release team block

[Sam Hartman]

>>>>> "Adam" == Adam Borowski  writes:

Adam> On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote:
>> I reached out to jcristau to talk about his block hint.  Based on
>> our IRC discussion, it sounds like he was having trouble bringing
>> himself to remove the hint presumably because he doesn't think
>> the broader issue was being dealt with.

>> The systemd maintainers are telling you that you need to provide
>> libpam-systemd.

Adam> We _did_ use libpam-systemd in the past.  This code was
Adam> working and tested, by January 2018 (using consolekit not
Adam> elogind by then), then a different version (with elogind),
Adam> well-tested in Devuan then finally submitted in November 2018.
Adam> The difference is the point the alternative happens at:

As Mark pointed out I meant libsystemd0.
That is, to make the convergance point the dbus APIs etc.

--Sam

Bug#940034: elogind and the release team block

[Sam Hartman]

Dear Mark:

I reached out to jcristau to talk about his block hint.
Based on our IRC discussion, it sounds like he was having trouble
bringing himself to remove the hint presumably because he doesn't think
the broader issue was being dealt with.

I suggested that he might open his concerns as an RC bug on the package,
because that would regularize the situation.

Please do not just downgrade an RC bug opened by a member of the release
team.  I think the release team would be entirely justified in blocking
your package or removing it at that point.

Unfortunately, it sounds like you are in a bad situation.

The systemd maintainers are telling you that you need to provide
libpam-systemd.

Actually, they would prefer that you create an elogind that mirrors
enough of the interfaces that you can just use libpam-systemd.  You said
that would not work, explaining that elogind for example doesn't have a
concept of slices.  You never clearly articulated why it couldn't
emulate slices enough to pacify libpam-systemd.  I don't know if it is
just that work hasn't been done or if it would be a bad idea for some
reason.

Now you've got someone arguing that the providing libpam-systemd and
conflicting with libpam-systemd is problematic.
And I'll admit that it is definitely a problematic approach.
I realize that you talked it over with the systemd maintainers and while
they didn't quite agree, my reading of their message was fairly
sympathetic.


So now you've got conflicting requirements coming from multiple
directions.

I really don't see a way forward besides getting enough of the right
parties involved to understand the issues and come up with a solution
that balances the trade offs across multiple packages.

I'm sorry that you've been placed in this position.

--Sam

Bug#930869: Asked to try and mediate this bug.

[Sam Hartman]

Michael, I've been asked to try and mediate this bug.
Unfortunately, to do that, I'm going to need to ask at least one
question that Adam is already asked.  I can assure you that I'm not as
smart as you believe he is, so I really am going to need some help to
understand the situation:-)

What are the replacements?
Are the replacements init system agnostic?
I mean I can think of various systemd specific replacements and various
desktop replacements, but pm-utils is at a lower level than a desktop
and is init system agnostic.
Am I missing something or are those the sort of replacements you are
thinking of?

I'm also having a bit of trouble trying to understand how the various
hook directories work (power.d, sleep.d, etc).  If I install pm-utils
and use another mechanism like say systemctl suspend to suspend my
system, do the pm-utils hooks get called or not?

--Sam

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Sam Hartman]

I'm writing with my DPL hat on in the role of a facilitator/mediator.
I have no actual power in this situation and it is entirely reasonable
to ignore me.

I feel very uncomfortable with a change as big as this revert happening
this late in the release cycle.
I think that my reading of how the release team handles issues is
sufficient to say that they almost certainly have serious concerns about
that big of a change this late too.

And yet, the lack of a clear reconfirmation in this time line even given
the wonderfully civil discussion is telling.

My proposal--which again I have no power to implement--is that we go
forward with the current default.  However, we remain open to a revert
in the first couple of buster point releases.  The criteria for that
revert should be based on the actual severity and frequence of problems
our users run into, but should specifically exclude the blanket
reluctance to  make a change like that in a point release.
We would still need adequate testing of such a revert.

So, what I think this would require to be a viable proposal is:

* an ack from the buster stable release managers that if we run into
  real problems they would accept such a change

* an ack from gnome that if we do need to do a revert we'd be willing to
  revert in unstable and testing for a while to do as much testing of
  the revert in those environments.  Obviously such testing is imperfect
  given that gnome may (hopefully will) have moved on in Debian by then.

Again, feel free to ignore this message entirely if it does not move the
conversation forward.
I'm just seeing a stuck issue and proposing a way to try and unstick it.

--Sam


signature.asc
Description: PGP signature

Bug#921688: NMU Diff

[Sam Hartman]

Dear maintainer.
I made the following 0-day NMU of electrum.
I suspect that once you update to a new version you will not wish to
include these changes, but in the interest of awareness of your package
I wanted to make sure you were aware.

diff --git a/debian/changelog b/debian/changelog
index 4ff..c30a279 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+electrum (3.2.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * On startup print a warning that this version in insecure and then
+exit, Closes: #928518
+
+
+ -- Sam Hartman   Mon, 06 May 2019 22:11:19 -0400
+
 electrum (3.2.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/patches/replace-with-security-warning.patch 
b/debian/patches/replace-with-security-warning.patch
new file mode 100644
index 000..e8f409e
--- /dev/null
+++ b/debian/patches/replace-with-security-warning.patch
@@ -0,0 +1,60 @@
+From: Sam Hartman 
+Date: Mon, 6 May 2019 22:10:51 -0400
+X-Dgit-Generated: 3.2.3-1.1 3afceceac2d1042645e470189c13edb4f965e7a9
+Subject: Replace with security warning
+
+On startup print to GUI and stdio a security warning and then exit.
+
+---
+
+--- electrum-3.2.3.orig/electrum/electrum
 electrum-3.2.3/electrum/electrum
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python3
++#!/usr/bin/python3
+ # -*- mode: python -*-
+ #
+ # Electrum - lightweight Bitcoin client
+@@ -30,13 +30,42 @@ script_dir = os.path.dirname(os.path.rea
+ is_bundle = getattr(sys, 'frozen', False)
+ is_local = not is_bundle and os.path.exists(os.path.join(script_dir, 
"electrum.desktop"))
+ is_android = 'ANDROID_DATA' in os.environ
++try:
++import PyQt5
++except Exception:
++sys.exit("Error: Could not import PyQt5 on Linux systems, you may try 
'sudo apt-get install python3-pyqt5'")
+ 
++from PyQt5.QtGui import *
++from PyQt5.QtWidgets import *
++from PyQt5.QtCore import *
++import PyQt5.QtCore as QtCore
+ # move this back to gui/kivy/__init.py once plugins are moved
+ os.environ['KIVY_DATA_DIR'] = os.path.abspath(os.path.dirname(__file__)) + 
'/electrum/gui/kivy/data/'
+ 
+ if is_local or is_android:
+ sys.path.insert(0, os.path.join(script_dir, 'packages'))
+ 
++security_message = ''' \
++This version of Electrum is vulnerable to malicious code inserted by
++attackers and is being actively exploited to try and convince users to
++give their private credentials to attackers.  See
++https://bugs.debian.org/921688 for details.  Until the version in
++Debian is updated, please see https://electrum.org/download.html
++'''
++sys.stderr.write(security_message)
++
++
++from electrum.gui.qt.util import MessageBoxMixin
++class Window(QMainWindow, MessageBoxMixin):
++
++def __init__(self, *args, **kwargs):
++super().__init__(*args, **kwargs)
++self.show_warning(msg = security_message, title = "THIS APPLICATION 
is INSECURE")
++
++
++app = QApplication(["electrum", "gui"])
++window = Window()
++sys.exit(2)
+ 
+ def check_imports():
+ # pure-python dependencies need to be imported here for pyinstaller
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..8ffe66a
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+replace-with-security-warning.patch
diff --git a/electrum/electrum b/electrum/electrum
index dd35c35..8c5ef37 100755
--- a/electrum/electrum
+++ b/electrum/electrum
@@ -1,4 +1,4 @@
-#!/usr/bin/env python3
+#!/usr/bin/python3
 # -*- mode: python -*-
 #
 # Electrum - lightweight Bitcoin client
@@ -30,13 +30,42 @@ script_dir = os.path.dirname(os.path.realpath(__file__))
 is_bundle = getattr(sys, 'frozen', False)
 is_local = not is_bundle and os.path.exists(os.path.join(script_dir, 
"electrum.desktop"))
 is_android = 'ANDROID_DATA' in os.environ
-
+try:
+import PyQt5
+except Exception:
+sys.exit("Error: Could not import PyQt5 on Linux systems, you may try 
'sudo apt-get install python3-pyqt5'")
+
+from PyQt5.QtGui import *
+from PyQt5.QtWidgets import *
+from PyQt5.QtCore import *
+import PyQt5.QtCore as QtCore
 # move this back to gui/kivy/__init.py once plugins are moved
 os.environ['KIVY_DATA_DIR'] = os.path.abspath(os.path.dirname(__file__)) + 
'/electrum/gui/kivy/data/'
 
 if is_local or is_android:
 sys.path.insert(0, os.path.join(script_dir, 'packages'))
 
+security_message = ''' \
+This version of Electrum is vulnerable to malicious code inserted by
+attackers and is being actively exploited to try and convince users to
+give their private credentials to attackers.  See
+https://bugs.debian.org/921688 for details.  Until the version in
+Debian is updated, please see https://electrum.org/download.html
+'''
+sys.stderr.write(security_message)
+
+
+from electrum.gui.qt.util import MessageBoxMixin
+class Window(QMainWindow, MessageBoxMixin):
+
+def __init__(self, *args, **kwargs):
+super().__init__(*args, **kwargs)
+self.show_

Bug#921688: electrum being actively used for phishing

[Sam Hartman]

I realize that we normally don't care about packages only in sid, but
the version of electrum in sid is apparently only useful to funnel your
bitcoin to attackers.
The issue is that versions prior to 3.3  are vulnerable to mallware, and
as a result all the public servers refuse to talk to the version in sid,
but rogue servers are happy to  take your credentials and money.

The maintainer has not addressed this bug since Feb 7.

I don't have time to go look into the package and upgrade before leaving
on a trip tomorrow.

If we can't get this fixed really quick would ftpmaster accept a request
to remove the package?

--Sam


signature.asc
Description: PGP signature

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

control: severity -1 normal

Hi.  I ran a number of other upgrades today of libvirtd from stretch to
buster and was not able to reproduce the problem in the environments I
thought would cause it.
I don't know what's up, but I don't think characterizing this as RC
given the data we have is correct.

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

When I marked the bug RC, I thought it was happening all the time; I
then went to reproduce yet again in a controlled environment to be more
in a position to test a fix.
That's when I discovered things are more complex.

Obviously if this is a fringe situation, then it shouldn't be RC.

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

>>>>> "Guido" == Guido Günther  writes:

Guido> Hi,
Guido> On Mon, Apr 15, 2019 at 02:38:27PM -0400, Sam Hartman wrote:
>> control: severity -1 serious
>> 
>> justification: libvirtd upgrades from stretch to buster break
>> causing apt to fail and requiring the admin to get the systemd
>> units into a consistent state before things can continue
>> 
>> 
>> Unfortunately based on discussion so far this is a complex bug to
>> fix.  Ubuntu's solution is to drop the sysv scripts and to drop
>> Also= lines in some of the units.

Guido> Did you reproduce this bug on a stretch->buster upgrade?
Guido> Cause I just did that and didn't encounter any errors.

I've run into this on two active server upgrades--servers that were
running VMs,
but I haven't been able to reproduce on a clean install.
It's frustrating: on my machines where I really want the upgrade to be
smoothe this bit me, but on all my toy tests, it didn't happen.
What I think may be necessary is for virtlogd to be active.
So it may be necessary to actually get libvirtd running and actually
running a VM to use the socket before the issue comes up.
Alternatively, it's possible some other change has fixed this in the
last month.
I'll certainly say that a month ago ran into this on two different VM
servers.

Bug#905772: [Pkg-libvirt-maintainers] Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

Guido let me know if  you need any help or prod me on IRC if I'm needed.
Will certainly test the result, but if you get stuck would be happy to
spend time on this.

Bug#900912: Java Accessibility for Buster

[Sam Hartman]

Hi.  I have not been looking forward to having no java accessibility in
buster and it is really good to see the work Samuel has done on this
bug.  I'd really hate to see buster release without some mechanism for
blind users like myself to use Java applications.  Also, in the long
run, if buster does require editing a property file, I hope that we can
get to a place where that's not needed for the next release.

Matthias, I realize that you've got a lot on your plate, and have a lot
of stuff to balance.  I'd appreciate it if you would find the time to
move this forward and get the patch uploaded or let someone else do so.

Thanks for all your hard work,

--Sam

Bug#828441: moonshot-trust-router: FTBFS with openssl 1.1.0

[Sam Hartman]

Status is that I didn't find the time to get moonshot-trust-router dealt
with before buster and so I had deprioritized it.
There is in fact a new upstream, and it does fix the issue.
Blocking on moonshot-trust-router is silly: no one wants the version in
unstable anyway.
Is it possible to remove openssl and make moonshot-trust-router
uninstallable?
In my mind the only reason to keep moonshot-trust-router around now is
to avoid needing to take a trip through new again when I do fix it post
buster.

If you really need me to go deal with moonshot-trust-router now, I'll do
that, but my preference for my Debian time is to focus on buster
issues.  

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

I'd value the autofs configuration much more than the directory setup
instructions.
I have no desire to go install centos7 to debug a Debian bug:-) and have
some familiarity with setting up LDAP.
What I don't have is familiarity configuring autofs.

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

latest upgrade of libkrb5-3 (1.16.1-1 -> 1.16.2-1)
>> automount starts but dies immediately after accessing a
>> automounter point.
>> 
>> Automount is configured to authenticate via GSSAPI using system
>> keytab.  After the GSSAPI authentication succeeded, any access to
>> a configure automount entry causes automount to die with an
>> assertion failure (followed by an abort()):

Adrian> Thanks for your report.

Adrian> I'm moving this bug report to libkrb5-3 since this is the
Adrian> change that triggered your regression for assessment whether
Adrian> the bug is there.

Adrian, I'm guessing you're looking at this with your QA hat on?
How well do you understand autofs?  Any chance you could help put
together a repo?  If you don't know autofs-ldap well, I can learn it
just as well as anyone, but if you do happen to know it well, help would
be appreciated.
In the latest krb5 package, the debian/tests directory contains a
slapd-gssapi test which happens to set up LDAP well enough that you can
SASL authenticate it.
So, my guess is that adapting that test to  set up an autofs-ldap that
uses gss auth to ldap probably isn't too incredibly hard.
I don't know autofs at all, and for example I don't know how to set up
the directory to have the right info.

If you or the submitter can easily help, it would be appreciated.
If not, I'll look into it.

--Sam

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Sam Hartman]

So what's happening here is  that a k5_mutex_lock is getting  an invalid
argument error calling  a series of wrappers that basically all boil
down to pthread_mutex_lock.
So, basically somehow pthread_mutex_lock is getting passed a bad mutex.
This appears to be happening in the credentials cache code.

There are no thread support changes between 1.16.1 and 1.16.2.
There is one ccache related change which I'll include below related to
memory ccaches.
Do you know what type of credential cache  is being used here?

>From 6d784809fe07c2d5f60c1a692bcac08b0d40f0a7 Mon Sep 17 00:00:00 2001
From: Greg Hudson 
Date: Sun, 1 Jul 2018 00:12:25 -0400
Subject: [PATCH] Fix bugs with concurrent use of MEMORY ccaches

A memory ccache iterator stores an alias into the cache object's
linked list of credentials.  If the cache is reinitialized while the
iterator is active, the alias becomes invalid.  Also, multiple handles
referencing the same memory ccache all use aliases to the same data
object; if one of the handles is destroyed, the other contains a
dangling pointer.

Fix the first issue by adding a generation counter to the cache and to
cursors, incremented each time the cache is initialized or destroyed.
Check the generation on each cursor step and end the iteration if the
list was invalidated.  Fix the second issue by adding a reference
count to the cache object, counting one reference for the table slot
and one for each open handle.  Empty the cache object on each destroy
operation, but only release the object when the last handle to it is
destroyed or closed.

Add regression tests for the two issues to t_cc.c.

The first issue was reported by Sorin Manolache.

(cherry picked from commit 146dadec8fe7ccc4149eb2e3f577cc320aee6efb)

ticket: 8202
version_fixed: 1.16.2
---
 src/lib/krb5/ccache/cc_memory.c | 164 +---
 src/lib/krb5/ccache/t_cc.c  |  51 +
 2 files changed, 154 insertions(+), 61 deletions(-)

diff --git a/src/lib/krb5/ccache/cc_memory.c b/src/lib/krb5/ccache/cc_memory.c
index c5425eb3ae..8cdaff7fb3 100644
--- a/src/lib/krb5/ccache/cc_memory.c
+++ b/src/lib/krb5/ccache/cc_memory.c
@@ -102,18 +102,20 @@ extern krb5_error_code krb5_change_cache (void);
 typedef struct _krb5_mcc_link {
 struct _krb5_mcc_link *next;
 krb5_creds *creds;
-} krb5_mcc_link, *krb5_mcc_cursor;
+} krb5_mcc_link;
 
 /* Per-cache data header.  */
 typedef struct _krb5_mcc_data {
 char *name;
 k5_cc_mutex lock;
 krb5_principal prin;
-krb5_mcc_cursor link;
+krb5_mcc_link *link;
 krb5_timestamp changetime;
 /* Time offsets for clock-skewed clients.  */
 krb5_int32 time_offset;
 krb5_int32 usec_offset;
+int refcount;   /* One for the table slot, one per handle */
+int generation; /* Incremented at each initialize */
 } krb5_mcc_data;
 
 /* List of memory caches.  */
@@ -122,6 +124,12 @@ typedef struct krb5_mcc_list_node {
 krb5_mcc_data *cache;
 } krb5_mcc_list_node;
 
+/* Iterator over credentials in a memory cache. */
+struct mcc_cursor {
+int generation;
+krb5_mcc_link *next_link;
+};
+
 /* Iterator over memory caches.  */
 struct krb5_mcc_ptcursor_data {
 struct krb5_mcc_list_node *cur;
@@ -132,7 +140,23 @@ static krb5_mcc_list_node *mcc_head = 0;
 
 static void update_mcc_change_time(krb5_mcc_data *);
 
-static void krb5_mcc_free (krb5_context context, krb5_ccache id);
+/* Remove creds from d, invalidate any existing cursors, and unset the client
+ * principal.  The caller is responsible for locking. */
+static void
+empty_mcc_cache(krb5_context context, krb5_mcc_data *d)
+{
+krb5_mcc_link *curr, *next;
+
+for (curr = d->link; curr != NULL; curr = next) {
+next = curr->next;
+krb5_free_creds(context, curr->creds);
+free(curr);
+}
+d->link = NULL;
+d->generation++;
+krb5_free_principal(context, d->prin);
+d->prin = NULL;
+}
 
 /*
  * Modifies:
@@ -150,16 +174,12 @@ krb5_mcc_initialize(krb5_context context, krb5_ccache id, 
krb5_principal princ)
 {
 krb5_os_context os_ctx = >os_context;
 krb5_error_code ret;
-krb5_mcc_data *d;
+krb5_mcc_data *d = id->data;
 
-d = (krb5_mcc_data *)id->data;
 k5_cc_mutex_lock(context, >lock);
+empty_mcc_cache(context, d);
 
-krb5_mcc_free(context, id);
-
-d = (krb5_mcc_data *)id->data;
-ret = krb5_copy_principal(context, princ,
-  >prin);
+ret = krb5_copy_principal(context, princ, >prin);
 update_mcc_change_time(d);
 
 if (os_ctx->os_flags & KRB5_OS_TOFFSET_VALID) {
@@ -185,61 +205,59 @@ krb5_mcc_initialize(krb5_context context, krb5_ccache id, 
krb5_principal princ)
 krb5_error_code KRB5_CALLCONV
 krb5_mcc_close(krb5_context context, krb5_ccache id)
 {
-free(id);
-return KRB5_OK;
-}
-
-static void
-krb5_mcc_free(krb5_context context, krb5_ccache id)
-{
-krb5_mcc_cursor curr,next;
-krb5_mcc_data *d;
+krb5_mcc_data *d = 

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

[Sam Hartman]

>>>>> "Sebastian" == Sebastian Andrzej Siewior  writes:

Sebastian> On 2018-12-11 18:26:24 [-0500], Sam Hartman wrote:
>> Fixing moonshot-gss-eap and getting a new moonshot-ui is next up
>> for me for Debian weekend tasks.

Sebastian> This means an upload from exp to unstable?

I'm not sure if that's enough, but it's certainly part of it.
There may be a bit of porting involved.

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

[Sam Hartman]

Fixing moonshot-gss-eap and getting a new moonshot-ui is next up for me
for Debian weekend tasks.

Bug#877469: NMU diff for 1.0.23-3.1

[Sam Hartman]

Uploaded to delayed/5

diff --git a/debian/changelog b/debian/changelog
index 3f9833c..76020bf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+node-websocket (1.0.23-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't run dh_nodejs against libjs-websocket, because that is an arch
+all package with no ABI dependencies.  We don't want shared library
+dependencies on an arch all package because it breaks the ability to
+do binary NMUs for library transitions, Closes: #877469
+
+ -- Sam Hartman   Tue, 11 Dec 2018 08:50:44 -0500
+
 node-websocket (1.0.23-3) unstable; urgency=medium
 
   * Team Upload
diff --git a/debian/rules b/debian/rules
index e347699..a49f49e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,9 @@ export DH_OPTIONS
 override_dh_auto_test-arch:
tap test/unit
 
+# We do not need abi dependencies for a source all package
+override_dh_nodejs:
+   dh_nodejs -pnode-websocket
 override_dh_install-arch:
dh_install
chmod 644 
$(CURDIR)/debian/node-websocket/usr/lib/nodejs/websocket/build/Release/*.node


signature.asc
Description: PGP signature

Bug#915639: Apologies for shibboleth-resolver FTBFS

[Sam Hartman]

Hi.

I am not sure how I managed to produce the binary package for amd64.  I
*thought* that I used sbuild in a clean sid chroot to do so, but it's
quite clear from trying to reproduce that that I failed.  I'm somewhat
baffled because my work flow makes it hard for something not coming out
of sbuild with a clean chroot to end up in the right place to be
uploaded, but it's certainly the case that the dsc I uploaded simply
does not work.

I regret that the package was so broken and that I managed not to catch
it.  I did intend to avoid the obvious failure of building on my host
system, and I thought I had a work flow that was not vulnerable to
screwing that up.
Anyway, apologies that you had to waste your time on my error.

Bug#915007: opensaml2 FTBFS with xmltooling 3

[Sam Hartman]

Built fine I have not yet tested against moonshot

On December 3, 2018 8:52:10 AM EST, "Cantor, Scott"  wrote:
>On 12/1/18, 4:48 AM, "Pkg-shibboleth-devel on behalf of wf...@niif.hu"
>on behalf of wf...@niif.hu> wrote:
>
>> Please let me know if you need any help; for example I can see that
>> version 3 of the resolver uses pkg-config for finding the SP, which
>is
>> cool in principle but nobody tested it in Debian yet, so that may
>> uncover bugs lower in the stack.
>
>Finding the SP is probably fine, but both the SP and that library had a
>lot of very difficult to test changes to the autoconf handling around
>GSS-API, and that's where your problems will probably crop up.
>
>-- Scott
>
>
>___
>Pkg-shibboleth-devel mailing list
>pkg-shibboleth-de...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shibboleth-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#915007: opensaml2 FTBFS with xmltooling 3

[Sam Hartman]

Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file the
removal requests.
They are both basically broken in unstable, so there's no reason to
block.

Bug#867945: Working on porting to libsecret

[Sam Hartman]

I'm working on porting moonshot-ui from gnome-keyring to libsecret.
It's somewhat involved because upstream needs to support both
interfaces--they have a long tail of operating systems they need to work
on.  Also, the existing code could use some refactoring to be cleaner.

I'm probably 70% of the way through coding this but the results will
need to be tested.
I anticipate being able to get moonshot-ui back into buster testing
(without gnome-keyring) in time to make the freeze.

Bug#911481: libkrb5support0:i386 has broken dependencies

[Sam Hartman]

control: tags -1 moreinfo
control: severity -1 normal

Hi.  Your bug is a little short on details, and I was not able to
reproduce.  I took a new sid chroot, added i386 as an architecture, and
installed libkrb5support0:i386 by


apt install libkrb5support0:i386
I ended up with krb5 1.16.1-1 and libkeyutils1 1.5.9-9.3

I suggest you look into why libkeyutils1 is not able to be installed in
your situation.

Bug#887810: krb5-multidev: "krb5-config.mit --cflags gssapi" returns wrong include directory

[Sam Hartman]

I am testing a fix.
My apologies for the sloppy change.

Bug#828441: moonshot-trust-router: FTBFS with openssl 1.1.0

[Sam Hartman]

There's a new upstream for moonshot-trust-router that I believe should
work with openssl 1.1.
Realistically, I should be able to deal with moonshot-gss-eap #848680
within a month.
I think it may be more like two months to deal with both
moonshot-gss-eap and moonshot-trust-router, both of which have new
upstreams.
Right now, neither is in testing.  I expect Buster to be the first
release to include moonshot-trust-router and definitely plan to get
moonshot-gss-eap back into testing for Buster, but I'm not bothered if
moonshot-trust-router spends a month FTBFS because you remove openssl
1.0.


--Sam

Bug#876927: moonshot-ui FTBFS with vala 0.36

[Sam Hartman]

I suspect the version in experimental with work with vala 0.36, but will
confirm that.

Bug#872760: asterisk-opus: uninstallable in unstable

[Sam Hartman]

OK, if the checksum doesn't change regularly, I can understand why  the
current arrangement makes sense.

It would bxe great to get asterisk-opus rebuilt though:-)

Bug#872760: asterisk-opus: uninstallable in unstable

[Sam Hartman]

Package: asterisk-opus
Version: 13.7+20161113-3
Severity: grave
Justification: renders package unusable


The asterisk package in unstable provides
asterisk-1fb7f5c06d7a2052e38d021b3d8ca151

but asterisk-opus depends on asterisk-fa819827cbff2ea35341af5458859233

It looks like this is a system that is very locked to the specific
build of asterisk.  I wonder whether merging the asterisk and
asterisk-opus package using the 3.0 package format's features for
additional source component tarballs might not be a more appropriate
packaging strategy.  Meanwhile, this is clearly broken as it cannot be
installed.

Bug#766298: An update on trust router and release status

[Sam Hartman]

> "Petter" == Petter Reinholdtsen  writes:

>> I think shortly after the release of buster, we can close this
>> bug and let moonshot-trust-router migrate into testing.

Petter> Did this time arrive?
Mostly.
I'm working through all the moonshot software  and updating it to new
upstream versions.
moonshot-ui has a new version in experimental.
Working on moonshot-gss-eap, then will work on moonshot-trust-router.

I don't see a reason not to let the new moonshot-trust-router into
testing at least for now.
Near the freeze I'll coordinate with upstream about whether we're
willing to support that version of the protocol for a full Debian
release.

Petter> There is also the OpenSSL 1.1 issue, bug #828441.  -- Happy
Petter> hacking Petter Reinholdtsen

Yep.
That shouldn't be a big problem.

Bug#869260: CVE-2017-11368

[Sam Hartman]

I can absolutely prepare a stable point update request for stretch.
Is there still going to be a last point release to jessie?
If so I'll look into that too; I'd definitely like to get an update in.

Bug#869260: CVE-2017-11368

[Sam Hartman]

Actually, on that note, why does this bug merit a DSA?
It like the other bugs is a simple KDC crash from an authenticated
attacker.
It seems like it should be handled the same.

Bug#869260: CVE-2017-11368

[Sam Hartman]

Take a look at  the stretch branch of
git://git.debian.org/git/pkg-k5-afs/debian-krb5-2013.git

Shall I upload that to stable-security?

Bug#866712: moonshot-gss-eap FTBFS on arm64: libeap/src/utils/common.h:429:0: error: "__bitwise" redefined [-Werror]

[Sam Hartman]

I'm starting the process of updating to new upstream.
I think that is reasonably likely to fix this.  If not, I'll look into
the issue after the update.
I'm OK if moonshot-gss-eap falls out of testing for a few weeks.

--Sam

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

[Sam Hartman]

control: severity -1 normal

Will remove this file early in buster.

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

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Package: libgssapi-krb5-2 Version: 1.15-1 Severity: serious
Helmut> libgssapi-krb5-2 is a shared library package and contains
Helmut> /etc/gss/mech.d/README. The latter filename does not depend
Helmut> on the soname of the library and thus does not change when
Helmut> the soname changes.

Hi.

I'm going to start by  explaining why that file is there and asking for
your help in figuring out what to do.
I'm then going to argue that this is not an RC bug (probably not even a
bug at all).
But I'm more interested in finding a solution that works for us both
than simply closing bugs because I can.

The issue is that older versions of krb5 had two related problems with
regard to /etc/gss/mech.d:

1) They only supported a config file for reading mechanism config, not
an entire directory

2) Because of a bug in how I set prefix, they read /usr/etc/gss/mech not
/etc/gss/mech as that config file.

Nothing shipped /usr/etc/gss/mech on Debian--it's clearly not
FHS-compatible.

However, there are some gss mechanism packages, mostly not in Debian,
that need to configure themselves even on older krb5.
I needed a way to figure out whether the gss library was new enough to
read /etc/gss/mech.d.

So I dropped a README in that directory.  Code that detects that file
and uses it as a flag not to create and write /usr/etc/gss/mech has
escaped.  The main culprit is moonshot-gss-eap (especially versions not
in Debian), but I've recommended the approach to others and not tracked
where all it might be being used.

I think we can move away from that approach for stretch +1, but I really
kind of need that file to be there, and I'm quite uncomfortable trying
to get the replaces/conflicts/provides dance correct this late in the
stretch cycle.


So, that's why I care about the file for stretch, and why I want to be
careful about a fix.

I claim this is not a violation of policy 8.2.  In particular, It seems
very likely that if the soname of libgssapi_krb5 changes, you'll need
different mechanism configuration for the new version.  It seems very
unlikely that the same mechanism will work for GSS v2 and v3.  So, I'd
expect the directory to be /etc/gss3/mech.d or /etc/gss/mech3.d, and if
the readme were retained, I'd expect it to be in that new directory in
the new library.

That said, I'll note that libgssapi_krb5.so.2 has been stable since
before the release of Kerberos 1.0 back in 1995.  A change in gss's
soname is going to be a huge massive pain in all sorts of ways if it
ever happens, and I don't think having to deal with one README is going
to even make the headache list.

You said that you're running into dpkg issues.
I'm sympathetic to that, but I'd like to find a way that your needs and
mine can both be met.

--Sam

Bug#852039: [pkg-opensc-maint] Bug#852039: pam-p11: diff for NMU version 0.1.5-6.1

[Sam Hartman]

If your upload goes in tomorrow, it will superceed mine which will never
get processed.
If you miss a day, yours will still replace mine.

Bug#852039: pam_p11: crashes with tokens that require login

[Sam Hartman]

package: pam-p11
version: 0.1.5-6
severity: grave
tags: security, patch
justification: unusable in most secure configurations; DOS, possibly
exploitable

Hi.
I found that pam_p11_openssh was causing my login process to segfault.
Tracing the code through the debugger, I found the following in libp11:
if (relogin == 0) {
/* Calling PKCS11_login invalidates all cached  
 * keys we have */ 
if (slot->token) { 
pkcs11_destroy_keys(slot->token, CKO_PRIVATE_KEY);
pkcs11_destroy_keys(slot->token, CKO_PUBLIC_KEY);
pkcs11_destroy_certs(slot->token);
}


That is, all certificate objects are invalidated on token login.  That's
kind of expected: a pkcs11 token is likely to give you more objects when
you login than before you login.

Unfortunately, authcert is used in pam_sm_authenticate after the call to
PKCS11_login, so uninitialized memory is used.  I'm surprised; I
actually managed it get it to work once yesterday, but it sure doesn't
work reliably, or on any machine but that one.

Here's a quick and dirty patch to rescan after login.
From 1392f5c0f1822e7c306ae6d9bdd3ede6f90b37c2 Mon Sep 17 00:00:00 2001
From: Sam Hartman <hartm...@debian.org>
Date: Fri, 20 Jan 2017 17:24:05 -0500
Subject: [PATCH] Read certs again on token login

PKCS11_login destroys all certs and keys retrieved from the token.  So
after logging in it is necessary to enumerate the certificates again.
Without this, the library is very likely to crash.
---
 debian/patches/reread_certs_on_token_login | 40 ++
 debian/patches/series  |  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 debian/patches/reread_certs_on_token_login

diff --git a/debian/patches/reread_certs_on_token_login b/debian/patches/reread_certs_on_token_login
new file mode 100644
index 000..f6c5557
--- /dev/null
+++ b/debian/patches/reread_certs_on_token_login
@@ -0,0 +1,40 @@
+Index: pam-p11/src/pam_p11.c
+===
+--- pam-p11.orig/src/pam_p11.c
 pam-p11/src/pam_p11.c
+@@ -56,6 +56,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
+ 	const char *user;
+ 	char *password;
+ 	char password_prompt[64];
++	int loggedin = 0;
+ 
+ 	struct pam_conv *conv;
+ 	struct pam_message msg;
+@@ -119,7 +120,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
+ 	}
+ 
+ 	/* get all certs */
+-	rv = PKCS11_enumerate_certs(slot->token, , );
++ cert_scan: rv = PKCS11_enumerate_certs(slot->token, , );
+ 	if (rv) {
+ 		pam_syslog(pamh, LOG_ERR, "PKCS11_enumerate_certs failed");
+ 		rv = PAM_AUTHINFO_UNAVAIL;
+@@ -156,7 +157,7 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
+ 		goto out;
+ 	}
+ 
+-	if (!slot->token->loginRequired)
++	if (!slot->token->loginRequired ||loggedin)
+ 		goto loggedin;
+ 
+ 	/* get password */
+@@ -209,6 +210,9 @@ PAM_EXTERN int pam_sm_authenticate(pam_h
+ 		goto out;
+ 	}
+ 
++	loggedin = 1;
++	goto cert_scan;
++	
+   loggedin:
+ 	/* get random bytes */
+ 	fd = open(RANDOM_SOURCE, O_RDONLY);
diff --git a/debian/patches/series b/debian/patches/series
index 2d7f923..04d6505 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-Use-INSTALL-instead-of-libLTLIBRARIES_INSTALL.patch
+reread_certs_on_token_login
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#766298: An update on trust router and release status

[Sam Hartman]

There was a trust router release in October.
At one level, this release is probably functional enough that it would
be nice to have included in stretch.
At another level,there have been enough upstream bugs files that I
don't think it's stable enough to include and support for the lifetime
of stretch.

However, I think  we're in a good position to put something into
experimental (and then stretch-backports) very soon.  Also, now that
freeradius 3 is in Debian, we should be able to get that infrastructure
enabled.
I think shortly after the release of buster, we can close this bug and
let moonshot-trust-router migrate into testing.

Bug#846088: Info received (Bug#846088: Alladin License in krb5)

[Sam Hartman]

To be clear I've contacted upstream off-list and we'll see what we find
in the next few days.

Bug#846088: Alladin License in krb5

[Sam Hartman]

Hmm.
So,  first, the file refers to a modified copy of the Alladin free
public license, from a kit for implementing filesystems.
I'm kind of boggled that someone would start from the Alladin license,
but since I have no idea what modifications they made, I have no idea
whether it's free.

However the author of the software in question was working for the part
of MIT responsible for Kerberos around that period of time.
I suspect this is a simple case of someone cut their work from
one project to another and failing to fix up the license header.
MIT is fairly good about getting copyright assignments so this can
probably be cleared up.


--Sam

Bug#828440: moonshot-gss-eap: FTBFS with openssl 1.1.0

[Sam Hartman]

> "Sebastian" == Sebastian Andrzej Siewior  writes:

Sebastian> control: tags -1 patch
Sebastian> On 2016-06-26 12:23:04 [+0200], Kurt Roeckx wrote:
>> OpenSSL 1.1.0 is about to released.  During a rebuild of all
>> packages using OpenSSL this package fail to build.  A log of that
>> build can be found at:
>> 
https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/moonshot-gss-eap_0.9.5-1_amd64-20160529-1451

Sebastian> this builds now. Do you have anything to verify?

Hi.
I'm sorry I didn't get a chance to respond to your other mail.
upstream has dealt with moonshot-gss-eap and moonshot-ui and I plan to
address the bugs there with a new upstream version.
We'll probably need to build-dep on libssl1.0 until the entire cluster
builds with 1.1; I think having two related libraries in the same
address space use different versions of ssl will be problematic.

Bug#837000: kerberos-configs: FTBFS: Undefined subroutine ::read_config called at ./genblob line 9.

[Sam Hartman]

> "Lucas" == Lucas Nussbaum  writes:

Lucas> Hi,

Lucas> During a rebuild of all packages in sid, your package failed
Lucas> to build on amd64.

Lucas> Relevant part (hopefully):
>> fakeroot debian/rules binary ./genblob >tmp & tmp config-blob
>> Undefined subroutine ::read_config called at ./genblob line
>> 9.  debian/rules:17: recipe for target 'config-blob' failed make:
>> *** [config-blob] Error 2

Lucas> The full build log is available from:
Lucas> 
http://people.debian.org/~lucas/logs/2016/09/06/kerberos-configs_2.3_unstable.log

Lucas> A list of current common problems and possible solutions is
Lucas> available at http://wiki.debian.org/qa.debian.org/FTBFS
Lucas> . You're welcome to contribute!

Lucas> About the archive rebuild: The rebuild was done on EC2 VM
Lucas> instances from Amazon Web Services, using a clean, minimal
Lucas> and up-to-date chroot. Every failed build was retried once to
Lucas> eliminate random failures.

Looks like a . removed from cwd bug in perl.
Kerberos-configs is a bit over-due for some love anyway.
The fix is easy, but I'll go fold in a bunch of other bugs while I get
to it.


--Sam

Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)

[Sam Hartman]

> "Raphael" == Raphael Hertzog  writes:

Raphael> It would seem natural to orphan it and to let the new
Raphael> maintainer deal with updating it to version 3.x.

I think 3.x is likely to be new packaging and entirely breaks
compatibility with the 2.x config.

If we orphan 2.x someone might fix the RC bug and get it back into
testing.
At this point I think releasing stretch with 2.x would be worse than
releasing stretch without freeradius.

Bug#806617: freeradius: FTBFS when built with dpkg-buildpackage -A (dh_install: freeradius-common missing files)

[Sam Hartman]

> "Josip" == Josip Rodin  writes:

Josip> On Tue, Aug 30, 2016 at 11:20:50AM +0200, Raphael Hertzog wrote:
>> Josip, do you really still care about this package?

Josip> I'm pretty sure I told Sam to take it over a few years
Josip> back...?

O, if that's what you were trying to say, that is very different from
 what I heard.

Regardless, I have move on from the job that had a lot of dependence on
FreeRadius, and can't give it attention either.

--Sam