Philipp Kern wrote:
> One machine (the primary) serves them just fine. The others don't.
>
> We did some maintenance over the weekend to change the primary. It looks like
> some syncing got caught up in the cross-fire.
>
> I'll provide another update when it's fully fixed but it's likely going to
(404):
Thanks for the report.
https://snapshot.debian.org/archive/debian/20250818T025134Z/zzz-dists/trixie-backports/Release
https://snapshot.debian.org/archive/debian/20250818T025134Z/zzz-dists/trixie-backports-sloppy/Release
https://snapshot.debian.org/archive/debian/20250818T083758Z/zzz-dists
ps://snapshot.debian.org/archive/debian/20250818T025134Z/zzz-dists/trixie-backports/Release
> https://snapshot.debian.org/archive/debian/20250818T025134Z/zzz-dists/trixie-backports-sloppy/Release
> https://snapshot.debian.org/archive/debian/20250818T083758Z/zzz-dists/trixie-proposed-updates/Rel
broken: Picking the most recent timestamp, none of
the following files can be downloaded (404):
https://snapshot.debian.org/archive/debian/20250818T025134Z/zzz-dists/trixie-backports/Release
https://snapshot.debian.org/archive/debian/20250818T025134Z/zzz-dists/trixie-backports-sloppy/Release
https
On Thu, Jul 24, 2025 at 11:28:02AM +0200, frikilinux2 wrote:
not a DD but an autistic user, so maybe it's weird that I'm here but
anyway, I don't see the problem with using AI for 3 reasons:
1. There are concerns about AI detection tools flagging content
generated by autistic people incorrect
it's an important point on
the AI discourse and not sure how this reads.
I'm not subscribed to the list in this email and this is not AI generated.
Thanks for your time,
frikilinux2
On 23/7/25 16:08, Aaron Rainbolt wrote:
On Wed, Jul 23, 2025 at 4:02 AM Lucy wrote:
Dear Debian Deve
Hello,
To people who may wonder why it's so obvious that AI was at the very
least used to "improve" the writing, it already merely comes from the
vocabulary being used:
Lucy, le jeu. 24 juil. 2025 09:16:12 +0200, a ecrit:
> How delightfully ironic
> Your theatrical performance
> you've weaponiz
On Thu, Jul 24, 2025 at 09:16:12AM +0200, Lucy wrote:
>
> What a fascinating display of community dynamics.
[...]
@Lucy: please don't take my disagreement with Marc's tone as
an endorsement of yours. Not by a far stretch.
While I could have interpreted your first post as a genuine
sign of distr
Lucy, le jeu. 24 juil. 2025 09:16:12 +0200, a ecrit:
> @Samuel: Ah yes, "ChatGPT-written polemic."
Your AI is not even able to grasp who said what.
Discussion can only stop here.
Samuel
What a fascinating display of community dynamics.
@GPTZero evangelists: Your algorithm flags coherent prose as artificial.
How delightfully ironic that structured writing triggers your detectors
while actual code quality apparently doesn't.
No AI was involved, but I suppose when mediocrity bec
On Wed, Jul 23, 2025 at 6:49 AM Aurélien COUDERC wrote:
>
>
>
> Le 23 juillet 2025 11:01:36 GMT+02:00, Lucy a écrit :
> >Dear Debian Developers,
>
> Dear Lucy,
>
> for the record to everyone this has already been discussed in #1101759 [1]
> and I declined to do the change discussed here.
Do I hav
On Wed, Jul 23, 2025 at 6:42 AM tomas wrote:
>
> On Wed, Jul 23, 2025 at 11:41:20AM +0200, Marc Haber wrote:
> > Hi,
> >
> > I have noticed that the Cc list is missing the Pope, the President, the
> > Chancellor, the Chairperson of the Central Committee, Udo Lindenberg, Neil
> > Armstrong and Jay L
On Wednesday, July 23, 2025 2:41:20 AM Mountain Standard Time Marc Haber
wrote:
> On Wed, Jul 23, 2025 at 11:01:36AM +0200, Lucy wrote:
> >With the upcoming release of Debian 13 "Trixie", I want to formally
> >raise a critical technical objection to one of the adopted
Le mercredi 23 juillet 2025, 16:08:18 heure d’été d’Europe centrale Aaron
Rainbolt a écrit :
> On Wed, Jul 23, 2025 at 4:02 AM Lucy wrote:
> This shows up as being 98% AI-generated according to GPTZero [1]. If
> this really matters to you, why are you using an AI slop generator to
> write your p
On Wed, Jul 23, 2025 at 4:02 AM Lucy wrote:
>
> Dear Debian Developers,
>
> With the upcoming release of Debian 13 "Trixie", I want to formally raise a
> critical technical objection to one of the adopted upstream changes that
> risks undermining the efficiency,
&
On Jul 23, to...@tuxteam.de wrote:
This is incredibly witty, but really: was it necessary?
Maybe it was not /necessary/ strictly speaking, but it was definitely
entertaining.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Wed, Jul 23, 2025 at 12:36:58PM +0200, Samuel Thibault wrote:
Lucy, you are piling rhetoric over rhetoric, that won't make a fruitful
discussion.
ChatGPT-written polemic emails aren't intended to make a fruitful
discussion. I would be glad if at least people on Debian lists recognized
such
On Wed, Jul 23, 2025 at 11:41:20AM +0200, Marc Haber wrote:
> Hi,
>
> I have noticed that the Cc list is missing the Pope, the President, the
> Chancellor, the Chairperson of the Central Committee, Udo Lindenberg, Neil
> Armstrong and Jay Leno. The Person who has chosen this Cc list obviously
> wa
Hello,
Lucy, you are piling rhetoric over rhetoric, that won't make a fruitful
discussion.
Lucy, le mer. 23 juil. 2025 12:01:59 +0200, a ecrit:
> Debian has never just been “a Linux distro.” It has always stood for
> deliberation, control, and the ability to resist upstream when needed.
That's n
ian Desktop
team.
>With the upcoming release of Debian 13 "Trixie", I want to formally raise a
>critical technical objection to one of the adopted upstream changes that risks
>undermining the efficiency,
>consistency, and user trust that Debian has long upheld:
>
>KDE
Neil Armstrong and Jay Leno. The Person who has chosen
this Cc list obviously wants an Audience. We should not give them that.
That being said,
On Wed, Jul 23, 2025 at 11:01:36AM +0200, Lucy wrote:
With the upcoming release of Debian 13 "Trixie", I want to formally
raise a critical technic
give them that.
That being said,
On Wed, Jul 23, 2025 at 11:01:36AM +0200, Lucy wrote:
With the upcoming release of Debian 13 "Trixie", I want to formally
raise a critical technical objection to one of the adopted upstream
changes that risks undermining the efficiency,
consistency
,
On Wed, Jul 23, 2025 at 11:01:36AM +0200, Lucy wrote:
With the upcoming release of Debian 13 "Trixie", I want to formally
raise a critical technical objection to one of the adopted upstream
changes that risks undermining the efficiency,
consistency, and user trust that Debian has l
good point about
don't think Debian should diverge from upstream KDE's decision on
this.
+1
cheers Ferdinand
/-\
Samuel Thibault schrieb am Mi. 23. Juli 2025 um
11:20:
> Hello,
>
> Lucy, le mer. 23 juil. 2025 11:01:36 +0200, a ecrit:
> > 2. The double-click change is functionally regressiv
On 23/07/2025 11.20, Samuel Thibault wrote:
Hello,
Lucy, le mer. 23 juil. 2025 11:01:36 +0200, a ecrit:
2. The double-click change is functionally regressive
Single-click has been the KDE default for over a decade
I have always found this behavior surprising because on desktop
computers, I'
Hello,
Lucy, le mer. 23 juil. 2025 11:01:36 +0200, a ecrit:
> 2. The double-click change is functionally regressive
>
> Single-click has been the KDE default for over a decade
I have always found this behavior surprising because on desktop
computers, I've only seen it in KDE. And thus I find it
Dear Debian Developers,
With the upcoming release of Debian 13 "Trixie", I want to formally
raise a critical technical objection to one of the adopted upstream
changes that risks undermining the efficiency,
consistency, and user trust that Debian has long upheld:
KDE Plasma 6
ges were either too
young (so they were too late regarding the hard freeze anyway) or almost
ready (so they insta-migrated as soon as I lifted the “udeb freeze”) —
cryptsetup, libpng1.6, lvm2, during the 16:00Z britney run this Friday.
> That being said, the release team has agreed (should it be need
that made sense to have in trixie, some of them
looked like “unimportant” updates that could wait, and I've ignored
them. I haven't been consistent, but you can check debian-boot@ and/or
debian-release@ from the last few hours for some public queries sent to
maintainers/uploaders, as I trie
ucing
packages to wait for your pre-approval before uploading anything
non-urgent to unstable during this period; or is it OK to upload to
unstable, and rely on the block-udeb hints to prevent our packages from
reaching testing at an inconvenient time?
(subject to the usual release team app
Hi Paul,
I used the release notes to upgrade a bookworm system to a trixie system. I
like the new layout of the release notes, thanks for the layout upgrade :-)
Overall it went very well, for the only real issue I run into, I filed a bug
report:
https://bugs.debian.org/cgi-bin/bugreport.cgi
On Sun, Apr 13, 2025 at 10:45:56PM +0200, Rainer Dorsch wrote:
> I am not a Debian developer, therefore I cannot create a pull request for
> fixes
> in the release notes myself,
You absolutely can. One does *not* need to be a Debian Developer to send
patches to the Debian BTS, or
On Wed, Mar 26, 2025 at 12:26:42PM +0530, Sarbjit Singh Sandhu wrote:
Thanks for your suggestion I liked that but can you please help me that how
to use and install debian on approx 20 computers of my schools with the kde
plasma desktop and how to update them every 2 years and also making it user
gt; * TBA- Milestone 4 - Full Freeze
>all packages need a manual unblock for migration
>
> === RC bugs ===
>
> The current list of Release Critical bugs for trixie [3] is
> progressively looking better. Thanks to everybody who is helping
> out. That said,
t; * 2025-04-15 - Milestone 2 - Soft Freeze
>>no new packages, delayed migration
>> * 2025-05-15 - Milestone 3 - Hard Freeze - key packages and packages
>>without autopkgtests need a manual unblock for migration
>> * TBA- Milestone 4 - Full F
/Preseed
> [1]: https://fai-project.org/
> >
> > On Wed, 5 Mar, 2025, 1:45 pm Gard Spreemann, > <mailto:g...@nonempty.org>> wrote:
> >
> >
> > Sarbjit Singh Sandhu > <mailto:sarbjitsinghsandhu...@gmail.com>> writes:
> >
> >
ing to propose the creation of a new Debian branch that
> offers a stable release every year, as opposed to the current 5-year
> cycle.
It's really great to see young people interested in Debian. I do need to
point out that the current cycle has been approximately 2
, 1:45 pm Gard Spreemann, wrote:
>
> Sarbjit Singh Sandhu writes:
>
> > I am writing to propose the creation of a new Debian branch that
> > offers a stable release every year, as opposed to the current 5-year
> > cycle.
>
> It's really great to see young peo
Am Mittwoch, dem 05.03.2025 um 14:38 + schrieb Jeremy Stanley:
> There's also a several-month freeze after taking a snapshot of
> packages from sid before the release occurs, so when an Ubuntu LTS
> release happens the contemporary age of packages in the prior LTS is
> we
On 2025-03-05 10:40:38 + (+), Stephan Verbücheln wrote:
[...]
Ubuntu schedules its LTS release always for April (normal releases
October), because Gnome is always releasing in March and September. So
for Ubuntu LTS users, the age of desktop apps is up to two years.
[...]
Not really
cantly older.
For example, the Bookworm freeze started in January 2023, so the
desktop apps are based on the Gnome release of September 2022. When
Trixie will be released, the apps in Bookworm will be almost three
years old. This is where average users feel the age.
Ubuntu schedules its LTS release
Sarbjit Singh Sandhu writes:
> I am writing to propose the creation of a new Debian branch that
> offers a stable release every year, as opposed to the current 5-year
> cycle.
It's really great to see young people interested in Debian. I do need to
point out that the current
> In my opinion, the better solution would be to have more backports in
> the stable release because people are mostly unhappy with outdated apps
> and not with outdated essential core components.
What about the project to automatically build backports around janitor ?
What is the statu
In my opinion, the better solution would be to have more backports in
the stable release because people are mostly unhappy with outdated apps
and not with outdated essential core components.
This would probably not even require a policy change in Debian. But it
requires a lot of people with a lot
Andrey Rakhmatullin writes:
Unfortunately, while proposing is cheap, actually *doing* this
is somewhat harder. So unless you, and a suitable number of
other people, are ready to work on this, this won't happen.
A more realistic goal might be to increase the number of packages
in the backpo
On Tue, Mar 04, 2025 at 02:12:05PM +0530, Sarbjit Singh Sandhu wrote:
Dear Debian Developers,
I am writing to propose the creation of a new Debian branch that offers a
stable release every year, as opposed to the current 5-year cycle. This
would be particularly beneficial for educational
Dear Debian Developers,
I am writing to propose the creation of a new Debian branch that offers a
stable release every year, as opposed to the current 5-year cycle. This
would be particularly beneficial for educational institutions, where a
balance between stability and up-to-date software is
On 28/01/2025 12:37, Frank Guthausen wrote:
On Tue, 28 Jan 2025 09:34:37 +0100
Emilio Pozuelo Monfort wrote:
On 27/01/2025 23:15, Andrea Bolognani wrote:
https://release.debian.org/trixie/freeze_policy.html
Updated
Almost - there are still the first three TBAs in the 2nd table row.
On Tue, 28 Jan 2025 09:34:37 +0100
Emilio Pozuelo Monfort wrote:
> On 27/01/2025 23:15, Andrea Bolognani wrote:
> >
> >https://release.debian.org/trixie/freeze_policy.html
>
> Updated
Almost - there are still the first three TBAs in the 2nd table row.
--
kind regards
Frank
pgpFVLmM08Tzp.
On 27/01/2025 23:15, Andrea Bolognani wrote:
On Wed, Jan 22, 2025 at 11:00:00PM +0100, Emilio Pozuelo Monfort wrote:
Trying to follow our release cadence, we are going to start freezing
trixie in March. As usual, it is our intention to have a short freeze,
though with the short notice that may
On Wed, Jan 22, 2025 at 11:00:00PM +0100, Emilio Pozuelo Monfort wrote:
> Trying to follow our release cadence, we are going to start freezing
> trixie in March. As usual, it is our intention to have a short freeze,
> though with the short notice that may be hard. We apologiz
Package: release-notes
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org, gib...@debian.org
TL;DR -- It is expected that trixie will be the last release of
Debian to include LXD, and users are encouraged to migrate to Incus
after upgrading.
(CC'ing debian-devel for br
On Sun, Mar 03, 2024 at 09:25:41PM +0100, hwspeedy wrote:
> Hi Simon Quiqley, (CC: debian-devel)
>
> I'm trying to figure out how to get the hardinfo2 - release 2.0.12 into
> debian repository.
> hardinfo2 is a community fork of hardinfo and should continue as hardinfo
Hi Simon Quiqley, (CC: debian-devel)
I'm trying to figure out how to get the hardinfo2 - release 2.0.12 into
debian repository.
hardinfo2 is a community fork of hardinfo and should continue as
hardinfo package, currently maintained in debian by Simon Quiqley.
Salvo Tomaselli suggested
Hi Simon Quigley, Debian Maintainer, (CC: debian-devel list)
We are proud to suggest new hardinfo2 release 2.0.12 to be included in
debian repositories - test on debian 7 - SID(13).
https://github.com/hardinfo2/hardinfo2/releases/tag/release-2.0.12
PS: My first release, so please guide me
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-k8s-sigs-release-utils
Version : 0.7.7-1
Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/release-utils
* License : Apache-2.0
Programming Lang: Go
Hi
On 18-12-2023 11:29, Santiago Vila wrote:
El 17/12/23 a las 22:40, Steven Robbins escribió:
Does that mean ceasing the "ITP" messages in debian-devel?
I'd certainly welcome that!
I think he really meant debian-release, as this was "Bits from
the Release Team"
Hi,
On 18-12-2023 13:18, Antonio Terceiro wrote:
Will reproducibility regressions block migration to testing?
Not for the near future for 2 reasons:
1) contrary to autopkgtest where removal of the test "fixes" regression,
it feels that currently blocking on regression would give maintainers
On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote:
> Reproducibility migration policy
>
>
> The folks from the Reproducibility Project have come a long way since they
> started working on it 10 years ago, and we believe it's time for the next step
> in De
On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote:
> During the wonderful mini-DebConf at Cambridge, the Release Team had a sprint
> and other discussions. Some of the discussed topics are worth sharing, so here
> we go.
[...]
> Reproducibility migr
already archives all information, and there are
multiple ways anyone can subscribe to the Release Team bugs, so this
mirroring seems unnecessary. More importantly it inhibits the list from
being a more useful discussion channel that we like it to be. Hence, we'll
try to work with the BTS maintaine
there are
> multiple ways anyone can subscribe to the Release Team bugs, so this
> mirroring seems unnecessary. More importantly it inhibits the list from
> being a more useful discussion channel that we like it to be. Hence, we'll
> try to work with the BTS maintainers to direct the tra
Matthew Garrett writes:
> On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
>
>> qemu is basically an interpreter for foreign machine code. If your
>> threat model allows access to qemu-user-static for an attacker, they
>> can run pretty much any binary is if it were native, and the w
Hi,
* Colin Watson [2023-07-14 11:50]:
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote:
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> qemu is basically an interpreter for foreign machine code. If your
> threat model allows access to qemu-user-static for an att
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote:
> On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> > qemu is basically an interpreter for foreign machine code. If your
> > threat model allows access to qemu-user-static for an attacker, they
> > can run pretty much an
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
> qemu is basically an interpreter for foreign machine code. If your
> threat model allows access to qemu-user-static for an attacker, they
> can run pretty much any binary is if it were native, and the whole
> SystemCallArchitectures h
* Guillem Jover [2023-07-13 19:36]:
The same would apply to any other interpreted program, as long as the
interpreter matches the systemd native architecture.
This, by the way, includes the following scenario:
* Trent W. Buck [2023-07-06 10:41]:
dpkg --add-architecture arm64
apt updat
Hi!
On Thu, 2023-07-06 at 18:41:38 +1000, Trent W. Buck wrote:
> "Trent W. Buck" writes:
> > e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> > people (anyone doing dpkg --add-architecture)
Yes, see #982456.
> Short version:
>
> • SystemCallArchitectures=native + debian
On Sun, 2023-07-09 at 18:02 +0100, Luca Boccassi wrote:
> Note that we already have such a package in the archive: dbus-broker.
> It has been the default in Fedora for a long time, and it will be the
> default in Ubuntu in the future. It has been available in Debian since
> Bullseye - please help
On Thu, 6 Jul 2023 at 09:42, Trent W. Buck wrote:
>
> "Trent W. Buck" writes:
> > e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> > people (anyone doing dpkg --add-architecture)
>
> Short version:
>
> • SystemCallArchitectures=native + debianutils:i386 doesn't break
> dp
s
> package build a variant that doesn't support traditional activation (for
> use on systemd-only systems), and a variant that does (for use on other
> systems). Then, we could work towards ensuring every D-Bus service
> supports service-based activation rather than only tradition
"Trent W. Buck" writes:
> e.g. I expect "SystemCallArchitectures=native" to break for a lot of
> people (anyone doing dpkg --add-architecture)
Short version:
• SystemCallArchitectures=native + debianutils:i386 doesn't break
dpkg-db-backup.service.
• Probably savelog simply never calls an AR
Russ Allbery writes:
> "Trent W. Buck" writes:
>
>> As someone who does that kind of thing a lot, I'd rather have
>> the increased annoyance of opt-out hardening than
>> the reduced security of opt-in hardening.
>> Even if it means I occasionally need to patch site-local rules into
>> /etc/appar
"Trent W. Buck" writes:
> As someone who does that kind of thing a lot, I'd rather have
> the increased annoyance of opt-out hardening than
> the reduced security of opt-in hardening.
> Even if it means I occasionally need to patch site-local rules into
> /etc/apparmor.d/local/usr.bin.msmtp or
>
Russ Allbery writes:
> [⋯]
> We know which PAM modules are installed and
> can analyze the PAM configuration files to know which ones are configured.
> We know which daemons use PAM.
> We similarly know which NSS modules are enabled.
> We can figure out what facilities they require, and could
> a
Philipp Kern writes:
> On 2023-07-05 09:36, Russell Coker wrote:
>> On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
>>> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
> My fear here would be that you are not in control of what your
> dependencies are doing. This is especia
||
|We would also like to reveal the codename of Debian 15, which will be
"Buttercup". This name follows the tradition of naming Debian releases
after characters from the Toy Story movies. We hope you like it and
look forward to your contributions to make Debian 15 another grea
On Wed, Jul 05, 2023 at 11:05:05PM +0200, Joaquín Rufo Gutierrez wrote:
> No, Debian 13 will be released on 2024 occasionally.
Who are you, sorry?
The person who sent this "announcement" doesn't seem to be part of the
Debian Project, they're also not listed as a member of the release
team at https://www.debian.org/intro/organization
Someone from the release team might confirm my assumption, but for now
please assume
Il 05/07/2023 22:50, Joaquín Rufo Gutierrez ha scritto:
|Hello Debian users, We are happy to announce that Debian 13,
codenamed "Trixie", is expected to be released sometime in 2024,
following the usual 2-year release cycle.|
|
|
|Hi, sorry but if it were |||2-year release cycle |
rixie", is
> > expected to be released sometime in 2024, following the usual 2-year
> > release cycle.
>
> Bookworm was released in 2023. The usual 2-year release cycle would put
> the next Debian to be released some time in 20*25*?
>
> Mike
>
On Wed, Jul 05, 2023 at 10:50:34PM +0200, Joaquín Rufo Gutierrez wrote:
> Hello Debian users,
>
> We are happy to announce that Debian 13, codenamed "Trixie", is
> expected to be released sometime in 2024, following the usual 2-year
> release cycle.
Bookworm was rele
Hello Debian users,
We are happy to announce that Debian 13, codenamed "Trixie", is
expected to be released sometime in 2024, following the usual 2-year
release cycle. The exact release date will depend on the progress of
testing and bug fixing, but we will keep you updated on the
d
Philipp Kern writes:
> My fear here would be that you are not in control of what your
> dependencies are doing. This is especially true if you think of NIS and
> PAM, where libraries are dlopen()ed and can spawn arbitrary helper
> binaries. I remember openssh installing a syscall filter for its a
On 2023-07-05 09:36, Russell Coker wrote:
On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
People have asked how hard it is to create policy for daemons. For an
individual to create them it's a moderate amount of work, 1-2 h
On Monday, 3 July 2023 22:37:35 AEST Russell Coker wrote:
> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
People have asked how hard it is to create policy for daemons. For an
individual to create them it's a moderate amount of work, 1-2 hours per daemon
which is a lot considering
Marco d'Itri writes:
> This is a good example of what an almost fully sandboxed service looks like:
> https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service
My best score is a little better :-)
On Debian 11 (systemd v247):
→ Overall exposure level for collection4.servic
Marco d'Itri writes:
> On Jul 04, Andrey Rakhmatullin wrote:
>
>> Cool but looks like a lot of work.
[...]
>> start with applying all of them and then looking what needs to be
>> disabled?
> This is what I do.
FYI below is my basic workflow.
Once you've done 2-5 daemons, you get a "feel" for
Marco d'Itri writes:
> On Jul 04, "Trent W. Buck" wrote:
>
>> * If it runs its own process manager (e.g. postfix's "master"),
>> don't bother trying to harden it.
> I disagree. It may not be possible to use NoNewPrivileges, but at least
> file system hardening is usually trivial to enable
On Jul 04, Andrey Rakhmatullin wrote:
> Cool but looks like a lot of work.
I do not think that this is really a lot of work.
> Is it possible to do this without
> applying the flags one by one and testing the result? Is it easier to
You may intimately know what the daemon needs to do and how the
On Mon, Jul 03, 2023 at 11:40:18PM +0200, Marco d'Itri wrote:
> This is a good example of what an almost fully sandboxed service looks
> like:
>
> https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service
Cool but looks like a lot of work. Is it possible to do this without
On Jul 04, "Trent W. Buck" wrote:
> * If it runs its own process manager (e.g. postfix's "master"),
> don't bother trying to harden it.
I disagree. It may not be possible to use NoNewPrivileges, but at least
file system hardening is usually trivial to enable for most daemons.
> * If it
a variant that does (for use on other
systems). Then, we could work towards ensuring every D-Bus service
supports service-based activation rather than only traditional
activation. Over the course of a release cycle or so, we *could* get to
the point of being able to lock down D-Bus on systemd systems.
RL writes:
> Russell Coker writes:
>
>> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
>>
>> I think we should make it a release goal to have as many daemons as
>> possible running with systemd security features to aim for a low score
>> from &
Hi,
Jonathan Carter (2023-07-03):
> One shouldn't trust everything that is read on Matrix. I suggest asking
> the release team for clarification, because my last understanding is
> that release goals still exist, it's just that the release team doesn't
> want to be t
boxing,
considering that it is so easy with systemd.
I am not sure if it can be a release goal, but it definitely should be
a best practice.
This is a good example of what an almost fully sandboxed service looks
like:
https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.s
On Mon, 03 Jul 2023 at 20:21:20 +0100, RL wrote:
> (One of the issues for services that send email is that it is very
> easy to break exim)
It's also very easy to break anything else that relies on running a
setuid/setgid/setcap executable (including many mail delivery agents,
not just Exim), as t
On 2023-07-03 14:21, RL wrote:
Russell Coker writes:
https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
I think we should make it a release goal to have as many daemons as
possible running with systemd security features to aim for a low score
from "systmd- analyze security&q
Russell Coker writes:
> https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity
>
> I think we should make it a release goal to have as many daemons as
> possible running with systemd security features to aim for a low score
> from "systmd- analyze security".
This
Hi Russell
On 2023/07/03 14:37, Russell Coker wrote:
Someone said on Matrix that we aren't going to have official release goals in
future.
One shouldn't trust everything that is read on Matrix. I suggest asking
the release team for clarification, because my last understandin
1 - 100 of 5814 matches
Mail list logo
