Bug#1056166: systemd-homed: `passwd` fails

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> Ah thanks for the pointer to the file, I had missed that
Luca> somehow in the first reply. I see it now: the pam-config for
Luca> unix.so assumes that if something runs before then everything
Luca> is done already.  Unfortunately that assumption is wrong. I'll
Luca> see if I can just hack it and monkey patch common-password in
Luca> the postinst to fix it up for now, as I assume this is some
Luca> load-bearing assumption.

I think if you want to play with it and modify common-password, that's
fine.

I do not think that's appropriate for testing though.

I'm fairly uncomfortable  with a package other than pam touching
common-password in postinst other than through pam-auth-update.
It's fairly unlikely to work and likely to cause problems on upgrade.
I'd be much happier with  (at least for now) simply not auto-configuring
systemd-home and leaving that to the sysadmin.
I appreciate that is not what you want to hear, but:

1) I believe that package a modifying a configuration file of package b
without cooperation of package b is a clear policy violation.

2) common-password is a configuration file of pam.

3) I'd like to understand the situation muchd better and especially why
you need   to be account-type:primary.
I suspect we're going to need to have changes to pam-auth-update.

Bug#1056166: systemd-homed: `passwd` fails

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> 
https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html

It's going to be a long time (a couple of weeks) before I have cycles to
actually look at systemd-home rather than to answer questions with my
pam hat on without looking at your application.
The limits issue you wrote to me about yesterday is ahead in the queue,
as likely is a new version of krb5.

Luca> Any idea where use_authtok try_first_pass could be coming
Luca> from? I don't see them defined anywhere in the pam config I am
Luca> shipping, so I have no idea why pam-auth-update is adding
Luca> them.

I gave you pointers where to look for these: /usr/share/pam-config/unix
This is complex enough that someone who both has a good understanding of
pam and systemd-home is going to need to get involved.
I can talk about the broader pam context, and some issues people have
run into in the past, but someone needs to have both systemd-home and
pam in their heads to definitively decide what systemd-home wants out of
pam.
That's not going to  be me any time soon.

Bug#1056166: systemd-homed: `passwd` fails

[Sam Hartman]

Hi.
I'm not really swapped in on Debian this weekend; dealing with a
transition for day job.

But quick thoughts.

I'm surprised that systemd-home is a pam auth module.
That is, I wouldn't expect systemd-home to be able to decide whether you
have presented valid credentials to log in.
It may be that it has an account entry point, but it's auth entry point
is trivial.

pam-auth-update assumes that you don't want to reenter a password.
So, it assumes the first module in the stack will take a password and
then we will reuse that.

Similarly for password, you don't want to for example  change the ldap
and local passwords to different values.


compare the auth vs auth-initial password vs password-initial lines in
/usr/share/pam-configs/unix.


Will systemd-home work with  an auth-type of additional rather than
primary?

Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently

[Sam Hartman]

> "Santiago" == Santiago Vila  writes:

Santiago> Hello.  My plan for base-files is to stop overriding the
Santiago> PATH in /etc/profile.

Santiago> Ubuntu did that a long time ago and it's probably the
Santiago> right thing to do.

I'd be happy to pick up the Ubuntu patch to include PATH in
/etc/environment for libpam-modules.


signature.asc
Description: PGP signature

Bug#1070072: RM: moonshot-ui -- ROM; poorly maintained upstream

[Sam Hartman]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: moonshot...@packages.debian.org
Control: affects -1 + src:moonshot-ui



After discussing with upstream, we no longer believe it makes sense to
include the moonshot suite in a stable Linux distribution.
See the discussion from the moonshot-community list this weekend.

Bug#1070071: RM: moonshot-gss-eap -- ROM; poorly maintained upstream

[Sam Hartman]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: moonshot-gss-...@packages.debian.org
Control: affects -1 + src:moonshot-gss-eap



After discussing with upstream, we no longer believe it makes sense to
include the moonshot suite in a stable Linux distribution.
See the discussion from the moonshot-community list this weekend.

Bug#1070070: RM: moonshot-trust-router -- ROM; poorly maintained upstream

[Sam Hartman]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: moonshot-trust-rou...@packages.debian.org
Control: affects -1 + src:moonshot-trust-router



After discussing with upstream, we no longer believe it makes sense to
include the moonshot suite in a stable Linux distribution.
See the discussion from the moonshot-community list this weekend.

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Sam Hartman]

> "Chris" == Chris Hofstaedtler  writes:

Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog files.

Chris> Thorsten Kukuk and others have been working on replacements for the
Chris> existing file formats and interfaces [1]; these are called wtmpdb
Chris> and lastlog2.

Relatedly, PAM upstream and apparently at least some aspects of Fedora
have been moving to logind to handle utmp functionality.
You will start to see the  first impacts of that in pam unstable.

--Sam

Bug#1069858: libkrb5-3: krb5.conf seems to ignore rdns = false

[Sam Hartman]

> "Lukas" == Lukas Grässlin  writes:

Lukas> We have a scenario where we need to disable reverse lookups for 
Lukas> canonicalization in Kerberos as the customer's PTR records are not 
Lukas> consistent and lead to wrongly requested SPNs otherwise (see 
Lukas> 
https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html#reverse-dns-mismatches)

How are you actually triggering the GSS-API authentication?
ldapsearch in all cases?
And you are confident that libkrb5 is triggering the reverse lookup not
your application?
(I realize that you may be using the same application on Debian and RH,
but there could be differences in the application code).

Bug#1069772: pmbootstrap: description doesn't tell me what the package does

[Sam Hartman]

package: pmbootstrap
version: 2.2.1-1
severity: minor

The description should tell the user what postmarket OS is.  That is for
example more important than knowing the package uses alpine chroots in
determining whether this package is useful to me as a user.

--Sam

Bug#1065806: fixed in pam 1.5.3-7

[Sam Hartman]

> "Christoph" == Christoph Anton Mitterer  writes:

Christoph> Hey Sam.
Christoph> There's a typ in the NEWS enty:
>> this user a group name that differs from the user name or add
Christoph>  |
Christoph>   should probably be "use"

Thanks, fixed on salsa for the next version.

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Sam Hartman]

I've read the wiki page.  I'm fine with the proposed approach.  I note
that by including pam_lastlog2.so in a pam-auth-update configuration,
other services (gdm, for example) will include lastlog info.

The fact that gdm and other display managers do not include
pam_lastlog.so suggests that it's usage is not all that important.

If pam_lastlog2 is also a session module,  I recommend it only be used
for interactive sessions
To do this include the following in the pam-auth-update config:

Session-Interactive-Only: yes




signature.asc
Description: PGP signature

Bug#1065806: pam: recent upgrade changes previous default umask

[Sam Hartman]

control: clone -1 -2
control: retitle -2 Document pam_umask change in release notes

Bug#1065806: pam: recent upgrade changes previous default umask

[Sam Hartman]

> "Professor" == Professor Jeebs  writes:


Professor> I prefer the way it is handled per user.  There is a related, 
commented
Professor> out, option in /etc/skel/.profile, which lands in new user 
directories,
Professor> which I have never touched the umask part until now.  I 
uncommented the
Professor> line to set the users' default umask settings to 022 and updated 
users
Professor> already on the system.


Just confirming.  You could have modified /etc/login.defs if you chose
and gotten a similar affect, right?

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Sam Hartman]

> "Aurelien" == Aurelien Jarno  writes:

Aurelien> If we go that route, here is a proposed alternative patch:

Aurelien> --- a/policy/ch-source.rst
Aurelien> +++ b/policy/ch-source.rst
Aurelien> @@ -338,7 +338,8 @@
Aurelien>  For example, the build target should pass 
``--disable-silent-rules``
Aurelien>  to any configure scripts.  See also :ref:`s-binaries`.
 
Aurelien> -For packages in the main archive, required targets must not 
attempt
Aurelien> +Except for packages in the non-free archive with the 
``Autobuild``
Aurelien> +control field unset or set to ``no``, required targets must not 
attempt
Aurelien>  network access, except, via the loopback interface, to services 
on the
Aurelien>  build host that have been started by the build.

Seconded.


signature.asc
Description: PGP signature

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sam Hartman]

> "Josh" == Josh Triplett  writes:



I tend to agree with  Sean that your rationale is not convincing.
It sounds like you want to use policy as a stick to hit people
over the head and say "policy is not a stick."

I get the impression that you are trying to shift the status quo
somehow, and remove flexibility and replace it with certainty.

Let's take installing info files.
Yes, the policy around info files is optional.
But if you have info files, I think it would be a great idea if you
installed them.
(And if you are going to do that, I think we are all agreed you should
follow policy in how you do that.)

You appear to be wanting to say that the presence of the info policy is
entirely neutral.
And I don't quite think that's true.

It could mean:

1) hey it's there if you want to install info files

2) Hey if you've got info files go install them and use this great
mechanism for doing so.

3) Hey, if you're looking for how to document your software strongly
consider info because we have a way of dealing with info.

I think you're arguing that globally unless policy says otherwise we're
at 1 above.
For info I think we're closer to 2, but probably somewhere between 1 and
2.
In the past, we were probably definitely at 2 and probably somewhere
between 2 and 3.
It has shifted over time as the set of software without texinfo
documentation increased, as the limitations in info format became more
important, and as html became more of a common format.

I think the kind of language you propose to add to policy harms rather
than encourages that sort of shift over time.

I think arguments of the form we have an approach for handling this in
policy, and uniformity is good, so please use this approach are
sometimes good.
I think your language would try and cut off those arguments more than
they should be cut off.
I also understand those arguments are sometimes bad.  As an example,
arguments of that form were made in favor of the Debian menu system long
past the time when desktop files were a better choice.

I suspect there are similar issues with cron files.  Five years ago,
even if policy didn't encourage cron as the preferred mechanism for
periodic tasks, it probably was the right choice.  Saying use cron
because we have a cron policy was not and should not be a valid
argument.  Saying that in a multi-init-system world there are
complexities around using something besides cron, and we've thought
through how to handle cron, so it's probably a good choice probably was
a compelling argument five or six years ago.  We probably haven't
thought through the implications of using something other than cron in a
multi-init-system world and making sure everything works well.  What has
changed is that it's not clear we're really in a multi-init-system-world
any more, and systemd has thought through the implications of periodic
tasks in a systemd world.

But I think the kind of language you proposed would be used to treat
arguments like "if you use cron it will work better for sysvinit; we
care about sysvinit; so do that," as "we talk about cron in policy, so
use it."
The second argument never has been valid.
The first argument is one I think should be valid in form, although at
the current time I think it is liked based on a false premise.
The second argument can be dismissed because of its form.
I think the first argument requires more consideration, and I think your
proposal would remove that consideration, even if reworded.


--Sam


signature.asc
Description: PGP signature

Bug#1066979: common-auth: sudo should not have incorrect password delay

[Sam Hartman]

> "Tim" == Tim Hutt  writes:
Tim> By default, on Debian and derivatives, `sudo` has a ~2 second
Tim> delay for incorrect password attempts. This serves no security
Tim> purpose whatsoever and merely annoys the user.

It's not obvious to me that it serves no security purpose.
Why can't sudo be used as a channel for password guessing?
Consider a case where ssh authentication does not permit passwords, but
where a password is required for sudo.

I'm unlikely to decide this is worth the complexity to fix (I think your
analysis of the possible options is roughly correct) even if there is no
security benefit.  I'm definitely not interested in fixing if there is a
security benefit.

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

[Sam Hartman]

> "Steve" == Steve Langasek  writes:


Steve> Hi Sam,

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

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

Will upload fixed krb5 sometime this weekend.

--Sam

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

[Sam Hartman]

> "Matthew" == Matthew Garrett  writes:

Matthew> I agree with the conclusions drawn here, but feel that it's
Matthew> possibly worth making a stronger general statement that
Matthew> policy should never prevent the implementation of a
Matthew> well-considered simple solution. I would like some further
Matthew> analysis of Sam's proposal, though - I don't think there's
Matthew> any advantage in undoing the existing solution, but if it
Matthew> would work then it's maybe a more straightforward solution
Matthew> for any similar issues in future?

Unfortunately, I think Simon's response to me is definitive.
Ultimately if the old package exists, it will continue to satisfy
dependencies.
That's exactly what we don't want in the time_t transition.

I think we might revisit this when we come to a discussion of how our
tools could provide us more flexibility to make issues like usrmerge and
time_t transition easier in the future.

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

[Sam Hartman]

Are there solutions in the space of having glib2.0-0 continue to exist
as a package depended on by glib2.0-0t64 or depending on the new library
allowing you to replace the postrm?
That might create a space in time where glib2.0-0.so does not exist, but
we probably have more flexibility there than  we do with essential
packages.

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

[Sam Hartman]

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

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

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

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

--Sam

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

[Sam Hartman]

package: pam
version: 1.5.3-5
severity: serious

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

This version of pam is not suitable for testing.

Bug#1065064: libpam-doc: doc-base reports missing files

[Sam Hartman]

> "Colin" == Colin Watson  writes:
Colin> in those doc-base files but are in fact missing.  I don't
Colin> know whether this is intentional (in which case the doc-base
Colin> registrations should be removed to match), or an accidental
Colin> build issue that should be fixed.


I think this is probably a build issue with the 1.5.2 -> 1.5.3 upgrade.
There were a number of doc changes.
I'm going to prioritize getting the archive working again over this:-)
but will get to it in a few days.


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

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

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

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

--Sam


signature.asc
Description: PGP signature

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

[Sam Hartman]

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

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

--Sam

Bug#1064454: debian-policy: Restrict deb822 field names more

[Sam Hartman]

> "Niels" == Niels Thykier  writes:

Niels> Simon Josefsson:
>> Would it make sense to change this to use an inclusive list of
>> permitted characters instead?  How about checking the field names
>> that is in use today, and construct a regexp of permitted symbols
>> out of that?  Starting point: [A-Za-z][A-Za-z0-9-_]*
>> 
>> /Simon

Niels> That is an option and would work for me.

I'd support something along these lines--an inclusive description rather
than an exclusive description.

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Sean" == Sean Whitton  writes:
Sean> In general, I agree with Santiago.  I find Policy's current
Sean> scope and working process effective, and not especially
Sean> ambiguous.  I think everyone should read it during the NM
Sean> process, if not sooner.

Sean> Russ has concretely considered these issues much more than me,
Sean> and Niels has worked extensively on an implementation, and I
Sean> have not.  These things count, so my sense that things are
Sean> broadly okay as they are only goes so far.

I agree with the above.
When Russ brought up concerns I didn't want to add stop energy to making
things better.
But I also am generally happy with policy today.  I find it useful and
refer to it often.  I find that with almost all of my NM applicants I
end up asking them to look at policy at various points in the process
and they do not run into trouble using the document.
The only reason they did not before is they were not in the practice of
doing so.

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Sam Hartman]

> "Matthew" == Matthew Vernon  writes:
Matthew> This continues to make me worry we are not on the path of
Matthew> robust engineering. But I appreciate I'm in a very small
Matthew> minority in that regard.

I want to second the above.
I do still believe that the way forward is through rather than by
backing out and starting over.
However, I think it is essential that we spend significant time figuring
out how we can do better with future upgrades and decision processes,
possibly at a point where we have enough distance that we can hear each
other without anger, while not so much distance that we have lost the
technical detail.

As an example, if I had known protective diversions would be part of the
solution back when debating whether merged /usr was something we were
ready to do, I would have said we absolutely were not ready to go down
the path until we had better architected tools.

I'm not proposing to turn around now, and that may possibly be an area
where Matthew and I disagree.  But I absolutely want to lend credibility
to the idea that we are digging ourselves into a hole, hoping that it
will become a tunnel and we will find light at the other end.

--Sam


signature.asc
Description: PGP signature

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Sam Hartman]

> "Ansgar" == Ansgar   writes:


Ansgar> As far as I understand this approach will break any consumer
Ansgar> on a library whose ABI changes to to the ABI changes
Ansgar> introduced here unless the consumer is built with the flags
Ansgar> from `dpkg-buildflags` (which would now define the ABI).

Ansgar> Do we want this?

I'm fairly sure we do not.  Elsewhere in the thread, I saw one of the
toolchain maintainers talking about what is involved in getting gcc to
support the new flags.  My suspicion is that handling things with
dpkg-flags is more about moving quickly with the transition than a
desired end state.

Personally I'd consider it a release blocker if we don't get the
compilers updated prior to the release.

I think it would be reasonable to open a bug on the toolchain packages
now talking about this.
I think logistically it would not be desirable for those bugs to be RC
at this time.
Yes, if not fixed they will eventually need to be, but for example I
don't think it would be desirable to block toolchain testing migrations
on this issue at this time.  And obviously we're not going to remove the
toolchain from the release.

--Sam
Speaking with my armchair I have no hat in this non-hat on.

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

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

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

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

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

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

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

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

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

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

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

Steve and I are unaware of usage in Debian either.

--Sam


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

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


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

Bug#1062210: libpam-runtime: pam-auth-update doesn't allow user-ordering of modules

[Sam Hartman]

control: severity -1 wishlist
control: tags -1 help

> "Philip" == Philip Prindeville  writes:

Philip> Package: libpam-runtime Version: 1.4.0-11ubuntu2.3 Severity:
Philip> important

Philip> Dear Maintainer,

Philip> We were trying to configure PAM authentication to use LDAP,
Philip> Radius, and local (pam_unix) authentication sources in that
Philip> order, so we ran "sudo pam-auth-update --enable ldap radius
Philip> unix".  Alas it's written in the descending priority order
Philip> coming from the /usr/share/pam-configs/ files.

That's true, and it turns out there are also issues even within a single
profile about whether you want try_first_pass or use_first_pass and some
other local issues involving interactions between ldap and unix.
If you take a look at the bugs open against pam, you see a number of
related issues.

However, this is an enhancement request, not  a bug.
pam-auth-update does not cover your use case, and it's going to be
nontrivial to get that working especially in the debconf interface.
I do not have time to work on that enhancement.

I would be happy to cooperate with someone on a design here and review
patches.  I'd ask though that as part of that process, they examine the
existing bugs related to interactions between pam_ldap and pam_unix and
make sure that we will not have to revisit the design later to
incorporate the other related issues.

--Sam

Bug#1061280: sysvinit crashes podman container on install

[Sam Hartman]

package: sysvinit-core:
version: 3.08-5
severity: important
justification: breaks unrelated software in uncommon environment

I was curious about a discussion on debian-devel, so I tried to install
sysvinit and wdm at the same time.
I tried:

podman run --rm -ti debian:unstable
apt update
apt install sysvinit-core

And my container crashed when sysvinit-core was installed and restarted.
To get things "installed" I copied /dev/null over the sysvinit-core
postinst.

I'd like to be able to create a podman or docker image running sysvinit.
To do that I need to be able to install sysvinit with a container that
has /bin/bash or /bin/sh as an entry point and then image that container
into an image that has init as the entry point.  For that to work
sysvinit-core has to be able to install even when there is no init
system.

--Sam

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Package: tech-ctte Given our discussion at the last CTTE
Helmut> meeting, I am turning my request for advice into a formal
Helmut> one.

Helmut> Most of the /usr-move that is happening via DEP17 seems to
Helmut> be working out, but the effects of Conflicts raise the
Helmut> question of what kinds of interactions with a package
Helmut> manager are considered supported.

Helmut> A naive reading of Debian policy 7.4 suggests that declaring
Helmut> a conflict reliably prevents concurrent unpack:

Helmut> | When one binary package declares a conflict with another
Helmut> using a | Conflicts field, dpkg will refuse to allow them to
Helmut> be unpacked on | the system at the same time.

Helmut> If you account for the effects of aliasing, this turns out
Helmut> to be a too naive reading as dpkg actually allows unpacking
Helmut> a conflicting package if the other package is scheduled for
Helmut> removal. Normally, this exception should not have observable
Helmut> consequences, but aliasing makes it observable in the form
Helmut> of file loss. I have filed #1057199 to clarify
Helmut> debian-policy.

I'd really like to understand why this is desired dpkg behavior.
I appreciate that even if it is not desired behavior, we might not be
able to get it fixed in ways that matter for this discussion.
However my intuition is that it  will help me at least think about the
situation.
As an example if the reason that behavior is needed has to do with some
situation involving essential packages and conflicts, I'd like to
understand that situation and how common it is.
It would not be the first time in this discussion that we have
discovered a new complexity.

--Sam

Bug#1057775: [INTL:sv] Swedish strings for pam debconf

[Sam Hartman]

> "Anders" == Anders Jonsson  writes:

Anders> Hi Martin, one change in this one (fixed spelling of
Anders> "användare").

I don't think you attached a .po file.

Bug#1060034: ITP: python-openai -- OpenAI Python API library

[Sam Hartman]

> "Mo" == Mo Zhou  writes:

Mo> On 1/5/24 11:45, Ansgar wrote:
>> Then the package should be in main.
>> 
>> We do not require external software to be free as well, be that
>> Web APIs provided by Github, Twitter, or the NVidia firmware
>> required for Nouveau, microcode or storage/keyboard/sound/printer
>> firmware required for Linux, ...  We would have to move pretty
>> much everything to contrib if that was the case.
Mo> OK. It seems that I misunderstood it all the time. Mailed
Mo> ftp-master to reject so I can change the section and reupload.


Also, I thought that there were several open-source implementations of
this API, including from llama.cpp and ctransformers among others.  My
impression was the OpenAI API had become kind of a standard for gluing
something like text-generation-webui to a hosted model not running
locally.
Or is that some *different* OpenAI API?

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> At least the dpkg behavior seems entirely
Guillem> correct to me and required for safe upgrades (

Can you help me understand the sentence above?
Where is the case where this behavior is needed for safe upgrades?
(I am asking out of curiosity; I'm guessing it's some corner case with
essential packages, but I would like to understand.)

--Sam

Bug#1058779: libk5crypto3 fails to install via apt (dpkg error) triggers ci file contains unknown directive 'set'

[Sam Hartman]

control: severity -1 normal
control: tags -1 help

> "Fernando" == Fernando Toledo  writes:

Fernando> as workarount i do apt-mark hold libk5crypto3 until
Fernando> problem fixes

I don't think this problem is likely to be in libkrb5crypto3.
I don't have enough experience with the dpkg trigger mechanism to really
understand what is going on, but my suspicion is that some other package
is setting up a trigger that your version of dpkg does not understand
(or that something is corrupted on your system).

Bug#1057729: pam FTCBFS: passes host flags to build compiler

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:
Helmut> Can I leave this up to you? To verify the cross build
Helmut> failure, please use amd64 or arm64 as host
Helmut> architecture. These are the only ones with
Helmut> architecture-specific compiler flags.

Up to who?  Andreas?  If so, I will let him speak for himself.  If you
are asking me to take this on, I'd love to but realistically I do not
have the time.

Bug#1032207: libpam-modules: Drop pam_userdb

[Sam Hartman]

Bastian> Your suggestion splitting out and removing after one
Bastian> release would be fine for me.


Helmut, I was hoping for a sanity check.
Bastian wants to split out some code from pam.
He wants to move pam_userdb.so into its own package to remove db5.3 from
the pseudo-essential set.

I've said that I'd be fine with that if we had libpam-modules depend on
the new package for a release. (It might be okay to do something else,
but that would require surveying users or detecting breakage in ways
that require more thought than I would like to spend).

Complications:

* pam is ppseudo-essential
* usrmerge transition (pam libdir is currently /lib)

So ignoring essential and usrmerge, I think the new package  would
replace/breaks libpam-modules << the split point.

Do you have advice on what we want to do given usrmerge and essential?

--Sam

Bug#1032207: libpam-modules: Drop pam_userdb

[Sam Hartman]

> "Bastian" == Bastian Germann  writes:

Bastian> X-Debbugs-Cc: vor...@debian.org Hi Sam and Steve,

Bastian> On Wed, 1 Mar 2023 18:34:50 +0100 Bastian Germann wrote:
Bastian> I would volunteer to provide a patch for this but only if
Bastian> it will be considered.

The patch isn't the hard part.
Honestly, I think splitting into a separate package is a lot lower risk
than  removing, but if we do that, we presumably need to have
libpam-modules depend on that package for a release cycle.

I'd definitely take a patch against the wip/debian_1.5.3 patch to split
out the module into its own package and to add a dependency from
libpam-modules to that new package. (and then we would want to remove
that dependency in the next release).

Anything more disruptive requires me to think a lot.
I'd rather not focus my energy on that, but I am open to being convinced.
I am not tracking your involvement in projects that want to reduce the
pseudo-essential set.
Is this a nice to have for you, or are you heavily involved in something
with broad consensus where this is important.

--Sam

Bug#915583: debian sphinx styling: second attempt

[Sam Hartman]

>>>>> "Stéphane" == Stéphane Blondon  writes:

Stéphane> Le ven. 3 nov. 2023 à 15:43, Sam Hartman
Stéphane>  a écrit :
>> >>>>> "Sean" == Sean Whitton  writes:
>> 
>> I'm happy to test with Orca on Firefox on Debian.  Feel free to
>> point me at a URL.
>> 


Stéphane> You can test it at: http://stephane.yaal.fr/tmp/policy/

Given a quick look, appears okay to me.

Bug#915583: debian sphinx styling: second attempt

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> - it would be good to do some accessibility testing of some
Sean> kind, at least with screenreaders.  But maybe the fact that
Sean> you've based your theme on an existing, popular Sphinx theme
Sean> means this is covered?

I'm happy to test with Orca on Firefox on Debian.
Feel free to point me at a URL.

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

[Sam Hartman]

>>>>> "Lucas" == Lucas Nussbaum  writes:

Lucas> On 26/10/23 at 07:45 -0600, Sam Hartman wrote:
>> >>>>> "Lucas" == Lucas Nussbaum  writes:
Lucas> Hi,
>> 
Lucas> As an additional data point, I can still reproduce this
Lucas> failure.
>> 
>> So, my understanding is that so far for you it always fails, and
>> the evidence so far suggests that it generally (or always, but I
>> am not sure we have long enough evidence for that) succeeds on
>> the builds.
>> 
>> What is your environment like?  Chroot? Container?  If any
>> namespaces are involved, how do you build the namespaces, and
>> what non-default capability settings do you have on top of the
>> defaults of containerization software you use.

Lucas> It's a standard sbuild setup, on an AWS EC2 VM.

Yep, it's some sort of DNS issue.  A kind developer gave me access to a
similarly configured machine on which I can reproduce the problem.

Outside the chroot:

PING ip-10-84-234-64(ip-10-84-234-64 (fe80::816:edff:fe35:ded1%ens5)) 56
data bytes
64 bytes from ip-10-84-234-64 (fe80::816:edff:fe35:ded1%ens5):
icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from ip-10-84-234-64 (fe80::816:edff:fe35:ded1%ens5):
icmp_seq=2 ttl=64 time=0.035 ms
^C
--- ip-10-84-234-64 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1010ms
rtt min/avg/max/mdev = 0.022/0.028/0.035/0.006 ms


(bookworm)hartmans@ip-10-84-234-64:~$ ping ip-10-84-234-64
ping: ip-10-84-234-64: Name or service not known

The test framework uses gethostname() to find the name to use to contact
the KDC.
kinit is trying to look up ip-10-84-234-64 and contact a KDC on that
address.
But because that name is not resolvable within the chroot, the test
fails.

The configuration difference between inside the chroot and outside the
chroot appears to be the use of systemd-resolved.
In particular libnss-resolve  is installed on the host.
Resolved can resolve ip-10-84-234-64,
but the EC2 nameserver referenced by resolv.conf in the chroot cannot
resolve that name without qualification.

I'm not entirely sure what the right fix is.  Krb5 tests really do want
a name that they can use to refer to the local machine (and it would be
significant work to get that name from a source other than
gethostname()).

Possibilities include:

* Use 127.0.0.53 inside the chroot and let systemd-resolved resolve the
  name.

* Find some way to detect this situation and bypass the tests.

* include the appropriate search domain in the chroot's resolv.conf so
  that EC2 can resolve the machine's name.
  

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

[Sam Hartman]

> "Lucas" == Lucas Nussbaum  writes:
Lucas> Hi,

Lucas> As an additional data point, I can still reproduce this
Lucas> failure.

So, my understanding is that so far for you it always fails, and the
evidence so far suggests that it generally (or always, but I am not sure
we have long enough evidence for that) succeeds on the builds.

What is your environment like?
Chroot? Container?  If any namespaces are involved, how do you build the
namespaces, and what  non-default capability settings do you have on top
of the defaults of containerization software you use.

--Sam

Bug#1054228: pam FTBFS: No series file found

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

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

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

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

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

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

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

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


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Santiago" == Santiago Vila  writes:


Santiago> This could be simply a race condition.

Santiago> I've seen many packages to fail their tests randomly
Santiago> because of that.

It could be a race, but given what I know of the tests, I doubt it is.
Take a look at util/k5test.py in _start_daemon
In particular, it waits for a particular string to be printed before
declaring the service running.


Santiago> However, you seem to be automatically assuming that the
Santiago> failure is due to some of those things you enumerated,
Santiago> i.e. a "difference of build environments".

Santiago> But such thing is not necessarily true.

Agreed.
Based on a long history with the package and the tests in question I am
making some assumptions.
You're absolutely right that these assumption may end up being
inaccurate.
Certainly if I do see failures on a buildd that suggest a race, I will
be very concerned.
If there is a race on the buildds, I think that will become clear over
time.
>> So, unless I'm violating some written policy somewhere, my claim
>> is that this is all good.

Santiago> I think you forgot Policy 4.2, which is also "written
Santiago> policy somewhere".  This is what it says:

I'm aware of policy 4.2.
I'm also aware that there has been some disagreement over the years
about what that means for things beyond packaged dependencies.
In particular, how that relates to available memory, cpu, etc.
And for example related to where builds can write, etc, etc.
And some of that has been resolved, and I suspect some issues have not.
It would not surprise me if there are some corner cases surrounding what
builds can do with regard to the network on the local system are
ambiguous.
We all agree that builds cannot access the internet, but beyond that I
think there is ambiguity.

But yes, if this ends up being a race, I will absolutely be interested
in fixing the race or disabling the tests.

--Sam

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

[Sam Hartman]

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

Lucas> Hi,

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


Lucas> Relevant part (hopefully):


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

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

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

--Sam

Bug#1052433: bookworm-pu: package pam/1.5.2-6+deb12u1

[Sam Hartman]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: p...@packages.debian.org, Guido Berhoerster 

Control: affects -1 + src:pam


[ Reason ]

Before the bookworm freeze, I introduced a --disable option to pam-auth-update 
so you could programatically disable a pam profile.  (You can also muck around 
in debconf and then call pam-auth-update --package, at least under some 
circumstances, but this is a better interface.)
Unfortunately, I had a bug,  and the next time pam-auth-update is run, the 
profile will be enabled again.

The fix is trivial and is covered by a updated autopkgtest.
Debian-edu says they would like this change in bookworm so they can
disable ldap auth in favor of Kerberos.  I think this is low risk.

I have also included translation updates.


[ Impact ]

Debian-edu will have to work around this somehow.  The new --disable option 
won't work in many situations.

[ Tests ]

Autopkgtests have been updated to confirm the fix; I confirmed the old code 
fails and the new code passes.
I've also tested manually.



[ 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 ]
git diff debian/1.2.5-6..HEAD

diff --git a/debian/changelog b/debian/changelog
index 83794f03..22c1699d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pam (1.5.2-6+deb12u1) bookworm; urgency=medium
+
+  * Fix pam-auth-update --disable logic error, Closes: #1039873
+  * Set myself as maintainer; thanks Steve for past and future work.
+  * Updated Turkish Debconf translations, Thanks Atila KOÇ, Closes: #1029002
+
+ -- Sam Hartman   Thu, 21 Sep 2023 14:55:12 -0600
+
 pam (1.5.2-6) unstable; urgency=medium
 
   * Update debian/copyright, Thanks Bastian Germann, Closes: #460232
diff --git a/debian/control b/debian/control
index 4b685f16..9cdc3f81 100644
--- a/debian/control
+++ b/debian/control
@@ -1,8 +1,8 @@
 Source: pam
 Section: libs
 Priority: optional
-Uploaders: Sam Hartman 
-Maintainer: Steve Langasek 
+Maintainer: Sam Hartman 
+Uploaders: Steve Langasek 
 Standards-Version: 4.6.0
 Build-Depends: debhelper-compat (= 13), dh-exec, quilt, flex, libdb-dev, 
libcrypt-dev, libselinux1-dev [linux-any], po-debconf, dh-autoreconf, 
autopoint, libaudit-dev [linux-any] , pkg-config, libfl-dev, 
libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m
 Build-Conflicts-Indep: fop
diff --git a/debian/local/pam-auth-update b/debian/local/pam-auth-update
index b3de86e7..ac00b1c9 100644
--- a/debian/local/pam-auth-update
+++ b/debian/local/pam-auth-update
@@ -162,7 +162,9 @@ push(@enabled,
 # Disable anything explicitly disabled
 @enabled = grep {!$to_disable{$_} } @enabled;
 # And we've seen anything we disable
-delete @seen{ keys %to_disable};
+foreach my $i (keys %to_disable) {
+$seen{$i} = 1;
+}
 
 # an empty module set is an error, so in that case grab all the defaults
 if (!@enabled) {
diff --git a/debian/po/tr.po b/debian/po/tr.po
index 0bd9b64c..19b0c1ef 100644
--- a/debian/po/tr.po
+++ b/debian/po/tr.po
@@ -1,48 +1,40 @@
-# Debconf questions for the Linux-PAM package.
-# Copyright (C) 2007 Steve Langasek 
+# Turkish translation of pam.
 # This file is distributed under the same license as the pam package.
-# Mert Dirik , 2008.
+# Mert Dirik , 2008, 2014.
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: pam 0.99.7.1-5\n"
+"Project-Id-Version: pam\n"
 "Report-Msgid-Bugs-To: p...@packages.debian.org\n"
-"POT-Creation-Date: 2021-02-26 10:32-0500\n"
-"PO-Revision-Date: 2014-08-01 14:42+0200\n"
-"Last-Translator: Mert Dirik \n"
-"Language-Team: Debian L10n Turkish \n"
+"POT-Creation-Date: 2021-03-15 18:23-0400\n"
+"PO-Revision-Date: 2022-12-26 12:26+0300\n"
+"Last-Translator: Atila KOÇ \n"
 "Language: tr\n"
+"Language-Team: Debian L10n Turkish \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Plural-Forms: nplurals=1; plural=0;\n"
-"X-Generator: Poedit 1.5.4\n"
+"X-Generator: Poedit 2.4.2\n"
+"Plural-Forms: nplurals=2; plural=(n > 1);\n"
 
 #. Type: string
 #. Description
 #: ../libpam0g.templates:1001
 msgid "Services to restart for PAM library upgrade:"
-msgstr ""
-"PAM kitaplığının yükseltilmesi için yeniden başlatılacak olan hizmetler:"
+msgstr "PAM kitaplığının yükseltilmesi için yeniden başlatılacak hizmetler:"
 
 #. Type: string
 #. Description
 #: ../libpam0g.templates:1001
-#, fuzzy
-#| msgid ""
-#| "Most services that use PAM need to be restarted to use modules built for "
-#| "this new version 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> Aside from more practical considerations, shipping /var
Luca> content in packages is problematic because it's supposed to be
Luca> local variable data,

I agree with the above.

Luca> that can be removed without breaking a
Luca> system.

Says who?
Where?
Do we have any agreement within Debian that is true for Debian systems?
If so, where?  This is the first I am hearing about the idea I should be
able to delete local variable data and have the system  still work.

If you're talking about *empty directories in /var* or *cache
directories in /var*,
I support that as a goal.  I think it is a new goal though, and I'm
uncomfortable stating it as a reality.
(I think tmpfiles.d helps us achieve that and that's one of the
compelling reasons for tmpfiles.d).

But WRT other data in /var, I don't think we've agreed that being able
to delete it is a goal.

Bug#1051371: Post-/usr-merge paths for script interpreters

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Wed, 13 Sept 2023 at 04:48, Russ Allbery  wrote:
>> 
>> Control: retitle -1 Post-/usr-merge paths for script interpreters
>> 
>> Simon pointed out that this bug is not yet ready to act on, which
>> was very helpful.  Thank you.  However, presumably the buildds
>> will be /usr-merged at some point in the not-too-distant future,
>> and we do need to decide what to do after that point.

Luca> While that could be said for the original revision, in my view
Luca> that's not really the case for the latest that I posted?

Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371#120

Luca> So I would prefer if this was a clone rather than a
Luca> retitle/repurpose.  Unless I'm missing something, the changes
Luca> linked above should be uncontroversial and simply remove
Luca> excessively normative language in what are essentially
Luca> examples that should have been taken as such - and that
Luca> currently are not. So, could that be taken forward
Luca> independently of the problem you define below?

I agree the above is uncontroversial and would support including it in
policy now.
I don't think it needs seconds because it is non-normative.

(As an aside, reading the summary, I expected to find the patch
something I was not entirely happy with.  I was planning to hold my
nose, and neither support the patch nor object.  However, since you
brought it up again, I read the full patch and find I like the patch a
lot better than your summary of it:-)


signature.asc
Description: PGP signature

Bug#1039873: fixed in pam 1.5.2-7

[Sam Hartman]

> "Guido" == Guido Berhoerster  writes:

Guido> Are there plans to get this into stable-updates?

No, not currently.
But if you would agree to test in testing/unstable now, and test again
once it gets into stable-proposed, I'd be happy to raise the severity to
important so that it is eligible for bookworm and prepare an update.

--Sam

Bug#1051371: Post-/usr-merge paths for script interpreters

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> with a narrower issue).  Several other people were, I think,
Russ> arguing for (a), but I'm not sure if they would continue to do
Russ> so when it's put in these terms.

It's hard for me to express what I was advocating for in the terms you
have adopted.
I think you've  advanced the discussion significantly by making it clear
where the difficulty is, which will help me focus my argument.


Russ> If someone wants to argue for (a) or (c), I think the biggest
Russ> problem with either of them is an enforcement mechanism.

My problem with (b) is that I value interfaces and that  especially for
/bin/sh I do think that /bin/sh is more portable as an interface path
than /usr/bin/sh.
I care a lot that we use /bin/sh in our documentation and examples
(especially in policy).
I care a lot that we point out that the reality of the situation is
people  will see other paths.
At least for things traditionally in /bin I do not want to encourage
those other paths, but I also don't think it is often a good use of
project resources to "fix" those other paths.
In some cases (for example what version of a path autoconf detects), I
think that patching individual packages to detect a particular path
would be net harmful.

So I want to argue for (a) with no  enforcement mechanism in packages.

1) Policy should encourage /bin paths for binaries traditionally in
/bin. (At a minimum I'd like to see this for /bin/sh and /bin/bash).
That at most makes it a minor bug if you don't follow that
encouragement.

2) The examples in policy should use the standard interface paths.
(This is the thing I care most about).

3) I'd like to see policy point out that /usr/bin paths will end up
being used, and packages SHOULD work regardless of which path is used.

I think there are some complexities here.  Imagine someone writes a tool
to determine if something is a shell script.  If it's security
sensitive, I think it is important that it work both for /bin/sh and
/usr/bin/sh.

If it's a syntax highlighting program and it only detects
/bin/sh as a valid shell script, I'd be okay if the maintainer didn't
want to fix it but instead said "fix your shell scripts if they say
/usr/bin/sh."  (I think the maintainer would be doing a better job if
they supported both).  But I would not be comfortable with a syntax
highlighting tool pushing people toward /usr/bin/sh.



signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

I don't know if this needs seconds, but I reviewed all the text and it
looks good.
If seconds are required, I second.


signature.asc
Description: PGP signature

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Bill" == Bill Allombert  writes:
Bill> But we do: we support debhelper 13.11.4 and debhelper 13.11.6.
Bill> Even if we support a single implementation, we still need to
Bill> know what is expected of it.

At that level, I think the answer is roughly that if you call
dh_installsystemd, then any units in the package installation directory,
or any units matching certain file patterns in the debian directory will
be installed and if appropriate enabled.


I understand there's some work to do:

* do we support units in /lib/systemd/system, /usr/lib/systemd/system,
  or both.

* What are those filename patterns for finding service units under
  debian?

* You might implicitly call dh_installsystemd via dh

I think Russ might be arguing that we should actually push all that out
to the Debhelper documentation.  I'd support that, although I understand
that makes the debhelper 13.4 vs 13.6 issue more relevant.  I'd also
support describing a bit of the interface between debian/rules and
debhelper wrt systemd units if it allowed us to move forward.

My argument is that even if we support multiple versions of debhelper,
we do not need to define the interface between debhelper and systemd in
policy: we do not need to specify deb-systemd-helper and
deb-systemd-invoke.

--Sam

Bug#1051523: Doxygen changes breaks krb5 documentation build

[Sam Hartman]

> "Tianyu" == Tianyu Chen  writes:


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

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

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

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

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


signature.asc
Description: PGP signature

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Santiago" == Santiago Vila  writes:

Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió:
>> I therefore would like to propose a first: I think Policy should
>> simply say that any package that provides a system service should
>> use debhelper and rely on dh_installsystemd to put the
>> appropriate commands in its maintainer scripts.  (We can then
>> discuss whether we should do the same for init scripts and
>> dh_installinit, although its stanzas are simpler.)

Santiago> Hello. I don't like this approach, and I believe we are
Santiago> mixing two different things here. One of them is our
Santiago> ability (or lack thereof) of policy to catch up with real
Santiago> development done elsewhere. Another one is the fact that
Santiago> policy does not mandate any given implementation.

The question in my mind is whether it is valuable to support multiple
implementations, and I think the answer is no.

In the past, there was not a preference for using debhelper.  So, back
then, we did need to support multiple implementations of debian/rules,
and we needed to specify the things debhelper did.

Having a specified interface like policy is expensive.  I know; I've
spent a good chunk of my life working on various protocols and
standards.
Having specified interfaces brings value when you need multiple
implementations and in a few other cases, like where you need to plan
for certain forms of extensibility or isolation.

There's a part of this where we do need an interface.  We will have
multiple packages wanting their debian/rules to install systemd units.
So, we do need to at least say or imply that if you stick systemd units
in the right place and call dh_installsystemd, then your systemd units
will be properly handled.

But today, we have a policy preference for using debhelper.  We do not
need multiple implementations of debhelper.  There does sort of need to
be an interface between debhelper and systemd if for no other reason
than to allow for systemd to change and to control which details are
hard-coded in maintainer scripts.  But if we agree that we do not need
multiple implementations of debhelper, the policy team does not need to
be part of defining that interface.  We can be more efficient by not
being involved in that process.  Also, we can do a better job of
focusing on the interface that the project does care about (how to tell
debhelper to install your systemd units) and not confuse people with the
details between debhelper and systemd.

Also, by explicitly acknowledging that the deb-systemd-helper and
deb-systemd-invoke interfaces are effectively between debhelper and
systemd, those interfaces can be simpler because they do not need to
allow for multiple implementations of debhelper or systemd.

In effect by making this decision, we are strengthening our preference
for saying packages should use debhelper.  For a significant class of
packages (those with service units) there really will be no easy
alternative.  And if we go down that route, over time, we will probably
prefer debhelper more and more, and it will be less possible to generate
a policy-compliant package that does not use debhelper.

I think that's desirable.
I think we can still find ways to experiment with new more declarative
ways of handling package building.  But I think that having more
uniformity in the cases where we have a single solution that has broad
support will make things easier for everyone.

Put another way, having multiple implementations is often very expensive
in terms of interface complexity, testing complexity, and especially
complexity that developers need to deal with.
In this instance, I do not think that cost is justified.

--Sam


signature.asc
Description: PGP signature

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> I therefore would like to propose a first: I think Policy
Russ> should simply say that any package that provides a system
Russ> service should use debhelper and rely on dh_installsystemd to
Russ> put the appropriate commands in its maintainer scripts.  (We
Russ> can then discuss whether we should do the same for init
Russ> scripts and dh_installinit, although its stanzas are simpler.)

For a variety of reasons, I support this.


--Sam

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

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Sun, 10 Sept 2023 at 03:19, Russ Allbery  wrote:
>> 
>> Russ Allbery  writes:
>> 
>> > -If a service unit is not present, ``systemd`` uses dependency
>> information > -contained within the init scripts and symlinks in
>> ``/etc/rcn.d`` to decide > -which scripts to run and in which
>> order.  The ``sysv-rc`` runlevel system > -for ``sysvinit`` uses
>> the same symlinks in ``/etc/rcn.d`` to decide which > -scripts to
>> run and in which order at boot time and when the init state (or >
>> -"runlevel") is changed.  See the ``README.runlevels`` file
>> shipped with > -``sysv-rc`` for implementation details.  Other
>> alternatives might exist.  > +``systemd`` uses dependency and
>> ordering information contained within the > ++enabled unit files
>> to decide which services to run and in which order.  > +The
>> ``sysv-rc`` runlevel system for ``sysvinit`` uses the same
>> symlinks in > +``/etc/rcn.d`` to decide which scripts to run and
>> in which order at boot > +time and when the init state (or
>> "runlevel") is changed.  See the > +``README.runlevels`` file
>> shipped with ``sysv-rc`` for implementation > +details.  Other
>> alternatives might exist.
>> 
>> And of course I have to post the diff to see the bugs.  The part
>> that says "uses the same symlinks" should now say "uses
>> symlinks".

Luca> Thank you, looks good to me, seconded.

LGTM too, seconded.



signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Sun, 10 Sept 2023 at 11:31, Simon McVittie  wrote:
>> 
>> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
>> > Luca, am I right that service directories are specific to,
>> well, services?  > If so, what would you think of moving them to
>> Policy 9.3 alongside the > other discussion of systemd units?
>> They feel out of place here, since > packages that do not use
>> services cannot use this functionality
>> 
>> I'm not Luca, but I think you're correct here.

Luca> Moved as suggested. Also incorporated your suggestion on the
Luca> versioned virtual package dependency verbatim.

>> > Luca Boccassi  writes: > > +Packages might
>> need additional files or directories to implement their > >
>> +functionality. Directories that are located under ``/var/`` or >
>> > +``/etc/``, and files that are located under ``/var/``, should
>> not be > > +created manually via maintainer scripts, but instead
>> be declaratively > > +defined via the `tmpfiles.d > >
>> +`_
>> > > +interface.  Files and directories under ephemeral
>> filesystems such as > > +``/tmp/`` may also be created and
>> managed via ``tmpfiles.d`` snippets.
>> >
>> > I understand the empty directory part, but I don't believe
>> "files that are > located under /var" is correct unless you
>> specifically mean *empty* files > (and even then, I'm not clear
>> on precisely when this would be needed).  > For example,
>> /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package >
>> maintainer script, and I can see no possible way that action
>> could (or > should) be handled by the tmpfiles.d mechanism.
>> 
>> In general tmpfiles.d handles files that exist only as metadata:
>> symbolic links (for which the target is the only interesting
>> fact), empty files (for which the existence and
>> ownership/permissions are the only interesting facts),
>> directories (ditto) and so on.
>> 
>> It can also handle files that have static initial contents that
>> do not vary between systems, but can change in a system-specific
>> way later, with initial contents either hard-coded in the
>> tmpfiles.d snippet (for short text strings) or copied from
>> somewhere below /usr (canonically /usr/share/factory).
>> 
>> Files generated by non-trivial imperative code, like
>> machine-specific initial contents (/var/lib/dbus/machine-id) or
>> some sort of compiler (/var/lib/gnubg/gnubg_ts0.bd, as far as I
>> can tell), are out of scope for tmpfiles.d, so I think you're
>> right to be concerned that Luca's wording as written is asking
>> gnubg to do something that is unimplementable.
>> ch-maintainerscripts.rst has the same issue.
>> 
>> Perhaps "files with trivial contents that are located under /var"
>> would be a good wording that is not overly specific about
>> implementation details, covers the 90% case, and leaves room for
>> exceptions by declaring packages like dbus and gnubg to be
>> non-trivial?

Luca> I have reworded as suggested, citing symlinks or short fixed
Luca> strings as examples.

I second this patch, and do not need to additionally review Russ's
minor rewordings

--Sam


signature.asc
Description: PGP signature

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Here is an updated proposed change for this bug, incorporating
Russ> Guillem's suggestions.  It is ready for seconds.

Russ> -- Russ Allbery (r...@debian.org)
Russ> 

I have reviewed the patch; I support the idea and second the specific
wording.


signature.asc
Description: PGP signature

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:
Luca> Secondly, and less importantly, while I appreciate it's not
Luca> how you handle policy changes, the way the rest of the
Luca> distribution works is by 'building consensus' on mailing
Luca> lists. Now I don't particularly like it, but it is what it
Luca> is. And that means if somebody comes up with the most
Luca> egregious nonsense like, to pick a completely fictional
Luca> example, "hey folks, usr-merge broke docker, rsync and
Luca> ansible, we need to revert it", and it is left unchallenged,
Luca> then it becomes doxa.  So it has to be challenged. Every
Luca> time. After half a decade, you don't think _that_ is
Luca> exhausting?


Thanks for sharing this.
I understand what you've been doing a lot better now.  And if it is
actually true that you need to challenge these assertions every time,
your behavior makes more sense to me.

However, it's been my experience that challenging these assertions every
time is unnecessary.  It actually makes it harder to judge consensus and
keeps discussions alive longer than they need to.
I actually think that there are cases where if you had said less, a
consensus you would have liked just fine would have emerged faster  than
has happened.
Often when someone says something rediculous in a consensus discussion
it is best to let it fall into a void of silence.
Challenging it can sometimes just give it energy.

I would be very open to helping you (or anyone) explore how to work more
efficiently in a consensus environment and how to espace from a
consensus discussion when consensus is the wrong tool.
I realized that I focused a lot on consensus during my term as DPL.  A
lot of that was that I was hoping to help people explore how to approach
consensus discussions better (and because it was the right tool for some
of those discussions).
But there are a lot of discussions where consensus is the wrong tool.
And now that we've leveled up how we approach consensus discussions,
perhaps we should level up how not to have them:-)


signature.asc
Description: PGP signature

Bug#1041129: krb5-config install doesn't gracefully handle read-only /etc/krb5.conf file and errors out

[Sam Hartman]

> "Ben" == Ben Brenek  writes:


Ben> Installing Kerberos on other distributions with a similar setup
Ben> does not result in this type of error. Which is why I'm opening
Ben> this bug report.

What forced you to install krb5-config though?
Is there any hard dependency forcing this, or is it just a recommends.
It's generally expected that when installing a package, that package
should be able to write the files it owns.
If all you need to do is not install krb5-config, then I will consider
that sufficient.
Your suggestion that we test /etc/krb5.conf writability can potentially
fail to detect situations where the installation should properly fail.

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> I would. Having two paths for the same thing is a technical
Bill> debt going forward.

I think the TC has made it clear we're committed to usrmerge at this
point, and I think that one of the drivers behind usrmerge is that we
gain more from having both /bin/python and /usr/bin/python work than we
lose by having two paths.
I understand people disagree,
but I think we should fall in behind the TC decision and accept we've
decided that in this instance we value aliasing.

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

>>>>> "Ansgar" == Ansgar   writes:

Ansgar> On Wed, 2023-09-06 at 16:51 -0600, Sam Hartman wrote:
>> > > > > > "Luca" == Luca Boccassi  writes:    
>> Luca> /bin/sh is not universally compatible with non-Linux OSes.
>> 
>> I claim it is more compatible.

Ansgar> Why should that matter to Debian?


Debian has traditionally valued supporting common interfaces like posix,
fhs, Linux ABIs, etc where that makes sense.
We recently had a discussion of the value of interfaces in  the
discussion of changing the ABI to make merged /usr easier, and I do not
want to revisit that.

I do value this sort of interface stability, and Debian's alignment with
my values is one of the things that drew me to Debian.

So, yes, I do believe we should support encouraging portability where
that is reasonable for us.
I admit that I care more about OSes like FreeBSD than Mac OS.

More over, when merged /usr was presented to the project, it was
presented as a way to move the physical locations on files and as a way
to create an alias so that we didn't need to argue when different
distributions  made different decisions about /bin vs /usr/bin.
It was not presented as a change to common interface paths like /bin/sh.

This request is new, and given the politics, is something I find highly
problematic.
It is not abusing maintainers to ask them to respect long-standing
interfaces like the location of /bin/sh.
As Simon has pointed out, in a number of cases it is still actually RC
because it can break builds.
It is not abusive to ask maintainers to fix issues that prevent their
packages from building.
We make mistakes.
It is not abusive to get the severity of a bug wrong or even to disagree
with the severity of a bug.

I am sympathetic to the idea that after buildds are updated, we we might
want to reduce the severity of not using longstanding interface paths,
and in some cases not even treat it as a bug.
I reject the idea that /usr/bin/sh should be preferred over /bin/sh or
even the idea that it should be equally preferred.
I am open to the idea that we may not care to record that as a bug or
spend the time fixing it.

However, the tone and approach in this discussion does not encourage me
to participate.
If the current tone continues, I will use up the energy I have for
working toward a compromise and simply stand behind my support of
longstanding practice and  support of portable interfaces.

--Sam


signature.asc
Description: PGP signature

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:
Luca> How would such a change look like?

I looked at your patch.

In most of the cases you are changing non-normative language.
That is, parts of policy that do not create a requirement.
For example:
>Scripts may assume that "/bin/sh" implements the POSIX.1-2017 Shell
>Command Language  [7] plus the following additional features not
>mandated by POSIX.1-2017.. [8]

That creates no requirement on a package.

>* The term *may* and the adjective *optional* are used to clarify
>  cases where it may otherwise appear that Policy is specifying a
>  requirement or recommendation. In those cases, these words describe

I.E. in the cases you adjust, I think it is already
not a bug, and it would be inappropriate to use existing policy language
to complain about which interpreter path people use.

There is one case however where I think your patch adjusts normative
language.

I propose the following adjustment to your patch.  Rather than mandating
a particular path for a csh interpreter, make it clear that the policy
requirement is that the csh script start with a #! line rather than
simply assuming csh will interpret the script as was all too common back
in the days of csh:

@@ -266,7 +266,7 @@ including ``open``, ``print``, ``close``, ``rename`` and 
``system``.
 Programming Considered Harmful*, one of the ``comp.unix.*`` FAQs, which
 can be found at http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/. If
 an upstream package comes with ``csh`` scripts then you must make sure
-that they start with ``#!/bin/csh`` and make your package depend on the
+that they start with the path of a csh interpreter such as ``#!/bin/csh`` and 
make your package depend on the
 ``c-shell`` virtual package.

 Any scripts which create files in world-writeable directories (e.g., in

I think the other hunks of your patch are unnecessary to avoid policy be
used to create bugs in this space.

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:
Luca> /bin/sh is not universally compatible with non-Linux OSes.

I claim it is more compatible.


Luca> Also I thought that policy should not be used to beat other
Luca> developers (it is because of this) and it should reflect the
Luca> common practices adopted in Debian (it does not because of
Luca> this). Is that no longer the case?

I'd consider it a non-RC bug if someone were manually writing
#!/usr/bin/sh

We can debate about normal vs minor.

I do not think it should be a bug if some automated build process found
/usr/bin/sh and stuck that into a script.
I'd support a policy change to make that clear.

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> Debian only supports merged-usr since Bookworm. We should
Luca> update policy to reference /usr/bin/sh and similar paths to
Luca> describe recommended shebangs for scripts.

I do not support this change.  /bin/sh should still be the recommended
interface path for the posix shell.  Among other reasons, it promotes
compatibility between Linux and other posix architectures.  Besides
that, I suspect there are cases where tools look for /bin/sh in a #!
line and do not accept /usr/bin/sh.

I absolutely agree that the physical path of the posix shell should be
/usr/bin/sh.
I disagree that we should be changing interface paths for items
traditionally found in /bin.


signature.asc
Description: PGP signature

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Sam Hartman]

TL;DR: I think I understand one of Ian's points.  I explain, but do not
believe it is compelling as an argument to switch direction.

> "Helmut" == Helmut Grohne  writes:
>> I think "package management" is the wrong term here.  It's not
>> just our tools and packages that are affected.  All forms of
>> operating system management are affected: anything that changes
>> the software, and not just its configuration.
>> 
>> Affected tooling includes not just our .debs, but also remote
>> configuration management systems like Ansible, image construction
>> (Dockerfiles), and 3rd-party software installation progrmas
>> (including both 3rd-party .debs and 3rd-party script-based
>> installation systems).

Helmut> I don't follow the reasoning. Much of the tasks you'd carry
Helmut> out with (wlog) ansible - even when updating files - will
Helmut> continue to work in the aliasing layout. The reason that
Helmut> dpkg is more affected is that it has an inventory of files
Helmut> and reasons about their ownership in terms of
Helmut> packages. That's not how any kind of configuration
Helmut> management operates.  If you just "make install" something,
Helmut> chances are that it'll just work with an aliasing layout
Helmut> even when installing with --prefix=/. I continue to argue
Helmut> that the problems we are seeing are quite specific to dpkg
Helmut> in large parts.

I spent some time with Ian's paragraph you quote above trying to
understand it, and I think I got somewhere.
I considered replying yesterday but decided against, because I think we
are already seeing these effects, and have been seeing them long enough
that  we would  have a good feel for how serious the problems are.

I do think that configuration management does have enough of an
inventory of files and reasoning about structure that some of these
problems could arise.  I agree that configuration management does not
typically reason in terms of packages.

But mechanisms like

* ADD/COPY in Containerfile

* The rsync module in ansible
* The file module in Ansible

* various inventories related to modification detection in
configuration management do  reason about the filesystem.

I don't know what would happen if I did

hosts: lots
remote_user: root
name: Does this shoot me in the foot
tasks:
  - rsync: src=install_root dest=/

where install_root has a bin directory containing a couple of scripts.
I don't know if rsync will replace a symlink with a directory, or will
just write through the symlink in that situation.
If rsync happens to write through the symlink, there's probably some
other tool somewhere else thatreplaces the symlink.
And when an admin does that, they get an unbootable system, and fix
their playbook/whatever.

Similarly, I bet someone somewhere has integrity management scripts that
want to look at what pam modules are installed under /lib/security, and
depending on how it worked,
they had to adjust the config when that moved to
/lib/security/x86_64-linux-gnu and then again some of them had to adjust
when /lib became a symlink.  And they were probably frustrated during
the time when new installs had /lib as a symlink and upgrades did not.

Similarly, I bet you can run into trouble with apparmor profiles if you
try to profile /bin/python rather than /usr/bin/python or similar.

I bet people who had custom selinux policies had to adjust their
labeling rules and again some of them probably found the mixed state
where upgraded systems behaved differently than installed systems
frustrating.


I seem to recall having to make some minor adjustments at my day job
related to usrmerge back in the buster/bullseye time frame.
I don't remember what they were.

I think we've already committed to this pain, and I think we have enough
of a window into that commitment that it doesn't seem to be very much
pain.
I mean spread across all our users, yes people have had to spend
hundreds or thousands of hours dealing with this.
But that's true with any upgrade.

If we move back--if we unwind--things would get much much worse  WRT
this type of pain for a while.
I think many more things would be sensitive to /bin/perl being a symlink
than to /bin being a symlink.
You could get into situations where /usr/bin/perl and /bin/perl were
both files and differed.
You could get into situations where /bin/perl vanished on one system.
Etc.

And if we actually try to have a symlink flower patch rather than a
symlink farm, we are left with the pain of where things live differing
between distributions and releases in a distribution.

Mostly all we have left is the dpkg database.
That pain will only affect people producing debs, which isn't just us.
And yes, it will dis proportionally affect people who don't have our
infrastructure and the ability to catch problems.  Perhaps we should
think about ways to mitigate that.

There will be other smaller pains; if someone else had a system 

Bug#1050001: Unwinding directory aliasing

[Sam Hartman]

> "Ansgar" == Ansgar   writes:
Ansgar> And the more important question: how often do we want to
Ansgar> rehash the usrmerge discussion?  At some point we should
Ansgar> stick with a decision and not endlessly restart discussions
Ansgar> (unless something really significant changes, but I don't
Ansgar> think this is the case).  *mumble* leadership something
Ansgar> *mumble*

For myself, I think the issues raised in DEP17 are significant enough
that I would at least read a proposal to explain a different way to get
to a merged /usr system.
I.E. yes, I believe that something has changed significantly enough that
I would be willing to read proposals for alternate ways to get to the
end goal we've agreed to.

However:

1) Jackson is not making such a proposal.  As it turns out, he has
proposed a different end goal, and has not (in my mind) met the
extraordinary burden of explaining why we should change goals.  He did
not even address our current goal and the divergence from that goal.

2) While I would be willing to read such proposals, I am not interested
in pausing current efforts unless something really unexpected comes up
in such a proposal.


Part of building a community is listening to people and engaging with
them even when you do not expect to be convinced.  I do think there are
limits to that.  Prior to the discussions that led to DEP-17, I think a
message like Jackson's would have been out of bounds.  I am disappointed
that Jackson did not more clearly articulate that his end state was
different than the one we agreed to: for me, that complicates things.
If you argue that his message should be out of bounds because he wasn't
even trying to get us to the place we had agreed we wanted to reach, I
will not object.

But I think coming forward and asking what level of proof would be
required for an alternate approach that involved unwinding current
progress but ultimately got us to merged /usr would be something in good
faith at this point.
Other than having an entirely different goal in mind, that is what
Jackson did.


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Steve" == Steve Langasek  writes:
Steve> I've therefore prepared and uploaded the attached patch to
Steve> mantic, which implements your option 1.  I note you only
Steve> mentioned adding Breaks: against older libk5crypto3; a scan
Steve> of the binary packages showed many other reverse-dependencies
Steve> of libkrb5support0 using strlcpy and strlcat, so rather than
Steve> trusting that a Breaks: of libk5crypto3 would be enough to
Steve> force the upgrade together, I added explicit Breaks: against
Steve> all of these other packages.


I've applied your patch, adjusting the version number for the breaks for
Debian.
Including the strict binary dependency in symbols was clever, I would
not have thought of that.

I do think that breaking libk5crypto3 would have gotten many of the
other libraries transitively (as an example krb5-user depends strictly
on libkrb5-3, and libkrb5-3 has depended on  the exact version of
libkrb5support0 for a while.
But your patch is more conservative, and that is best in this instance.

Thanks very much for your contribution.

Bug#982309: Session-Interactive-Only: no is equivalent to Session-Interactive-Only: yes

[Sam Hartman]

> "Lucas" == Lucas Nussbaum  writes:

Lucas> When using config snippets in /usr/share/pam-configs/, it
Lucas> seems that 'Session-Interactive-Only: no' is equivalent to
Lucas> 'Session-Interactive-Only: yes'.

I'm not going to fix in this upload, because I don't have time to test a
fix thoroughly now, but I wanted to write myself a note.  I used
codesearch.debian.net to confirm that the only value we have for
Session-Interactive-Only is 'yes'.
I.E. a simple string compare will not break anything in the archive.
This is consistent with how we treat default in pam-auth-update.

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

[Sam Hartman]

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


Marc> Quack,

Marc> Thanks for adding the feature in #1004000 but it unfortunately
Marc> does not work.

Um, yeah,:-(
I finally got a chance to look into this.

I think the following patch fixes my logic error.
I've also added autopkgtests that detect all the ways in which the
current version fails.

diff --git a/debian/local/pam-auth-update b/debian/local/pam-auth-update
index b3de86e7..ac00b1c9 100644
--- a/debian/local/pam-auth-update
+++ b/debian/local/pam-auth-update
@@ -162,7 +162,9 @@ push(@enabled,
 # Disable anything explicitly disabled
 @enabled = grep {!$to_disable{$_} } @enabled;
 # And we've seen anything we disable
-delete @seen{ keys %to_disable};
+foreach my $i (keys %to_disable) {
+$seen{$i} = 1;
+}
 
 # an empty module set is an error, so in that case grab all the defaults
 if (!@enabled) {

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, >principal)) {
+   return (FALSE);
+@@ -443,6 +444,9 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+   if (!xdr_krb5_int16(xdrs, >n_key_data)) {
+   return (FALSE);
+   }
++  if (xdrs->x_op == XDR_DECODE && objp->n_key_data < 0) {
++  return (FALSE);
++  }
+   if (!xdr_krb5_int16(xdrs, >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 *) >key_data,
+- , ~0, sizeof(krb5_key_data),
+- xdr_krb5_key_data_nocontents)) {
++  r = xdr_array(xdrs, (caddr_t *) >key_data, , 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#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, >principal)) {
+   return (FALSE);
+@@ -443,6 +444,9 @@ _xdr_kadm5_principal_ent_rec(XDR *xdrs, 
kadm5_principal_ent_rec *objp,
+   if (!xdr_krb5_int16(xdrs, >n_key_data)) {
+   return (FALSE);
+   }
++  if (xdrs->x_op == XDR_DECODE && objp->n_key_data < 0) {
++  return (FALSE);
++  }
+   if (!xdr_krb5_int16(xdrs, >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 *) >key_data,
+- , ~0, sizeof(krb5_key_data),
+- xdr_krb5_key_data_nocontents)) {
++  r = xdr_array(xdrs, (caddr_t *) >key_data, , objp->n_key_data,
++sizeof(krb5_key_data), xdr_krb5_key_data_nocontents);
++  objp->n_key_data = n;
++  if (!r) {
+   return (FALSE);
+   }
+ 

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#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> 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#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#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#1036234: unblock: krb5/1.20.1-2

[Sam Hartman]

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

Please unblock package krb5


[ Reason ]

My fix for 1020424 was incomplete.
Even with that fix applied, you can end up installing the new crypto library 
with the old libkrb5support.
Unfortunately because of some internal changes  that can cause segfaults.
I've changed the .symbols file, and now libk5crypto depends on the new 
libkrb5support.
As a consequence the entire krb5 library upgrade from bullseye to bookworm 
needs to be done lockstep.
I try to avoid that, but apt appears to deal with it fine.


[ Impact ]
If the user mixes krb5 library versions from bullseye and bookworm they can get 
segfaults until they upgrade fully.



[ Tests ]
I've confirmed that libk5crypto3 now has tight dependencies manually.


[ Risks ]

Very minimal diff.

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

[ Other info ]
diff --git a/debian/changelog b/debian/changelog
index cc56e29b95..39cc059e25 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+krb5 (1.20.1-2) unstable; urgency=medium
+
+  * Tighten dependencies on libkrb5support0.  This means that the entire
+upgrade from bullseye to bookworm needs to be lockstep, but it appears
+that's what is required, Closes: #1036055
+  
+
+ -- Sam Hartman   Mon, 15 May 2023 17:44:41 -0600
+
 krb5 (1.20.1-1) unstable; urgency=high
 
   [ Bastian Germann ]
diff --git a/debian/libkrb5support0.symbols b/debian/libkrb5support0.symbols
index 827d80898a..5c3de884f5 100644
--- a/debian/libkrb5support0.symbols
+++ b/debian/libkrb5support0.symbols
@@ -65,8 +65,8 @@ libkrb5support.so.0 libkrb5support0 #MINVER#
  k5_set_error_info_callout_fn@krb5support_0_MIT 1.12~alpha1+dfsg
  k5_siphash24@krb5support_0_MIT 1.18.2
  k5_strerror_r@krb5support_0_MIT 1.13~alpha1+dfsg
- k5_utf16le_to_utf8@krb5support_0_MIT 1.16
- k5_utf8_to_utf16le@krb5support_0_MIT 1.16
+ k5_utf16le_to_utf8@krb5support_0_MIT 1.20
+ k5_utf8_to_utf16le@krb5support_0_MIT 1.20
  k5_vset_error@krb5support_0_MIT 1.12~alpha1+dfsg
  krb5int_close_plugin@krb5support_0_MIT 1.7dfsg~beta2
  krb5int_close_plugin_dirs@krb5support_0_MIT 1.7dfsg~beta2


unblock krb5/1.20.1-2

Bug#1035904: What does merged /usr bring us

[Sam Hartman]

>>>>> "Sam" == Sam Hartman  writes:

Sam> Hi.  Off list, I wanted to try to explain what I think merged

My apology for sending a mail intended to be private to the bug.  It was
not my intent to clutter an already cluttered discussion.  I was really
just trying to help provide what understanding I had to a friend.

--Sam

Bug#1035904: What does merged /usr bring us

[Sam Hartman]

Hi.
Off list, I wanted to try to explain what I think merged /usr has
brought us that is positive.
I want to stress that I'm not a huge fan of merged /usr, and I know
you've encouraged me not to argue from a devil's advocate position in
the past.
All the things I cite here are things I actually think are a positive
value, but I fully agree they do not justify the change to me.

* Normalization of paths.  Whether things ended up in /usr/bin or /bin
  tended to vary between unixes and especially between linux distros.
That has produced a lot of complexity over the years in build systems.
  But it's also produced a lot of non-portable software--stuff written
  either for Redhat or Ubuntu that manages to get the path wrong for the
  other, and doesn't have the complexity of something like autoconf to
  detect the change.
  It's kind of nice to ignore all that.

* There's work, from people related to the systemd crowd, to effectively
  get to a place where the initial state of a system is very close to
  empty with a few symlinks and a read-only /usr.  And then possibly
  things get filled in a bit on first boot if necessary.  So, for
  example the systemd style split of /usr/lib/systemd/system vs
  /etc/systemd/system where the /etc path generally gets to be empty at
  least initially is part of this.
  In some ways it reminds me of how AIX dealt with diskless
  workstations.  (I realize that's based on how Sun did it, but I never
  dove into SunOS or Solaris as deep as AIX).
  The goal is more for containers or for deploying updates to EOT
  devices than for diskless.
  The ideais kind of cool.
  The updater/installer/container  creater knows very little and can
  start with an initial state.
  It's easy to figure out what has been customized because anything in
  /etc is a customization.
doing a factory reset is fairly easy.
It works well with signed OS images and ostree for deploying updates/the
  sort of thing Endless does.
  And yet there are probably other ways to get all the same benefits.

--Sam

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Sam Hartman]

> "Matthew" == Matthew Vernon  writes:

Matthew> On 15/05/2023 16:54, Bdale Garbee wrote:
>> I could.
>> 
>> Can you provide an example of actual value delivered to Debian
>> from merged-/usr?

Matthew> With respect, I don't think this line of argument is going
Matthew> to get us very far - this bug isn't about whether we should
Matthew> undo usr-merge, so I don't think a debate on the merits or
Matthew> otherwise of usr-merge is germane.

I actually think the whole ABI issue is basically irrelevant for this
bug.
I think that in this bug at least we are hoping to discuss the
appropriateness of the dpkg warning for sources downstreams grab from
the Debian archivje.
That issue seems quite sufficient for one bug:-)

Bug#1036055: Acknowledgement (libk5crypto3: depend on latest libkrb5support0 to avoid crashing at load time)

[Sam Hartman]

control: severity -1 important

> "Otto" == Otto Kekäläinen  writes:

Otto> Seems the package already has correct depends in
Otto> 
https://salsa.debian.org/debian/krb5/-/blob/master/debian/control#L354-358:

The 1.16 is coming from  is libkrb5support0.symbols.

libkrb5-3 already depends on libkrb5support0 at binary:Version.  My
recollection is that we've run into trouble if we add that to
libkrb5support0, effectively making everything upgrade in lockstep.
Sometimes (like now) it's necessary.  But a lot of times it makes the
upgrade more complicated than necessary and introduces other problems.

So, the new libkrb5support is properly marked as breaking the old
libk5crypto and old libkrb5-3.  That probably doesn't matter so much
because libkrb5-3 depends on the new libk5crypto, and depends on
libkrb5support at binary:version.  So my previous change here didn't
help as much as I thought it did.  You can still install the new
libk5crypto3 with the old libkrb5support0 even though that doesn't work.


I will put something together for bookworm in the next day or so and
hopefully get it in, but if not get it in for the first point release.

--Sam


signature.asc
Description: PGP signature

Bug#1035908: Bullseye regression: NFS4 referals appear not to work

[Sam Hartman]

package: nfs-utils
severity: important
justification: regression from bullseye with silent failure
version: 1:2.6.2-4

Hi.
I've noticed that since upgrading to  bookworm the refer option in
/etc/exports appears to be entirely ignored.

Looking through the sources to exportd and support/export/cache.c, it
looks like perhaps referals support in exports is keyed on
--enable-junctions.  I'm not entirely sure of that, but
it looks like write_fsloc is only called in dump_to_cache  if
HAVE_JUNCTION_SUPPORT is enabled.

I *think* write_fsloc is what writes out the referal location as well as
any junction location.
So, I *think* that as part of adding the junction support upstream has
broken referals unless you enable junction support.

That's kind of unfortunate for us because junction support comes with
dependencies like libxml2 which are kind of a lot to swallow in
nfs-utils.

I'd appreciate help confirming my conclusions.

* Are referals actually broken

* Is there an easy way to get them back without junction support

* how willing to turn on junction support are we in bookworm?  In a
  bookworm backport?
  


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> It has come to my attention that there is one package in
Luca> Debian using dpkg-divert to mask a systemd configuration file
Luca> (an udev rule).  Speaking as one of the maintainers, both
Luca> upstream and downstream, I find this greatly undesirable for
Luca> several reasons that I will outline later. Hence I would like
Luca> to propose explicitly mentioning that dpkg- divert must not be
Luca> used for systemd configuration files (units, rules, etc), and
Luca> instead the supported workflow (drop-ins, masking, etc) must
Luca> be used, both by packages and administrators.

First, I thought there was already a prohibition about one package
mucking with another package's configuration.
In many cases it sounds like it's already against policy for one package
to change the default systemd or udev configuration--at least for
packages in the archive.
(I am skepticle that amazon-ec2-utils complies with policy in general).


In cases where the change being made is permitted by policy, I think you
have made a compelling case to vastly prefer the native systemd and udev
mechanisms to dpkg-divert.
I don't think that your case is strong enough to forbid dpkg-divert.

As far as I can tell reading your reasoning, dpkg-divert *works fine*.
It just gives surprising results to someone coming from the systemd
universe.

But consider a package that diverts several resources, several of them
systemd and several of them not systemd.
The maintainer might legitimately want to use the same mechanism for all
the overriding/masking  so that systemd resources and non-systemd
resources were handled the same.

There's a real trade off there, and we generally leave those to
maintainers.

So, I'd support policy advice (ENCOURAGED) rather than policy
requirements (MUST) in this case.

I do think that if a maintainer violates this advice without a good
reason, important is a more appropriate bug severity than wishlist, but
unfortunately we don't have a good way to specify that in policy
language.

I would not support policy recommendation language (RECOMMENDED/SHOULD)
because that has a connotation that failing to follow the recommendation
is always a bug, and I don't think that's true here.

--Sam

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

[Sam Hartman]

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

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

Bug#1035489: krb5-config: missing dependency to C compiler

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> krb5-config on a system without a compiler.  In general, all
Russ> *-dev packages in Debian are only useful with a compiler,
Russ> since their whole purpose is to provide support for linking
Russ> new binaries with libraries.  We generally don't make that
Russ> dependency explicit, though, since it adds a lot of edges to
Russ> the dependency graph and it's not clear they serve much
Russ> purpose.

Ah, thanks for saving me the trouble to ask what common practice is
here.

We could represent this as a dependency or a recommends if there is some
special reason that libkrb5-dev needs the dependency.
krb5-config not working alone is not enough to justify a depends
relationship: as I understand it (Russ please correct me if I'm getting
this wrong from memory), the policy requirement is not that every
program in a package work with the installed dependencies, but that the
package as a whole work.  I.E.  I could say that we care far more about
the pkgconfig .pc files, krb5-config is legacy, and so policy does not
force us to depend on a compiler even though krb5-config is kind of
useless without it.

But if there's some special reason that we need a compiler dependency
(or recommendation) I think we have options.
There does appear to be a c-compiler virtual package.
We could depend on gcc|c-compiler.

It looks like over the years, a few things have provided c-compiler that
probably shouldn't (for example bcc, a 16-bit x86 only c-compiler).  But
the list appears reasonably clean now.
I did try krb5-config with pcc as /usr/bin/cc, and it did work.

But like Russ, I'd want to see a special reason why libkrb5-dev needs a
dependency.


signature.asc
Description: PGP signature

Bug#1035387: csound: Regression from Bullseye: K opcodes not initialized at init time

[Sam Hartman]

Package: csound
Version: 1:6.18.1+dfsg-1
Tags: fixed-upstream, upstream

See https://github.com/csound/csound/issues/1707

I'd like to NMU a fix once things settle down on the upstream side and
I'd like to file an unblock request (or a stable update request if
this misses the bookworm release).

I'm not a member of the multimedia team, but I am familiar with the csound 
packaging.
Are you okay with me doing an NMU and  submitting a merge request on salsa once 
we settle on a fix on the upstream github issue?

You can declare an opcode something like

opcode inittest,K,0

According o the docs, the output parameter is copied both at k-time
and at i-time.  It turns out in csound 6.14 (bullseye) it's always
copied at i-time even if declared as 'k' not 'K'.  But that in 6.18
it's only copied as k-time.  If you are using the opcode as a state
machine, triggering reinits, etc, that can totally break your
orchestra.

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

[Sam Hartman]

control: severity -1 normal

> "Cyril" == Cyril Brulebois  writes:


Cyril> serious & wontfix make for a strange combination…

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

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

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

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

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

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

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

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

--Sam

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

[Sam Hartman]

> "Karl" == Karl O Pinc  writes:

Karl> On Mon, 20 Mar 2023 09:27:39 -0300
Karl> Andreas Hasenack  wrote:

>> The extra randomness suffix happens when you login via
>> ssh/gssapi.

Karl> That is exactly how I'm logging in, authenticating credentials
Karl> with MS Active Directory, with configuration set in
Karl> /etc/sssd/sssd.conf and /etc/krb5.conf -- after joining with
Karl> the "realm" command.

pam_sssd always adds randomness to the cache name.
So, this is not an issue with krb5; pam_sssd is explicitly setting
KRB5CCNAME environment variable.

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

> "Jeremy" == Jeremy Bícha  writes:

Jeremy> Open the GNOME Tweaks app.  Scroll down the left sidebar to
Jeremy> the panel named Windows.  In the main panel, scroll down to
Jeremy> the Window Focus section.  Click to Focus should be
Jeremy> selected.

Jeremy> I haven't spent much time trying to navigate the GNOME
Jeremy> Tweaks app with the keyboard and screen reader. It may not
Jeremy> be a great experience.

It's not great, but it's not horrible until you get to the end.
I can find the focus control, but I cannot figure out the current value.
I hit tab to where it should be and it simply announces "label."
I can however expand the options and use the orca review keys to select
click to focus with the orca mouse click.
I *assume* that probably makes things click to focus,
And I'm assuming that  the command Simon gave me should work.
But as I indicated in my signed response, even on a fresh install (which
presumably has the default focus), I can reproduce.

--Sam

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> On the upstream issue, a bug reporter mentions that to
Simon> reproduce the bug, you need two things: the focus mode needs
Simon> to be set to "sloppy focus", and there needs to be at least
Simon> one window open on the current workspace.

I'd like to push back on the idea that sloppy focus is required.

I tried the following:

* Install task-gnome-desktop on top of  effectively debian:bookworm out
  of docker (roughly debootstrap --varient=minbase)

* adduser --uid 8042 hartmans

* systemctl restart gdm

* At the console alt-super-s to enable orca and then log in

* alt-f2 run gnome-terminal

* Confirm I'm in the terminal

* ctrl-alt-tab to get to the top bar [fails to stay there]

I then confirmed that if I hit super  to get to overview panel and then
ctrl-alt-tab to the top it works.

I also confirmed your work around of going to an empty workspace; that
does work.
But I cannot verify the claim that sloppy focus is required.
I also tried resetting the focus preference you indicated and that did
not help.

--Sam


signature.asc
Description: PGP signature

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

> "Simon" == Simon McVittie  writes:
Simon> If click-to-focus is suitable for your workflow, the focus
Simon> mode can be reset to the default with this command:

Simon> gsettings reset org.gnome.desktop.wm.preferences focus-mode

I tried running that and can still reproduce the issue.
Do I need to do anything to make that take effect?  Where can I find the
focus mode in the GUI to confirm it is set correctly?

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

Package: gnome-shell
Version: 43.1-2
Severity: normal
Tags: a11y

I've also reproduced against 43.3-1, but it's harder to send email from that 
system.

I'm blind, running gnome on X using orca as a screen reader.
In bullseye I could hit ctrl-alt-tab to switch up to the top bar, and then use 
shift-tab to get to the system menu and do things like turn on/off networking.

On bookworm, that doesn't work.  ctrl-alt-tab does announce "top bar", but when 
I release it, I'm dropped back into whatever application I was in.
For example, I had Firefox focused, and hit ctrl-alt-tab.
I hear
" top bar"
"activities toggle button not pressed"
"Element [1] #debian-devel Mozilla firefox"
I.E. I was briefly on the top bar, but then found myself back in Firefox.

In Bullseye I would have stayed on the top bar.

I can get to the top bar, but it's involved.
I hit the windows key, to get to what is spoken as the "overview" screen.
I then hit ctrl-alt-tab until I get to the top bar, and it sticks.
That's a lot more keystrokes, and ends up being a fair bit slower.


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

Kernel: Linux 6.0.0-2-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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-1+b1
ii  gir1.2-adw-1 1.2.0-1
ii  gir1.2-atk-1.0   2.46.0-4
ii  gir1.2-atspi-2.0 2.46.0-4
ii  gir1.2-freedesktop   1.74.0-2
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1
ii  gir1.2-gdm-1.0   43.0-1
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-2
ii  gir1.2-gnomebluetooth-3.042.5-1
ii  gir1.2-gnomedesktop-3.0  43-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.5-1
ii  gir1.2-gtk-3.0   3.24.36-1
ii  gir1.2-gtk-4.0   4.8.2+ds-4
ii  gir1.2-gweather-4.0  4.2.0-1
ii  gir1.2-ibus-1.0  1.5.27-4
ii  gir1.2-mutter-11 43.2-4
ii  gir1.2-nm-1.01.40.8-1
ii  gir1.2-nma-1.0   1.10.4-2
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-1
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-1
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.38.3-1
ii  gnome-backgrounds43-1
ii  gnome-settings-daemon43.0-3
ii  gnome-shell-common   43.1-2
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.63-4
ii  libatk-bridge2.0-0   2.46.0-4
ii  libatk1.0-0  2.46.0-4
ii  libc62.36-7
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.2-1
ii  libedataserver-1.2-273.46.2-1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libgirepository-1.0-11.74.0-2
ii  libgjs0g 1.74.1-1
ii  libgles2 1.5.0-1
ii  libglib2.0-0 2.74.4-1
ii  libglib2.0-bin   2.74.4-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.36-1
ii  libgtk-4-1   4.8.2+ds-4
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.2-4
ii  libnm0   1.40.8-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpolkit-agent-1-0  

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

> "Michael" == Michael Biebl  writes:

Michael> If a service is not supposed to be enabled, then an
Michael> override for dh_installsystemd is the correct solution,
Michael> setting --no-enable, but not by moving it into a
Michael> subpackage.

Sorry, I was imprecise.
Imagine something like a webserver.
You might well want to install the web server binary so you can run it
as a user for development testing an app or for sharing files.
But you might also want to  install it as a system service.
I think two options are viable depending on factors like whether some
dependencies want to know that it is running as a system service and
how common each configuration will be:

* Install a disabled unit by default but keep everything into one
  package

* or move the system service unit into its own package.  If you just
  want the binary you install one package, but if you want the system
  service, you install the package containing the unit.
  In this case the unit is enabled by default.

If we were to move units back from /usr/lib/systemd/system to
/lib/systemd/system, the second case would potentially trigger the dpkg
bug.  But:


Michael> I also don't see a good reason, why a unit file, once
Michael> installed in /usr/lib/systemd/system should ever move back
Michael> to /lib/systemd/system.

I agree with you here.   This requires keeping the debhelper change
rather than backing it out after the bookworm release.
I think both you and I support that.


signature.asc
Description: PGP signature

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

>> Moreover, I suspect in a number of the cases related to this
>> current bug, replaces will be likely.  I suspect that in some of
>> the cases where units have been introduced that are disabled
>> currently, but will be enabled by the dh_installsystemd change,
>> we will discover we'd like those units disabled in some
>> configurations.  A logical way to handle that may be to split out
>> the units into separate packages.  That makes the replaces
>> interacts with file moves class of bugs more likely in this
>> situation than average.

Sebastian> The TC advice refers to files moving between packages
Sebastian> which wouldn't be the case here (at least not in
Sebastian> general).

Not in general, but I think that these  systemd units will be more
likely than average to move packages.

These units have been sitting around more or less doing nothing for
months.
And in most cases we don't have bugs.

I'm imagining the  following situation:

* We make the debhelper change

* unit b in package a starts running

* Users complain that they don't really always want that.

* We release

* unit b is moved back to /lib/systemd/system

* Later the complaints get serious enough that package a splits into a
  and a-daemon, a-daemon replaces/breaks a<< version-of-split.  a-daemon
  now has b.

* Now we have a potential problem where we have both a file move and a
  replaces, and b can disappear on an upgrade from a pre-split a to
  a+a-daemon after the split.
  Whether that happens depends on dpkg's order of operations

The nasty thing about this situation is that moving b from /usr to /
can happen at very different points in the release cycle from doing the
split and adding the replaces.
You need to remember whether during the release cycle you've had any
moves that can involve aliased paths.
If you have, you must not later in the release cycle introduce replaces.

So, in general, we'll be fine.  But in specific I don't think we'll be
fine that removing the debhelper code will be a sane thing to do.


signature.asc
Description: PGP signature