Bug#1073608: Bug#1074014: Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:
> "Helmut" == Helmut Grohne writes: Helmut> In bullseye and earlier, I guess it works. Helmut> If you start with bullseye or earlier, upgrade to bookworm Helmut> and then to trixie, it continues to work, because the dash Helmut> maintainer scripts preserve any diversion that is not owned Helmut> by dash. This seems really broken. As a sysadmin I would definitely expect to be able to repoint the /bin/sh symlink and have that preserved. I hope we choose to move back to a situation at some point where it does not require diversions to get that behavior. In my mind that is an even higher priority than say avoiding bootstrap tools needing to create a /bin/sh symlink.
Bug#1075813: Krb5: fails to pick up debian configuration
package: krb5-kdc severity: grave version: 1.21.3-2 A typo in version 1.21.3-2 incorrectly interrupts the configure args, among other things causing sysconfdir to be incorrectly set. This breaks krb5-kdc because it does not read /etc/krb5kdc/kdc.conf. Found by CI tests. signature.asc Description: PGP signature
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
> "Chris" == Chris Hofstaedtler writes: Chris> Adam (adsb) points out that the test code in Chris> lib/rpc/unit-test/client.c [1] uses code that does not Chris> support IPv6(-only). I.e. gethostbyname for a name that has Chris> no IPv4 address will fail. So, are the builds going to unshare or not? given that the code is apparently quite happy to work with a hostname that points to ipv4 loopback and given that I already spent a good chunk of time dealing with buildd churn this month, I don't have a lot of love for dealing with more gratuitous environment changes entirely outside my control. I'm kind of tempted to take this to the TC and ask for clarity about what is reasonable to expecte from buildds. --Sam
Bug#1072952: krb5: FTBFS: ../../src/tests/t_iprop.py - E: Build killed with signal TERM after 60 minutes of inactivity
> "Chris" == Chris Hofstaedtler writes: Chris> When building krb5 with sbuild, configured to use the unshare Chris> backend, the t_iprop.py test apparently times out without any Chris> output. I'm guessing, but have not confirmed that sbuild unshare is setting up a network namespace with nothing but lo in it. I've certainly seen the same behavior you see in such a configuration. What's happening is that get_wildcard_address in kpropd.c passes AI_ADDRCONFIG into getaddrinfo. Since loopback addresses are ignored by AI_ADDRCONFIG, there is no valid v4 or v6 address and the routine fails to find a wildcard address to bind to. I'm mistified why the daemon doesn't just fail at thait point, but I have not looked into that. I did modify get_wildcard_address to prefer AI_ADDRCONFIG but to fall back to calling getaddrinfo without AI_ADDRCONFIG if that's all that will work. That's enough for t_kpropd.py to succeed. I'm working through a few other FTBFS issues in a container, some of which apparently didn't show up for sbuild unshare (they happen earlier in the build) but which are getting in my way. I hope to have 1.21.2 uploaded and building by end of weekend. signature.asc Description: PGP signature
Bug#1072952: krb5: FTBFS: ../../src/tests/t_iprop.py - E: Build killed with signal TERM after 60 minutes of inactivity
control: tags -1 -help +confirmed I reproduced the problem with a podman container with no network. Apparently t_iprop.py hangs if the only network interface is loopback. I'm fairly sure it would work fine only talking to itself if there was a non-127.0.0.1 address for it to use. If I can fix this easily, I'll do so. Otherwise I'll engage with the sbuild maintainers. It's always been the case that builds have had a network interface, even if it has been illegal to reach off the local machine. Kerberos has always treated lo different than other local interfaces; the rationale for this goes back to the Kerberos standard (RFC 4120). --Sam
Bug#1072952: krb5: FTBFS: ../../src/tests/t_iprop.py - E: Build killed with signal TERM after 60 minutes of inactivity
control: tags -1 +help Chris> Filing with severity: serious as the buildd network has Chris> started switching to sbuild with unshare backend, and Chris> multiple people have reproduced this problem. I'm not running sbuild these days; I'm mostly moving toward containerized builds for my local development. I am currently setting up a new environment and if I can reproduce there, I'm happy to look into it. But if it literally happens only on sbuild unshare, I'm going to need help because that's not a beast I have a desire to deal with.
Bug#1065702: krb5-kdc: uninstallable due to hard-coded dependency on libverto-libev1 | libverto-libevent1,
> "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
> "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
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
> "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)
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
> "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
> "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
> "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
> "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
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
> "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
> "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
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
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
> "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
> "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
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
> "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
> "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
>>>>> "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
> "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
> "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
> "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
> "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
>>>>> "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), &pac); ++if (!ret) ++err(context, ret, "krb5_pac_parse should have failed"); ++ret = krb5_pac_parse(context, fuzz2, sizeof(fuzz2), &pac); ++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 1
Bug#1024267: krb5: CVE-2022-42898: integer overflows in PAC parsing
> "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
> "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
> "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
> "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
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
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
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
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
> "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
> "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
> "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
> "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
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
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
> "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
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
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
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]
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]
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
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
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
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
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
> "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
> "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
> "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
>>>>> "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
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
> "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
> "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 a
Bug#940034: elogind and the release team block
>>>>> "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
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.
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
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
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
Bug#921688: electrum being actively used for phishing
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
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
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
>>>>> "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
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
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
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.)")
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.)")
> "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.)")
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 = &context->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, &d->lock); +empty_mcc_cache(context, d); -krb5_mcc_free(context, id); - -d = (krb5_mcc_data *)id->data; -ret = krb5_copy_principal(context, princ, - &d->prin); +ret = krb5_copy_principal(context, princ, &d->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; +krb
Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3
>>>>> "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
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
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
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
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
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
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
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
I am testing a fix. My apologies for the sloppy change.
Bug#828441: moonshot-trust-router: FTBFS with openssl 1.1.0
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
I suspect the version in experimental with work with vala 0.36, but will confirm that.
Bug#872760: asterisk-opus: uninstallable in unstable
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
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
> "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
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
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
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]
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)
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)
> "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
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
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 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, &certs, &ncerts); ++ cert_scan: rv = PKCS11_enumerate_certs(slot->token, &certs, &ncerts); + 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
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.