eone to
tell me I'm five years behind and the batch systems have already picked up
this work and we can just point people at them.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Simon Richter writes:
> On 5/8/24 07:05, Russ Allbery wrote:
>> It sounds like that is what kicked off this discussion, but moving /tmp
>> to tmpfs also usually makes programs that use /tmp run faster. I
>> believe that was the original motivation for tmpfs back in the da
hat this isn't
as much of a concern as it used to be, but VMs often still have quite
small / partitions and put /var/tmp on that partition.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
systems that didn't support
those attributes. atime is often turned off, but I believe support for
ctime is fairly universal among the likely file systems for /var/tmp, and
I believe tmpfs supports all three. (I'm not 100% sure, though, so please
correct me if I'm wrong.)
--
Russ Allbery (r.
idn't honor TMPDIR.
This is not a new problem. Nor is having /var/tmp fill up and cause all
sorts of system problems because someone turned off /var/tmp cleaning
while trying to work around broken applications.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
their data deleted at some point,
regardless of what Debian does.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ata if
they use a different distribution or even a differently-configured Debian
distribution with tmpreaper installed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
of screen use /run/screen, which is
a more reasonable location. Using a per-user directory would be even
better, although I think screen intentionally supports shared screens
between users (which is a somewhat terrifying feature from a security
standpoint, but that's a different arg
tion and thus
inherits that setting from the rest of the system.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
language other than English), so
it's easy to fall into the trap of assuming that they're completely
fluent, but English is full of problems like this that will trip up even
highly advanced non-native speakers.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ugh
reason to keep a dependency in a security-critical, network-exposed
service. I'm mildly grumbly becuase it's yet another thing I have to
change just to keep things from breaking, but such is life.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
f depth 1 is sufficient, although that's not
sufficient to get the correct version number from Git in all cases.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nt of
work just to get back to where you started. I look at the amount of
effort and start thinking things like "well, if I'm going to rewrite a
bunch of things anyway, maybe I should just rewrite the software in Rust
instead."
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
but I can
see the merits of simplicity here. But I no longer maintain a large
infrastructure built on Kerberos, so I'm not putting as much weight on the
GSSAPI support as I used to.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
M4 macros in m4/* that do not come from an external source.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
usted.gpg.d/
> which should only have files claimed by some .deb.
Guillem has a plan for addressing this, I believe as part of metadata
tracking, that would allow such files can be registered by their packages
and then tracked by dpkg.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Luca Boccassi writes:
> On Sat, 30 Mar 2024 at 15:44, Russ Allbery wrote:
>> Luca Boccassi writes:
>>> In the end, massaged tarballs were needed to avoid rerunning
>>> autoconfery on twelve thousands different proprietary and
>>> non-proprietary Unix varia
ls is
IMMENSE, and while probably 75% of it is now irrelevant because the
systems that needed it are long-dead, no one can agree on what 75% that is
or figure out which useful 25% to extract. And rewriting it in some other
programming language is daunting and feels like churn rather
Simon Josefsson writes:
> Russ Allbery writes:
>> I believe you're talking about two different things. I think Sean is
>> talking about preimage resistance, which assumes that the known-good
>> repository is trusted, and I believe Simon is talking about
>> ma
I can
responsibly make entirely for myself, since it affects people who are
using Debian as well. So I don't get to have the final decision here.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Jeremy Stanley writes:
> On 2024-03-29 23:29:01 -0700 (-0700), Russ Allbery wrote:
> [...]
>> if the Git repository is somewhere other than GitHub, the
>> malicious possibilities are even broader.
> [...]
> I would not be so quick to make the same leap of faith. Git
brain cells for other things) only needs preimage
resistance, but the general case of a malicious upstream may be vulnerable
to manufactured collisions.
(So far as I know, preimage attacks against *MD5* are still infeasible,
let alone against SHA-1.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g the people who step up to help works out
great.
The hardest part about defending against social engineering is that it
doesn't attack attack the weakness of a community. It attacks its
*strengths*: trust, collaboration, and mutual assistance.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ing a cleaner build system," and that's not an entirely
unreasonable thing to say, but that's going to be a hard sell for a lot of
upstreams that care immensely about this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
model for archive management. One of them is that it
captures the full Git history of upstream at the point of the upload on
Debian-controlled infrastructure if the maintainer of the package bases it
on upstream's Git tree.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Moritz Mühlenhoff writes:
> Russ Allbery wrote:
>> I think this question can only be answered with reverse-engineering of
>> the backdoors, and I personally don't have the skills to do that.
> In the pre-disclosure discussion permission was asked to share the
> p
Russ Allbery writes:
> Sirius writes:
>> This is quite actively discussed on Fedora lists.
>> https://www.openwall.com/lists/oss-security/2024/
>> https://www.openwall.com/lists/oss-security/2024/03/29/4
>> Worth taking a look if action need to be taken on Debian.
ted to 5.4.5 in unstable yesterday by the
security team and migrated to testing today. Anyone running an unstable
or testing system should urgently upgrade.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
>= 7:6.0)
The apt resolver seems to be struggling pretty hard to make sense of the
correct upgrade path.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
be available, but attempting to force
it would remove gdb and jupyter if that helps.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
't look like the migration is finished yet, so this is expected.
There are a whole lot of packages that need to be rebuilt and a whole lot
of libraries, so some edge cases will doubtless take a while to sort out.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Thorsten Glaser writes:
>> Right… and why does pkexec check against /etc/shells?
> pkexec checks against /etc/shells because this is the traditional way to
> determine whether the user is in a restricted shell, and pkexec is
> essentially a type
Russ Allbery writes:
> That definitely should not be the case and any restricted shell that adds
> itself to /etc/shells is buggy. See chsh(1):
> The only restriction placed on the login shell is that the command
> name must be listed in /etc/shells, unless
Vincent Lefevre writes:
> On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
>> and pkexec is essentially a type of sudo and should be unavailable to
>> anyone who is using a restricted shell.
> The pkexec source doesn't say that the goal is to check whether
> the user is
ing a restricted shell.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Thorsten Glaser writes:
> Dixi quod…
>> Russ Allbery dixit:
>>> My guess is that pkexec is calling realpath to canonicalize the path
>>> before checking for it in /etc/shells, although I have not confirmed
>>> this.
>> Now that would be weir
Thorsten Glaser writes:
> Russ Allbery dixit:
>> 3. Something else that I don't yet understand happened that caused pkexec
>>to detect the shell as /usr/bin/mksh instead of /bin/mksh. I'm not
> What sets $SHELL for the reporter’s case? Fix that instead. login(1)
> set
Vincent Lefevre writes:
> On 2024-02-14 17:16:23 -0800, Russ Allbery wrote:
> Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168
> | with usrmerge, some programs - such as pkexec, or LEAP's bitmask
> | on top of that- fails to run. Specifically, the
Vincent Lefevre writes:
> On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:
>> I'm sorry, this is probably a really obvious question, but could you
>> explain the connection between the subject of your mail message and the
>> body of your mail message? I can't see any relat
hip, so I guess I
need it spelled out for me in small words.
(I believe /etc/shells enforcement is done via PAM or in specific
programs that impose this as an additional non-POSIX restriction. This is
outside the scope of POSIX.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ted, and that we have
nonetheless dealt with throughout the whole history of Debian. There is
no one-size-fits-all solution, but we have historically managed to muddle
through in a mostly acceptable way.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Roger Lynn writes:
> On 15/01/2024 18:00, Russ Allbery wrote:
>> When you have the case of an application that optionally wants to do foo,
>> a shared library that acts as a client, and a daemon that does foo, there
>> are three options:
>>
>> 1. Always install t
es of the shared library. We in
general try not to do 1 for reasons that I think are sound. Minimizing
the footprint of applications for people who don't want optional features
is something that I personally value a lot in Debian.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Jeremy Stanley writes:
> Or build and sign the .tar.gz, then provide the .tar.gz file to the
> upload automation on GitHub for publishing to PyPI.
Oh, yes, that would work. You'd want to unpack that tarball and re-run
the tests and whatnot, but all very doable.
--
Russ Allb
no one really
used, although I think there was some recent movement towards maybe
integrating it a bit more. It's very hard to create a critical mass of
people who care enough to keep all the pieces working.
PGP signatures definitely seem to be a minority interest among most
upstream language communities.
Andrey Rakhmatullin writes:
> On Fri, Nov 10, 2023 at 11:44:06AM -0800, Russ Allbery wrote:
>> The good news is that if you're using debhelper, you don't have to care
>> about how man handles these indirections and can just use a symlink.
>> Install the man page into usr
s
canonical (possibly by using dh_installman), and then create a symlink in
usr/share/man/man1 from the other man page name to that file.
dh_installman will then clean this all up for you and create proper .so
links and you don't have to care about the proper syntax.
--
Russ Allbery (r...@debian.org
says that it's non-breaking (I believe that's
the case, although please tell me if I got that wrong) and is more
(perhaps excessively) explicit about distinguishing it from "-" because of
all the confusion about this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ography (the hyphen-minus is one of 25 dashes in Unicode), you may want
to say that explicitly in addition to saying that it's the character used
in UNIX command-line options (and, arguably as importantly, in UNIX
command names).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
en turned
into \-. People will have to rewrite them using proper Unicode hyphens to
get proper formatting.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hat is dropped by truncation.
In other words, the intent is to guarantee that all the information that
apt-listchanges needs is present on disk, but it would have to deal with
the /usr/share/doc symlinks.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
tles),
which in some cases is fine but in some cases can become overwhelming.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nusable for a lot of applications YAML does well on.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
office regularly and I do recommend it. If anyone else who still prints
regularly prefers the simple command-line interface, you may want to
consider adopting it, although it looks like you're likely to have to
adopt upstream as well since it seems to have disappeared.
--
Russ
her things (in which case they probably should move
to rlpr).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ccomplishing some goal, and you then argue that it's their problem to fix
their packages, even though there was no agreement about that goal.
Accomplishing things like this in Debian has a large social component that
I think is being neglected.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
tion file and have
everything happen automatically and correctly despite requiring some quite
complex PAM syntax.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Peter's
example, that would be a silent error; authentication may well succeed,
but without running, say, pam_limits.so.
I don't know if anyone is making this specific configuration change, but
if they are, I think that result would be surprising.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
th a proper directory of overrides and a standard
configuration syntax would be a *drastic* improvement over our complex
single-file configuration management tools such as ucf, let alone over
basic dpkg configuration file management.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
derstand
what our goals would be.
(License texts that have portions that vary between packages they apply to
are a menace and make everything much harder, and I really wish people
would stop using them, but of course the world of software development is
not going to listen to me.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ight file, though. If we
take this approach, we'll need to be very explicit that you can only use
whatever triggers the automatic inclusion of the license text if your
license text is word-for-word identical. Otherwise, you'll need to cut
and paste it into the file as always.
--
Russ A
anaging to
keep in the air is... low, even though I do have a much more active
comaintainer.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
, so it wouldn't know to include licenses
referenced in License stanzas without the license text included.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
bility that certain carefully-crafted
configurations with a subset of packages may work in this mode, of
course.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
be we
still need to do something with common-licenses?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
need serious improvements.
That was something else I wanted to ask: I've invested all of a couple of
hours in this script, and would be happy to throw it away in favor of
something that tries to do a more proper job of classifying the licenses
referenced in debian/copyright. Has someone already done this (J
Russ Allbery writes:
> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal. This is
> what I would do if the decision was entirely up to me:
> Licenses will be included in common-licenses if t
articular bug, but I would love to see the
pointer to common-licenses turned into a formal field of this type in the
copyright format, rather than being an ad hoc comment.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Hideki Yamane writes:
> Russ Allbery wrote:
>> Licenses will be included in common-licenses if they meet all of the
>> following criteria:
> How about just pointing SPDX licenses URL for whole license text and
> lists DFSG-free licenses from that? (but yes, w
32
MPL 1.1 165
MPL 2.0 361
SIL OFL 1.0 11
SIL OFL 1.1 258
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ed in SPDX using an "-only" and "-or-later" syntax in the identifier
at the insistence of the FSF rather than a separate generic syntax the way
that we do.
https://spdx.org/licenses/ is the current license list and assigned short
identifiers.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
licenses that we see that are not yet registered.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g on here, and you can explain further in a Comment.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
munity or encouraging productive collaboration, because the contents of
our archive don't need to do either of those things. Lots of people use
Debian who are not members of any shared community, and this is a feature.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ust as if you were using a Git forge.
Obviously, dgit doesn't have the other functions of a Git forge, such as
issue tracking, CI, or merge requests. But it does manage source packages
in Git.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Dominik George writes:
> On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote:
>> This implies that Salsa is happy to create accounts for people under
>> the age of 13, since the implicit statement here is that Debian's own
>> Git hosting infrastructure is less
uld not dare to venture an analysis without legal advice.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
opt in to "hardening that might break
something," but I'm not sure the best way to do that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g to just
the daemons that are configured to use that PAM module is possible if we
know which PAM name the daemon uses.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ing on
which I wholeheartedly agree with Guillem (and, I think, you): the problem
is complex and requires careful design and thorough testing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ked by
not having a solution for this transition, it will be easier to get to #3d
from #3e than it is right now.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nating outweigh the costs of doing the
coordination.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
going back and
properly documenting things we're already doing. If we somehow miss the
window while the change or new thing is being worked on, it can slip
through the cracks. I used to have a lot more time to work on language
for that than I do now.
--
Russ Allbery (r...@debi
Simon Richter writes:
> On 6/28/23 13:05, Russ Allbery wrote:
>> In that case, I don't actually know why we usually use Conflicts with
>> Replaces. Maybe we don't really need to?
> Replaces+Conflicts together has a special meaning, that is used for
> replacing a package co
Simon Richter writes:
> On 6/28/23 02:31, Russ Allbery wrote:
>> Normally Conflicts is always added with Replaces because otherwise you can
>> have the following situation:
>> * Package A version 1.0-1 is installed providing file F.
>> * File F is moved to pack
ackage doesn't exist (Policy is certainly shy of
that), and if it did, would form a hardcover book large enough to use as a
boat anchor. We should be tryingn to whittle that down over time with
automation and tools, not rely on people's memory and constantly
re-reading Policy.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
that changes apt behavior in any way.) Presumably the sysvinit init
system package should depend on orphan-sysvinit-scripts, so the
Replaces/Conflicts should then force the right upgrade to happen.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
fficult to slow down a little bit and
follow a process.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ication rather than technical specifics, and I
think it's better for you to be able to change those details as you see
fit without having to update Policy.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Luca Boccassi writes:
> On Sun, 11 Jun 2023 at 18:06, Russ Allbery wrote:
>> On the other, related topic, I've also been somewhat confused in this
>> discussion why it seems like there's a long-term goal to not have any
>> Debian package ship the /bin and /lib symlink
t seems like the most efficient way
to prevent them from being removed, and also just seems obviously correct
semantically.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
now. But
it means that looking for packed won't find one case of this that I know
exists.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I'm afraid the problem with INN is worse than the history and overview
> databases. The on-disk CNFS header contains time_t, so if you're using
> CNFS as your spool storage, the whole article spool becomes unreadable.
Oh, wait! No, I'm wrong, CNFS actu
xactly the same problem that we had with LFS, and I'm
really regretting not switching everything on-disk to uint64_t or the like
a long time ago. (But there was never a point after we introduced CNFS
when that was going to be easy.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Luca Boccassi writes:
> On Wed, 17 May 2023 at 01:05, Russ Allbery wrote:
>> I do think the industry is moving away (well, has already moved away)
>> from Linux Standards Base pre-compiled C binaries without wrappers like
>> snap or flatpak, although there are some ve
problem for us if they hadn't). I think Oracle subsequently
added more support for Debian, or at least Ubuntu, but I'm sure there are
other cases like that still around today.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
data migration. This time around, maybe we'll manage to write a
conversion program in time.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
are more important to them than cross-distro
compatibility, and given their goals, that seems like an entirely
reasonable decision. I would disagree vehemently with that decision for
Debian because Debian is not Guix.
In other words, it depends.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nt question than the one discussed in this
thread.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
something that would be in scope for the Linux Test
Project, though, and it's possible their existing tests do some of this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
1 - 100 of 4300 matches
Mail list logo
