Hi again,
Am Sun, Apr 07, 2024 at 04:10:15PM +0200 schrieb Wouter Verhelst:
> >
> > What is your opinion about pushing logtool to Salsa?
>
> I did that as part of my latest upload :)
>
> https://salsa.debian.org/wouter/logtool
Great.
> (I realize now that I forgot to add VCS headers... ah
On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
> Hi Wouter,
>
> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > [Feel free to quote any part of this email which I wrote outside of this
> > mailinglist]
>
> OK, moving the discussion to debian-devel where it
Hi Wouter,
Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> [Feel free to quote any part of this email which I wrote outside of this
> mailinglist]
OK, moving the discussion to debian-devel where it should belong.
> Debian packages need to be well maintained. In some cases,
On Sun, 7 Apr 2024 13:26:49 +0200
José Luis González wrote:
> The maintainer accumulates a lot of bugs for the package, doesn't take
> care about almost all, and when I filed a RC bug because the package
> became unusable to me he downgraded severity to important claiming it
> was just a Gmail
ing as the correct persona as mutt does guess who to send as, but it
does not always get it right. Has it led to me sending emails with the
wrong sender? Yep. And I apologise when it happens and move on, re-rending
with the correct sender.
I do not consider this to be a defect in mutt as mutt ha
On Apr 07, José Luis González wrote:
> I want to know why Debian 12 was released with those two Sylpheed RC
> bags, report the incident to you all, know what to do with the
> maintainer and kindly request that someone better at the job takes over
> Sylpheed maintainance, or otherwise I will
On Sun, 7 Apr 2024 13:26:49 +0200
José Luis González wrote:
> Debian 12 was released with two Release Critical bugs I filed on May
> 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I
> found on stable, and remain, with Debian 12 released later on June 10th
> 2023.
Those are not
Hello,
On Sat 06 Apr 2024 at 02:24pm +02, Guillem Jover wrote:
> Hi!
>
> On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote:
>> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>> > Right now the preferred form of source in Debian is an upstream-signed
>> > release tarball, NOT
Hello,
On Sat 06 Apr 2024 at 02:42pm +03, Adrian Bunk wrote:
> On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote:
>> Hello,
>>
>> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>>
>> >
>> > Right now the preferred form of source in Debian is an upstream-signed
>> > release
On Thu, 2024-04-04 at 01:01 -0700, John Lee wrote:
> I just wondered if I can sell computers that I build with Debian
> Linux pre-installed. The computers may also include programs I
> create. I tried to find the answer to this question but still
> unsure.
In addition to the other response you
* License : GPL, LGPL, BSD, MIT, CC0
Programming Lang: C++
Description : Library for rendering SVG-based themes with stylesheet
re-coloring and on-disk caching
KSvg provides both C++ classes and QtQuick components to render svgs based
on image packs. Compared to plain QSvg, it caches
Hey.
Seems some of the reverse engineers may have found some more
interesting stuff[0].
As far as I understand it, that would still require a running an
reachable sshd (so we'd still be mostly safe).
But he also thinks[1] that it may allow an interactive session.
(Not that this would change a
Hello,
Michael Shuler wrote on 06/04/2024 at 16:31:28+0200:
> On 4/5/24 10:30, Pierre-Elliott Bécue wrote:
>> Pierre-Elliott Bécue wrote on 31/03/2024 at 14:31:37+0200:
>>> Wookey wrote on 31/03/2024 at 04:34:00+0200:
>>>
On 2024-03-30 20:52 +0100, Ansgar wrote:
> Yubikeys,
On Sat, Apr 06, 2024 at 06:32:47PM +0200, Bastian Germann wrote:
> Am 06.04.24 um 18:29 schrieb Colin Watson:
> > There might be some small errors in this, but I couldn't see any when
> > eyeballing the resulting uniquified list of Maintainer fields. It looks
> > like 78% of source packages in
Am 06.04.24 um 18:29 schrieb Colin Watson:
There might be some small errors in this, but I couldn't see any when
eyeballing the resulting uniquified list of Maintainer fields. It looks
like 78% of source packages in unstable are team-maintained, which can't
reasonably be called an "exception".
On 2024-04-06 16:30:44 +0100 (+0100), Simon McVittie wrote:
[...]
> Indeed, if upstream does ship generated files in addition to the actual
> source code, we have traditionally said that Debian package maintainers
> "should, except where impossible for legal reasons, preserve the entire
> building
On Sat, 06 Apr 2024 at 15:54:51 +0200, kpcyrd wrote:
> On 4/6/24 1:42 PM, Adrian Bunk wrote:
> > You cannot simply proclaim that some git tree is the preferred form of
> > modification without shipping said git tree in our ftp archive.
> >
> > If your claim was true, then Debian and downstreams
On Sat, Apr 06, 2024 at 01:46:28AM +0200, Debian Project Secretary - Kurt
Roeckx wrote:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 9c605edd-40a5-469c-9489-cbf80ac05970
> [1] Choice 1: Andreas Tille
> [2] Choice 2: Sruthi Chandran
> [ ] Choice 3: None Of The
On Sat, Apr 06, 2024 at 03:54:51PM +0200, kpcyrd wrote:
>...
> autotools pre-processed source code is clearly not "the preferred form of
> the work for making modifications", which is specifically what I'm saying
> Debian shouldn't consider a "source code input" either, to eliminate this
> vector
On 4/5/24 10:30, Pierre-Elliott Bécue wrote:
Pierre-Elliott Bécue wrote on 31/03/2024 at 14:31:37+0200:
Wookey wrote on 31/03/2024 at 04:34:00+0200:
On 2024-03-30 20:52 +0100, Ansgar wrote:
Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
Possibly also TPM modules in
On 4/6/24 1:42 PM, Adrian Bunk wrote:
You cannot simply proclaim that some git tree is the preferred form of
modification without shipping said git tree in our ftp archive.
If your claim was true, then Debian and downstreams would be violating
licences like the GPL by not providing the
Hi!
On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote:
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
>
> The preferred form of modification is not simply up for
On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote:
> Hello,
>
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>
> >
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
>
> The preferred form of modification is
d artifacts.
I think your proposal is good at providing provenance for the subset of files
that originate from VCS; what I'm not sure it provides is confirmation about
how to confirm regeneration of the remainder of the dist files.
Another way to think about it is: let's say you _do_ attempt to reg
Hello,
On Fri 05 Apr 2024 at 03:19pm +01, Simon McVittie wrote:
> There are basically three dgit-compatible workflows, with some minor
> adjustments around handling of .gitignore files:
>
> - "patches applied" (git-debrebase, etc.):
> This is the workflow that proponents of dgit sometimes
Hello,
On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>
> Right now the preferred form of source in Debian is an upstream-signed
> release tarball, NOT anything from git.
The preferred form of modification is not simply up for proclamation.
Our practices, which are focused around git,
On Apr 05, Simon McVittie wrote:
> I find that having the upstream source code in git (in the same form that
> we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> but excluding any files that we exclude by repacking) is an extremely
> useful tool, because it lets me
code
> did, an analysis of how the data was hidden in the 'corrupt' xz archive
> under testing and some analysis of the actual .o which suggested this was
> not just a backdoor but a remote-code-execution portal almost.
I've also tried to follow the various lists and RE efforts on dis
There's also a very through exploration at https://github.com/amlweems/xzbot
Including, very interestingly, a discussion of format(s) of the
payload(s), and a mechanism to replace the backdoor key to play with
executing commands against a popped sshd, as well as some code to go
along with it.
In days of yore (Fri, 05 Apr 2024), Daniel Leidert thus quoth:
> Am Freitag, dem 29.03.2024 um 23:20 +0100 schrieb Moritz Mühlenhoff:
> > 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
Am Freitag, dem 29.03.2024 um 23:20 +0100 schrieb Moritz Mühlenhoff:
> 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
Pierre-Elliott Bécue wrote on 31/03/2024 at 14:31:37+0200:
> Wookey wrote on 31/03/2024 at 04:34:00+0200:
>
>> On 2024-03-30 20:52 +0100, Ansgar wrote:
>>> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
>>> Possibly also TPM modules in computers.
>>>
>>> These can usually
On Fri, 5 Apr 2024 at 16:18, Colin Watson wrote:
>
> On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote:
> > I find that having the upstream source code in git (in the same form that
> > we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> > but excluding any
On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote:
> I find that having the upstream source code in git (in the same form that
> we use for the .orig.tar.*, so including Autotools noise, etc. if present,
> but excluding any files that we exclude by repacking) is an extremely
> useful
On Sat, 30 Mar 2024 at 14:16:21 +0100, Guillem Jover wrote:
> in my mind this incident reinforces my view that precisely storing
> more upstream stuff in git is the opposite of what we'd want, and
> makes reviewing even harder, given that in our context we are on a
> permanent fork against
Hi Attila,
On Fri, 2024-04-05 at 09:47 +0100, Attila Szalay wrote:
> Based on https://wiki.debian.org/NonMaintainerUpload, the binNMU
> should
> be careful
I think you are confusing binNMUs and NMUs.
See https://wiki.debian.org/binNMU
They are handled more or less automatic as soon as a rebuild
Am 05.04.24 um 12:31 schrieb John Paul Adrian Glaubitz:
Hello,
On Tue, 2024-04-02 at 12:40 +0200, Pierre-Elliott Bécue wrote:
If at all, this whole situation is a plea to finally end single-person
maintainership of packages.
It is my opinion that all packages should be either in collab maint
Hi!
On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote:
> On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote:
> > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote:
> > > On 2024-03-29 22:41, Guillem Jover wrote:
> > > I think with my upstream hat on I'd rather ship a clear manifest
Hello Steve,
I do understand your concern about the time_t structure change and I
also admit that there are some room of improvement how the syslog-ng
package manage the library versioned dependency, but this is not the
solution.
Based on https://wiki.debian.org/NonMaintainerUpload, the binNMU
On Fri, Apr 05, 2024 at 01:30:51AM +0200, kpcyrd wrote:
> On 4/5/24 12:31 AM, Adrian Bunk wrote:
> > Hashes of "git archive" tarballs are anyway not stable,
> > so whatever a maintainer generates is not worse than what is on Github.
> >
> > Any proper tooling would have to verify that the
On 4/5/24 12:31 AM, Adrian Bunk wrote:
Hashes of "git archive" tarballs are anyway not stable,
so whatever a maintainer generates is not worse than what is on Github.
Any proper tooling would have to verify that the contents is equal.
...
Being able to disregard the compression layer is still
On Fri, Apr 05, 2024 at 01:31:25AM +0300, Adrian Bunk wrote:
> On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote:
> >...
> > I've checked both, upstreams github release page and their website[1], but
> > couldn't find any mention of .tar.xz, so I think my claim of Debian doing
> > the
On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote:
>...
> I've checked both, upstreams github release page and their website[1], but
> couldn't find any mention of .tar.xz, so I think my claim of Debian doing
> the compression is fair.
>
> [1]: https://www.vim.org/download.php
>...
Perhaps
On Thu, Apr 04, 2024 at 06:42:08PM -0300, Henrique de Moraes Holschuh wrote:
> If libwrap is bringing in complex libs, maybe we could reduce the
> attack surface on libwrap itself? It would be nice to have a variant
> that only links to the libc and that's it...
Yeah, that's
On Tue, Apr 2, 2024, at 07:04, Marco d'Itri wrote:
> On Apr 02, Colin Watson wrote:
>
>> At the time, denyhosts was popular, but it was removed from Debian
>> several years ago. I remember that, when I dealt with that on my own
>> systems, fail2ban seemed like the obvious replacement, and my
On 2024-04-04 21:39:51 +0200 (+0200), kpcyrd wrote:
[...]
> I don't know if Debian has this kind of provenance information available, to
> my knowledge, Debian operates on "our maintainers upload .tar.xz files into
> our archive and we take them for face value". Which does make sense,
>
On 4/3/24 4:21 AM, Adrian Bunk wrote:
On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
...
I figured out a somewhat straight-forward way to check if a given `git
archive` output is cryptographically claimed to be the source input of a
given binary package in either Arch Linux or Debian
On Thu, 4 Apr 2024 13:25:04 +0200, Stephan Seitz
wrote:
>Am Di, Apr 02, 2024 at 13:30:43 +0200 schrieb Marc Haber:
>>from being vulnerable to the current xz-based attack. Just having to
>>dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to
>>maintain a packet filter.
>
>Stupid
Florian Lohoff writes:
> These times have long gone and tcp wrapper as a security mechanism has
> lost its reliability, this is why people started moving away from tcp
> wrapper (which i think is a shame)
> I personally moved to nftables which is nearly as simple once you get
> your muscle
On 3/25/24 19:17, Julian Gilbey wrote:
Hi all,
[NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to
set to d-science and the RFP bug only]
An update on Apache Arrow, and in particular the Python library
PyArrow. For those who don't know:
Apache Arrow is a development
On Thu, Apr 04, 2024 at 01:32:11PM +0200, Marc Haber wrote:
> So you have dedicated packet filters on every machine you run, even if
> sshd is the only network-facing service?
on most machines and it was as simple as doing:
apt install ufw
ufw allow ssh
ufw enable
voila, done. rules configured
On Thu, 4 Apr 2024 13:03:50 +0200, Florian Lohoff wrote:
>I personally moved to nftables which is nearly as simple once you get
>your muscle memory set.
So you have dedicated packet filters on every machine you run, even if
sshd is the only network-facing service?
Greetings
Marc
--
Am Di, Apr 02, 2024 at 13:30:43 +0200 schrieb Marc Haber:
from being vulnerable to the current xz-based attack. Just having to
dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to
maintain a packet filter.
Stupid question, but if you put „ALL: ALL” into hosts.deny, couldn’t
On Tue, Apr 02, 2024 at 01:30:43PM +0200, Marc Haber wrote:
> On Tue, 2 Apr 2024 01:30:10 +0100, Colin Watson
> wrote:
> >We carry a patch to restore support for TCP wrappers, which was dropped
> >in OpenSSH 6.7 (October 2014); see
>
Hi
John Lee wrote on 04/04/2024 at 10:01:48+0200:
> Hello Debian Team,
>
> I just wondered if I can sell computers that I build with Debian Linux
> pre-installed. The computers may also include programs I create. I
> tried to find the answer to this question but still unsure.
>
> If you need
On 3/25/24 7:17 PM, Julian Gilbey wrote:
So this is a plea for anyone looking for something really helpful to
do: it would be great to have a group of developers finally package
this! There was some initial work done (see the RFP bug report for
details:
Hi Guillem,
On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote:
> On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote:
> > On 2024-03-29 22:41, Guillem Jover wrote:
> > I think with my upstream hat on I'd rather ship a clear manifest (checked
> > into Git) that tells distributions which files
On Wed, Apr 03, 2024 at 04:01:34PM -0400, Michael Stone wrote:
> To speed things up for those who really want it, perhaps make
> openssh-client/server dependency-only packages on
> openssh-client/server-nogss? People can choose the less-compatible version
> for this release if they want to, and
On Tue, Apr 02, 2024 at 01:30:10AM +0100, Colin Watson wrote:
* add dependency-only packages called something like
openssh-client-gsskex and openssh-server-gsskex, depending on their
non-gsskex alternatives
* add NEWS.Debian entry saying that people need to install these
packages
Hi!
On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote:
> On 2024-03-29 22:41, Guillem Jover wrote:
> > (For dpkg at least I'm pondering whether to play with switching to
> > doing something equivalent to «git archive» though, but see above, or
> > maybe generate two tarballs, a plain «git
On Wed, Apr 03, 2024 at 04:38:19PM +0200, Marc Haber wrote:
> On Wed, 03 Apr 2024 14:10:37 +0100, "Jonathan Dowland"
> wrote:
> >For you and fellow greybeards, perhaps: I'd be surprised if many people
> >younger than us have even heard of tcp wrappers. I don't think the
> >muscle memory of a
On Wed, 03 Apr 2024 14:10:37 +0100, "Jonathan Dowland"
wrote:
>On Tue Apr 2, 2024 at 12:30 PM BST, Marc Haber wrote:
>> Please don't drop the mechanism that saved my¹ unstable installations
>> from being vulnerable to the current xz-based attack. Just having to
>> dump an ALL: ALL into
On Tue Apr 2, 2024 at 12:30 PM BST, Marc Haber wrote:
> Please don't drop the mechanism that saved my¹ unstable installations
> from being vulnerable to the current xz-based attack. Just having to
> dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to
> maintain a packet filter.
On Fri, Mar 29, 2024 at 09:09:45PM +0100, Sirius wrote:
> 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.
FWIW, just
On Wed, Apr 03, 2024 at 02:01:23AM -0400, Robert Edmonds wrote:
> This backdoor abused the IFUNC mechanism in the GNU toolchain to hook into
> the sshd process. Looking on my Debian sid workstation with about 1900 library
> packages installed, I see a very small handful of source packages shipping
This backdoor abused the IFUNC mechanism in the GNU toolchain to hook into
the sshd process. Looking on my Debian sid workstation with about 1900 library
packages installed, I see a very small handful of source packages shipping
libraries with IFUNC symbols, mostly things like gcc, glibc, haskell,
On Wed, Apr 03, 2024 at 02:31:11AM +0200, kpcyrd wrote:
>...
> I figured out a somewhat straight-forward way to check if a given `git
> archive` output is cryptographically claimed to be the source input of a
> given binary package in either Arch Linux or Debian (or both).
For Debian the proper
On Mon, 1 Apr 2024 at 19:28, Vincent Bernat wrote:
>
> On 2024-04-01 18:05, Jonathan Carter wrote:
> > The included firmware contributed to Debian 12 being a huge success,
> > but it wasn't the only factor.
>
> Unfortunately, the shipped firmwares are now almost a year old,
> including for
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 correct version number from Git in all cases.
[...]
Some tools (python3-reno, for example) want to inspect the commits
and historical
On 2024-04-03 00:33:47 +0200 (+0200), Thomas Goirand wrote:
[...]
> Also, sdists are *not* "upstream-created source tarballs". I
> consider the binary form built for PyPi. Just like we have .debs,
> PyPi has tarballs and wheels, rather than how you describe them.
[...]
Upstream in OpenStack we
Stefano Rivera writes:
> Then you haven't come across any that are using this mechanism to
> install data, yet. You're only seeing the version determination. You
> will, at some point run into this problem. It's getting more popular.
Yup, we use this mechanism heavily at work, since it avoids
Hi Thomas (2024.04.02_22:33:47_+)
> Anyways, on the 400+ packages that I maintain within the OpenStack team, I
> did come across some upstream using setuptools-scm. To my experience, using
> the:
>
> git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
> | xz
On 3/30/24 08:02, Gioele Barabucci wrote:
For too many core packages there is an opaque "something happens on the
Debian maintainer laptop" step that has no place in 2024.
Let's replace this by an opaque "something happens on the Salsa CI".
Cheers,
Thomas Goirand (zigo)
On 4/1/24 00:32, Stefano Rivera wrote:
So... for Python packages using setuptools-scm, we're pushed towards
depending on upstream-created source tarballs (sdists), rather than
upstream git archives, because we don't have the ".git" directory in our
source packages.
Hi Stefano,
Thanks for
On Tue, Apr 2, 2024 at 5:12 PM Pierre-Elliott Bécue wrote:
> If you have a master key on your laptop, when a yubikey is in, while
> running gpg --edit-key your_main_key, you can use the "addcardkey" to
> create a subkey on the Yubikey directly.
>
Yeah, seconded for sure. This is the
PICCA Frederic-Emmanuel
writes:
> One missing piece for me in order to migrate to meson is the integration
> between flymake and the autotools.
>
> https://www.emacswiki.org/emacs/FlyMake#h5o-7
>
There is an unofficial Meson LSP[1]. Maybe it can be configured with
Eglot or lsp-mode.
--
Iustin Pop wrote on 01/04/2024 at 12:29:59+0200:
> On 2024-03-31 22:23:10, Arto Jantunen wrote:
>> Didier 'OdyX' Raboud writes:
>>
>> > Le dimanche, 31 mars 2024, 14.37:08 h CEST Pierre-Elliott Bécue a écrit :
>> >> I would object against creating a PGP key on the HSM itself. Not having
>> >>
Le lundi, 1 avril 2024, 19.41:45 h CEST Andrey Rakhmatullin a écrit :
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often
On Tue, Apr 02, 2024 at 08:20:31PM +0300, Adrian Bunk wrote:
> On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote:
> > On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> > > Does gnulib upstream support upgrading/downgrading the gnulib m4 files
> > > (like the one used in the
On 2024-04-02 11:05, Russ Allbery wrote:
Meson honestly sounds great, and I personally love the idea of using a
build system whose language is a bit more like Python, since I use that
language professionally anyway. (It would be nice if it *was* Python
rather than yet another ad hoc language,
Andrey Rakhmatullin dijo [Mon, Apr 01, 2024 at 10:41:45PM +0500]:
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often not
One missing piece for me in order to migrate to meson is the integration
between flymake and the autotools.
https://www.emacswiki.org/emacs/FlyMake#h5o-7
On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote:
> On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> > On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
> > > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> > > > This seems like a serious bug in
On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
> > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> > > This seems like a serious bug in autoreconf, but I've not checked if
> > > this has been brought up
On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
>...
> On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
>...
> > This seems like a serious bug in autoreconf, but I've not checked if
> > this has been brought up upstream, and whether they consider it's
> > working as
Adrian Bunk writes:
> On Mon, Apr 01, 2024 at 11:17:21AM -0400, Theodore Ts'o wrote:
>> Yeah, that too. There are still people building e2fsprogs on AIX,
>> Solaris, and other legacy Unix systems, and I'd hate to break them, or
>> require a lot of pain for people who are building on MacPorts,
On Mon, Apr 01, 2024 at 11:17:21AM -0400, Theodore Ts'o wrote:
> On Sat, Mar 30, 2024 at 08:44:36AM -0700, Russ Allbery wrote:
>...
> > Yes, perhaps it's time to switch to a different build system, although one
> > of the reasons I've personally been putting this off is that I do a lot of
> >
Colin Watson writes:
> GSS-API key exchange
>
> However, OpenSSH upstream has long rejected it
> All the same, I'm aware that some people now depend on having this
> facility in Debian's main openssh package
> How does this rough plan sound?
>
> * for Debian trixie
f 9/11 of Linux distros. Everyone knew it could have
happened, but now that it has and we see how relatively easy it was I
think it's time to re-evaluate things. I now do not think anymore that
sid is secure enough for high-profile targets such as DDs. All it takes
is one bad upload, and your s
On Tue, 2 Apr 2024 01:30:10 +0100, Colin Watson
wrote:
>We carry a patch to restore support for TCP wrappers, which was dropped
>in OpenSSH 6.7 (October 2014); see
>https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
>and thread. That wasn't long before the Debian 8
Hello
J’ai l’impression que vous vous êtes trompé de canal.
Cet outil a t’il un lien avec Debian ou packages annexes à Debian ??
On Tue 2 Apr 2024 at 13:30, Ghislain Pierrat wrote:
> Bonjour ,
> En tant qu’utilisateur de produit APPLE , j’utilise le gestionnaire de mot
> de passe TROUSSEAU
> Je
On 4/2/24 15:03, Ghislain Pierrat wrote:
Bonjour ,
En tant qu’utilisateur de produit APPLE , j’utilise le gestionnaire de mot de
passe TROUSSEAU
Je me connecte épisodiquement sur un site de données biologiques de santé pour
lequel un mot de passe m’a été fourni . Ce mot de passe est déclaré
On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote:
> Yes, people. I object to removing TCP wrappers support since the patch
> is tiny and it supports use cases like DNS-based ACLs which cannot be
> supported by L3 firewalls.
I suspect OpenSSH upstream would also want me to point out
On Apr 02, Colin Watson wrote:
> You could use a drop-in unit to wrap sshd in tcpd, as suggested by the
> Fedora wiki page? This would avoid exposing sshd's process space to
> libwrap and all the stuff it links to by default.
This would require to switch to socket activation of sshd, which is
On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote:
> On Apr 02, Colin Watson wrote:
> > At the time, denyhosts was popular, but it was removed from Debian
> > several years ago. I remember that, when I dealt with that on my own
> > systems, fail2ban seemed like the obvious
On Tue, 2 Apr 2024 at 02:30, Colin Watson wrote:
>
> [I've CCed openssh-unix-dev for awareness, but set Mail-Followup-To to
> just debian-devel and debian-ssh to avoid potentially spamming them with
> a long discussion. If you choose to override this then that's your
> call, but please be
On Tue, Apr 02, 2024 at 11:49:50AM +0200, Francesco P. Lovergine wrote:
> Speaking about that, I'm a simple guy: how can anyone trust
> sources signed by an unsigned-gnupg-key committer (I mean both the
> actors of this tragically ridicolous drama)? In 2024. Really?
As opposed to sources not
On Apr 02, Colin Watson wrote:
> At the time, denyhosts was popular, but it was removed from Debian
> several years ago. I remember that, when I dealt with that on my own
> systems, fail2ban seemed like the obvious replacement, and my impression
> is that it's pretty widely used nowadays; it's
On Fri, Mar 29, 2024 at 09:09:45PM +0100, Sirius wrote:
Hi there,
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.
Speaking
On Sun, Mar 31, 2024 at 12:39:55PM +0200, Johannes Schauer Marin Rodrigues
wrote:
In summary: would running unstable instead of bookworm let me find more bugs
than running bookworm with unstable chroots? For my specific work: yes,
absolutely. Am I upgrading from bookworm to unstable or at
501 - 600 of 172865 matches
Mail list logo
