Re: What is going on with atomics?

[Theodore Ts'o]

A question about --as-needed as an upstream developer who wants to
care about more than just Debian or Linux.  Am I correct in assuming
this will work on any system using GNU binutils?  And it doesn't
matter whether you are using gcc, clang, etc.  What about other OS's
such as *BSD, MacOS, etc.?

I guess I could add an autoconf test to see if the linker barfs on
--as-needed, but I'm curious how much this actually matters in
practice.

Thanks,

- Ted

Re: Is HURD's lack of HOST_NAME_MAX and PATH_MAX a good architectural approach

[Julien Plissonneau Duquène]

Hi,

Le 2025-01-20 21:21, Sam Hartman a écrit :

One of the issues is HOST_NAME_MAX in modules/pam_xauth/pam_xauth.c.


It doesn't make much sense to allow arbitrarily long host names. I'm 
more reserved for path names as there are (arguably pathological) use 
cases where any fixed limit could be reached.


I think that a satisfactory way to deal with some security issues (let's 
call them "name bombs") would be for HURD to implement limits that can 
be configured at run time, in the spirit of linux sysctls for many 
limits. That won't help much with the other issues though.


In the case of pam above, I believe that patching it in a way that sets 
an arbitrary high limit when there is none and documenting this as a 
limitation could be appropriate.


Cheers,

--
Julien Plissonneau Duquène

Re: Is HURD's lack of HOST_NAME_MAX and PATH_MAX a good architectural approach

[Samuel Thibault]

Julien Plissonneau Duquène, le mar. 21 janv. 2025 11:24:31 +0100, a ecrit:
> Le 2025-01-20 21:21, Sam Hartman a écrit :
> > One of the issues is HOST_NAME_MAX in modules/pam_xauth/pam_xauth.c.
> 
> It doesn't make much sense to allow arbitrarily long host names. I'm more
> reserved for path names as there are (arguably pathological) use cases where
> any fixed limit could be reached.
> 
> I think that a satisfactory way to deal with some security issues (let's
> call them "name bombs") would be for HURD to implement limits

It already does so. It just doesn't expose them in the API, so they can
be raised if need be.

Samuel

Re: write the fine manual (was Re: Removing manpages from libpam-modules to improve multi-arch)

[Theodore Ts'o]

On Wed, Jan 15, 2025 at 06:03:42PM -0600, G. Branden Robinson wrote:
> I've saved the worst for last.
> 
> That is of course docbook-to-man.  Ingo and I both find the quality of
> its output to be execrable.  It has been unmaintained for many years and
> consistently seems to burn out and drive from FLOSS development anyone
> who has gotten involved with it.  Its brownfield status appears to be
> widely if vaguely understood, and it is avoided--but only by its
> would-be _maintainers_--like a toxic waste dump piled 100 meters deep
> with burning tires, at the center of which a column of blue Cerenkov
> light stabs the sky like a beacon of death.
> 
> It is consequently extremely popular and has enjoyed wide adoption, and
> continues to be thought of as a viable tool even as the luster of XML
> doctypes and DocBook in particular has worn off.  Notoriously, all the
> Git man pages are produced via this means.  This is entirely in keeping
> with prototypical Linux kernel developer behavior: identify a good idea
> (like having a single master documentation format from which others are
> generated), select the shittiest implementation thereof available, and
> nail oneself to it for all eternity.  And why change?
> 
> Yo, kernel hackers got better things to do than writing docs, bro.  One
> doesn't achieve world domination by telling other people how to do it.

Interestingly, in 2016 the Linux kernel switched from using DocBook to
reStructedText[1].  So the flaws of ASCII doc were relatively well
known as far back as eight years ago by the kernel community.

[1]  https://lwn.net/Articles/692704/

The problem seems to be that Sphinx is really not great for creating
man pages, and very few people actually do roff these days.  So the
man pages in the kernel (for example, for the perf tool) and the git
project are still implemented in AsciiDoc.  That's probably because
it's good enough for the users of docbook-to-man, even if it's a
brownfield.

(For example, X11 still works better for me because Wayland still has
inconsistent support for cursor sizing across applications, sigh.
>From windowing system and desktop developers' perspective, most
probably wish X11 would die already, but users have these pesky
requirements, like not having their cursor effectively disappear when
it wanders into the wrong window if you are using a HiDPI display (at
least, if you are using KDE; I don't know if GNOME is any better at
this point, but GNOME has its own problems about listening to power
users' requirements...)

I'm sure that if someone wanted to help those consumers of DocBook to
switch to something better, by *listening* to their requirements and
then trying to meet them, and showing them how to do an automated job
of converting of their man pages from one source format to another,
most projects would be willing to switch.  But that's a huge amount of
work for any volunteer or volunteer community to take on, whether it's
the git development community or some documentation tool community.

- Ted

Re: What is going on with atomics?

[John Scott]

Hello everyone,

(TL;DR at the end)

I've mostly been lurking on Debian mailing lists for a long time, so if you 
don't know me, I'm John, a Debian Maintainer working on a couple cross 
toolchains for building the device firmware that *is* free from source, but I 
pitch in on many packages here and there and wear different hats. I still have 
a lot to learn, but I'm working my way down the stack to learn more and to 
advance free software as well as hardware that can facilitate it. I don't 
represent Debian in this capacity, but in particular I'm a member of The Austin 
Group (https://www.opengroup.org/austin/), the body that maintains the POSIX 
and Single UNIX Specification standards—although I'm mostly an observer there 
and likewise do not speak for them. I think a few other Debian contributors are 
members as well; a full list is at 
https://pubs.opengroup.org/onlinepubs/9799919799/frontmatter/participants.html

In mid-2024, The Open Group and the IEEE (and hopefully the ISO/IEC standards 
bodies soon as well) published POSIX Issue 8 and the Single UNIX Specification 
5 (SUSv5). The reason I'm sharing that is because POSIX specifies how a C 
compiler can be invoked on a conforming system so that essential functionality 
can work across different UNIX-like systems without needless change. A big part 
of the 2024 major revision, the first in about fifteen years, was incorporating 
C11/C17, the version of the ISO C standard that introduced atomics.
In this revision of POSIX, the standardized C compiler is installed under the 
name 'c17'. Neither Debian nor GCC make any claims to adhere to this part of 
the standard and there have always been minor quirky differences between GCC's 
command-line syntax parsing and how the standard says it should be done for the 
standardized compiler (formerly named 'c99'), but in practice I believe GCC and 
GNU software generally tries to adhere when it makes sense and entertains 
patches to improve compatibility with other systems and standards when they're 
wholesome.

POSIX says that systems may require specific compiler flags to access 
particular sets of functions. For example, use of the "-l m" option may be 
required for the math functions to be available when building an application. 
At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358#c16 you can see the bug 
report to GCC upstream asking for GCC to link with the atomics support library 
when necessary as required. Atomics require special care mainly from the 
compiler and its machine code underpinnings (as opposed to the ISO C standard 
library), so GCC is the main orchestrator of atomics and is best informed to 
handle this.
In my reply to that bug, I shared an insight I had which is that, in my 
personal opinion in trying to interpret the specification, a compiler 
conforming to POSIX may *not* require the usage of special compiler flags to 
get support for atomics, except if those systems pre-define the 
__STDC_NO_ATOMICS__ macro to indicate the absence of any claim by the OS to 
support atomics. In particular POSIX does not specify an "-l atomic" option, 
but it does say that the compiler, by default, will expose all of the symbols 
needed for functions and objects specified in headers like , 
except for those special exceptions like "-l m" for math and "-l rt" for 
realtime functionality. No such exception was added for atomics-related 
symbols. GNU is not afraid to deviate from specifications if doing so better 
serves users 
(https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html), but 
they ultimately do whatever is most useful, especially when they coincide.

This quirk of how to link with support for atomics mostly shows up on less 
common architectures and I figured maybe this hasn't been on GCC's radar 
because of that, and folks building software for such systems are probably more 
likely to figure out how to appease the compiler on-the-fly. Therefore, in my 
appeal on the upstream bug, I shared that addressing this issue in practice 
will have the bonus feature of helping standards conformance and 
interoperability with other systems as well (this being more of an "issue in 
principle").
I was delighted when I saw in my inbox some time later an update that a fix had 
been made upstream. It apparently caused regressions on some systems so it had 
to be promptly reverted, but this is to say that problem-solving efforts have 
been making great strides very recently. For Debian's needs, as-needed linking 
with libatomic could maybe be done without as much fuss downstream in the 
meantime, but I don't really work on Debian's core GCC packages and can't judge 
how easy this could be.

This silly technicality is not something that upstream applications should have 
to care about, or even really build systems. GCC is the right place to fix this 
and they're fortunately doing it right now. Other downstream hacks we might 
could do is have dpkg or debhelper set build flags appropriately, a

Re: What is going on with atomics?

[Colin Watson]

On Tue, Jan 21, 2025 at 10:31:29AM -0500, Theodore Ts'o wrote:
> A question about --as-needed as an upstream developer who wants to
> care about more than just Debian or Linux.  Am I correct in assuming
> this will work on any system using GNU binutils?  And it doesn't
> matter whether you are using gcc, clang, etc.  What about other OS's
> such as *BSD, MacOS, etc.?

I often consult Gnulib for lore on this kind of thing.
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/lib-ignore.m4
seems to have some useful hints, with comments for those not fluent in
m4.

This also seems to be a standalone file, so if your project is using
Autoconf but not Gnulib, then you should be able to copy it into your
project's local macro directory, add gl_IGNORE_UNUSED_LIBRARIES to
configure.ac, and add $(IGNORE_UNUSED_LIBRARIES_CFLAGS) etc. to whatever
*_LDFLAGS variable is appropriate.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Is HURD's lack of HOST_NAME_MAX and PATH_MAX a good architectural approach

[Simon Josefsson]

Janneke Nieuwenhuizen  writes:

> Sam Hartman writes:
>
>> TL;DR: Is it time for the rest of Debian to stop conforming to HURD's
>> lack of maximums for path and hostname?
>
> The GNU Coding standards say: Avoid arbitrary limits
> (.

I agree, but it is going further than that: POSIX doesn't require
PATH_MAX and I believe the semantics of PATH_MAX is not what some code
assume that the symbol has.  See below for specified semantics.

I believe use of PATH_MAX as a char[] array length specifier is usually
an indicator of a bug or a security vulenrability waiting to happen.  It
is not a idiom we should strive towards.

/Simon

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/limits.h.html

Pathname Variable Values

The values in the following list may be constants within an
implementation or may vary from one pathname to another. For example,
file systems or directories may have different characteristics.

A definition of one of the symbolic constants in the following list
shall be omitted from the  header on specific implementations
where the corresponding value is equal to or greater than the stated
minimum, but where the value can vary depending on the file to which it
is applied. The actual value supported for a specific pathname shall be
provided by the pathconf() function.

{PATH_MAX}

Maximum number of bytes the implementation stores as a pathname in a
user-supplied buffer of unspecified size, including the terminating
null character. Minimum number the implementation shall accept as
the maximum number of bytes in a pathname.

Minimum Acceptable Value: {_POSIX_PATH_MAX}

{_POSIX_PATH_MAX}
Minimum number the implementation shall accept as the maximum number of 
bytes in a pathname.
Value: 256

{_XOPEN_PATH_MAX}
[XSI] [Option Start]
Minimum number the implementation shall accept as the maximum number of 
bytes in a pathname.
Value: 1024 [Option End]


signature.asc
Description: PGP signature

Re: Is HURD's lack of HOST_NAME_MAX and PATH_MAX a good architectural approach

[Janneke Nieuwenhuizen]

Sam Hartman writes:

> TL;DR: Is it time for the rest of Debian to stop conforming to HURD's
> lack of maximums for path and hostname?

The GNU Coding standards say: Avoid arbitrary limits
(.  That
was one of the great inspirations for me for wanting to learn much more
about GNU.

Similarly, GNU LilyPond was designed--other than all other music
softwares in the day--to not have arbitrary limits.

If you are running a distribution such as GNU Guix or NixOS, you may
even have run into file name limits.

It often surprises (saddens?) me how few people in the free software
community actually read (or remembered) the GNU standards.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: sbuild wiki page - cross compiling section query

[Phil Wyett]

On Mon, 2025-01-20 at 18:23 +0100, Jochen Sprickerhof wrote:
> * Phil Wyett  [2025-01-20 17:10]:
> > * A VM with Debian trixie install - standard utilities plus ssh server.
> 
> Which arch has the VM?
> 
> > For --host=arm64 I have to generate an arm64 chroot and install crossbuild-
> > essential-arm64 for crossbuilds to work.
> 
> If you want to cross build a package, i.e. your system is not arm64 and 
> you want to compile a package that is arm64 you need a chroot from host 
> system arch and sbuild will take care of the rest, no need to manually 
> install crossbuild-essential-arm64 or anything. Did you try that?
> 
> Cheers Jochen

Hi Jochen and all,

Indeed, the crossbuild-essential-* were not necessary and have now been
removed.

I will be keeping the arm64 riscv64 chroots to enable autopkgtest to run
successfully with sbuild and I find the tests run extremely quickly.

Running native methods mentioned I will test on another laptop I shall make
full Debian testing. These things are not possible on my daily driver that due
to circumstance it runs Red Hat Enterprise Linux 9.x.

Regards

Phil

-- 

Donations...

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

--

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg

Threads: https://www.threads.net/@kathenasorg

--



signature.asc
Description: This is a digitally signed message part

Bug#1093739: ITP: golang-github-lifenjoiner-dhcpdns -- dhcpdns is a golang package to get the DHCP DNS.

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: golang-github-lifenjoiner-dhcpdns
  Version : 0.0.6-1
  Upstream Author : 
* URL : https://github.com/lifenjoiner/dhcpdns
* License : Expat
  Programming Lang: Go
  Description : dhcpdns is a golang package to get the DHCP DNS.

 dhcpdns is a golang package to get the DHCP DNS.
 .
 It helps programs to use the upstream DNS easily when your network
 changed.

New upstream dependency for dnscrypt-proxy.

Re: What is going on with atomics?

[Matthias Klose]

On 21.01.25 22:01, Colin Watson wrote:

On Tue, Jan 21, 2025 at 10:31:29AM -0500, Theodore Ts'o wrote:

A question about --as-needed as an upstream developer who wants to
care about more than just Debian or Linux.  Am I correct in assuming
this will work on any system using GNU binutils?  And it doesn't
matter whether you are using gcc, clang, etc.  What about other OS's
such as *BSD, MacOS, etc.?


--as-needed has been there forever. The --push-state/--pop-state options 
are implemented in binutils 2014 (ld), and binutils 2016 (gold).  I 
didn't look at other linkers.


Using these in libtool still seems to be a problem, as libtool has it's 
own idea about how to re-sort command line options and libraries.



I often consult Gnulib for lore on this kind of thing.
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/lib-ignore.m4
seems to have some useful hints, with comments for those not fluent in
m4.

This also seems to be a standalone file, so if your project is using
Autoconf but not Gnulib, then you should be able to copy it into your
project's local macro directory, add gl_IGNORE_UNUSED_LIBRARIES to
configure.ac, and add $(IGNORE_UNUSED_LIBRARIES_CFLAGS) etc. to whatever
*_LDFLAGS variable is appropriate.

Bug#1093737: ITP: android-cuttlefish -- Cuttlefish Android Virtual Device companion package

[PaulLiu]

Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: android-cuttlefish
  Version : 1.0.0
  Upstream Contact: https://github.com/google/android-cuttlefish
* URL : https://github.com/google/android-cuttlefish
* License : Apache-2.0
  Programming Lang: C++
  Description : Cuttlefish Android Virtual Device companion package
 Contains set of tools and binaries required to boot up and manage
 Cuttlefish Android Virtual Device that are used in all deployments.

Yours,
Paul

Re: What is going on with atomics?

[Simon Richter]

Hi,

On 1/22/25 00:31, Theodore Ts'o wrote:


I guess I could add an autoconf test to see if the linker barfs on
--as-needed, but I'm curious how much this actually matters in
practice.


From an upstream perspective, I think the best approach is

AC_CHECK_LIB([atomic],[main])

That creates a few unnecessary dependencies, but it should work pretty 
much everywhere.


If Debian maintainers feel annoyed by warnings about unnecessary 
dependencies, they are welcome to replace this with a hardcoded


LDFLAGS="${LDFLAGS} -Wl,--push-state,--as-needed,-latomic,--pop-state"

because unlike upstream, Debian can assume reasonably recent GNU tools.

Someone GNU adjacent might want to build something more sophisticated 
for the autoconf-archive -- but I'd draw the line at


0. if the library does not exist, assume it's not needed and explicitly 
say so in the build log

1. if --push-state/--pop-state are supported, wrap them around --as-needed
2. if --as-needed is supported, but no state stack, use --no-as-needed 
afterwards, and if any other macro wants to use --as-needed, they need 
to add their own

3. if neither is supported, unconditionally link

Like libm, what is actually needed at link time depends on inlining, 
which is affected by constant propagation, so it is impossible to build 
100% reliable tests.


   Simon