> "Adrian" == Adrian Bunk writes:
Adrian> Sam, could you make a maintainer upload with this change?
Adrian> krb5 is quite central in the OpenLDAP transition that just
Adrian> started.
Absolutely, thanks for the ping. Will get to it now.
> "Lucas" == Lucas Nussbaum writes:
> install: cannot change ownership of
> 'debian/krb5-admin-server/usr/sbin/krb5_newrealm': Operation not permitted
It looks like this is a result of defaulting to rules-requires-root: no
(was that change in your rebuild?)
I think that I need to set rules-
> "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
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
Descriptio
> "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 goi
> "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 namesp
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 t
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 fo
> "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 dep
> "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
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 ve
> "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 li
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 tha
> "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 th
> "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 thes
> "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).
> "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
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 coul
> "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 docume
> "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 f
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_names
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
> "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 c
> "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 tha
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.
R
> "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: > > ...
> "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 o
>>>>> "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
> "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 thi
> "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
Mo
> "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 contain
> "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 lead
er 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
> "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
> "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> includ
> "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 fre
> "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
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.
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 m
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
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/securi
> "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
> "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 unti
> "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 h
> "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
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.
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.
In
> "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 character
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
7be83fd6167f02ad256 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 enabl
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.
control: tags -1 pending
I've uploaded to delayed/3, using your minimal patch.
Thanks.
--Sam
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.
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 implementatio
Thanks.
I am in the middle of fixing.
Apologies I didn't get a fix uploaded before you filed a bug.
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
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.
> "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 t
> "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 e
> "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 fi
>>>>> "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 m
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
> "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 deci
> "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
>>>>> "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 br
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
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 ar
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 rel
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
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 vers
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.
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.
>>>>> "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
>
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.
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
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 op
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.
> "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 authent
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 cod
>>>>> "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
Fixing moonshot-gss-eap and getting a new moonshot-ui is next up for me
for Debian weekend tasks.
ocket, 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 -05
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 sbui
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
>> vers
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.
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 th
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 lib
I am testing a fix.
My apologies for the sloppy change.
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
I suspect the version in experimental with work with vala 0.36, but will
confirm that.
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:-)
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
> "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
upstr
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.
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.
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?
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
control: severity -1 normal
Will remove this file early in buster.
> "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 an
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.
1 - 100 of 268 matches
Mail list logo
