rk. See the Pre-Depends in base-files, which is there to make
some awk implementation essential while still allowing the user to switch
between implementations.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
is not legal advice, and it's worth what you paid for it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
think this was intentional, to be clear, but I believe your MUA is
not working the way that you think it's working.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ebian which says that mixing different Kerberos implementaions
> on a host which is meant to be a KDC is not necessarily a good idea.
I don't think anyone wants to mix implementations on the KDC itself.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
o which that symbol should resolve is, in fact, versioned. The
problem is that the information required to diagnose that problem is
difficult for Lintian to acquire.
> In my short experience running lintian, it has been right 99% of the
> time, so this feels like a bug.
Oh, sure, I
Ahmad Khalifa writes:
> On 28/01/2025 22:28, Sam Hartman wrote:
>>>>>>> "Russ" == Russ Allbery writes:
>> Russ> recollection (it's been a *lot* of years so I'm hoping I'm
>> Russ> getting this right) is that this int
they too are resolved from the main executable at
dlopen time. My recollection (it's been a *lot* of years so I'm hoping I'm
getting this right) is that this interfered with proper symbol versioning
and could cause the symbols to be resolved weirdly in a way that could
cause ser
Ahmad Khalifa writes:
> On 27/01/2025 18:24, Russ Allbery wrote:
>> Annoying to implement because I think the implementation would have to
>> know what symbols are provided by libc.
> To my knowledge objdump will spit out the symbols with (GLIBC_v*)
Oh, if one can reliably d
Marvin Renich writes:
> * Russ Allbery [250126 12:47]:
>> In theory it would be possible to do better in Lintian by scanning the
>> symbol table to see if the libc dependency is really unneeded. But
>> doing that sounds at least a little annoying.
> Annoying to users o
Simon McVittie writes:
> On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:
>> maybe it's more common these days to have plugin libraries that aren't
>> linked with libc? Back in the day, it was very rare for people to
>> successfully manage to write code
27;t linked with libc? Back in the day, it was very rare for people
to successfully manage to write code that never called a libc symbol.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
it be something stronger. That's an
argument for putting them in libpam-runtime, even though it's not a
perfect semantic fit, because that package is Priority: required.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ble, between the time the source package was uploaded and built and
the time a binNMU was scheduled for one of the architectures.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
people who seemed to have a good grasp of the
> man(7) macro language and the underlying roff(7) one--in other
> words, old school Unix graybeards who knew their way around troff
> sufficiently to submit a USENIX paper. A dying breed. Third, the
> long-time maintainer
tly the
reasons you describe.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
cess standpoint (like a lot of compiler bootstrapping), and we may not
want things to work this way, but I don't think that makes it non-free?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
verriding are
somewhere in /usr; Policy doesn't care whether they are hard-coded inside
some binary or present on disk in some loadable form.
I'll open a bug against debian-policy so that we can clarify the wording
and avoid this misreading.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e never
going to all agree on the best way of handling configuration files? Is
there some way that we can try to accomodate both groups?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ProtectSystem, PrivateDevices, or ProtectKernelTunables that
seems quite unlikely to break anything.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
S classes, which
means the base of people who know at least some Python is probably larger
than any other language filling the same niche.
I think the only real competitor to Python today on the popularity and
existing knowledge front would be JavaScript, and I think it's less
suitable for the
Otto Kekäläinen writes:
> On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote:
>> On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote:
>> [...]
>>> I think a shallow clone of depth 1 is sufficient, although that's not
>>> sufficient to get the correc
d
rather continue down the path of providing Debian tools and processes that
reduce the delta between how Debian packaging uses Git and how most free
software development uses Git.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
much to say about this unless we need
some mechanism for labeling such packages other than a MR to Lintian. The
important information is the list of packages that shouldn't be used this
way, and the hard part is probably gathering that list.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ed debian/unstable
and debian/experimental.
Personally, I use debian/unstable but do experimental development in that
same branch if it's "targeting unstable," which is either the best or
worst of both worlds, depending on your perspective.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ately exit with no changes to the commit message, and to do that we
probably need to write down what those expectations are. I think the
Policy language was written in a time where we just assumed there was an
obvious way for editors to behave that didn't include things like
backgrounding the
uot; specifically:
https://docs.python.org/3/library/fractions.html
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ion numbers that are much
smaller. In other words, to quote policy, "situations where the upstream
version numbering scheme changes." Yes, in this case it was only in their
packages and not in their software releases, but that still counts when
they have an existing user base that has those packages installed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ll that my contribution to this thread accomplished was to
demonstrate that I set up sbuild years ago based on a wiki article for
btrfs and don't know what I'm talking about. :) Apologies for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
n access the base via the
> source: names.) I never liked the type=file stuff, as it's slow to
> setup and maintain.
Ah, thank you, I didn't realize that existed. That sounds like a nice
generalization of the file system snapshot approach.
--
Russ Allbery (r...@deb
job to update the source subvolume
daily to ensure that it's fully patched.
Unfortunately, there's no way that we can rely on this, but it would be
nice to continue to support it for those who are using a supported
underlying file system already.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
for supporting architectures, including
the kernel, GCC, binutils, etc. If that ecosystem stops supporting
architectures, it will be very difficult for Debian to keep support, and
doing so usually requires the people interested in keeping those
architectures working to also become upstream kernel
it to do something like set the soft limit to the
hard limit (that sounds like a very INN sort of thing to do), but if so, I
couldn't find it in a quick search.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t; magnitude in Debian that was managed on this professional level. I
> especially praise the way you have communicated the progress.
100% agreed. The care and excellence that you've brought to this work has
been exceptional.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Matthew Garrett writes:
> On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote:
>> Historically, deleting anything in /var/tmp that hadn't been accessed
>> in over seven days was a perfectly reasonable and typical
>> configuration. These days, we have the com
ding support.
Note that its dependency is only Suggests. I have not checked if that's
there for some other reason.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
, so I generally start
with a tagged release from the upstream Git repository, create a branch
based on it, and start writing and committing debian/* files.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
eep the debian directory in a separate repository or try
to keep the Debian Git branches in a separate repository, and all of that
was just annoying and tedious and didn't feel like it accomplished much.
Just pushing the same branches everywhere is easy and seems to accomplish
the same thing.
d the dgit-maint-gbp(7) workflow, which is basically just the
normal git-buildpackage workflow, for years and still use it for some of
my packages and it works fine.
Maybe you mean something different by this than I think you meant.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s to problems of this sort. It's
because we've chosen a governance model that intentionally makes central
decision-making and therefore consistency and coordination difficult, in
exchange for other perceived benefits.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
rally includes a version (as it does here). See:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
reat; the ecosystem expectation
is that one uses separate virtualenvs, which don't really solve the Debian
build dependency problem.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
download multiple packages. Debian
packages should not make use of these convenience copies unless the
included package is explicitly intended to be used in this way.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
st possible response to this post would be for someone 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
ves that 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/>
em on file 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 wron
ications that didn'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/>
going to result in someone getting their data deleted at some point,
regardless of what Debian does.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ibing habits that are going to lose their data 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/>
ions 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 dif
#x27;t its own partition and thus
inherits that setting from the rest of the system.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e skills in any 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/>
tion format is probably not a good enough
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/>
I think a shallow clone of 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/>
mense amount 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/>
ward. More features are nice, 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/>
hich
have M4 macros in m4/* that do not come from an external source.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
etc/apt/trusted.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
baked into these tools 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 fee
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
>> m
x27;s not a security trade-off that 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
I've
recycled those 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/>
ing 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/>
on portability to older systems as
the cost of having 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/>
Debian-controlled mirrors of upstream Git repositories so that we could
detect rewritten history. (There are a whole lot of reasons why I think
dgit is a superior 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
&
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.
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/>
format60 (>= 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/>
s seem to 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 of
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 the in
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 use
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 weird and
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
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 error I ge
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
e any relationship, 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/>
ther Rust or Go even existed, 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
ly means that we're not
properly representing the dependencies 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
ast I checked, 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 l
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 pag
name is
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 (
also explicitly 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/>
aphy (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/>
at have been 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/>
r need the
content that 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/>
ting wontfix bugs (at least their titles),
which in some cases is fine but in some cases can become overwhelming.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
d tables in a way that makes it
mostly unusable for a lot of applications YAML does well on.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
n an
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.
s or other things (in which case they probably should move
to rlpr).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
packages are broken as collateral damage in
accomplishing 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/>
just ship a configuration 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/>
nlike 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/>
1 - 100 of 2952 matches
Mail list logo
