Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
07.02.2024 11:06, Helmut Grohne :
..
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
Attached is a sketch to make pam compatible.
I had a more complete and *tested* fix 2 days ago but I forgot
it was in /tmp and I rebooted the machine, so had to do it again
yesterday.
The idea is to have both die_time and die_time64, and keep them
in sync (using minimum between two values which is !=0).
This is a sketch using a #define, though better is to use symbol
versioning here and have time32 compat stuff for old programs
and 64bit time stuff for new, using redirection at the link time,
instead of the #defines which makes whole thing rather difficult
to read, - that's extra several lines of code, also to the .map
file.
What the whole thing needs is the criteria to use to enable the
trick. Right now I used #ifdef NEED_TIME64_COMPAT which should
be defined somehow, - since I don't know the precise list of
architectures where this has to be done. This is an externally-
controlled thing, there's no way to determine this directly from
the .c code (short of using architecture list in the .h file),
so it must be some symbol substituted at the package build time,
like Provides: t64:Compat (or whatever it is) is substituted in
d/control.
This is a less-intrusve-to-original-code version of the sketch,
ie, I tried to keep all changes outside of the original code as
possible, keeping all the original logic as it is.
/mjtdiff --git a/libpam_misc/include/security/pam_misc.h b/libpam_misc/include/security/pam_misc.h
index fca2422..922341c 100644
--- a/libpam_misc/include/security/pam_misc.h
+++ b/libpam_misc/include/security/pam_misc.h
@@ -21,6 +21,15 @@ extern int misc_conv(int num_msg, const struct pam_message **msgm,
#include
+#if NEED_TIME64_COMPAT
+
+extern time32_t pam_misc_conv_warn_time;
+extern time32_t pam_misc_conv_die_time;
+#define pam_misc_conv_warn_time pam_misc_conv_warn_time64
+#define pam_misc_conv_die_time pam_misc_conv_die_time64
+
+#endif
+
extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
extern time_t pam_misc_conv_die_time; /* cut-off time for input */
extern const char *pam_misc_conv_warn_line; /* warning notice */
diff --git a/libpam_misc/misc_conv.c b/libpam_misc/misc_conv.c
index 908ee89..a02d491 100644
--- a/libpam_misc/misc_conv.c
+++ b/libpam_misc/misc_conv.c
@@ -30,6 +30,9 @@
time_t pam_misc_conv_warn_time = 0; /* time when we warn */
time_t pam_misc_conv_die_time = 0; /* time when we timeout */
+static void fixup_compat_time();
+static void reset_warn_time();
+
const char *pam_misc_conv_warn_line = N_("...Time is running out...\n");
const char *pam_misc_conv_die_line = N_("...Sorry, your time is up!\n");
@@ -96,6 +99,8 @@ static int get_delay(void)
expired = 0;/* reset flag */
(void) time(&now);
+fixup_compat_time();
+
/* has the quit time past? */
if (pam_misc_conv_die_time && now >= pam_misc_conv_die_time) {
fprintf(stderr,"%s",pam_misc_conv_die_line);
@@ -107,7 +112,7 @@ static int get_delay(void)
/* has the warning time past? */
if (pam_misc_conv_warn_time && now >= pam_misc_conv_warn_time) {
fprintf(stderr, "%s", pam_misc_conv_warn_line);
- pam_misc_conv_warn_time = 0;/* reset warn_time */
+ reset_warn_time();
/* indicate remaining delay - if any */
@@ -399,3 +404,36 @@ failed_conversation:
return PAM_CONV_ERR;
}
+
+#ifdef NEED_TIME64_COMPAT
+
+#undef pam_misc_conv_warn_time
+#undef pam_misc_conv_die_time
+
+int pam_misc_conv_warn_time, pam_misc_conv_die_time;
+
+/* in compat 32/64 case, we have 2 values: time and time64.
+ We perform all operations with time64
+ But we try to keep them in sync, whiciever is smaller but !0 */
+#define fixup(t, t32) \
+if (t32 && (!t || t > t32)) t = t32; /* if t32 fires sooner */ \
+if (t < 0x7fff) t32 = t /* only if t can fit in t32 */
+
+static void fixup_compat_time() {
+fixup(pam_misc_conv_warn_time64, pam_misc_conv_warn_time);
+fixup(pam_misc_conv_die_time64, pam_misc_conv_die_time);
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+ pam_misc_conv_warn_time64 = 0;
+}
+
+#else
+
+static void fixup_compat_time() {
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+}
+
+#endif
Re: Transparency into private keys of Debian
On 2/1/24 10:38, Simon Josefsson wrote: Hi I'm exploring how to defend against an attacker who can create valid signatures for cryptographic private keys (e.g., PGP) that users need to trust when using an operating system such as Debian. A signature like that can be used in a targetted attacks against one victim. For example, apt does not have any protection against this threat scenario, and often unprotected ftp:// or http:// transports are used, which are easy to man-in-the-middle. Even with https:// there is a large number of mirror sites out there that can replace content you get. There is a risk that use of a compromised trusted apt PGP key will not be noticed. Attackers are also in a good position to deny themselves out of their actions if they are careful. hello, thanks for raising this. I've spent some time exploring this in 2022 and figured, though I don't have the resources to do anything meaningful about this, I can still help by making reasoning about this attack easier by implementing it. I authored a malicious update server for multiple package managers including apt (the contrib/ folder has a few examples, some of them being incomplete or defunct tho, please do not make assumptions unless you tested them, many of them have a `check:` section for automatic integration testing): https://github.com/kpcyrd/sh4d0wup The name is derived from "shadow updates" that carry a valid signature (through private key abuse) but are fed directly to an update client and therefore never show up in Debian. It has some features to illustrate how I would assume targeted attacks to work (switch the Release/InRelease files based on source IP address and/or user-agent, leading them to a different /by-hash/ url that nobody else knows about). From what I've learned the most interesting keys are (for each respective release): - Debian Archive Automatic Signing Key - Debian Security Archive Automatic Signing Key - Debian Stable Release Key The DM/DD keys probably also have some value, but would leave a permanent record in Debian which might get noticed at some (distant or not so distant) point in the future, however when abusing release signing keys you are almost guaranteed to get away with it. --- Having built all of this (and also hence having proven writing the software for this is well within reach of a single, semi-determined rando), I then spent some time in 2023 trying to think up a system that is as annoying as possible for sh4d0wup users and developed apt-swarm. It's my first attempt of an autonomous p2p network and it uses the configured public-keys for a "proof of authority", gossip-sync protocol to attempt an eventually-consistent view of all Release/InRelease files. However: - I need an embedded database with specific properties for the sync protocol (allowing fast, ordered lookups by key-prefix), I picked the `sled` library as suggested by a debian-rust friend at FOSDEM 2023, but I later learned sled needs to be able to fit the entire database into RAM, so running a node currently requires ~8GB RAM (and *will* require more in the future). - Because of this, the entire p2p network is currently running from a single server (that is provided to me by a friend from a local hackerspace). You can join your own nodes at any time but so far nobody has done so. - Despite it's name, it doesn't know about apt and only stores opaque signed documents, the Release/InRelease files. It does not store any copies of any referenced package indexes (or packages), which limits the amount of data you get to triage incidents with. The last part is important because availability of this kind of data is going to set the scene in case you ever need to actually investigate something. I found that rekor from the sigstore project is a great public resource, but will only tell you "there's a signature you don't have any records of", but nowhere to go from there. It doesn't complement the snapshot service and it's impossible to tell apart if somebody generated themselves the inclusion-proof for a malicious update or if snapshot.debian.org simply missed/lost a snapshot. With apt-swarm you can look at the alleged `Date:` field of the release file but you will (likely) still be missing the package index that was fed into user's apt clients (and the code they executed) unless you recognize the referenced hashes. Development of this project has stalled due to the mentioned RAM usage issue, little interest for this kind of tech (even inside the security community) and cyberpunk 2077 being a really good game. Throughout the year apt-swarm has collected (among others): - 20,459 signatures from `Debian Archive Automatic Signing Key (10/buster)` - 18,085 signatures from `Debian Archive Automatic Signing Key (9/stretch)` - 10,463 signatures from `Debian Archive Automatic Signing Key (11/bullseye)` - 6,843 signatures from `Debian Security Archive Automatic Signing Key
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
> On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > bit, and it looks like it might have portability bug, at least on > big-endian architectures. For instance: > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 Thanks for having a look. I will take care. > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > nice to fix. Are you upstream or do you know upstream? Can yall fix > these? I will try to do a MR upstream > > Thanks! >
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
Hi. Thanks for your contribution. I looked at the upstream code a tiny bit, and it looks like it might have portability bug, at least on big-endian architectures. For instance: https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 This assumes that sizeof(long)==4. Maybe this is benign, but it would be nice to fix. Are you upstream or do you know upstream? Can yall fix these? Thanks!
Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Andreas,
On Wed, Feb 07, 2024 at 03:47:37PM +0100, Andreas Metzler wrote:
> Package: libselinux1t64
> Replaces: libselinux1
> Provides: libselinux1 (= 3.5-2.1~exp1)
> Breaks: libselinux1 (<< 3.5-2.1~exp1)
>
> Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
> "libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
> version gets a dep on "libselinux1t64 (>= 3.5)".
The *t64 libraries only break ABI on some architectures. Notably, on all
64bit architectures, i386 and x32, the ABI will not change. On the next
upload after the transition, library dependencies will move to the t64
variants, yes.
> Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
> for real t64-builds? (The ones in experimental are not.) If that is case
> this bug and this way of testing does not make sense.
No, the t64:Provides will remain that way for all architectures that do
not break ABI. In theory, we could have skipped the rename on those
architectures, but having architecture-dependent package names is
annoyingly hard. Hence, we rename them on e.g. amd64 as well even though
nothing changes there.
Hope this explains
Helmut
Re: O: nvi - 4.4BSD re-implementation of vi
On Tue, Feb 06, 2024 at 06:38:18PM +0100, Paride Legovini wrote: > Hi Tobias! > > On 2024-02-05 10:43, Tobias Heider wrote: > > On Sat, Jan 26, 2013 at 12:38:07AM +, Stuart Prescott wrote: > >> > >> The maintainer for the "nvi" package has indicated that he is unable to > >> maintain this package for the time being. I'm marking this package as > >> orphaned > >> now. > > > > Looks like this is still orphaned over ten years later. > > > > As an active nvi user I would love to step up and help, but the biggest > > problem I see is that the choice of upstream project. Since the original > > is gone there isn't a clear successor. > > > > The BSDs all have their own forks which diverged over time (and those don't > > build on Linux). > > The other two options there are today are https://repo.or.cz/nvi.git which > > d/control currently points to and more recently > > https://github.com/lichray/nvi2. > > > > The first has a very low commit frequency (last commit was 2020, before > > that 2016) and sticks very closely to the original source. nvi2 has added > > new features such as multibyte support and is starting to receive bug fixes > > and features from the different *BSD forks. > > > > I have been thinking of proposing a new package for nvi2 but maybe it would > > make more sense to move this one to the more active upstream. It looks like > > some of the issues we are carrying patches for in Debian might be fixed > > there > > already and if not they seem active enough to merge our fixes. > > > > What would be the best way forward here? ITA and eventually switch the > > upstream > > or start a new package and let this one continue its slow death? > > I think making the O bug and ITA and switching upstream is right thing to > do here, maybe explaining the history of the package in README.source. > > I can't think think of a reasonable use case where nvi2 would not be > a suitable drop-in replacement for nvi; if neither can you (knowing > the editor way better than me!), then I'd say go for the switch. > > I'll be happy reviewing/sponsoring if needed. Thanks! Yours and Andreas' feedback give me enough confidence that it might be worth it, so I'll start hacking and see if it's doable. I think I'll ITA and check if I can fix some smaller things first before making the big move, since that will require more time and lots of testing to make sure everything still works. I'll let you know if I have something that needs sponsoring! > > Cheers, > > Paride >
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On 2024-02-06 Helmut Grohne wrote:
> Package: libselinux1t64
[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
> first removes libselinux1 before proceeding to install libselinux1t64.
> Unfortunately, libselinux1 is transitively essential and dpkg links it,
[...]
> both dpkg and tar are now broken. This is pretty bad. To make matters
> worse, the situation arises from the combination of Breaks + Provides
[...]
Hello,
color me stupid but isn't this fishy?
Package: libselinux1t64
Replaces: libselinux1
Provides: libselinux1 (= 3.5-2.1~exp1)
Breaks: libselinux1 (<< 3.5-2.1~exp1)
Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
"libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
version gets a dep on "libselinux1t64 (>= 3.5)".
Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
for real t64-builds? (The ones in experimental are not.) If that is case
this bug and this way of testing does not make sense.
Otherwise the plan looks flawed.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bug#1063388: ITP: chuffed -- lazy clause generation CP solver
Package: wnpp Severity: wishlist Owner: Kari Pahula X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: chuffed Version : 0.13.1 * URL : https://github.com/chuffed/chuffed * License : MIT/X Programming Lang: C++ Description : lazy clause generation CP solver Chuffed is a state of the art lazy clause solver designed from the ground up with lazy clause generation in mind. Lazy clause generation is a hybrid approach to constraint solving that combines features of finite domain propagation and Boolean satisfiability. It combines some of the advantages of finite domain constraint programming (high level model and programmable search) with some of the advantages of SAT solvers (reduced search by nogood creation, and effective autonomous search using variable activities). Chuffed only supports 3 different propagator priorities. Chuffed implements a number of global propagators (alldiff, inverse, minimum, table, regular, mdd, cumulative, disjunctive, circuit, difference). It also only supports two kinds of integer variables. Small integer variables for which the domain is represented by a byte string. And large integer variables for which the domain is represented only by its upper and lower bound (no holes allowed). All boolean variables and boolean constraints are handled by the builtin SAT solver. The solver, when run with lazy clause generation disabled, is somewhat comparable in speed with older versions of Gecode. The overhead from lazy clause generation ranges from negligible to perhaps around 100%. The search reduction, however, can reach orders of magnitude on appropriate problems. Thus lazy clause generation is an extremely important and useful technology. The easiest way to use Chuffed is as a backend to the MiniZinc constraint modelling language. Chuffed can also be used as a C++ library. The description is edited from upstream's description, it went into more detail than this about the implementation. For certain types of CP problems it works better than the alternatives. Chuffed is both a library and it provides a binary (fzn-chuffed). The library can be used as a dependency for both minizinc and minizinc-ide (which I maintain) and it provides an alternative flatzinc implementation for minizinc. I plan to maintain this under the Debian Science team. As of now upstream is building chuffed as a static library only but I'll try to convince them to provide a shared library before packaging it.
Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Guillem,
On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> Yes, I'm not sure I understand either. This is what symbol versioning
> makes possible, even providing different variants for the same symbol,
> see for example glibc or libbsd.
I think symbol versioning is subtly different and glibc does not use
symbol versioning for e.g. gettimeofday selection. With symbol
versioning, you select a default version at release time and stick to
it. In other words, building against the updated libselinux does not
allow you to use the older 32bit variant of the symbol even if you opt
out of lfs and time64 and you always get the 64bit symbol. What glibc
does is a little more fancy than my simplistic #define in that it uses
asm("name") instead. Still this approach allows for selecting which
symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
me if I am misrepresenting this as my experience with symbol versioning
is fairly limited.
> In any case, if going the bi-ABI path, I think upstream should get
> involved, and the shape of this decided with them. In addition
> the library should also be built with LFS by the upstream build
> system, which it does not currently, to control its ABI.
I agree that involving upstream is a good idea and my understanding is
that someone from Canonical is doing that already, which is why the
schedule was delayed.
My real question here though is what's the downsides of providing two
variants of this symbol (whether with symbol versioning or name
redirection). From my pov, this effectively is your option 3 and what I
sketched is the most stupid implementation of it. My sketch did assume
that libselinux would be built with LFS support everywhere including
i386. Enabling that on the upstream side definitely is even better,
because it gets us to not have a Debian-specific ABI.
> I think there are only three ways to go about this, excluding the t64
> attempt:
Thanks for confirming that I've reported a real problem.
> If you'd like assistance with trying to get a proposal for 3 to
> present upstream I could look into that. But I think they should be
> involved early on to see what they'd like to see and what they might
> outright reject.
>From my naive point of view, this option 3 is the clear winner. Though
it all depends on what upstream says. If upstream cooperates on any
option, that's better still as we avoid ABI deviation.
Going from here, I also looked a bit into whether we could additionally
use an upstream-cooperating approach for other packages central to
Debian to avoid t64 bumps.
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
We cannot symbol-version these in a reasonable way. All we could do is
ask upstream for a real soname bump. We have a slight advantage here: On
little endian (such as armhf), we can extend this to 64bit and 32bit
accesses will continue to work for small values. However, doing this to
m68k would break horribly. I also couldn't find any in-Debian users of
these symbols (super merely vendors pam source), so just bumping it and
accepting breakage (Guillems option 1) might be worth a go?
For libaudit1, I fail to understand why we bump it at all. Both reports
look fine to me:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/base_to_lfs/compat_report.html
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/lfs_to_time_t/compat_report.html
This does not extend to libauparse0 where the report gives a reason, but
libaudit1 is the one that interacts with /usr-move and libauparse0 not,
so can we skip the dance for libaudit1?
For libtirpc, it is only about rpcb_gettime, which returns time via a
time_t* and can indicate success/failure via return. It seems fairly
simple to implement ABI duality here and libtirpc already does symbol
versioning. Maybe we can also approach upstream about this?
For libfuse2, I think the ABI analysis is broken. The base-to-lfs report
supposedly is ok
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/base_to_lfs/compat_report.html
and then going lfs-to-time changes ino_t
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/lfs_to_time_t/compat_report.html
while I would have expected ino_t to change with lfs already. Are we
sure about this? In any case, this is more of an academic question as
adding ABI-duality would be more involved here. Moreover, I don't see
any ACC report for libfuse3-dev. Did that fail to analyze?
libiw30 only has one affected symbol:
iw_print_timeval ( char* buffer, int buflen, struct timeval const* time, struct
timezone const* tz )
Providing ABI duality for this seems doable. Moreover, libiw30 already
has soname 30, so maybe upstream is open to bumping it again? The
resulting library transition is f
Re: 64-bit time_t transition in progress
Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit : > > I don't see any practical reason why not. > > Because packages are not required to use dpkg-buildflags. And more generally, does this scheme will require to build third-party packages on 32bit Debian system to set CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 or will this be made the default in gcc or glibc ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
Package: wnpp Severity: wishlist Owner: Manuel Traut X-Debbugs-Cc: debian-devel@lists.debian.org, ma...@mecka.net * Package name: libuio Version : 0.2.8 Upstream Contact: Benedikt Spranger * URL : https://github.com/missinglinkelectronics/libuio * License : LGPL Programming Lang: C Description : Linux Kernel UserspaceIO helper library A small Userspace IO driver helper library. More details about UIO can be found here: https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html UIO can be used to map device memory and interrupts into user-space. It is used to write user-space drivers for devices that do not fit in any existing kernel subsystem. libuio makes it easy to access a UIO device from user-space. It is what is libgpio for GPIOs or libiio for IIO devices. I would need a sponsor to upload this package.
