hose lines, but
hadn't taken it quite far enough. That would make it akin to dpkg
--add-architecture, which feels like a good model (although as you mention
I don't think we want --remove-architecture).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Well, bootstrapping a new Debian system involves running a tool that
> bootstraps a new Debian system. I think you're constraining the problem
> too much.
> It's a nice property that everything on the system comes straight from a
> Debian packa
ust solving the
problem properly, with the caveat as mentioned above that writing the
necessary filter may be difficult.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
mess and make it much harder to reason about the behavior or test it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e to do archive-wide package
inspection to try to find patterns that might cause problems, and to ask
all maintainers to remember this rather obscure rule, when we could just
fix dpkg to make the problem go away.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
always required when there's a new
major OpenSSL release (and are far, far less significant than, say, the
differences between the OpenSSL and GnuTLS APIs).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
and improve
GnuTLS, switching to OpenSSL is a lot easier and makes most problems like
this go away.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
't Red Hat attempt to
standardize on NSS a while back? I feel like that didn't work and they
stopped that effort, but some quick searching didn't uncover any support
for that belief.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
l. Making that sort of change without a GR to be sure the
project is behind it feels like the kind of thing that's likely to spawn
endless arguments that will sap everyone's will to live.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
PI versions, then it's all the more
> important that the tests run against the Debian versions of the
> dependencies.
I believe the dependencies in question are test dependencies. In other
words, they're dependencies required to drive the test suite machinery,
not dependencies
would not use +dfsg.N-1. It's not consistent with the other places
where we add suffixes, such as backporting and stable updates.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
kaging to remove
non-free source removes functionality as well, this leaves version space
for users who need that functionality for whatever unfortunate reason to
package upstream's release as-is and have that version be later than
Debian's version.
--
Russ Allbery (r...@debian.org)
erface. If you want portable semantics, the
standardized command is command -v, but it doesn't do quite the same thing
in quite the same way. If you want which, you have to live with the fact
that it's not portable and different which implementations behave in
different ways.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Please do not do this. I do not want to have to reason about the
> security impact of someone who controls local DNS taking over my apt
> sources.
Incidentally, this is also exactly why I believe we should be using https
by default, so that a compromise of the
those machines.
We should not enable people who control the local network but not the
Debian system to dynamically change security-relevant configuration of
that system, which I believe includes apt sources, without explicit
permission.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
onates.
Yes. For example, the approach used by apt-cacher-ng works fine.
Explicitly opting in to a local cache seems desirable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ersonally would probably prefer the text/*
behavior most of the time, but I'm also not a typical user.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
gt; https://wiki.debian.org/Teams/Dpkg/Spec/SysUser. But that's clearly a
> lot of work, and this change wouldn't preclude it.
This does seem like clearly the right solution in the long run for all
problems of this sort, though. I wouldn't want to add many statically
allocated UIDs. (
oing to arrive at a solution that
isn't going to make you even more unhappy. In order to break this
deadlock, I think we have to have a design discussion in the shared space
of mutually agreeable solutions and not (on all sides) retreat back to a
single preferred architectural decision and on
ble.
Yes, that's probably the most appropriate place to make a change to Policy
to clarify this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wouter Verhelst writes:
> On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
>> If we tried to document every random bit of buggy packaging behavior
>> anyone thought of in Policy, Policy would become unwieldy, so I want to
>> verify here that someone really thoug
sition and, if we do
decide on that, work out the implications for when packages should
standardize on /usr paths (if indeed they will ever need to do so; I
assume that they probably will out of cleanliness if nothing else, but I'm
also not sure it's strictly needed).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
root=admin/ifupdown2 usr=admin/ifupdown
I've chcked these and they all declare explicit Conflicts.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
n and /usr/bin is not sensible, yes? (I believe that's the topic
under discussion in this thread.) I'm trying to understand if enough
people thought this was a sensible, non-buggy thing to do today that it's
worthwhile adding something to Policy explicitly saying that
sr/bin in user-set PATHs is not fixed
and has never mattered.
(It may be that someone has done this *accidentally* and thus created an
edge case that the package management system has to cope with, but that's
a question of finding buggy packages, which is not something Policy can
really help wi
Luca Boccassi writes:
> On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote:
>> This is already the case. Policy 10.1:
>>To support merged-/usr systems, packages must not install files in
>>both /path and /usr/path. For example, a package must not install both
&
the case. Policy 10.1:
To support merged-/usr systems, packages must not install files in
both /path and /usr/path. For example, a package must not install both
/bin/example and /usr/bin/example.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Debian mirrors seems like something we should not support.
Agreed. This seems like a feature, not a bug.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
o
compromise of the TLS certificate authority chain, which is possible of
course and which degrades to the http case), whereas with http you will
download the malicious package first and then apt will refuse to install
it when the hash doesn't match. That difference mostly doesn't
you have containers that you can't modify but that are
self-modifying (by updating apt packages) at runtime.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
step would be to open a bug with a summary of this
discussion. I'm happy to do that, but I'm not sure what package owns this
configuration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
lyze any of this: use TLS
by default wherever you can. It's not a panacea, but ubiquitous, default
use of TLS helps both your security and your privacy compared to either
the previous default of no TLS or spending a bunch of mental energy
picking and choosing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
btlety that I had completely failed to grasp and didn't
realize this was way the rule was worded the way it was. Sorry for that
mistake; we should revert it.
If we separately want to drop this in favor of pure multiarch, that's
great and we can always reflect that later, but we shouldn&#
s in the understanding of sudo and what it can and can't do by the
people writing the configuration. It is *extremely hard* to configure
sudo correctly in anything other than "logged access to root" mode.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
mon these days. (/var/tmp is
available if one needs a file system more likely to be on a larger disk.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I see that you have your system configured to store /tmp on your disk.
> This is generally not recommended these days. Storing /tmp in tmpfs is
> much faster for some applications and automatically achieves the desired
> and standard /tmp behavior of clearing
n and therefore am not involved
in analyzing any of the technical concerns they raise.
"Courage" seems to me like an odd label to put on any of this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g a multi-user system. But otherwise, separating out
things like /var or /usr/local or /opt or /srv is more likely to cause you
long-term headaches than it is to do anything useful.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
(We can then also grab some of it for Policy where appropriate, but I
think most of it is more of a Developer's Reference thing.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
scussion
system*. And second, I want to change the GR discussion system because of
the mess during systemd discussion, not because of this vote, although
this vote did re-raise the same issues.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wouter Verhelst writes:
> On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
>> * A formal amendment has to be sponsored like a new GR before it can be
>> accepted, but the original proposer of a GR can make their own amendment
>> without having it be sponso
e folks (not including
me, but I do understand) have been unhappy with the plain English
implications of "further discussion" for some time and often feel
obliged to propose a ballot option that's functionally equivalent but
isn't seen as calling for more discussion.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
llot construction process.
I personally have little interest in messing with the rules about how we
do Condorcet, although of course other people might and I will read their
proposals with interest.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Timo Röhling writes:
> * Russ Allbery [2021-03-26 13:01]:
>> If this were the case, it would be fine to re-sign *.dsc files, but
>> there has been quite a lot of opposition to that in the past. The
>> upstream signing key is at least as useful as the signature on the
>&
riodically. But I'd like to see some
confirmation that people really don't care.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Ansgar writes:
> On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote:
>> I'm not all that familiar with the intended semantics of OpenPGP key
>> expirations, but intuitively I think a signature made before the
>> expiration should be considered valid, even if the
OpenPGP key
expirations, but intuitively I think a signature made before the
expiration should be considered valid, even if the key has now expired and
thus shouldn't be used to make new signatures.
I'm curious how your numbers would change if you only counted as expired
keys that were
Adrian Bunk writes:
> On Tue, Feb 09, 2021 at 12:02:33PM -0800, Russ Allbery wrote:
>> Adrian Bunk writes:
>>> On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
>>>> users on shared systems can expect it to be available without asking
>
t
>> makes sense to install it by default.
>>...
> "Shared systems" have become pretty rare.
They've become *rarer*, but they're still very common in the academic and
scientific research world.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Thomas Goirand writes:
> On 2/9/21 7:40 PM, Russ Allbery wrote:
>> I've been using wrap-and-sort -ast on all of my packages for a while, with
>> much the same justification.
>> My recollection is that the relevant Config::Model model has a slightly
>> differ
s used for this, I think, so if the two of them could agree, that
would go a long way towards having a common format (and this may have
already happened without me knowing).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Andrey Rahmatullin writes:
> On Sun, Feb 07, 2021 at 10:25:26AM -0800, Russ Allbery wrote:
>> To me, the rewards of keeping the orphaned packages clearly outweigh
>> the risks. If the package is actually broken, presumably sooner or
>> later someone will notice and report
;t think this answer is obvious, but I would lean towards saying
we're better off with them.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
better-handled by other mechanisms than a blanket rule for unmaintained
packages.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
for information, my drafts were
>not autogenerated by a tool like, for example, pod2man(1).
>Rather, they were marked up by hand according to groff_man(7).
FYI, the --center flag to pod2man controls this header, and its default is
not that appropriate for anything oth
t; with secret keys to theoretically create memory pressure (which still
> wouldn't spill secret keys to swap).
I would not be at all certain that the only kernel attack surface you're
exposing is denial-of-service.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
to add
the same settings to their relevant unit files:
corekeeper: /etc/security/limits.d/corekeeper.conf
libvma: /etc/security/limits.d/30-libvma-limits.conf
lizardfs-common: /etc/security/limits.d/10-lizardfs.conf
stenographer-common: /etc/security/limits.d/stenographer.conf
uhd-host: /etc/
Simon McVittie writes:
> On Mon, 01 Feb 2021 at 09:54:56 -0800, Russ Allbery wrote:
>> Does this serve any useful purpose?
> Honestly, probably not, but removing security hardening (however
> dubious) is a regression, and if I remove it I'm sure there'll be a CVE
&g
and failure-prone.
[1] https://feeding.cloud.geek.nz/posts/encrypted-swap-partition-on/
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Marco d'Itri writes:
> On Jan 21, Julien Cristau wrote:
>> So I'd like to raise the priority of ca-certificates from optional to
>> at least standard, as a signal that it should be installed on
> Good idea: I think that "standard" is appropriate.
I agr
nd.
For the record, this is always the problem I have. The last system I
installed didn't have an Ethernet port. I think there was some way to
make Ethernet work over USB, but I didn't have the right hardware.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
systems with that bug (?!)
5. ???
6. More systems will stop requiring non-free software (profit!)
We've been wandering around in step 5 for a long time now. I'm not sure
it's working.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
cture around the
work, recruiting people, building a task list, and so forth, instead of
just assuming "oh, everything will work on i386, it always has."
Volunteering to do that sort of coordination is helpful even if you aren't
debugging FTBFS problems.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
tting
onto the amd64 kernel even if you keep an i386 userspace), but at some
point it seems likely they will no longer be. That means it may be time
to push our users a bit harder to switch to the amd64 kernel if they can.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
k on actual i386 hardware, and I don't know if it
has other issues that I personally happened not to notice.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
While all of these details of the RHEL and CentOS kernel driver support
model are doubtless fascinating, they seem off-topic on debian-devel,
which is for the development of an entirely different distribution.
Maybe this branch of the thread can be taken to some CentOS mailing list?
--
Russ
gt; Given that the maintainers of both javadoc and doxygen have declared
> this "wontfix" should we not at least stop lintian complaining about it?
Personally, I would think so, since it makes the Lintian tag effectively
unactionable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Matthias Klose writes:
> On 11/11/20 8:37 PM, Russ Allbery wrote:
>> Rust and Go both vendor dependencies during their build. Python isn't
>> really analogous; you *can* do something similar with virtualenvs, but
>> (a) Python doesn't really have a build the way
nly one of many ways of assembling Python applications,
whereas there's largely only one way Rust and Go binaries are built.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e
the crash happens and then figuring out if that's part of an attack
surface, but that's quite a bit of work which they're clearly not
volunteering to do.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ain* for compilation or execution),
If you need a non-free package to build the binary packages, that's what
"require a package for compilation" means. That's referring to the build
of the binary packages.
Packages can only go into main if they can be built using only other
packages from main.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
re self-documenting
and obvious what's going on.
That also avoids the hassle of having to maintain a bunch of separate test
data packages (although one could of course also do that) by collecting
the packaging in one place.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
x27;re packaging in a branch named experimental but your upload is
targeting unstable," which would have caught some errors that I've made
even as an experienced packager.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Richard Laager writes:
> On 8/29/20 5:19 PM, Russ Allbery wrote:
>> The problem in my case with not putting a branch name in Vcs-Git is
>> that, for packages for which I'm also upstream, the default branch in
>> the repository named in that header is the upstream de
Richard Laager writes:
> On 8/29/20 3:33 PM, Russ Allbery wrote:
>> I think the primary thing that bothers me about this workflow is that
>> experimental becomes an ephemeral branch, which appears and disappears
>> based on the vagaries of the release cycle.
> To me, th
Richard Laager writes:
> When I last brought this up [1], Russ Allbery said that debian/latest
> was desirable (to him, at least) because, "My normal use of experimental
> does not involve maintaining unstable and experimental branches
> simultaneously. I essentially never do
kind of like asking what the preferred form of
modification of a PGP public key is.
One might want to generate *more* testing data, I guess, but is that worth
keeping the old code around forever? I'm dubious the benefit is worth it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ore generally), which
has essentially the same properties and for which implementations are far
more widely available? What you describe is basically equivalent to how
Webauthn works except that Webauthn uses X.509 certs, for which there are
numerous well-tested and audited implementations.
Russ Allbery writes:
> That's effectively what a password manager simulates, albeit trading off
> local secure storage for convenience while limiting the strong passwords
> someone has to memorize to one. I would argue that the only functional
> difference between a properly-co
Salsa SSO provider being hacked is would allow the attacker to
impersonate anyone to anything protected by Salsa, but that's obviously
still true with SQRL, so it seems unrelated to the question of password
storage.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
f our machines, which together mean that implementing certificate
pinning for our own infrastructure is entirely doable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g back in
again. The "long time" seems subjectively to be a week or two (or maybe a
month). Am I doing something wrong?
What you say is true of GitHub for me.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g a physical object,
and since that object can break or be lost, also storing backup codes
somewhere safe.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ents. The control plane
and pod software for my purposes is provided by a platform provider, so is
outside of my scope.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
no significant
impact on software freedom.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
es
in the center of the QR codes, which is a different issue.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
character sets or encodings (test files in
base64, for instance), I think it looks obviously silly, and I'm not sure
why this case would be any different.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
h. However, my personal experience is limited, and I'd
be happy to be educated!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
act on our users than licensing bugs, such as
security bugs), we often make trade-off decisions in favor of accepting a
risk of upstream mistakes and having to fix them later.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
bout. (Also because, like gnulib, rra-c-util consists of a lot of
different pieces, most of which are not needed for any given package, and
includes pieces like Autoconf machinery that are tricky to maintain
separately.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
In this case, we create a bit more security work by separately
packaging the dependencies, since we now have to trace down the package
that corresponds to a Kubernetes security advisory and update it.
This of course doesn't apply if the individual libraries are releasing
their own security
user for more than two decades I also don't install
> every last bit of software from its packages.
I do when I can because I otherwise have to remember to wire together N
different update mechanisms, which is remarkably not-fun and takes time
away from the actual work I'm trying t
not recommend it unless
someone wants to adopt it and try to clean it up. I considered doing that
a few years ago, looked at the code and the existing patches, and switched
to vim instead.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ated by
systemctl mask will also prevent the init script from running.
The implementation creates a file in /etc/systemd, so I don't see any
reason why it wouldn't work with a chroot, although maybe there's some
wrinkle that I've not thought of.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ith a Linux distribution with
existing tools and maybe a few additions, but in practice you would have
to bless Perl and Python (at least), and then it's not clear if you're
getting enough security benefit.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
build in
> virtual machines with a timezone offset to UTC of -10 years, and I'd really
> like to move them to containers or light them on fire.
Time namespaces were merged for Linux 5.6.
https://lwn.net/Articles/766089/
https://lwn.net/Articles/810780/
--
Russ Allbery (r...@deb
sensus or conclusion.
https://bugs.debian.org/485559
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Dmitry Smirnov writes:
> On Thursday, 6 February 2020 10:22:24 AM AEDT Russ Allbery wrote:
>> I can't speak for Bernd, but I haven't seen any evidence in this thread
>> that the built binary is not DFSG-compliant.
> So now you are going to nitpick on my lang
e
DFSG you believe exist, rather than assuming everyone agrees with you and
then berating people for ignoring the DFSG? It seems far more likely
that, rather than ignoring the DFSG, people simply don't believe you're
correct in asserting there is a problem.
--
Russ Allbery (r...@debian.org)
believe I have *ever* accepted
all of the defaults or left a system in a purely default mode for longer
than about five minutes.
No one is going to prevent you from using rsyslog everywhere that you want
to use rsyslog.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
201 - 300 of 3430 matches
Mail list logo
