Bug#766194: debhelper: dh_installinit should gain option to ignore start failures

[Sam Hartman]

> "Marvin" == Marvin Renich  writes:

Marvin> * Niels Thykier  [180521 05:29]:
>> As I understood your original mail, it sounded like we expect the
>> service to fail because the user has not configured it yet.  I
>> think I am missing the point of having it start automatically if
>> it will not work out of the box.  Can you elaborate on what makes
>> you want it to start automatically?

Marvin> I'm not sure, so this may not be Sam's issue, but perhaps it
Marvin> should be attempted to start the service, but it might fail,
Marvin> and such failure should be ignored.  I'm not sure if
Marvin> dh_installinit can do different things on initial install
Marvin> and upgrade, and it almost certainly cannot determine if a
Marvin> proper configuration has been put in place by the sysadmin
Marvin> before the initial install that would allow the service to
Marvin> start correctly.  I don't use krb5-kdc, and don't know what
Marvin> the real issue is.

My bug can probably be closed.
My bug was filed at a point in time when dh_installinit
1) handled systemd service starting

2) tended to fail every time a systemd unit failed.

It sounds like neither of those are still true.

Bug#1000837: krb5: differing build paths trigger different documentation

[Sam Hartman]

Hi.
I've looked over your report and baffling patch.
This is really strange, and I don't have much to add.

It seems like it might be related to the pathsubst rules in
src/doc/Makefile.in.
But I don't see the build directory getting used there.

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sam Hartman]

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

Johannes> Hi Steve, Quoting Johannes Schauer Marin Rodrigues
Johannes> (2021-12-08 10:00:31)
Johannes> Since it has been more than a month without any reply I
Johannes> just uploaded a NMU of pam with the attached debdiff to
Johannes> DELAYED/10.  Those are the same changes as from
Johannes> https://salsa.debian.org/vorlon/pam/-/merge_requests/7 and
Johannes> our CI passes with those changes to pam
Johannes> https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

I have attempted to cancel this NMU.
I've tried to explicitly nack this change without feedback from Steve,
and I stand behind this.
This change adds a maintenance burden that I'm not entirely comfortable
accepting either as an NMU or as a co-maintainer without full authority.

I'm guessing my previous statement on this was insufficiently clear.
Please wait for feedback from Steve before integrating this change.

Thanks,

--Sam


signature.asc
Description: PGP signature

Bug#1007717: Native source package format with non-native version

[Sam Hartman]

> "Ian" == Ian Jackson  writes:
Ian>  3. Consequently, declare that the recent MBF on this topic
Ian> ought not to have been filed against packages where simply
Ian> changing the source format does not currently work.  That would
Ian> include at least 1.0 native packages with Debian revisions.

I'm a little confused.
My reading of the debian-devel discussion was that Lucas had already
modified the MBF in a manner consistent with what you're asking for.
It looks like there was a bug in the criteria he used, and it sounds
like he already agrees that a few bugs were filed that should not have
been.
It sounds like he's actively working to fix that.


I think asking the TC to get involved here is a great idea on the
other issues you ask about.
I'm just not sure there is a contraversyfor the TC on the specific
case of the MBF itself.

Bug#1007717: Native source package format with non-native version

[Sam Hartman]

Dear TC,
I cannot speak for what Ian wants,
but I would also like to formally ask the TC to rule on this issue.
My hope is that what Ian and I are asking for is similar enough that the
TC can consider the issues together.

Specifically, I'd like to ask the TC to come up with policy on native
packages and debian revisions using its power under  6.1.1.
In particular I ask the TC to consider the hypothesis that:

* Debian revisions are useful when there is a separate upstream flow
  from the packaging flow.  For example when Debian versions are
  released at different times than upstream times, Debian versions have
  different content (for example a debian directory), or Debian versions
  are maintained by different people.  IN these cases a debian revision
  may be useful.

* Native source package formats (1.0 tar only and 3.0 (native)) are
  useful when the work flow
  is easier to maintain without separated Debian changes.  There are
  several cases involving git work flows where package maintenance is
  improved by not requiring this separation.

* Git work flows are a best practice.  There may be other best practices
  too.  We want to encourage git work flows to become more streamlined
  and easier; when people have found git work flows that make their job
  as maintainers easier, we want to encourage that.

I don't think the TC needs to do out-of-charter design work to come up
with policy in this regard.
I think there's been a lot of work within debian-policy, within
discussions of git packaging flows, and within the  consensus-seeking
discussions run over the years.

I'll point outt that the behavior of non-experimental package
building tools explicitly falls under 6.1.1 and does not require the TC
to override a maintainer.

I believe it is also appropriate for the TC to rule under 6.1.2.
It's clear that policy, the packaging tools, archive build tools, and
tools to support git work flows need to be in harmony for things to work
well.
It's clear there is overlap, and it is clear to me we do not have
harmony today.

I'd also like to provide some initial briefing material to the TC to
help you all come up to speend on this issue.

* Ian's mail that you were forwarded

* #bug 737634

   * My messages starting at
 
https://lists.debian.org/0144017b42b6-b65ba883-c94b-472c-89b7-7341c14ce8ab-000...@email.amazonses.com
 and following the thread.  I explain one case where you want to use
 a debian revision with native packages.  I think Ian has described
 cases that are more clearly directly related to the Debian archive,
 but I clearly outline in that bug report problems I was having and
 why proposed alternatives did not work.

* Around that time  a claim was made that debian-policy did not permit
  debian revisions with native packages.  I challenged that claim and in
  https://lists.debian.org/8761otp2r1@windlord.stanford.edu Russ
  acknowledges that the section of policy he was pointing at did not
  actually forbid debian revisions with native packages.  So at the time
  dpkg made the change it was breaking things and there was no policy
  requirement for the change.

* Ubuntu had to make a change to dpkg-source at least as used by
  launchpad for recipe builds to continue to work.  I don't know if they
  still maintain that patch, but it seems like a bad sign when a major
  downstream needs to revert a change  we've done to get work done.  It
  would perhaps be valuable to look into whether they still have that
  delta and if not how they work around things.

* https://lists.debian.org/tsla738bpwz@suchdamage.org the most
  interesting bit there is a consensus of the project that if your
  upstream uses git, best practice is for your packaging to use git.

* https://lists.debian.org/tslr252ioa3.fsf...@suchdamage.org Consensus:
  native packages are sometimes an appropriate tool to use in contrast
  to earlier consensus that we wanted to move away from them.

* Plus the recent thread on debian-devel.

* The git packaging BOF at DebConf19.

Thanks for your consideration,

--Sam


signature.asc
Description: PGP signature

Bug#973611: libverto: Please consider switching to libevent

[Sam Hartman]

So, the main reason we're using libev is that upstream krb5 uses libev.
I think they do because libev is a smaller more self contained code base
than libevent, and because honestly the KDC isn't normally a performance
bottleneck, so it doesn't much matter.

That said, I think libverto in Debian should support all the options,
and certainly should support libevent.
That won't make things easier for Ubuntu really, if they want to avoid
building libverto against libev, but it will let Debian users use
libevent if that's what they want.

I'd love a merge proposal that turns on libevent and leaves libev
present, and will eventually try to get to that myself if you aren't
interested in submitting that.

Bug#973611: libverto: Please consider switching to libevent

[Sam Hartman]

> "Balint" == Balint Reczey  writes:

Balint> Hi Sam, Thank you for the quick response.
>> That said, I think libverto in Debian should support all the
>> options, and certainly should support libevent.  That won't make
>> things easier for Ubuntu really, if they want to avoid building
>> libverto against libev, but it will let Debian users use libevent
>> if that's what they want.

Balint> In general I agree with offering the choice, but in that
Balint> particular package's case I saw no prior indication of any
Balint> user wanting to use libverto-libevent1 rather than
Balint> libverto-libev1. I see that you maintain krb5, too. What
Balint> advantage do you see in providing libverto-libevent1, too,
Balint> that would make the extra complexity worth it?

So, if you are using libverto, in a particular application, you are
probably happier if your libverto event loop matches up well with your
application event loop.
So if you're using a library like krb5 in an application that uses
libevent or glib, you probably would like libverto to use that event
loop.

(libverto is effectively designed to allow libraries to use an event
loop.)
This doesn't matter in practice because not a lot of people use
libverto.
And because libkrb5 doesn't tend to use libverto much; I seem to recall
it's more a kdc-side thing.

In general in Debian though we tend to turn on all the upstream
compile-time options that a package supports.

Honestly, libverto seems like one too many layers for my taste.
Yeah, it's kind of a PITA to glue too event loops together, but it
actually is possible in the cases that matter, and I kind of wish that
krb5 had just chosen one event loop (pick any one) rather than going and
designing an abstraction for abstracting away the choice of event loop.


So, with my Debian-packages-should-support-upstream options hat on, I
kind of feel like libverto should support all the options as a wishlist
priority.
But I can't say that I think it would make much difference or that it's
where I plan to spend a lot of time.

Bug#973823: lvmlockd fails to create sanlock lock space with 1g extents

[Sam Hartman]

package: lvm2-lockd
version: 2.03.09-3


Hi.
This is a relatively brief bug report, I'm tossing off in the middle of
trying to get something working, and I apologize for not including a lot
of details.
The system where I can reproduce is several tunnels away from anything
with email so I definitely cannot run reportbug.
What appears to be happening is that if the volume group has an extent
size greater than 256m (which appears to be the default initial size for
lvmlock), it fails to create a lock space.
My guess is that it's rounding down rather than up trying to create the
volume or something.
But I can consistently create  a volume group with 256m extents and not
with 1g extents.


root@storage-a:~# vgcreate  --shared --pvmetadatacopies=1 -s 1g raidvg /dev/sdb
  Enabling sanlock global lock
  Skipping global lock: lockspace not found or started 
  Internal error: Unable to create new logical volume with no extents. 
  Failed to create sanlock lv lvmlock in vg raidvg 
  Failed to create internal lv.
  Failed to initialize lock args for lock type sanlock 
  Volume group "raidvg" successfully removed   
root@storage-a:~# vgcreate  --shared --pvmetadatacopies=1 -s 256m raidvg /dev/sd
b
  Enabling sanlock global lock
  Skipping global lock: lockspace not found or started 
  Logical volume "lvmlock" created.
  Volume group "raidvg" successfully created   
  VG raidvg starting sanlock lockspace
  Starting locking.  Waiting until locks are ready...  


If my guess is wrong and this is not obvious from code inspection, let
me know what additional details would be useful.
If I can get it without disrupting a production system I'll do that, but
I don't have a lot of environments where sanlock is set up.

--Sam

Bug#973880: krb5: CVE-2020-28196

[Sam Hartman]

Thanks for the note.  I've been meaning to do a much needed krb5 update
and this definitely pushes it up the priority stack.
I'll work on this over the weekend.

Bug#974531: krb5: Please include upstream fix "Unregister thread key in SPNEGO finalization"

[Sam Hartman]

I don't plan to ever put 1.17.2 into unstable; I plan to ask to move
1.18.2 into unstable shortly.
LTS is beyond my horizon of caring.
I won't stand in your way, and if you never became a DD, I'll be happy
to review and sponsor anything you need, but that's not where my energy
goes.

Bug#974531: krb5: Please include upstream fix "Unregister thread key in SPNEGO finalization"

[Sam Hartman]

This was not clear from my message yesterday.

If you want me to prepare an update for buster, and agree to test such
an update, I'm happy to do so.

Bug#1007717: Native source package format with non-native version

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Hi Russ,
Helmut> On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote:
>> > Specifically, I'd like to ask the TC to come up with policy on
>> native > packages and debian revisions using its power under
>> 6.1.1.
>> 
>> As a Policy Editor, I support this request.

Helmut> As a TC member I admit disliking this. While there is
Helmut> disagreement on how things are supposed to work, the views
Helmut> don't seem to be that far apart. Urgency is effectively
Helmut> removed by Lucas agreeing to pause further deprecation
Helmut> work. Do you think it would be impossible to move forward on
Helmut> this matter in a consensus-based way?

I think this is like usrmerge.
I actually think there is a rough consensus, but there are one or two
parties who find that consensus unacceptable and who are in a position
to block the consensus.

As an example, the text in policy 5.6.12 has been significantly revised
since Russ and I started discussing this issue in 2014.
It's possible that policy could be improved, but honestly I think that
policy is already consistent with the hypothesis I presented to the TC.

I also already tried to seek consensus where this is possible as DPL,
and included a pointer to my consensus call on the issues where there
was consensus in the material I already presented to the TC.

This is a case where people have slowly been building consensus since
2014.  One of the key stakeholders has not effectively participated
constructively, and so some things haven't been possible.

We're asking the TC to do the last mile work--review the existing
consensus-forming discussions, figure out where we are, and wrap it up
just like you did with usrmerge.

I've even tried to give you the key discussions that happened on
debian-devel.
I suspect one of the policy editors could go pull that together for
discussions on debian-policy, but if not, I'd be happy to do that work
if requested.

So, no, I do think this is ready for the TC to finish things up now.

--Sam


signature.asc
Description: PGP signature

Bug#1007717: Native source package format with non-native version

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Switching terminology to completely leave behind the terms
Russ> with ambiguous meanings isn't a bad idea, but if so we really
Russ> need a term that captures "is a packaging of an upstream
Russ> software package with a separate existence" versus "exists
Russ> solely as a Debian package."  "with-revision" or
Russ> "without-revision" doesn't feel to me like it does this.
Russ> Native and non-native do, which is why I was sticking with
Russ> them, but maybe we can come up with some other equally-good
Russ> terminology.

Why do we need that distinction?

Looking at current policy, 5.6.12 talks about having a debian revision
or not having a debian revision.

Other parts of policy talk about  what parts of the source package there
are.

Why do we need more than these two distinctions.

I think that current policy has mostly left behind the work native
(although their are a few uses still).
My suspicion is that avoiding native allowed us to get a broader
consensus in the policy process.

Why isn't what we have good enough?

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Sam Hartman]

> "Otto" == Otto Kekäläinen  writes:
Otto> Instead of manually trying to manage TMPDIR env variable in
Otto> various places, we should have a standardized way to run
Otto> maintainer scripts in clean shell sessions that have all env
Otto> variables set automatically correctly.

I think trusting TMPDIR when running a maintainer script as root is
fine.\
The sanitization should happen by sudo (or su or sshd) which is what
gates you into root privilege.

The issue with the mysql/mariadb scripts is that they are taking root's
environment and applying it to the mysql user.
So, those scripts need to do additional sanitization/trimming of the
environment.
But that comes up because those scripts are introducing a uid
transition.

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

[Sam Hartman]

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

Salvatore> The following vulnerability was published for krb5.

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

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

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


signature.asc
Description: PGP signature

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

[Sam Hartman]

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

Salvatore> Thank you.

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

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

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

Either way that's really bad.


signature.asc
Description: PGP signature

Bug#1021374: zephyr: reproducible-builds patches

[Sam Hartman]

> "Vagrant" == Vagrant Cascadian  writes:

Vagrant> Would you be amenable to an NMU to unstable applying the
Vagrant> following patches and fixing these issues? If yes, should I
Vagrant> build upon the package in experimental? Plans for using
Vagrant> salsa.debian.org? dgit?

I'd definitely be open to an nmu.
I'd recommend building on unstable and just uploading a source package.
Zephyr used to be maintained in subversion.  The maintainer died, and
discussions about how to convert to git kind of stalled out, which is
why the package is such a mess.


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Salvatore" == Salvatore Bonaccorso  writes:

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

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

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


signature.asc
Description: PGP signature

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

[Sam Hartman]

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

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

[Sam Hartman]

> "craig" == craig   writes:

craig> Inclusion into the Debian repository is a precursor to
craig> inclusion into Tails, which has been broadly requested in the
craig> Bitcoin community.  Sparrow is already released as a .deb
craig> package (see https://sparrowwallet.com/downloads/) as part of
craig> the standard release process.  I intend to maintain this
craig> package going forward.

In the past we've had a bit of trouble with bitcoin wallets in Debian
when security issues emerged.  If this package makes it into Debian
stable, will you be able to provide security support for the version in
stable without upgrading to new upstream versions for the release
lifetime of stable?


signature.asc
Description: PGP signature

Bug#932047: lightdm: greeter session support for elogind

[Sam Hartman]

> "Yves-Alexis" == Yves-Alexis Perez  writes:

Yves-Alexis> I'm not sure other display managers handle the greeters
Yves-Alexis> the same way (running under their own uid and stuff
Yves-Alexis> like that), so I'm unsure if we can really compare
Yves-Alexis> that.

gdm does.

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Sam Hartman]

> "Stephan" == Stephan Verbücheln  writes:

Stephan> As far as I understand it, the main point of BabaSSL is to
Stephan> add support for Chinese developed ciphers and algorithms.

It looked like there were two main points.
The first was in fact these ciphers.
I don't think that's a good reason for including in Debian because it
looks like OpenSSL is interested in adding these ciphers long-term, and
that appears a much better strategy for us as a ddistribution.

However there are some other features from the ITP:

-Support NTLS (formal GM dual-certificate protocol) handshake processing, 
according to GB/T 38636-2020
TLCP
-QUIC API support
-Support delegated credentials, according to draft-ietf-tls-subcerts-10

I don't recognize NTLS
and presumably since draft-ietf-tls-subcerts is a working group draft it
will be possible to get into OpenSSL eventually.

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Sam Hartman]

> "Bastien" == Bastien Roucariès  writes:
Bastien> I will like to stress that this kind of stuff is bad:
Bastien> 
https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec-
Bastien> support.preinst.in#L10

How would you do better in that instance?
I think everyone knows it's bad, but I'm guessing that the maintainer
didn't have a better approach for detecting whether the referenced
instructions worked on the installed system.

I'm assuming that if feature tests in /proc/cpuinfo were sufficient they
would have been used.

--Sam

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Sam Hartman]

roucaries> No the problem is not probing the cpu/cpuinfo...

Well, if the CPU info could be probed from shell, I'd argue that's
better than unpacking a binary.

roucaries> The problem is the base64 encoded binary.

Why is this bad.
I agree that it is esthetically displeasing, but *in this instance*, why
is it harmful?

roucaries> I ma solving this by pre-depends on a binary package and
roucaries> run the binary from the preinstalled package.

I would have been less caustic in my reply than Adam, but made the same
point.
Having multiple packages is more complex, especially in a situation
where the binary in question  is only used by the preinst.

It may be there are concerns I'm not seeing that make the current
arrangement worse than taht.
But let's actually articulate them.

Bug#1017995: Update CMS Digest Algorithm to SHA256

[Sam Hartman]

package: krb5-pkinit
version: 1.17-3+deb10u3
severity: important

Starting with RHEL9, Redhat updated the CMS digest signature to SHA256
instead of SHA1.
This makes sense after all since SHA1 was deprecated in 2011.
The main effect of this is that older clients will not be able to do
anonymous pkinit with a RHEL9 KDC.

MIT Kerberos has supported SHA256 signatures since version 1.15.

Update  the CMS digest algorithm for pkinit to SHA256.

This probably breaks compatibility with jessie and before.

So, assuming this is accepted for buster and bullseye (it's already in
sid and bookworm):

* Stretch will work with buster and jessie

* Buster and forward will work going forward up through sid but will not work
  with jessie or backward

Even if some problem results, anonymous pkinit (and pkinit in general)
is fairly rarely used.


signature.asc
Description: PGP signature

Bug#1017998: buster-pu: package krb5/1.17-3+deb10u4

[Sam Hartman]

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


[ Reason ]

Rhel9 deprecates SHA1 as a CMS digest algorithm.  Without this patch,
a buster client cannot perform (anonymous) pkinit to a RHEL9 KDC.
Pkinit is important enough that I'd like to see this fixed, but is not
so common that I'm worried about needing to do a huge cross-version
compatibility test before accepting the change.

That said, it looks like Redhat has fairly thoroughly researched the
compatibility issues.  Accepting this patch into buster probably
breaks anonymous pkinit from jessie to a buster KDC because jessie is
too old to support SHA256 for all the pkinit uses.  Stretch should be
new enough.

This has been in unstable as part of krb5 1.20 for a while.
Expect a bullseye update shortly.

[ Impact ]

Anonymous pkinit breaks against RHEL9 and probably bookworm+1.


[ Tests ]

I ran the automated pkinit tests and confirmed they have adequate coverage to 
test that I properly applied the patch.
I'm trusting Redhat's analysis for the cross-version testing.
Based on knowledge of the people involved and the description of the analysis I 
think that is appropriate.


[ Risks ]

See above.

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

[ Changes ]
(Explain *all* the changes)

diff --git a/debian/.git-dpm b/debian/.git-dpm
index fcd6a7f36e..713ff3581e 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-668523c82a2446609f3eab8688c8837c59b97de2
-668523c82a2446609f3eab8688c8837c59b97de2
+c5354e5b2e0ad5c68fc3f07ecf2c3ab3285d0f08
+c5354e5b2e0ad5c68fc3f07ecf2c3ab3285d0f08
 a75eb54fd955cbf7a8ac44e527fd0e400e87844a
 a75eb54fd955cbf7a8ac44e527fd0e400e87844a
 krb5_1.17.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index 45d55810ea..8167db8a4d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+krb5 (1.17-3+deb10u4) buster; urgency=medium
+
+  * Use SHA256 as Pkinit CMS Digest, Closes: #1017995
+
+ -- Sam Hartman   Tue, 23 Aug 2022 14:28:40 -0600
+
 krb5 (1.17-3+deb10u3) buster; urgency=high
 
   * Fix KDC null dereference crash on FAST request with no server field,
diff --git 
a/debian/patches/0016-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch 
b/debian/patches/0016-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
new file mode 100644
index 00..6bef568521
--- /dev/null
+++ 
b/debian/patches/0016-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
@@ -0,0 +1,128 @@
+From c5354e5b2e0ad5c68fc3f07ecf2c3ab3285d0f08 Mon Sep 17 00:00:00 2001
+From: Julien Rische 
+Date: Fri, 11 Mar 2022 12:04:14 +0100
+Subject: Use SHA-256 instead of SHA-1 for PKINIT CMS digest
+
+[ghud...@mit.edu: edited comments]
+
+ticket: 9055 (new)
+---
+ .../preauth/pkinit/pkinit_crypto_openssl.c| 41 +++
+ 1 file changed, 23 insertions(+), 18 deletions(-)
+
+diff --git a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 
b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+index 5ff81d8cf4..66b09c6f41 100644
+--- a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
 b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+@@ -1237,7 +1237,7 @@ cms_signeddata_create(krb5_context context,
+ /* will not fill-out EVP_PKEY because it's on the smartcard */
+ 
+ /* Set digest algs */
+-p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha1);
++p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha256);
+ 
+ if (p7si->digest_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_alg->parameter);
+@@ -1248,7 +1248,8 @@ cms_signeddata_create(krb5_context context,
+ /* Set sig algs */
+ if (p7si->digest_enc_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_enc_alg->parameter);
+-p7si->digest_enc_alg->algorithm = 
OBJ_nid2obj(NID_sha1WithRSAEncryption);
++p7si->digest_enc_alg->algorithm =
++OBJ_nid2obj(NID_sha256WithRSAEncryption);
+ if (!(p7si->digest_enc_alg->parameter = ASN1_TYPE_new()))
+ goto cleanup;
+ p7si->digest_enc_alg->parameter->type = V_ASN1_NULL;
+@@ -1259,16 +1260,17 @@ cms_signeddata_create(krb5_context context,
+ alen = data_len;
+ } else {
+ /* add signed attributes */
+-/* compute sha1 digest over the EncapsulatedContentInfo */
++/* compute sha256 digest over the EncapsulatedContentInfo */
+ ctx = EVP_MD_CTX_new();
+ if (ctx == NULL)
+ goto cleanup;
+-EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
++EVP_DigestInit_ex(ctx, EVP_sha256(), NULL);
+

Bug#1017999: bullseye-pu: package krb5/1.18.3-6+deb11u2

[Sam Hartman]

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

[ Reason ]

Rhel9 deprecates SHA1 as a CMS digest algorithm.  Without this patch,
a bullseye client cannot perform (anonymous) pkinit to a RHEL9 KDC.
Pkinit is important enough that I'd like to see this fixed, but is not
so common that I'm worried about needing to do a huge cross-version
compatibility test before accepting the change.

That said, it looks like Redhat has fairly thoroughly researched the
compatibility issues.  Accepting this patch into bullseye probably
breaks anonymous pkinit from jessie to a bullseye KDC because jessie is
too old to support SHA256 for all the pkinit uses.  Stretch should be
new enough.

This has been in unstable as part of krb5 1.20 for a while.  Companion
to the just submitted buster update.  The patch is slightly different
because I had to backport one of the changes and because bullseye uses
gbp pq while buster uses git-dpm.



[ Impact ]

Anonymous pkinit breaks against RHEL9 and probably bookworm+1.


[ Tests ]

I ran the automated pkinit tests and confirmed they have adequate coverage to 
test that I properly applied the patch.
I'm trusting Redhat's analysis for the cross-version testing.
Based on knowledge of the people involved and the description of the analysis I 
think that is appropriate.


[ Risks ]

See above.

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

[ Changes ]
(Explain *all* the changes)
diff --git a/debian/changelog b/debian/changelog
index 0be31136f4..d6eaa38262 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+krb5 (1.18.3-6+deb11u2) bullseye; urgency=medium
+
+  * Use SHA256 as Pkinit CMS Digest, Closes: #1017995
+
+
+ -- Sam Hartman   Tue, 23 Aug 2022 14:49:09 -0600
+
 krb5 (1.18.3-6+deb11u1) bullseye; urgency=medium
 
   * Fix KDC null dereference crash on FAST request with no server field,
diff --git 
a/debian/patches/0013-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch 
b/debian/patches/0013-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
new file mode 100644
index 00..720bca3bc7
--- /dev/null
+++ 
b/debian/patches/0013-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
@@ -0,0 +1,119 @@
+From: Julien Rische 
+Date: Fri, 11 Mar 2022 12:04:14 +0100
+Subject: Use SHA-256 instead of SHA-1 for PKINIT CMS digest
+
+[ghud...@mit.edu: edited comments]
+
+ticket: 9055 (new)
+---
+ src/plugins/preauth/pkinit/pkinit_crypto_openssl.c | 40 --
+ 1 file changed, 22 insertions(+), 18 deletions(-)
+
+diff --git a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c 
b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+index 8c7fd0c..4452d4e 100644
+--- a/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
 b/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
+@@ -1227,7 +1227,7 @@ cms_signeddata_create(krb5_context context,
+ /* will not fill-out EVP_PKEY because it's on the smartcard */
+ 
+ /* Set digest algs */
+-p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha1);
++p7si->digest_alg->algorithm = OBJ_nid2obj(NID_sha256);
+ 
+ if (p7si->digest_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_alg->parameter);
+@@ -1238,17 +1238,18 @@ cms_signeddata_create(krb5_context context,
+ /* Set sig algs */
+ if (p7si->digest_enc_alg->parameter != NULL)
+ ASN1_TYPE_free(p7si->digest_enc_alg->parameter);
+-p7si->digest_enc_alg->algorithm = 
OBJ_nid2obj(NID_sha1WithRSAEncryption);
++p7si->digest_enc_alg->algorithm =
++OBJ_nid2obj(NID_sha256WithRSAEncryption);
+ if (!(p7si->digest_enc_alg->parameter = ASN1_TYPE_new()))
+ goto cleanup;
+ p7si->digest_enc_alg->parameter->type = V_ASN1_NULL;
+ 
+ /* add signed attributes */
+-/* compute sha1 digest over the EncapsulatedContentInfo */
++/* compute sha256 digest over the EncapsulatedContentInfo */
+ ctx = EVP_MD_CTX_new();
+ if (ctx == NULL)
+ goto cleanup;
+-EVP_DigestInit_ex(ctx, EVP_sha1(), NULL);
++EVP_DigestInit_ex(ctx, EVP_sha256(), NULL);
+ EVP_DigestUpdate(ctx, data, data_len);
+ md_tmp = EVP_MD_CTX_md(ctx);
+ EVP_DigestFinal_ex(ctx, md_data, &md_len);
+@@ -1276,12 +1277,14 @@ cms_signeddata_create(krb5_context context,
+ goto cleanup2;
+ 
+ #ifndef WITHOUT_PKCS11
+-/* Some tokens can only do RSAEncryption without sha1 hash */
+-/* to compute sha1WithRSAEncryption, encode the algorithm ID for the 
hash
+- * function and the hash value into an ASN.1 value of type DigestInfo
+- * DigestInfo

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Sam Hartman]

> "Bill" == Bill Allombert  writes:


Bill> What if the user change their CPU afterward ?  This should
Bill> probably be tested at boot time instead.

There was a long thread on debian-devel about the potential issues with
isa-support:
https://lists.debian.org/yj5dazgacdgtp...@angband.pl

So, what you say is true, but isa-support has an existing interface it
needs to stay consistent with that involves checking at install time.
I think we're all agreed that we want to find alternatives to that
interface, but the policy question is about what ways of implementing
the existing interface are consistent with policy.

Bug#986320: Stronger advice on when to use native packages

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

Holger> On Mon, May 09, 2022 at 07:16:59PM -0700, Jonathan Nieder wrote:
>> > Even if that consensus does not exist, there is probably
>> consensus > that native packages are a poor match for large
>> packages (because of > the inefficiency of making small updates
>> to the packaging of native > packages), Do you mean large
>> packages with a separate upstream existence, or large packages in
>> general?  I don't think there's such a consensus for large
>> packages in general: if Debian is the canonical place for a
>> particular package to be released (e.g., as is true for dpkg),
>> then it doesn't seem like it would be worth the overhead of
>> making two releases, one upstream and one for packaging, whenever
>> updating that package.
 
Holger> speaking as the debian-edu-artwork maintainer, which at one
Holger> point in time was a >50mb sized native package: it's pretty
Holger> annoying to upload 50 or more megabytes for a 2 byte fix of
Holger> a maintainer script.

I'd much rather upload  a 50M package regularly than deal with the vcs
complexity of separate maintainer and upstream releases in a lot of
cases.
10 years ago sure, that would have been annoying for me, but these days
with modern networks 50M is not a big deal.

Granted not everyone has a fast network.

If there is a consensus that the upstream source split is important for
large packages, it is fairly rough.
I'd definitely like to call that consensus into question and suggest
that it's unclear whether it exists.
It may; my opinion on this issue is definitiely on one side, and that
would make me a poor choice to judge the consensus here.
However, I don't want us to move forward assuming that consensus exists
without actually exploring it.

Bug#1007717: attempt to summarize current state of this bug

[Sam Hartman]

> "Matthew" == Matthew Vernon  writes:

Matthew> Hi, I thought it might be useful to try and summarize where
Matthew> we are with this bug, which hasn't see much recent activity
Matthew> (not least as there's a TC meeting later...).

I read your summary and agree it is accurate.  Thank you.


signature.asc
Description: PGP signature

Bug#1009927: krb5: deprecated encryption type for master_key_type

[Sam Hartman]

> "Benjamin" == Benjamin Kaduk  writes:

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

Agreed.

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

For new installations, I think that's fine.  I think going back and
changing kdc.conf on existing installations would be fine so long as
they aren't old enough to use the pre-keytab stash file format.
As I recall that format didn't include enctype.
But I think that was a really long time ago.

I'll remove the master_key_type from kdc.conf in an upload soon.
I'll also add a news item recommending that people upgrade their master
key.
We can talk about how much automated upgrade is possible, but in the
case of kpropd, that's going to be hard.

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

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> Dear maintainer,

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

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



signature.asc
Description: PGP signature

Bug#1014829: kerberos-configs: consider setting rdns=false by default

[Sam Hartman]

Andreas> According to [1], the upstream implicit default of "rdns =
Andreas> true" is there for historical reasons only, and upstream
Andreas> suggests to consider setting it to "false":

Andreas> """ Consider setting rdns to false in order to reduce your
Andreas> dependence on precisely correct DNS information for service
Andreas> hostnames. Turning this flag off means that service
Andreas> hostnames will be canonicalized through forward name
Andreas> resolution (which adds your domain name to unqualified
Andreas> hostnames, and resolves CNAME records in DNS), but not
Andreas> through reverse address lookup. The default value of this

Yeah, this makes sense.
Thanks for reporting this.


I will try to get to this and getting krb5 1.20 into unstable by end of
DebConf.  I'm not at the conference, but that's a good time frame to
give myself a deadline.

Bug#1005821: please stop depending on bind9-host

[Sam Hartman]

control: retitle -1 Make krb5-config recommends
control: reassign -1 krb5-user

> "Michael" == Michael Tokarev  writes:

Michael> Um. I misfiled this bugreport actually. I started writing
Michael> it against krb5-user and realized the bind9-host dependency
Michael> comes from krb5-config not krb5-user.

Michael> And I think it is better to make krb5-CONFIG optional, not
Michael> krb5-USER.  Ie, for krb5-user, denote krb5-config from
Michael> Depends to Recommends.  Since actually, the only reason
Michael> krb5-config package is needed for krb5-user (and other krb5
Michael> stuff actually) is to *create* the initial configuration,
Michael> it does not need krb5-config package for runtime
Michael> operations, ie. krb5-config can be removed after
Michael> installation.

I agree with this analysis and will implement the change in a future
krb5 upload.
I wish I had looked at this bug in general  before the krb5 upload I
made Friday.


signature.asc
Description: PGP signature

Bug#858970: Still not in Debian

[Sam Hartman]

In hopes of honoring this request, I just looked at the heimdal sources
in debian.  I cannot find evidence of the includedir or include
krb5.conf directives there even in 2022.
Unless I'm missing something I still don't think it makes sense to add
this to Debian without heimdal support.

Bug#991859: Is a different opinion about a license a case for the ctte?

[Sam Hartman]

[I  accidentally sent this as a private reply earlier this morning
 before Phil's message.]
 
 TL;DR: you don't have any recourse that is appropriate for this
 situation.
 All the hammers are bigger than your nail.

 > "Andreas" == Andreas Tille  writes:

 Andreas> Hi folks, before I follow the advise how to refer a
 Andreas> question to the CTTE[1] I'm wondering whether licensing
 Andreas> questions are also a topic here.  I admit I'm a bit unsure
 Andreas> whether this minor issue about a license is really worth
 Andreas> that even more people spent time into it.  I'm demotivated
 Andreas> myself by no progress in something I would consider
 Andreas> nitpicking about a non-issue.  But I would like to use this
 Andreas> as a general example to know whether CTTE could be of help
 Andreas> in licensing questions.

 The secretary ruled that the CT cannover overrule a delegate acting in
 their delegated responsibility,
 so no the CT cannot overrule ftpmaster.

 The CT could give advice to ftpmaster, especially if ftpmaster requested
 that advice.
 I'd expect the CT would be reluctant to give non-technical advice.

 The CT could set *technical policy* and I'd expect delegates would
 generally be expected to follow reasonable technical policy established
 by the CT or be accountable to the DPL and membership at large.
 However, I don't really think that license standards are technical
 enough to be technical policy.

 ftpmaster could establish an appeals procedure.

 The DPL could establish another set of delegates for setting license
 policy and separate that out from the ftpmaster delegation.
 I.E. someone sets license policy, and ftpmaster interprets it.
 That said, some questions could not be separated.
 In particular, because of liability concerns, if ftpmaster believes
 something is not redistributable, it would be highly inappropriate to
 ask them to redistribute it in the current Debian liability model.

 Any of this could be handled by a GR.

Bug#1016544: pipewire-pulse: pacmd says no pulseaudio daemon running

[Sam Hartman]

Package: pipewire-pulse
Version: 0.3.56-1
Severity: normal

Many of the pipewire docs imply that pacmd ought to work even when 
pipewire-pulse is running.

Unfortunately, when I run

hartmans@industrial-algebra:~(1)> pacmd info
No PulseAudio daemon running, or not running as session daemon.

Other users on #debian-devel reported the same.
strace gets as far as reading $XDG_RUNTIME_DIR/pulse/pid, then looking up info 
on that process in /proc, then starting to open message catalogs.

I'm happy to provide more information as needed.


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

Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 pipewire-pulse depends on:
ii  init-system-helpers  1.60
ii  pipewire 0.3.56-1

pipewire-pulse recommends no packages.

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  0.3.56-1
ii  pulseaudio-utils  15.0+dfsg1-4+b1

-- no debconf information

Bug#1007717: Updated draft resolution

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:
Helmut> Indeed, and I do agree that 4c is such a clear statement. I
Helmut> would like to see a stronger statement here, but Sam et
Helmut> al. tried to gain consensus on that and there wasn't. So the
Helmut> CTTE advice probably shouldn't override that
Helmut> non-consensus. That makes 4c a lot more of an attractive
Helmut> option to me.

Actually, I think the TC making a decision when the project is unable to
come to consensus is often a great outcome.
The TC is one of our decision making options.  During my DPL term, the
TC did not appear to have the credibility to be a popular option for me
to go to when my consensus-making attempts got part of the way.
However, if the project is functioning well, I think that the TC is a
great option short of a GR.
I think that has worked well with usrmerge recently.

I DO NOT think this bug is the place for the TC to recommend something
like  the maintainer view of git source packages should be a
patches-unapplied format.
I think it would be great if the TC would take that on in a separate
bug.
If you would like me to pose such a question to the TC I'd be happy to
do so.
Driving a GR discussion on that issue is too much for me, but posing a
question to the TC is within the  energy I have available.

--Sam


signature.asc
Description: PGP signature

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> using other choices of "Rules-Requires-Root" than "no" and
Ansgar> "binary-targets".  The query [1] found two uses:

Can you help me understand how options other than binary-targets or no
were supposed to work/what they make possible?
I have found the policy text in this area a bit opaque.
I'd like to understand what we'd be giving up if we adopt your proposal.

Is this facility not used simply because everyone reads it and like me
goes "huh what does that really mean," and never gets around to thinking
it through?
Or is it an extension point we actually don't need?

Also, how much of the complexity cost you are concerned about has
already been paid and how much of it is ongoing?
Ignore for the moment maintenance in packages like dpkg-dev and sbuild.
I'm basically asking how many new tools over time are likely to need to
care about this complexity if we keep it.
I appreciate that you probably do care about the maintenance costs in
dpkg-dev, but our value functions probably diverge a bit there.

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

Here's my take on the discussion so far.
And I want to stress that I am not a policy editor, and to the extent
that they read the discusssion differently than I do, their reading
controls.

* Russ and I would be willing to accept either outcome--either you can
  collapse years or you cannot.

* Holder, you and I would prefer that you be able to collapse years.

* Sean would prefer that you not be able to collapse years.  He hasn't
  said whether his objection is strong enough to try and block
  consensus.

* I think there is a strong consensus that we want to make a change
  along the lines of one of your patches.

* I don't think anyone in the discussion so far would object to your
  second patch.  However, a majority of the participants might prefer
  your first patch.  Sean might object to that, and Russ might
  potentially think we haven't yet gotten enough showing of support to
  go that direction.

This is one of those awkward situations in consensus decision making
where you have to decide whether you're going to take the option
everyone can live with or do a bit more work and possibly get  an answer
that the community overall supports (even though some people do not).
What we should definitely avoid doing is losing energy and making no
change at all.

--Sam

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> That said, I tend to be hyper-conservative and nit-picky about
Russ> things like this, accurately representing copyright years
Russ> isn't in my top thousand things I want people to work on in
Russ> Debian, and I'm highly dubious that it will ever matter or
Russ> anyone will ever care.  So I'm very open to being told I'm
Russ> being much too cautious.

My rationale is that debian/copyright is a summary, it's not the license
text in the files.
I absolutely agree we shouldn't go change people's actual copyright
notices in the files.

And, I'm fairly convinced that it can never hurt us.  I mean if someone
came along and actually bothered to send us a legal letter, or even a
strongly worded bug report as a copyright holder, we'd go  use their
preferred notice.
What sort of damage are they going to be able to show because we listed
2009-2020 instead of 2009, 2012, 2019-2020.

As a copyright holder I'd probably be more annoyed at the hyphen instead
of the n-dash rather than the notice.  But that's  just me.

But I totally understand we're well into bikeshedding here.

On the compromise front, how would people feel about leaving the gap
years question ambiguous in policy?
That is, we clearly agree you can combine years across files, our
question is whether you can insert years that appear in no file.
Could we just sidestep the issue and leave that ambiguous?

Bug#975250: clarify gathering together of copyright information

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> Let us be honest with ourselves: what matter for most purpose
Bill> is the position of the ftp-master team that processes the NEW
Bill> queue.  What policy says is secondary.

I absolutely agree we should coordinate appropriately with the ftp team.

Bug#963754: nmu: moonshot-gss-eap_1.0.1-6

[Sam Hartman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu moonshot-gss-eap_1.0.1-6 . ANY . unstable . -m "Rebuild for shibboleth 
transition"

Please rebuild moonshot-gss-eap now that new libshibsp-dev and 
libshibresolver-dev are in unstable.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sam Hartman]

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

Johannes> Control: user debian-d...@lists.debian.org Control:
Johannes> usertag -1 + dpkg-root-support

Johannes> Hi Sam,

Johannes> Quoting Helmut Grohne (2021-09-24 18:14:28)
>> So if you continue refusing our patches, can you propose any
>> other way to move forward?

Johannes> it has been a month since your last mail, so I wanted to
Johannes> send a friendly ping to ask, whether there is anything
Johannes> else we can do to help you with this bug.

No.
I'm waiting for Steve to chime in.
I do owe you and Helmut an explanation of why I'm uncomfortable, but I
think that belongs outside of this bug.
If this were my package entirely, I'd accept the patch, but my rationale
for doing so would be because I respect all the work Helmut has done and
I'm uncomfortable standing in the way of that.
In a case where I'm not really the maintainer, simply someone helping
out, that's not a good enough rationale.

Bug#997960: Debspawn deletes anything mounted in a container

[Sam Hartman]

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

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

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

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




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

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debspawn depends on:
ii  debootstrap1.0.123
ii  python33.9.2-3
ii  python3-toml   0.10.1-1
ii  systemd-container  247.3-6
ii  zstd   1.4.8+dfsg-2.1

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

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

-- no debconf information

Bug#998361: pam FTBFS

[Sam Hartman]

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

Johannes> Hi,

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

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

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

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

Bug#935769: On the Removal of src:tensorflow

[Sam Hartman]

> "Mo" == Mo Zhou  writes:

Mo> Hi -devel, I've just filed an RM(#935769) bug against
Mo> src:tensorflow and I believe this is the most appropriate choice
Mo> at this stage. For packages that would easily draw attention
Mo> from the media, not providing them would be much better than
Mo> providing something much inferior than the users expected
Mo> (Recall "difficulty ... DL framework" and "conda ...").


I'm speaking as an individual here, not as the DPL.

I actually think it's valuable to provide Debian packages even if the
performance is not what users would want.
Provided that people are working on the packages and improving them.
Doing so makes it easier to free things up in the future, makes it
easier to understand what we don't have, etc.

I here that you no longer find it valuable to do this work.  And if
there aren't maintainers who are interested in working to improve the
situation, I definitely think it is best to remove the package.

I think the part of your message I'm disagreeing with is the desire to
discourage people from reintroducing the package in the future.

I think you've done a good job of documenting the obstacles.  I think
anyone who wants to reintroduce the package should consider the
obstacles you've documented.

But either if because they have work-arounds for those obstacles or
because they see it as worth their time without  work arounds, I think
that's OK.

Although, I'll admit that they're probably going to have to do
somethingf about a build system.  We don't have a lot of use for
packages that don't build:-)
I think what I'm trying to say is that it's great to step away from work
when you don't see value  It's great to document problems others would
face in the future.
But the bar for telling others not to do things they find valuable is
probably a lot higher.

As always thanks for all your work and especially for writing up your
results!

--Sam

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Sam Hartman]

> "Mark" == Mark Hindley  writes:

Mark> Michael,
Mark> On Tue, Sep 03, 2019 at 04:56:13PM +0200, Michael Biebl wrote:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934491
>> 
>> This bug report should be taken into account here. Not sure why
>> this is not marked as RC given that it can pretty much hose your
>> system.

Mark> If you actually read to the end of that report you will see
Mark> the suggestion that this behaviour is actually caused by apt
Mark> and/or dpkg, not elogind.

First, thanks for your work on elogind.
I appreciate the professional manner you've handled the communication
with the release team on this issue, the professional manner in which
you worked with the systemd maintainers to get to the current elogind
design, and the professional manner in which you worked through##934491.

I do agree with simon that #934491 does leave the system in a really bad
state.  And while I agree with you that it is not elogind's fault, it's
a situation that tends to only come up when elogind is in the picture.
I think Michael has a point that we should consider the impact of
#934491 on bullseye before introducing the elogind in sid to bullseye.

>From where I sit that impact is fairly significant, and I can see
wanting to fix apt or dpkg or whatever we're going to fix prior to
making that change in bullseye.

I can also see the argument that it's fairly early in the cycle and this
issue is not elogind's fault as discussed in #934491.

Bug#939483: krb5: Python2 removal in sid/bullseye

[Sam Hartman]

control: tags -1 fixed-upstream

The next major version of krb5 will be able to use python3 for docs
building, which is the major remaining use of python2 in the krb5
build/test system.
I expect that we'll be moving to that version soon enough that it will
not be a problem.
If things progress and you end up raising severity of this bug I can
backport changes.

--Sam

Bug#953378: Retitling to RFP

[Sam Hartman]

control: retitle -1 RFP: rake_nltk -- RAKE implemented in Python for nltk
control: noowner -1

Dear Daniel:

As you are aware, you have been expelled from the project as a Debian
Developer and then later removed from the Debian Maintainer
keyring in response to ongoing concerns with your behavior.

For these reasons, it is not appropriate for you to maintain packages.
As Project Leader with concurrence of two members of the ftpmaster team,
I confirm that Debian does not welcome you as a package maintainer.  I
request that anyone maintaining a package based on packaging you have
prepared audit that packaging as if it comes from an external source.
Since you cannot be a package maintainer, I am retitling this bug to RFP
instead of ITP.


Moreover, it is inappropriate for you to describe yourself as a Debian
Developer, as you did in your message filing the ITP.  Constitution
section 3.2 notes that the Project Leader's Delegates (in this case the
account managers) may expel developers; in your case this has happened.
So, you must not describe yourself that way or represent yourself as
speaking on behalf of the Debian Project.  Without limitation to other
circumstances, this includes when interacting with the Debian community,
its members, the BTS, and (without limitation) other aspects of the
community.  Such misrepresentations are unacceptable behavior in our
community.

In response to some of the same actions that ultimately ended up in your
key being removed from the maintainer's keyring, you were banned from
all our lists.
I reviewed how to respond to this ITP with members of ftpmaster, members
of the account manager team and members of the community team.
As part of that discussion, the question came up as to whether you were
welcome at all in our community.
With the concurrence of members of the account managers, ftpmaster, and
community team, I conclude that you are not welcome in the Debian
Project.
Please stop all interactions with our lists, our BTS, our forums,
salsa.debian.org, and any other Debian Project communications channels.
Allowing your activity and presence in our community would only
support behavior that is not welcome in our community--behavior that you
have declined to stop despite multiple requests from multiple parties
over an extended period of time.


As a general rule, the project avoids discussing expulsions in public.
However, your choice to represent yourself as a Debian Developer and to
attempt to act as a Debian Developer after you have been expelled put
the project in a position where we have chosen to make an exception to
that general rule so that our community can understand the situation and
understand that we do value acting to make Debian a place where people
can work free from disruption or harassment.

Sam Hartman
Debian Project Leader


signature.asc
Description: PGP signature

Bug#953378: enough conflict

[Sam Hartman]

> "Melanie" == Melanie Frost  writes:

Melanie> The volunteer was elected as a community representative and
Melanie> he's been hounded ever since.  It looks like he asked
Melanie> people to stop these games, he resigned and he was still
Melanie> chased.

The issue is that Daniel is still chasing us.
In this specific instance, I responded because Daniel filed an ITP.
If Daniel resigned and stopped interacting with the Debian community, we
would be a lot happier, and I would not have chosen to respond this way.

The primary issue from Debian's side is that Debian has asked someone to
leave--to stop interacting.  And yet they are still interacting by doing
things like filing ITPs.  We are not chasing anyone.  We are responding
and reacting to being chased on websites like debian.community, in our
own BTS, and in other fora.  We are responding to being chased by having
messages bcc'd to large numbers of our contributors even after we have
banned someone from posting to our lists.  In some cases, this has been
done by Daniel.  In other cases this has been done by people using
anonymous accounts using techniques that are very similar to techniques
described on a website run by Daniel.  We reject these forms of
interaction.  If it were not for these forms of interaction, we would be
much less vocal/much less interested in making public statements.

--Sam

Bug#939483: Python2 use in krb5

[Sam Hartman]

Thanks for the prod.  I think I can do what you need, but probably not
in the way you suggest.

I'm finding that finishing out my DPL term is taking up enough of my
time that  I don't really want to pull in a new krb5 upstream right now.
However it looks like pulling in the patches to the doc build machinery
shouldn't be bad at all.
My plan is to do something to remove the python2 dependency in the next
couple of days for you.
I'd prefer to handle the new upstream krb5 in May if I can.
But I'll do something, because I understand this is important.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Sam Hartman]

Actually directly switching on vendor seems fairly bad.

However, to the extent that downstream changes can be encapsulated into
options/deltas that someone might want, I think it may often be
reasonable to carry the delta in Debian.

So imagine that Ubuntu and several other downstreams care more about
security and hardening than they do about backward compatibility and
they choose to change a number of gcc and other tool defaults in support
of that.  I realize my example is not entirely hypothetical, but I want
to emphasize I have not researched to get all the details right, because
it doesn't matter.

Especially if multiple downstreams or individual users who build from
source might want the change, I think carrying the delta in  the Debian
source package can be valuable.  It needs to be balanced against a lot
of other concerns.

However, I do tend to agree with Ian that actually turning on that delta
in a specific vendor environment may be best carrief as a
vendor-specific source package.

That said, even there there are tradeoffs.
As an example, Ubuntu tries to use unmodified Debian source packages
where possible.  In some cases I think that the maintenance advantages
of doing this and the slight but real political pressure it creates to
push changes upstream to Debian may justify switching on dpkg-vendor.

I think my point here is that there's a lot of complexity, and I'm not
even convinced it would be desirable to recommend against using
mechanisms like dpkg-vendor.
I think what we can hopefully all agree on is that the dpkg vendor patch
series as bad.
Perhaps before we go and recommend something specific we can actually
write up some of these tradeoffs and give people the information they
need to make informed decisions.

And yes, in many cases dgit is the answer.  That said, if I were
maintaining the same package both for Debian and for the downstream I
work on, I might well value having a single source tree enough to use
dpkg-vendor or lsb-release or something to switch.

Bug#904558: What should happen when maintscripts fail to restart a service

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> the error path is most important were packages that provide a
Simon> system-level API to other packages, so their failures are
Simon> likely to cause other packages to fail to configure (such as
Simon> local DNS caches and authentication services like LDAP); and
Simon> packages that provide remote access, so their failures need
Simon> to be fixed before a potentially remote sysadmin logs out to
Simon> prevent the sysadmin from being locked out longer-term (like
Simon> sshd).

As a maintainer of one of the more important packages (krb5-kdc and
krb5-admin-server), ;I'd like to chime in here.  krb5-kdc provides
enterprise level authentication and if it fails may well take out
authentication for an entire environment.

Even so,  I've found that causing upgrades to fail does far more harm
than good even for this package.

Here is my experience based on my own observations and based on bug
reports and helping people diagnose problems in krb5:

* The vast majority of failures are when krb5-kdc gets installed on a
  system where it is not actually needed, or where it was partially
  configured for  a test.  In these cases, breaking an kupgrade does
  much more harm than good.  It may break other services, because those
  services may end up in a half-configured state, so a service that is
  not critical for a given system may break critical services for that
  system.

* When krb5 is a critical service, it's failure is going to be quite
  obvious regardless of whatever the maint script does.

* It is almost always the case that debugging  the situation involves
  installing some package and that  the first thing I end up doing is
  walking a user through adding exit 0 at the top of postinst in
  /var/lib/dpkg/info before going forward.  Even if  I don't need some
  additional tool, I've been burned by other parts of the system being
  in half-configured state.

* Leaving large chunks of the system in half-configured states is about
  one of the worst things you can do for system stability.  It's not
  something we test very often, and the interactions are very difficult
  to predict.

If I understood the cause of an error in a maintainer script and knew
that it indicated a problem that the sysadmin needed to fix (and one
that likely indicated krb5 was important on this system) I would be open
to returning a failure in postinst.
In almost all other situations I'd rather simply let the service fail to
start.


signature.asc
Description: PGP signature

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Sam Hartman]

>>>>> "Wouter" == Wouter Verhelst  writes:

Wouter> On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote:
>> That said, even there there are tradeoffs.  As an example, Ubuntu
>> tries to use unmodified Debian source packages where possible.
>> In some cases I think that the maintenance advantages of doing
>> this and the slight but real political pressure it creates to
>> push changes upstream to Debian may justify switching on
>> dpkg-vendor.

Wouter> I disagree with that, because it forgets why you're pushing
Wouter> things to Debian.

Wouter> The point of pushing things upstream is so that you as well
Wouter> as upstream end up being the same, and the maintenance
Wouter> difference disappears. By switching on dpkg-vendor, you're
Wouter> *not* the same; instead, you're hiding your difference. This
Wouter> is not generally helpful; it simply moves the maintenance
Wouter> burden from Ubuntu to Debian (where it simply does not
Wouter> belong).

I think that we're agreed that evaluating the maintenance burden is
exactly the right criteria.


Imagine a case where the same folks are maintaining a package for
multiple distributions and where the difference is small but important.
In such a case I think our users and the free software community might
best be served by a single repository and switching on something a lot
like dpkg-vendor.

Imagine a case where  it's a different set of people doing the work for
Debian than the distribution that wants the change.  The Debian
maintainers are not  in a good position to test the change and have no
desire to do so.  There, switching on vendor seems like the wrong
option.

We're a group of volunteers; we encourage cross-project collaboration
and working together.  I  believe that the primary consideration should
be what reduces the burden on those doing the work.  There are secondary
considerations of course.

--Sam

Bug#904558: What should happen when maintscripts fail to restart a service

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian>  * If the maintainer has no particular reason to diverge the
Ian> right answer is usually to fail the postinst with init systems
Ian> that do not provide service supervision; but to not fail the
Ian> postinst with ones that do.  (I think from earlier messages
Ian> that this is how the default implementations already work.)

So, it's not really the case that this is the default for init systems
today, and that actually has some important historical significance and
implications for perceived user-facing changes.

It's absolutely been the case that if an init script (init.d lsb script)
fails, the default behavior was to fail the postinst.

However, start-stop-daemon did not detect a lot of failures, especially
after fork.
So, there are all sorts of  things that caused daemons to fail to start
that used to not cause postinst failures.

I don't know what the default is today, but certainly for Jessie and for
a lot of the stretch cycle, dh_installinit would fail the postinst
whenever systemctl failed to start or restart a service.

Now, depending on how you wrote your service units, you might get the
same behavior as with sysvinit.  But you probably didn't do that.
So, suddenly, a whole bunch more conditions started showing up  as
things that caused postinst to fail.

If somewhere in stretch and with the migration from dh_installinit for
service units fto dh_systemd_*, we managed to change the default, then
we're probably reasonably close to what happened in the pre-systemd
days.  And that was reasonably OK.

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:


Wouter> But in the general case, I feel that downstream packaging
Wouter> changes belong downstream, not in Debian; therefore it is
Wouter> best to recommend that, in the general case, packages in
Wouter> Debian do not switch on dpkg-vendor.

Right.  Where as I believe it's not that clear cut and would rather
simply outline a bullet list of tradeoffs for maintainers to consider.

I'd be OK with a general case recommendation though; it's just not how
I'd do it if I were writing text.

And for the record, there are times when I've chosen to ship debian
directories upstream because it was the right thing in that case.
And I've dropped the upstream directory when circumstances changed.
There though, I agree with you that there is a dominant answer: don't
ship debian directories upstream.

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

[Sam Hartman]

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

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

Sebastian> This means an upload from exp to unstable?

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

Bug#926477: dgit accepts short keyid even though debsign does not

[Sam Hartman]

Package: dgit
Version: 8.3
Severity: important

Dear Maintainer,

Someone wrote in a forum that I can't quote here something along the
lines of it should be a bug for any Debian package to accept a
short-form GPG keyid.  I agree.


Dgit still accepts short-form keyids (and it doesn't look like this
has been fixed in the repo) even though tools it calls does not.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt 1.8.0~rc4
ii  ca-certificates 20190110
ii  coreutils   8.30-3
ii  curl7.64.0-1
ii  devscripts  2.19.3
ii  dpkg-dev1.19.5
ii  dput1.0.3
ii  git [git-core]  1:2.20.1-1
ii  git-buildpackage0.9.13
pn  libdigest-sha-perl  
ii  libdpkg-perl1.19.5
ii  libjson-perl4.0-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblocale-gettext-perl  1.07-3+b4
ii  libtext-glob-perl   0.10-1
ii  libtext-iconv-perl  1.7-5+b7
ii  libwww-perl 6.36-1
ii  perl5.28.1-3

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.9p1-5

Versions of packages dgit suggests:
ii  sbuild  0.78.0-2

-- no debconf information

Bug#926656: git-debrebase docs are intimidating

[Sam Hartman]

I don't know.
As I said in my mail I'm not even sure there's a problem here.

Let me give a bit of background here.
Ian and I had what I thought was a really exciting call about git and
source packages and stuff.

It sounded like Ian hopes we'll some day get rid of patches-unapplied
data models from our processes.  To do that, there needs to be something
to replace gbp pq in terms of simplicity and something that the average
developer can understand.  I said that I really didn't think git-dpm
counted; I liked git-dpm but found gbp pq lots simpler.  Ian nominated
git-debrebase as a gbp pq replacement.

I said I'd look.
My conclusion is that it's certainly a git-dpm replacement, and I'll
look at whether it is as easy to use in practice as gbp pq, but then I
wrote that note saying that I think its docs are harder to approach.

I think the one explicit concrete suggestion I'd make is to make it so a
casual user can read git-debrebase (1) without git-debrebase(5)
Or something so there's one man page that a user can start with that
tells them enough to get going, and that they can approach git-debrebase
without dgit.

Rationale:

1) dgit is more complex and has more failure modes because as we all
know, turning a git tree into a quilt dsc is really hard.

2) I think we're hoping eventually that pushing to salsa does the
dgit-like-thing (possibly by calling dgit) and users don't need to do
that themselves.

Bug#900912: Java Accessibility for Buster

[Sam Hartman]

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

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

Thanks for all your hard work,

--Sam

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

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.

The systemd maintainers proposed that dropping Also as well as some
changes to move toward dh_systemd_start being used even when sysvinit
scripts are present would help this situation.  Unfortunately it at
least doesn't look like those changes are in debhelper for buster.
Systemd folks, do you have any suggestions  on how to approach this for
buster?



signature.asc
Description: PGP signature

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

[Sam Hartman]

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

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sam Hartman]

I think there is another use of debian/copyright beyond just documenting
what ends up in the binaries.
I think that if I read debian/copyright in a source package, I should
expect to understand the licenses I need to comply with when dealing
with the source package.

So for example  if the package requires GPL-3 code during its build, and
by policy I don't want to deal with GPL-3 I should know I have a problem
only from reading debian/copyright.


So I think you need to talk about more than just binaries.

--Sam

Bug#954794: New packages must not declare themselves Essential

[Sam Hartman]

I concur with the comments raised so far.

I think it would be great to do a better job of outlining the problems
with essential packages in debian-policy.
I don't understand why we would tie our hands though.
A consensus of debian-devel seems adequate to consider those issues and
evaluate them.
If after making that consideration we decide to create a new essential
package, we're going to do that policy not withstanding.

I would support a statement in policy that as of the time of writing we
do not anticipate ever creating a new essential package.  That would
help people considering proposing making an essential package know they
are probably looking at things the wrong way.

--Sam

Bug#954794: New packages must not declare themselves Essential

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> But is it an actual problem ?  Do we see packages marked
Bill> Essential: yes by mistake ?

I think Josh's analysis brought up some important points for me that I
did not consider before and that need to be considered making decisions
in the future.
I think capturing that analysis in a pointer from policy or in policy is
important to me.

Bill> Each time we make policy longer we dilute the content.


Obviously, in the limit this is true.
I think that capturing rationale for things that have good rationale and
that could affect the project if not properly considered is worth doing
even though it makes policy longer.

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sam Hartman]

No, I missed this.
We're on the same page.

Bug#955622: release.debian.org: Testing auto removal claims moonshot-ui to be removed for bug it fixesmoonsot

[Sam Hartman]

Package: release.debian.org
Severity: normal

I got a message from testing auto removal saying:

>moonshot-ui 1.1.0+libsecret~2 is marked for autoremoval from testing on 
>2020-04-27

>It is affected by these RC bugs:
>952054: moonshot-ui: FTBFS: libmoonshot.vapi:45.34-45.56: error:
But that bug is *fixed* in moonshot-ui 1.1.0+libsecret2.


I'm guessing that this is probably some race condition between migration and 
removals data sources updating.
But it seems odd that the testing auto removal script knows about the new 
version but doesn't know that the new version  fixes the RC bug in question.

If the removal notice is correct and moonshot-ui is still scheduled for removal 
even though I fixed the bug, I'd like to better understand what's up.

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

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

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

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

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

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

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

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

Bug#905772: libvirtd upgrade broken stretch->buster

[Sam Hartman]

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#927725: Please build with --enable-mmdblookup

[Sam Hartman]

> "John" == John Goerzen  writes:

John> On Tue, Apr 23 2019, Michael Biebl wrote:

>> Am 23.04.19 um 11:12 schrieb Michael Biebl:
>> 
>>> But splitting each tiny module into a separate package adds
>>> significant overhead packaging-wise.
>> 
>> (not to forget NEW round trips)

John> What about an approach like exim4-daemon-light
John> vs. exim4-daemon-heavy?  Maybe have two rsyslogs, one of which
John> has all the deps enabled and the other doesn't.

Speaking entirely as an individual only vaguely familiar with the
situation.  I think that for rsyslogd a -extras package makes more
sense.  I don't think the deps have much of a cost if you don't install
them.

--Sam

Bug#924523: unblock: plinth/19.2

[Sam Hartman]

> "Sunil" == Sunil Mohan Adapa  writes:

Sunil> On 23/04/19 3:44 am, Ivo De Decker wrote:
>> Hi,


Sunil> However, there were still issues that we felt needed fixing
Sunil> for a stable release. Some of these fixes are workarounds for
Sunil> issues that were not fixed in other packages (such as #919517
Sunil> and smooth upgrade failures in other packages).

Sunil> Pretty much all the changes between 19.1 and 19.2 (version
Sunil> increment is because freedombox is a native package) were
Sunil> focused on Buster release during which we were not adding
Sunil> extra features.

I'm speaking as an individual who has been following freedombox in the
background for years and who has had to make decisions like what the
release team does in other projects.  I'm *not* speaking as the DPL even
a little bit.  And even if you follow my recommendations here, the RT
might be more conservative than you hope for.
 

In order to maximize the number of changes that can get in between 19.1
and 19.2, I recommend that you spend some time to make the release
team's job easier.


I'd recommend going through each commit, explaining why it meets the
release guidelines.

If it doesn't and you want to argue for an exception, be clear about why
that specific change is safe.  As an example, if one of your functional
tests covers it, say that.

Your job is to make sure that the release team can easily see in one
place why the change is worth the risk and that you've thought about it
explicitly and considered the option of dropping that change.

And you probably will find changes that it's better to drop.
Regardless of whether you missed the deadline by hours or whatever,
we're talking about  this issue now not then.  There's less time between
now and the buster release than there was back in March, and that means
the risks are higher.  And so in arguing for a change you need to
account for that increased risk.

And because the RT has a lot of work to do you need to make it easy for
them.  They are going to have to review each change, so you'd better do
that first:-)

As an example, from your original bug:

  - Upgrade changes: Complementary to unattened-upgrades, assist
non-technical  
FreedomBox users to automatically upgrade from older versions of
bind,  
tt-rss, firewalld, libpam-modules, and openvpn. This helps users
migrating  
from Stretch. Another change was to avoid a conffile prompt within  
FreedomBox itself to ease future upgrades.  

This sounds like an important bug: you ran upgrade testing from stretch
and ran into an issue that impacted users.
If there's not a bug number, you want one probably.  If there is, make
sure it's marked important and it's clear why.

Bug#921688: electrum being actively used for phishing

[Sam Hartman]

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

The maintainer has not addressed this bug since Feb 7.

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

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

--Sam


signature.asc
Description: PGP signature

Bug#925242: unblock: csound/1:6.12.2~dfsg-3.1

[Sam Hartman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package csound

Upstream csound introduces a regression over stretch.  If you're using
the synchronous granular synthesis opcodes and the sample rate of your
samples differs from the sample rate you're playing at, it is
impossible to make things sound right in buster.

So, for one synthesis technique that worked in stretch, you get into situations 
where it doesn't work in buster and there is no work around.

The upstream fix is simple: scale the pointer read rate along with
pitch scaling that upstream already introduced.  #924260 includes
details and a pointer to the upstream issue which includes even more
detailed analysis and upstream's fix.  This is just a backport of the
two upstream patches.  I've confirmed the fix with my DJ software.  I
have received permission to upload an NMU from the maintainer (again
see #924260 ) and will upload once I get a confirmation from the
release team that this looks good.
diff --git a/debian/changelog b/debian/changelog
index 84a4831..41d2499 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+csound (1:6.12.2~dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix diskgrain, syncgrain and syncloop when sample rate of sample
+differs from orchestra, Closes: 924260
+
+ -- Sam Hartman   Thu, 21 Mar 2019 10:31:29 -0400
+
 csound (1:6.12.2~dfsg-3) unstable; urgency=medium
 
   * Fix FTBFS on mips by avoiding a deadlock
diff --git 
a/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch 
b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
new file mode 100644
index 000..d5f3033
--- /dev/null
+++ b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
@@ -0,0 +1,58 @@
+From: veplaini 
+Date: Mon, 11 Mar 2019 09:11:40 +
+Subject: applied diskgrain fix to syncgrain andsyncloop
+
+---
+ Opcodes/syncgrain.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index cb0b2bd..1dc1973 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -96,15 +96,16 @@ static int32_t syncgrain_process(CSOUND *csound, syncgrain 
*p)
+ int32_t numstreams = p->numstreams, olaps = p->olaps;
+ int32_t count = p->count, j, newstream;
+ int32_t datasize = p->datasize, envtablesize = p->envtablesize;
++MYFLT  pscale =  p->sfunc->gen01args.sample_rate/CS_ESR;
+ 
+-pitch  = *p->pitch * p->sfunc->gen01args.sample_rate/CS_ESR;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(p->sfunc->gen01args.sample_rate/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+ grsize = p->sfunc->gen01args.sample_rate * *p->grsize;
+ if (UNLIKELY(grsize<1)) goto err1;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
+@@ -249,7 +250,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ int32_t loopsize;
+ int32_t firsttime = p->firsttime;
+ MYFLT   sr = p->sfunc->gen01args.sample_rate;
+-
++MYFLT pscale = sr/CS_ESR;
+ /* loop points & checks */
+ loop_start = (int32_t) (*p->loop_start*sr);
+ loop_end = (int32_t) (*p->loop_end*sr);
+@@ -260,7 +261,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ /*csound->Message(csound, "st:%d, end:%d, loopsize=%d\n",
+   loop_start, loop_end, loopsize); */
+ 
+-pitch  = *p->pitch * sr/CS_ESR;;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(sr/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+@@ -268,7 +269,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (loopsize <= 0) loopsize = grsize;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian/patches/diskgrain-prate-scaling.patch 
b/debian/patches/diskgrain-prate-scaling.patch
new file mode 100644
index 000..9f21a6e
--- /dev/null
+++ b/debian/patches/diskgrain-prate-scaling.patch
@@ -0,0 +1,30 @@
+From: veplaini 
+Date: Sat, 9 Mar 2019 14:03:22 +
+Subject: diskgrain prate scaling
+
+---
+ Opcodes/syncgrain.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index d7c461e..cb0b2bd 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -455,7

Bug#924260: NMUDIFF for csound 1:6.12.2~dfsg-3.1

[Sam Hartman]

Dear maintainer, I've uploaded the following patch to csound to
delayed/2.  Rationale for the short delay: we've already discussed the
change and you've reviewed my merge request, and the release team
requested that I upload in a timely manner.

diff --git a/debian/changelog b/debian/changelog
index 84a4831..72a6859 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+csound (1:6.12.2~dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix diskgrain, syncgrain and syncloop when sample rate of sample
+differs from orchestra, Closes: #924260
+
+ -- Sam Hartman   Thu, 21 Mar 2019 10:31:29 -0400
+
 csound (1:6.12.2~dfsg-3) unstable; urgency=medium
 
   * Fix FTBFS on mips by avoiding a deadlock
diff --git 
a/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch 
b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
new file mode 100644
index 000..d5f3033
--- /dev/null
+++ b/debian/patches/applied-diskgrain-fix-to-syncgrain-andsyncloop.patch
@@ -0,0 +1,58 @@
+From: veplaini 
+Date: Mon, 11 Mar 2019 09:11:40 +
+Subject: applied diskgrain fix to syncgrain andsyncloop
+
+---
+ Opcodes/syncgrain.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index cb0b2bd..1dc1973 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -96,15 +96,16 @@ static int32_t syncgrain_process(CSOUND *csound, syncgrain 
*p)
+ int32_t numstreams = p->numstreams, olaps = p->olaps;
+ int32_t count = p->count, j, newstream;
+ int32_t datasize = p->datasize, envtablesize = p->envtablesize;
++MYFLT  pscale =  p->sfunc->gen01args.sample_rate/CS_ESR;
+ 
+-pitch  = *p->pitch * p->sfunc->gen01args.sample_rate/CS_ESR;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(p->sfunc->gen01args.sample_rate/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+ grsize = p->sfunc->gen01args.sample_rate * *p->grsize;
+ if (UNLIKELY(grsize<1)) goto err1;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
+@@ -249,7 +250,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ int32_t loopsize;
+ int32_t firsttime = p->firsttime;
+ MYFLT   sr = p->sfunc->gen01args.sample_rate;
+-
++MYFLT pscale = sr/CS_ESR;
+ /* loop points & checks */
+ loop_start = (int32_t) (*p->loop_start*sr);
+ loop_end = (int32_t) (*p->loop_end*sr);
+@@ -260,7 +261,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ /*csound->Message(csound, "st:%d, end:%d, loopsize=%d\n",
+   loop_start, loop_end, loopsize); */
+ 
+-pitch  = *p->pitch * sr/CS_ESR;;
++pitch  = *p->pitch * pscale;
+ fperiod = FABS(sr/(*p->fr));
+ //if (UNLIKELY(fperiod  < 0)) fperiod = -fperiod;
+ amp =*p->amp;
+@@ -268,7 +269,7 @@ static int32_t syncgrainloop_process(CSOUND *csound, 
syncgrainloop *p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (loopsize <= 0) loopsize = grsize;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian/patches/diskgrain-prate-scaling.patch 
b/debian/patches/diskgrain-prate-scaling.patch
new file mode 100644
index 000..9f21a6e
--- /dev/null
+++ b/debian/patches/diskgrain-prate-scaling.patch
@@ -0,0 +1,30 @@
+From: veplaini 
+Date: Sat, 9 Mar 2019 14:03:22 +
+Subject: diskgrain prate scaling
+
+---
+ Opcodes/syncgrain.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Opcodes/syncgrain.c b/Opcodes/syncgrain.c
+index d7c461e..cb0b2bd 100644
+--- a/Opcodes/syncgrain.c
 b/Opcodes/syncgrain.c
+@@ -455,7 +455,7 @@ static int32_t filegrain_init(CSOUND *csound, filegrain *p)
+ p->pscale = p->sr/CS_ESR;
+ 
+ if (*p->ioff >= 0)
+-  sf_seek(p->sf,*p->ioff * CS_ESR, SEEK_SET);
++  sf_seek(p->sf,*p->ioff * p->sr, SEEK_SET);
+ 
+ if (LIKELY(sf_read_MYFLT(p->sf,buffer,p->dataframes*p->nChannels/2) != 
0)) {
+   p->read1 = 1;
+@@ -518,7 +518,7 @@ static int32_t filegrain_process(CSOUND *csound, filegrain 
*p)
+ if (UNLIKELY(grsize<1)) goto err1;
+ if (grsize > hdataframes) grsize = hdataframes;
+ envincr = envtablesize/grsize;
+-prate = *p->prate;
++prate = *p->prate * p->pscale;
+ 
+ if (UNLIKELY(offset)) memset(output, '\0', offset*sizeof(MYFLT));
+ if (UNLIKELY(early)) {
diff --git a/debian

Bug#1040436: pev: confusing comments in autopkgtests

[Sam Hartman]

Source: pev
Version: 0.81-9
Severity: minor


While reviewing pev, I noticed that  some of the comments in 
debian/tests/test-runs are inaccurate

I think the following patch is sufficient
diff --git a/debian/tests/test-runs b/debian/tests/test-runs
index 675d4ec..9fe48fd 100755
--- a/debian/tests/test-runs
+++ b/debian/tests/test-runs
@@ -1,14 +1,11 @@
 #!/bin/sh
 #
-# Try to build and run the example code.  Provide input on both stdin
-# and as first argument as the programs seem to handle either or both.
-# The goal is to verify that it is possible to link with the libvorbis
-# library and run the resulting binaries.
+
+# Some simple tests of pev against windows gzip executable
 
 set -e
 
 retval=0
-#cd $AUTOPKGTEST_TMP
 
 # We don't want plugins from the build directory for the
 # installed package.
@@ -37,9 +34,9 @@ else
 fi
 
 if $VALGRIND pehash "$TESTEXE" | grep sha256:; then
-echo "success: pehash reported ASLR status"
+echo "success: pehash reported correct hash status"
 else
-echo "error: pehash did not report ASLR status"
+echo "error: pehash did not report hash"
 retval=1
 fi
 

Bug#1039873: pam-auth-update --disable does not work

[Sam Hartman]

> "Marc" == Marc Dequènes (duck)  writes:

Marc> I don't recall if I tested the feature extensively but I
Marc> updated my Ansible rules and it is ineffective. After
Marc> switching a machine to bookworm I still get the module I want
Marc> disabled around (it is reenabled during upgrade) and that
Marc> breaks authentication.

Hmm.
I just tried:

* pam-auth-update --enable mkhomedir

* confirm pam_mkhomedir is in the config
p
* pam-auth-update --disable mkhomedir

* Confirm that it is not in the config.

--Sam

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

>> I consider this proposal to be premature. Policy should document
Luca> current
>> practice, and I do not think this proposal does that.

For what it's worth, I agree with Luca that we are ready for a change to
document that service units need to be included now, and I do not think
a change in this area is premature.
I have not (and probably will not get around to) reviewing the specific
text, but I do think it's time for this change now.

(Some of Simon's comments about the security implications of not being
able to depend on systemd for dbus service activation but instead still
needing to support dbus-daemon launching things itself make me think we
should consider even more sweeping changes soon.)

Bug#1043184: krb5: fails to build against glibc 2.38

[Sam Hartman]

> "Samuel" == Samuel Thibault  writes:

Samuel> strlcat and strlcpy were indeed added to glibc in version
Samuel> 2.38, so it's not surprising that krb5 doesn't define its
Samuel> internal versions any more, and the attached patch can
Samuel> probably be applied?

I guess I'd need to increase build-depends too and add a breaks from
libkrb5support0 to older versions of the libraries so the upgrade works
correctly.
Or alternatively unconditionally build  strlcat and strlcpy and
conditionally use them based on what libc provides.

--Sam

Bug#1038128: libkrb5-dev: Please provide static libraries (.a)

[Sam Hartman]

> "John" == John Goerzen  writes:

John> I am attempting to enable curl support in dar.  dar provides a
John> standard binary and dar_static, which is to be used for
John> emergency system rescues.

John> Curl provides a static version (.a).  Unfortunately, curl uses
John> gssapi_krb5, which is not available in a static version.  The
John> result is an inability to link a static program.

John> configure supports --enable-static.  I see in the changelog
John> that it was enabled in Debian in version 1.4.3-5, though that
John> was dropped since for an unknown reason.

Upstream --enable-static is more intended for debugging and embedded
systems than for  general usage.
The biggest problem is that upstream loads a number of  plugins
including GSS-API mechanisms and KDC location plugins.  (Preauth plugins
are also loaded, and while they will not affect dar's use case, they
would generally affect the ability of someone to get Kerberos tickets).

Those plugins generally link against the dynamic version of libkrb5-3.
So you could get some really messy situations with different versions of
libkrb5 pulled into the same process space.

I'm not opposed to building static libraries.
I think I'd want to put them in a special package  and to actually
document the implications of using them clearly
and possibly adjust plugin behavior.
I.E. I'm happy to turn on static libraries if we do a good job and think
through the complicated issues.

The last time this got any significant upstream discussion was on the
krb...@mit.edu list

Date: Thu, 30 Jun 2022 17:57:38 +0200
Message-ID: 

List-Archive: 

Bug#1043184: krb5: fails to build against glibc 2.38

[Sam Hartman]

> "Samuel" == Samuel Thibault  writes:

Samuel> Why? Having spurious symbols doesn't break the build, and
Samuel> these are internal symbols so that shouldn't harm
Samuel> reverse-dependencies.

Actually, the way I have it configured, extra symbols should break the
build.  I want that.


So, summarizing a conversation from debian-devel.


I can mark the symbols (optional) and then they can be present or absent
without breaking the build.

If I do that, the ABI of libkrb5support0 will depend on the version of
glibc that it is built against.

That's problematic, because there is not a strict version dependency
between libk5crypto3 and libkrb5support0.
The dependencies allow an old libk5crypto3 to be installed alongside a
new libkrb5support0.
For that to work, libkrb5support0 needs to not disappear symbols.

I have three options:

1) The option I'm likely to choose is to mark the symbols optional,
break old libk5crypto3 from new libkrb5support0 as a one-time thing, and
create a strict dependency on the binary version from libk5crypto3 to
libkrb5support0.
I *think* this is safe.
The ABI of libkrb5support0 will depend on which glibc we build against,
but nothing outside of the krb5 source package is permitted to care
about that ABI, and  a strict binary dependency will make it very likely
(absent local builds) that we get the same build for the ABI provider
(libkrb5support0) and the ABI consumers.

2) I could simply provide the strlcat and strlcpy implementations all
the time, and use them depending on what glibc provides.  I know this is
safe: the ABI is consistent, and if we end up using glibc symbols, then
the libc6 symbols file will arrange for the right dependency.

3) I can remove the symbols, make a build-depends of libc6-dev >= 2.38,
and add a breaks of libkrb5support0 on the old libk5crypto3.
This is also safe: it's what I would do if libkrb5support0 wanted to
drop a symbol and I didn't want the strict version dependency.

--Sam

Bug#1049373: bookworm-pu: package krb5/1.20.1-2+deb12u1

[Sam Hartman]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: k...@packages.debian.org
Control: affects -1 + src:krb5


[ Reason ]
Non-DSA security update for a DOS


[ Impact ]
A remote authenticated attacker can crash kadmind.

[ Tests ]
autopkgtest  should cover this code path; tested upstream.

[ Risks ]

Simple obvious patch.



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

[ Changes ]
diff --git a/debian/changelog b/debian/changelog
index 39cc059e25..a22fe91f26 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+krb5 (1.20.1-2+deb12u1) bookworm; urgency=high
+
+  * Fixes CVE-2023-36054: a  remote authenticated attacker can cause
+kadmind to free an uninitialized pointer.  Upstream believes remote
+code execusion is unlikely, Closes: #1043431 
+
+ -- Sam Hartman   Mon, 14 Aug 2023 14:06:53 -0600
+
 krb5 (1.20.1-2) unstable; urgency=medium
 
   * Tighten dependencies on libkrb5support0.  This means that the entire
diff --git a/debian/patches/series b/debian/patches/series
index 3e5f0ef336..1b79d4b90e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,3 +7,4 @@ debian-local/0006-Add-substpdf-target.patch
 debian-local/0007-Fix-pkg-config-library-include-paths.patch
 debian-local/0008-Use-isystem-for-include-paths.patch
 0009-Add-.gitignore.patch
+upstream/0010-Ensure-array-count-consistency-in-kadm5-RPC.patch
diff --git 
a/debian/patches/upstream/0010-Ensure-array-count-consistency-in-kadm5-RPC.patch
 
b/debian/patches/upstream/0010-Ensure-array-count-consistency-in-kadm5-RPC.patch
new file mode 100644
index 00..f3378aac51
--- /dev/null
+++ 
b/debian/patches/upstream/0010-Ensure-array-count-consistency-in-kadm5-RPC.patch
@@ -0,0 +1,63 @@
+From: Greg Hudson 
+Date: Wed, 21 Jun 2023 10:57:39 -0400
+Subject: Ensure array count consistency in kadm5 RPC
+
+In _xdr_kadm5_principal_ent_rec(), ensure that n_key_data matches the
+key_data array count when decoding.  Otherwise when the structure is
+later freed, xdr_array() could iterate over the wrong number of
+elements, either leaking some memory or freeing uninitialized
+pointers.  Reported by Robert Morris.
+
+CVE-2023-36054:
+
+An authenticated attacker can cause a kadmind process to crash by
+freeing uninitialized pointers.  Remote code execution is unlikely.
+An attacker with control of a kadmin server can cause a kadmin client
+to crash by freeing uninitialized pointers.
+
+ticket: 9099 (new)
+tags: pullup
+target_version: 1.21-next
+target_version: 1.20-next
+
+(cherry picked from commit ef08b09c9459551aabbe7924fb176f1583053cdd)
+---
+ src/lib/kadm5/kadm_rpc_xdr.c | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/lib/kadm5/kadm_rpc_xdr.c b/src/lib/kadm5/kadm_rpc_xdr.c
+index 0411c3f..287cae7 100644
+--- a/src/lib/kadm5/kadm_rpc_xdr.c
 b/src/lib/kadm5/kadm_rpc_xdr.c
+@@ -390,6 +390,7 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+int v)
+ {
+   unsigned int n;
++  bool_t r;
+ 
+   if (!xdr_krb5_principal(xdrs, &objp->principal)) {
+   return (FALSE);
+@@ -443,6 +444,9 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+   if (!xdr_krb5_int16(xdrs, &objp->n_key_data)) {
+   return (FALSE);
+   }
++  if (xdrs->x_op == XDR_DECODE && objp->n_key_data < 0) {
++  return (FALSE);
++  }
+   if (!xdr_krb5_int16(xdrs, &objp->n_tl_data)) {
+   return (FALSE);
+   }
+@@ -451,9 +455,10 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+   return FALSE;
+   }
+   n = objp->n_key_data;
+-  if (!xdr_array(xdrs, (caddr_t *) &objp->key_data,
+- &n, ~0, sizeof(krb5_key_data),
+- xdr_krb5_key_data_nocontents)) {
++  r = xdr_array(xdrs, (caddr_t *) &objp->key_data, &n, objp->n_key_data,
++sizeof(krb5_key_data), xdr_krb5_key_data_nocontents);
++  objp->n_key_data = n;
++  if (!r) {
+   return (FALSE);
+   }
+ 

Bug#1049374: bullseye-pu: package krb5/1.18.3-6+deb11u4

[Sam Hartman]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: k...@packages.debian.org
Control: affects -1 + src:krb5


This is the bullseye version of the bookworm  update request I just filed.

[ Reason ]
Non-DSA security update for a DOS


[ Impact ]
A remote authenticated attacker can crash kadmind.

[ Tests ]
autopkgtest  should cover this code path; tested upstream.

[ Risks ]

Simple obvious patch.



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

[ Changes ]
diff --git a/debian/changelog b/debian/changelog
index 60fb20b347..bea091f603 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+krb5 (1.18.3-6+deb11u4) bullseye; urgency=medium
+
+  * Fixes CVE-2023-36054: a  remote authenticated attacker can cause
+kadmind to free an uninitialized pointer.  Upstream believes remote
+code execusion is unlikely, Closes: #1043431 
+
+ -- Sam Hartman   Mon, 14 Aug 2023 14:42:46 -0600
+
 krb5 (1.18.3-6+deb11u3) bullseye-security; urgency=high
 
   * Integer overflows in PAC parsing; potentially critical for 32-bit
diff --git 
a/debian/patches/0015-Ensure-array-count-consistency-in-kadm5-RPC.patch 
b/debian/patches/0015-Ensure-array-count-consistency-in-kadm5-RPC.patch
new file mode 100644
index 00..658dc99e5b
--- /dev/null
+++ b/debian/patches/0015-Ensure-array-count-consistency-in-kadm5-RPC.patch
@@ -0,0 +1,63 @@
+From: Greg Hudson 
+Date: Wed, 21 Jun 2023 10:57:39 -0400
+Subject: Ensure array count consistency in kadm5 RPC
+
+In _xdr_kadm5_principal_ent_rec(), ensure that n_key_data matches the
+key_data array count when decoding.  Otherwise when the structure is
+later freed, xdr_array() could iterate over the wrong number of
+elements, either leaking some memory or freeing uninitialized
+pointers.  Reported by Robert Morris.
+
+CVE-2023-36054:
+
+An authenticated attacker can cause a kadmind process to crash by
+freeing uninitialized pointers.  Remote code execution is unlikely.
+An attacker with control of a kadmin server can cause a kadmin client
+to crash by freeing uninitialized pointers.
+
+ticket: 9099 (new)
+tags: pullup
+target_version: 1.21-next
+target_version: 1.20-next
+
+(cherry picked from commit ef08b09c9459551aabbe7924fb176f1583053cdd)
+---
+ src/lib/kadm5/kadm_rpc_xdr.c | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/lib/kadm5/kadm_rpc_xdr.c b/src/lib/kadm5/kadm_rpc_xdr.c
+index 8383e4e..9585080 100644
+--- a/src/lib/kadm5/kadm_rpc_xdr.c
 b/src/lib/kadm5/kadm_rpc_xdr.c
+@@ -390,6 +390,7 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+int v)
+ {
+   unsigned int n;
++  bool_t r;
+ 
+   if (!xdr_krb5_principal(xdrs, &objp->principal)) {
+   return (FALSE);
+@@ -443,6 +444,9 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+   if (!xdr_krb5_int16(xdrs, &objp->n_key_data)) {
+   return (FALSE);
+   }
++  if (xdrs->x_op == XDR_DECODE && objp->n_key_data < 0) {
++  return (FALSE);
++  }
+   if (!xdr_krb5_int16(xdrs, &objp->n_tl_data)) {
+   return (FALSE);
+   }
+@@ -451,9 +455,10 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+   return FALSE;
+   }
+   n = objp->n_key_data;
+-  if (!xdr_array(xdrs, (caddr_t *) &objp->key_data,
+- &n, ~0, sizeof(krb5_key_data),
+- xdr_krb5_key_data_nocontents)) {
++  r = xdr_array(xdrs, (caddr_t *) &objp->key_data, &n, objp->n_key_data,
++sizeof(krb5_key_data), xdr_krb5_key_data_nocontents);
++  objp->n_key_data = n;
++  if (!r) {
+   return (FALSE);
+   }
+ 
diff --git a/debian/patches/series b/debian/patches/series
index a62749cd49..c87cf1c9d2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -12,3 +12,4 @@ debian-local/0008-Use-isystem-for-include-paths.patch
 0012-Fix-defcred-leak-in-krb5-gss_inquire_cred.patch
 0013-Use-SHA-256-instead-of-SHA-1-for-PKINIT-CMS-digest.patch
 0014-Fix-integer-overflows-in-PAC-parsing.patch
+0015-Ensure-array-count-consistency-in-kadm5-RPC.patch

Bug#775277: krb5-kdc: kpropd init scripts missing from package

[Sam Hartman]

> "Michael" == Michael Weiser  writes:

Michael> Hi, Mark and I have built and used our own local packages
Michael> with this patch applied for some revisions now (at least
Michael> -17, -18 and -19) and all seems fine. But it it is quite a
Michael> hassle to rebuild those local packages on every Debian
Michael> update.

Michael> Since we have provided a full, self-contained patch that
Michael> seems to solve the issue for good, can you please review
Michael> and comment on it so we can make some progress on getting
Michael> it included into the Debian package?

Unfortunately, Debian 8.0 is in the final release freeze.  After the
release of Debian 8.0 later this month, we'll take a look for inclusion
in the next Debian release.  That's going to be a couple of years out
though.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#780403: debian-policy: Define what should happen when installing a package and the init script fails to start it

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Ivan Baldo  writes:
>> What should happen if installing a package and then when it tries
>> to start its service it fails?

>> Currently the most common behaviour seems to be that the
>> installation fails.

>> But is that the best outcome?

Russ> Currently, Policy leaves this to the discretion of the package
Russ> maintainer.  To change that, what will be needed here is not
Russ> just an argument that other behaviors besides failing
Russ> installation might be desirable, but that there is a
Russ> compelling need to standardize this behavior across the entire
Russ> archive instead of leaving it to the discretion of the
Russ> maintainer.

I find this issue tends to come up a lot more than it used to.  The
issue is that systemd units tend to track a lot more errors than init
scripts.  So, in Jessie, there tend to be a lot more cases where a
package will fail to install under the same situations where in wheezy
it'd install fine.  The problem is made more complex by debhelper, which
makes it somewhat annoying (especially in dh 7 mode) to express this
maintainer preference.  So, you have a lot of dh7 packages that suddenly
got much more picky because people created service units.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750135: Status of #750135 (Maintainer of aptitude package)

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:


Didier> Given the situation (an unresponsive Daniel, a proposal from
Didier> people with powers to push the situation forward), I'd be
Didier> more inclined to say yes to Christian, without a formal
Didier> resolution.

Given that Christian has asked for additional support before moving
forward, I'd prefer to give him that.  I think the resolution should be
non-binding.  Something along the lines of We observed this fact.
Christian asked for input on whether this would be a good way forward.
The TC believes it would be.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#783271: When configuring custom logging in /etc/krb5.conf,, xrb5 services are unable to write to these log files as they are not, permitted in the service configuration used by systemd

[Sam Hartman]

It's my plan to close this as not a bug; Russ's explanation for how to
relax the permissions check seems entirely reasonable as a solution.
--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#780264: Bug #780264 : Improved fix for M2Crypto incompatibility

[Sam Hartman]

Hi.
I'll be on vacation the rest of this week and will review on my return
monday.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> 1. The TC - not the policy process, not the policy editors, and
Ian> not the consensus on debian-policy - has the ultimate
Ian> responsibility to set technical policy.  (Constitution 6.1(1))

Ian> So in the TC the question of whether the policy process was or
Ian> was not followed does not dispose of the question of what the
Ian> policy text should actually be.

We are in strong agreement on this point.

Ian> It would therefore be quite wrong for the TC to confine itself
Ian> to discussions of whether the policy process was followed.

Also agreed.

Ian> 
Ian> More so, whether the policy process was followed is of no
Ian> bearing when we afre considering the technical and social
Ian> merits of the competing options.

Ian> The TC should be looking at the merits of the competing
Ian> options.


I actually think that whether the process is followed has very strong
bearing when considering the social merits of the competing options.
We are a volunteer project.
We thrive when people feel their contributions are valued, when they
feel they can make a difference.
There is a significant cost to the project when we reject contributions
that people have spent a lot of time working on.  People tend to
question whether allocating their time on these activities is valuable,
tend to question whether the project's values are aligned with their
values.

So, between two reasonable technical options, choosing the one that
values the time and work people have put in serves a significant social
good that helps build and strengthen our community.

I  think that there is a huge social benefit to fairness.  I find that I
am more willing to spend energy on organizations where I have rescourse
if I believe that fairness of process has not been met.
So I think it's absolutely critical that there be a way you can get a
process decision reviewed.
We can debate whether the TC is the right place for that.  I'll note
that reviewing a consensus call/a consensus process requires deep
knowledge of the technical issues involved.  If you take a look at
documents like RFC 7282 that discuss what it means to have rough
consensus, you'll find they are filled with judgment calls about the
technical issues.  So whoever does review this sort of call needs to
have significant technical skill.


I also think process has technical bearing.  I value consensus-based
processes because I believe they tend to produce superior technical
results.  I think that debian-policy has a wider set of skills than the
TC, and the members contributing to the discussion on debian-policy have
spent more time understanding the issue than the current TC members
involved in this discussion.
If the TC found itself coming to a different conclusion than an informed
rough consensus of debian-policy, it should carefully consider whether
that is the right course.

However, I absol/absolutely agree that the TC is responsible for the
content of policy and we cannot (or at least should not) delegate that
responsibility.
Even if the TC finds that the process is followed, the TC must evaluate
whether it has any objections to the resulting policy.

I think the key area where we differ is that I would give preference
other things being mostly equal to  upholding the work done in
debian-policy.  As I understand it, you would vote for the option you
thought technically best.  I wouldn't do that because I think the social
costs are important and because I recognize a real chance I might be
technically wrong.

I do think the form of the question posed to the TC has some importance.
I would be thinking about this somewhat differently if someone had asked us to
review menu policy because they had specific technical concerns with the
policy that was adopted.

You note that discussions of whether someone followed a process tend to
be acromonious.  We're in agreement there.  I've been frustrated when
I've seen people making this about Bill or about Charles and whether
they abused rights/responsibility.

I've tried to be careful to make this be about the process and not to
judge specific members of the community.  I'd be really happy if others
would join me in that.

My experience is that having discussions about process tends and whether
it is followed in specific cases tends to allow you to better understand
your requirements and understand gaps in shared expectations.
I find that  tends over time to significantly remove acromony.  As an
exampleI tend to feel a sense of relief that replaces frustration when I
understand that the reason someone isn't doing what I want is that they
have different expectations.  We can get down to the business of seeing
if there are mutually compatible expectations to be had.
It's quite obvious to me that Bill and Charles have different
expectations here, and I think there's significant acromony that can be
avoided if the community is able to clarify which expectations

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

>>>>> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and
>> I think the key area where we differ is that I would give
>> preference other things being mostly equal to upholding the work
>> done in debian-policy.  As I understand it, you would vote for
>> the option you thought technically best.  I wouldn't do that
>> because I think the social costs are important and because I
>> recognize a real chance I might be technically wrong.

Ian> I'm not sure precisely what social costs you are referring to.

Ian> Perhaps you mean disappointment on the part of people who have
Ian> spent effort to build consensus in debian-policy in order to
Ian> make progress in a controversial area.  But if there are
Ian> serious objections, which a participant wishes to take to the
Ian> TC, it seems to me that such a consensus (if it exists) has
Ian> probably been achieved by wearing down the sceptics rather than
Ian> by convincing them (or perhaps by the absence of the opponents
Ian> to begin with).

Having such serious objections that have not been adequately considered
means you don't have rough consensus at least in the ways I judge rough
consensus.
It was perhaps not obvious in some of my mail, but  I did:

* evaluate each objection Bill raised in his mail where he reverted the
  change to see if I thought it was addressed at a process level.

* Evaluate each of those objections as a TC member to see if I thought
  it was in my technical judgment a problem with the proposal.

* Try to explain the objections to the rest of the TC so they could make
  their evaluation using their technical judgment (including pointers if
  they want to  dig more deeply)

Doing all of those are important to me.

With regard to the current issue it's my opinion that we have no serious
issues that have not been considered.  It's my opinion that in my
technical judgment I'm comfortable with the resolution to the issues
that were considered.
If you or anyone else wants me to look at some specific issue either
from a process standpoint or to make a judgment about whether I think
the resolution is reasonable, please start another thread on the bug.
If I have not already voted I'll do so.

I'm still in the process of doing my own technical evaluation of the
proposal to see if I come up with any technical objections I consider
serious enough to raise.  It'll be awkward from a TC internal process
standpoint if I do because the ballot is frozen at this point, but I've
completed enough of my evaluation that I don't anticipate any such
objections.  I'll be done before I vote and will definitely be able to
complete within the voting period even if Don calls for a vote now.


Ian> Or perhaps you mean disappointment on the part of the policy
Ian> editors.  

I do not.  Your reasons are somewhat similar to mine.



Ian> To put it another way: the policy editors have cast themselves
Ian> as referees, not judges or designers.  

Agreed to some extent.  The policy editors do have some role as
consensus judges, but to a large extent they have delegated that to
those seconding proposals according to their process document.  In
practice, I suspect they do a fair bit of consensus judging themselves.


Ian> For the TC to do the
Ian> same would mean that - when the question is controversial and
Ian> has a strong political element - the actual decision would be
Ian> simply be based on which side has the most effort and best
Ian> tactics in a mailing list flamewar.

I would urge you to read RFC 7282.  I understand this is not the IETF
and even the IETF has not chosen to bind itself to that document.
However it displays some of the level of thought required in judging
rough consensus.
A judge of consensus is very much responsible for thinking about the
technical issues and making sure they have adequately been considered.
A judge of consensus is very much responsible for making sure the
process does not turn into who-shouts-loudest.

Someone reviewing a consensus process probably isn't in a position to
fix a process where participants were driven away in frustration
(silencing their objections) but should detect this sort of thing and
claim the process failed to reach consensus when significant viewpoints
were excluded.

However, I think the TC has very important roles beyond just judging
consensus.
We need to decide what the policy is.  We can and in my opinion should
factor in the opinions of others in doing that.

As a practical matter the debian-policy list does a lot of that.
When debian-policy properly takes up an issueit's important to me that
the TC value the work they have done.  Part of that to me is that we
should have a re

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> I made efforts to keep the wording mild, but I think that
Charles> it was an error.
>> From your attiude as the lead person behind the Debian Menu, it
>> is clear that
Charles> it has no future.  For one decade, you have taken no
Charles> leadership to build this future.  As a consequence, I think
Charles> that the next step is to plan its replacement and
Charles> deprecation.  Maybe the TC will come to this conclusion.

That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sam Hartman]

Unless someone objects
I propose that the following text also be included in option b:

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
  Debian menu package support translating .desktop files of
  packages which do not provide menu files.


I'd like to be able to vote on that option, but I suspect there's no one
who favors B who doesn't favor that text.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792685: Unable to upgrade from wheezy to jessie

[Sam Hartman]

Hi.
I attempted the following:

* Built with the patch applied on a jessie chroot
* installed s3ql

* On a wheezy system mkfs.s3ql, mount and  add some data.  unmount.

* On my patched jessie system run s3qladm upgrade

So far so good.

Then run fsck.s3ql.
It looks like it has trouble with the old metadata:
Backing up old metadata...
Uncaught top-level exception:
Traceback (most recent call last):
  File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 710, in _extractmeta
  return safe_unpickle(b64decode(buf), encoding='latin1')
File "/usr/lib/s3ql/s3ql/backends/common.py", line 629, in
safe_unpickle
encoding=encoding, errors=errors)
  File "/usr/lib/s3ql/s3ql/backends/common.py", line 613, in
  safe_unpickle_fh
  raise pickle.UnpicklingError('opcode %s is unsafe' %
  opcode.name)
  _pickle.UnpicklingError: opcode NEWOBJ is unsafe

  During handling of the above exception, another
  exception occurred:

  Traceback (most recent call last):
File "/usr/bin/fsck.s3ql", line 9, in 
load_entry_point('s3ql==2.11.1',
'console_scripts', 'fsck.s3ql')()
  File "/usr/lib/s3ql/s3ql/fsck.py", line 1224, in
main
cycle_metadata(backend)
  File "/usr/lib/s3ql/s3ql/metadata.py", line
121, in cycle_metadata
cycle_fn("s3ql_metadata_bak_%d" % i,
"s3ql_metadata_bak_%d" % (i + 1))
  File "/usr/lib/s3ql/s3ql/backends/comprenc.py",
line 290, in copy
self._copy_or_rename(src, dest, rename=False,
metadata=metadata)
  File "/usr/lib/s3ql/s3ql/backends/comprenc.py",
line 299, in _copy_or_rename
meta_raw = self.backend.lookup(src)
  File "/usr/lib/s3ql/s3ql/backends/common.py",
line 46, in wrapped


It may be as simple as ignoring unsafe pickles in old metadata.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792685: Yeah, just looks like metadata backup issue

[Sam Hartman]

I deleted the backup metadata by hand from s3 and fsck and mount work
fine.
I realize that's not exactly a supported operation, but it seemed likely
to work and I think gives confidence that the only problem with the
patch seems to be with regard to old metadata carried forward.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750135: Initial draft of resolution

[Sam Hartman]

Proposed for your consideration and checked into git for your editing:

Background/Rationale (Constitution 6.1(5)): 

1. In #750135, the
technical committee was asked by Manuel Fernandez Montecelo who should
be the maintainer of the aptitude projectp.  He had been actively committing 
until his commit access was removed by Daniel Hartwig.  Manuel  and Daniel took 
over development of aptitude in 2011 with the support of Christian Perrier, an 
admin for the aptitude alioth project.  There was friction between Manuel and 
Daniel, which eventually resulted in  Manuel's commit access being revoked by 
Daniel.  Since then, Daniel has become inactive, and did not comment on the 
issue when requested by the technical committee.

2) During the discussion of this issue, Christian proposed that he and
Axel Beckert could watch the social aspects of aptitude development
and restore Manuel's commit access.  Christian still has
administrative rights and believes he has the technical power to implement his 
proposal.  However he wants review from a broader audience before implementing 
that proposal.


Advice (Constitution 6.1.5):

1.  The technical committee agrees that Christian has the power to implement 
his proposal and encourages him to do so.

2.  The committee agrees that restoring Manuel's committ access is a
good step to move Aptitude development forward.  Since there is a
clear way to accomplish this goal within the existing Aptitude project
support that approach.

3.  We hope that Christian and Axel will work to managed the social
aspects of the Aptitude project, working to recruit new developers,
building a stronger Aptitude development community, and establishing
policies and procedures that promote a collaborative team.  Sometimes
the skills necessary to grow a community ar different than the skills
to develop a project.  Through this approach we hope the Aptitude
community will gain both sets of skills.

4.  We thank Manuel for bringing this matter to our attention and
apologize for our delay in resolving this matter.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750135: Initial draft of resolution

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:


>> Background/Rationale (Constitution 6.1.5):
>> 
>> 1. In #750135, the Technical Committee was asked by Manuel
>> Fernandez Montecelo who should be the maintainer of the Aptitude
>> project. He had been actively committing until his commit access
>> was removed by Daniel Hartwig. Manuel and Daniel took over
>> development of Aptitude in 2011 with the support of Christian
>> Perrier, an admin for the Aptitude alioth project. There was
>> friction between Manuel and Daniel, which eventually resulted in
>> Manuel's commit access being revoked by Daniel. Since then,
>> Daniel has become inactive, and did not comment on the issue when
>> requested by the Technical Committee.

Didier> That reads like a correct description of events as they have
Didier> been presented to us.

>> 2. During the discussion of this issue, Christian Perrier
>> proposed that he and Axel Beckert could watch the social aspects
>> of Aptitude development and restore Manuel's commit
>> access. Christian still has administrative rights and believes he
>> has the technical power to implement his proposal. However he
>> wants review from a broader audience before implementing that
>> proposal.

Didier> Ditto.

Didier> Did you intend to have these two paragraphs part of the
Didier> actual decision, or not?

Note that nothing in this resolution is formal at all.
We provide background and some advice to the aptitude process.
Only things that are part of the decision are things that are agreed by
the technical committee.
Yes, I believe it's important that we get a summary of our rationale and
background as something that  the TC agrees to, so yes, I believe that
should be part of the decision.

If we had a part of this resolution that had any force--that was a
statement of policy, a resolution of conflicting juristictions,
overiding a maintainer, deciding a matter delegated to us, I'd prefer to
keep the part of the text with actual force short.

>> Advice (Constitution 6.1.5):
>> 
>> 1. The Technical Committee agrees that Christian has the power to
>> implement his proposal and encourages him to do so.

Didier> I'd replace "agrees" with "acknowledges", but beware of my
Didier> en_CH !

To me agrees is more active, more supportive.
However I don't care at all about this.

>> 2. The committee agrees that restoring Manuel's commit access is
>> a good step to move Aptitude development forward. Since there is
>> a clear way to accomplish this goal within the existing Aptitude
>> project support that approach.
s:support:we support:
I'll go make that change.

Didier> I don't understand this second sentence. Is there some
Didier> punctuation hiccup?

>> 3. We hope that Christian and Axel will work to managed the
>> social aspects of the Aptitude project, working to recruit new
>> developers, building a stronger Aptitude development community,
>> and establishing policies and procedures that promote a
>> collaborative team. Sometimes the skills necessary to grow a
>> community ar different than the skills to develop a
>> project. Through this approach we hope the Aptitude community
>> will gain both sets of skills.

Didier> Although I don't disagree with the paragraph, I'm not overly
Didier> comfortable with formalizing our hopes in a resolution. I'd
Didier> rather drop the complete paragraph from the actual decision,
Didier> eventually moving it to a non-formal part (either pre- or
Didier> post- decision).

Again, I'm hoping that the TC as a whole will support this so I want it
 to be part of the resolution.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784651: moonshot-ui: depends on libgee-dev which is deprecated

[Sam Hartman]

Ah, and I see you did actually file the removal request, so yeah this is
RC under any evaluation.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784651: moonshot-ui: depends on libgee-dev which is deprecated

[Sam Hartman]

> "Emilio" == Emilio Pozuelo Monfort  writes:

Emilio> Control: severity -1 serious We want to remove libgee2 from
Emilio> unstable RSN, and there are only a few rdeps now, so I'm
Emilio> bumping the severity of the bugs.

For future reference, I don't think it's actually legitimate to bump the
severity of an rdep removal to RC until *after* you remove the rdep.
However, as maintainer, I'll say this is fine as serious by request of
maintainer.

I don't think this is a problem, I just need to rebuild and upload.
I'll try to get to that in a day or two.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Bug #741573:Process Approach vs Others

[Sam Hartman]

[moving back to the bug, because we're starting to discuss the issue
rather than a TC communications matter.]


>>>>> "Bdale" == Bdale Garbee  writes:
Bdale> I hear you, I just don't have any idea what to do differently
Bdale> on this specific issue in response to knowing how you feel
Bdale> about it.

I made a specific proposal in #741573.  
I'd be a lot happier if you'd say "No, I think we've already reached
agreement that the policy team didn't have consensus., so we don't need to
evaluate whether the process was followed."
I wouldn't agree with that, but sometimes people disagree with you.  I'm
OK with that outcome.

If we've already agreed that the policy team didn't have consensus,  my
preference would be to ask the policy community whether they want us to
take up the issue, rather than just asserting a decision from on high.
That is, we communicate to them that we believe that they didn't have
consensus rather than just jumping to a conclusion.
I don't think we need to vote for that if we have internal rough
consensus, although I'd be fine voting on that if we wish to do so.

However:

Bdale> Sam Hartman  writes:
Bdale> I really think the only difference here might be in how much
Bdale> of the process to date we've each been involved with.  When
Bdale> this first hit the TC, I recall discussion about whether
Bdale> policy process had run its course or not and my belief was
Bdale> that we had consensus after input from Russ that in fact
Bdale> policy process had failed here and it was appropriate for the
Bdale> TC to intervene.  I would have to go do more digging and
Bdale> reading to substantiate that assertion than I have time for
Bdale> this afternoon, but that's the position I *thought* we agreed
Bdale> we were in.

I've been reading this bug since the beginning even though I was not on
the TC.
I recall things differently.
Charles referred his question.
Ian jumped immediately to the technical discussion.
I wrote to Ian and the bug noting that he was jumping to the technical
discussion without considering the question Charles brought to the TC.
Ian wrote back  saying that it was inappropriate for the TC to consider
the question of whether the policy team had a consensus.
My perception is that everyone else ignored Charles and I and continued
on with the technical discussion.

Somewhere along that discussion a couple of TC members (I think you may
have been one) pointed out that going through the bug and determining
whether the policy team had consensus would be huge work.

So, if anything  the consensus of the TC prior to the resignations was
that it was not important to consider the question of whether the policy
team followed their process.

However a few things have happened since then:

* There has been a membership change in the TC.

* There's been a bunch of discussion within the TC and broader in the
  project that we might want to do a better job of working with folks.

* The policy team updated its process.  I don't know how extensive the
  update is, but it's my opinion that under the current process it's
  fairly easy to determine whether the policy team has consensus.
I proposed how to do so on this bug.
It may have been easy to do under the old process; I haven't researched
  that.

--Sam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org