On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:
> On 1/4/24 10:18, gregor herrmann wrote:
> > % dpkg -S $(which mv > coreutils: /usr/bin/mv
>
> On bookworm:
>
> $ dpkg -S $(which mv)
> dpkg-query: no path found matching pattern /usr/bin/mv
>
> This is caused by the /bin -
Hi,
Quoting Andrey Rakhmatullin (2024-04-01 09:58:21)
> On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:
> > On 1/4/24 10:18, gregor herrmann wrote:
> > > % dpkg -S $(which mv > coreutils: /usr/bin/mv
> >
> > On bookworm:
> >
> > $ dpkg -S $(which mv)
> > dpkg-query: no pa
On Mar 31, 2024 2:37 PM, Pierre-Elliott Bécue Wrote:
> The PGP submodule of a Yubikey can host 3 keys, one signing, one
> authent, and one encrypt. ISTR accessing the signing key is always
> prompting for the PIN. Same for the encryption key. (I think both can be
> configured otherwise)
"G. Branden Robinson" writes:
> At 2024-03-31T22:32:49+, Stefano Rivera wrote:
>> Upstreams would probably prefer that we used git repositories
>> *directly* as source artifacts, but that comes with a whole other can
>> of worms...
>
> Speaking from my upstream groff perspective, I wouldn't _
On Mon, 2024-04-01 at 10:59 +0200, tho...@goirand.fr wrote:
> Only for the signing operation, one can turn on the "force-sig"
> option so that the key always prompt for a pin. And that is not the
> default.
There are two levels. In the OpenPGP protocol, the smartcard can be
configured to require t
Hi
On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > What we can do unilaterally is to disallow vendoring those files.
> These files are supposed to be vendored in release tarballs,
> the sane approach for getting rid of such vendored files would
> be to discourage tarball uploads t
On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> That's not mutually exclusive. When adding an additional git remote
> and using gbp-import-orig's --upstream-vcs-tag you get the best of
> both worlds.
And this will error out if there are unexpected changes in the tarball?
How wil
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
> >> the proper control on the key is room for disaster as soon
Hi,
On Sun, 2024-03-31 at 14:34 +0200, Pierre-Elliott Bécue wrote:
> The PGP submodule of a Yubikey can host 3 keys, one signing, one
> authent, and one encrypt. ISTR accessing the signing key is always
> prompting for the PIN. Same for the encryption key. (I think both can
> be configured other
On Mon, Apr 01, 2024 at 12:03:48PM +0200, Bastian Blank wrote:
> On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> > That's not mutually exclusive. When adding an additional git remote
> > and using gbp-import-orig's --upstream-vcs-tag you get the best of
> > both worlds.
> And thi
Hi
On Mon, Apr 01, 2024 at 12:40:51PM +0200, Ansgar 🙀 wrote:
> For OpenSSH it might also be more convenient to use Webauthn, that is,
> the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`.
Also those key types allow two different uses. Persistent or
non-persistent keys differ in
De : Ansgar 🙀
À : Pierre-Elliott Bécue ; Luca Boccassi
Cc : debian-devel@lists.debian.org
Date : 1 avr. 2024 12:47:52
Objet : Re: xz backdoor
>
> Hi,
>
> On Sun, 2024-03-31 at 14:34 +0200, Pierre-Elliott Bécue wrote:
>> The PGP submodule of a Yubikey can host 3 keys, one signing, one
>> authen
Le lun. 1 avr. 2024 à 10:43, Johannes Schauer Marin Rodrigues
a écrit :
> > This is the reason I never expect dpkg -S to work and dpkg -L to be
> > correct. The (probably) oldest registered bug report about this is #213907,
> > from 2003. RPM has %ghost since before that, of course.
>
> This is th
On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
> Running ./bootstrap in a tarball may lead to different results than the
> maintainer running ./bootstrap in pristine git. It is the same problem
> as running 'autoreconf -fvi' in a tarball does not necessarily lead to
> the same re
Le lun. 1 avr. 2024 à 15:49, Colin Watson a écrit :
>
> The practice of running "autoreconf -fi" or similar via dh-autoreconf
> has worked extremely well at scale in Debian. I'm sure there are
> complex edge cases where it's caused problems, but it's far from being a
> disaster area.
It's pretty
On Mon, Apr 01, 2024 at 04:10:55PM +0200, Alexandre Detiste wrote:
> Le lun. 1 avr. 2024 à 15:49, Colin Watson a écrit :
> >
> > The practice of running "autoreconf -fi" or similar via dh-autoreconf
> > has worked extremely well at scale in Debian. I'm sure there are
> > complex edge cases where
"dpkg -S" or "apt-file" give me an incorrect or no answer, most of the
times.
Whereas this url always returns a correct answer:
https://www.debian.org/distrib/packages#search_contents
Best,
Fabrice
Le 01/04/2024 à 09:58, Andrey Rakhmatullin a écrit :
On Mon, Apr 01, 2024 at 01:03:04PM +1000,
On Mon, Apr 01, 2024 at 05:02:56PM +0200, Fabrice Aeschbacher wrote:
> "dpkg -S" or "apt-file" give me an incorrect or no answer, most of the
> times.
>
> Whereas this url always returns a correct answer:
> https://www.debian.org/distrib/packages#search_contents
Have you tried either of two exampl
Bastian Blank writes:
> I don't understand what you are trying to say. If we add a hard check
> to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
> if the upload is a tarball or git.
Er, well, there goes every C package for which I'm upstream, all of which
have M4 macros i
On Sat, Mar 30, 2024 at 08:44:36AM -0700, 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
> > variants, back in the day. In 2024, we do dh_autoreconf b
Colin Watson writes:
> On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
>> Running ./bootstrap in a tarball may lead to different results than the
>> maintainer running ./bootstrap in pristine git. It is the same problem
>> as running 'autoreconf -fvi' in a tarball does not neces
On Mon, Apr 01, 2024 at 08:13:58AM -0700, Russ Allbery wrote:
> Bastian Blank writes:
> > I don't understand what you are trying to say. If we add a hard check
> > to lintian for m4/*, set it to auto-reject, then it is fully irrelevant
> > if the upload is a tarball or git.
>
> Er, well, there g
On Mon, Apr 01, 2024 at 12:02:09PM +0200, Bastian Blank wrote:
> Hi
>
> On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > > What we can do unilaterally is to disallow vendoring those files.
> > These files are supposed to be vendored in release tarballs,
> > the sane approach for ge
On Mon, Apr 01, 2024 at 05:24:45PM +0200, Simon Josefsson wrote:
> Colin Watson writes:
> > On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
> >> Running ./bootstrap in a tarball may lead to different results than the
> >> maintainer running ./bootstrap in pristine git. It is the
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 unstable. I am following the progress since quite a few
years and I hav
On 2024-04-01 12:44, Bastian Blank wrote:
So in the end you still need to manually review all the stuff that the
tarball contains extra to the git. And for that I don't see that it
actually gives some helping hands and makes it easier.
So I really don't see how this makes the problem in hand a
On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote:
>
> I think that if Debian was using git instead of the generated tarball, this
> part of the backdoor would have just been included in the git repository as
> well. If we were able to magically switch everything to git (and we won't,
On Mon, Apr 01, 2024 at 04:47:05PM +0100, Colin Watson wrote:
> On Mon, Apr 01, 2024 at 08:13:58AM -0700, Russ Allbery wrote:
> > Bastian Blank writes:
> > > I don't understand what you are trying to say. If we add a hard check
> > > to lintian for m4/*, set it to auto-reject, then it is fully ir
On Mon, Apr 01, 2024 at 06:27:29PM +0200, 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
>
On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote:
> On 2024-04-01 12:44, Bastian Blank wrote:
> > So in the end you still need to manually review all the stuff that the
> > tarball contains extra to the git. And for that I don't see that it
> > actually gives some helping hands and m
Hi!
On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> Let's try to go in detail on how this was done on the build system
> side (I'm doing this right now, as previously only had skimmed over
> the process).
>
> The build system hook was planted in the tarball by adding a modified
> m4/
Hi Jonathan,
just a brief correction:
On 2024-04-01 18:05, Jonathan Carter wrote:
> I don't want to single out DSA there, it's difficult and affects many
> other teams. The Salsa CI team also spent a lot of resources (time and
> money wise) to extend testing on AMD GPUs and other AMD hardware. It
Hi. It'd be great to package Git credential helper
git-credential-libsecret in Debian. There's a patch prepared, but it
needs the attention of a Debian developer. Is anyone here able to
help? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878599
Kind regards
-M
Package: wnpp
Severity: wishlist
Owner: Bret Curtis
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: jolt
Version : 4.0.2
Upstream Contact: Jorrit Rouwe
* URL : https://github.com/jrouwe/JoltPhysics
* License : MIT
Programming Lang: C++
Descript
On 31/03/24 08:59, Sven Joachim wrote:
The coreutils bootstrap script fetches files over the network, so it is
not possible to build the Debian package from upstream git tags. At the
very least it would lack any translations, and there is also the
problem of the gnulib submodule.
Aren't these t
Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar
X-Debbugs-Cc: debian-devel@lists.debian.org, kd8...@gmail.com
* Package name: python-grpcio-status
Version : 1.62.1
Upstream Contact: The gRPC Authors
* URL : https://github.com/OctopusAI/grpcio-status
* Lic
[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 mindful of upstream's time.]
Following the xz-utils backdoor, I'm
On Tue, 2 Apr 2024, Colin Watson wrote:
[I'm not subscribed to the debian-* lists, please Cc me in replies if
you want me to see them]
> [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 discu
Hey.
On Tue, 2024-04-02 at 01:30 +0100, Colin Watson wrote:
> All the same, I'm aware that some people now depend on having this
> facility in Debian's main openssh package: I get enough occasional
> bug
> reports to convince me that it's still in use.
Being one of those people, and having even a
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com
* Package name: python-undetected-chromedriver
Version : 3.5.5
Upstream Contact: UltrafunkAmsterdam
* URL :
https://github.com/u
Christoph Anton Mitterer writes:
> Actually I think that most sites where I "need"/use GSSAPI... only
> require the ticket for AFS, and do actually allow pubkey auth (but
> right now, one doesn't have AFS access then).
In past discussions of this patch, this has not been the case. One of the
ad
In days of yore (Tue, 02 Apr 2024), Colin Watson thus quoth:
> TCP wrappers
>
Not used hosts.{allow,deny} for the last 17 years (since I started my
current employment) so I am biased. Honest opinion is that firewall and
fail2ban have pretty much obsoleted TCP wrappers.
> SELinux
> =
Damien Miller wrote:
> Another thing we're considering in OpenSSH is changing how we integrate
> with PAM. PAM's API demands loading modules into the authenticating
> process' address space, but obviously we've just been reminded that this
> is risky.
This was a long-standing problem with pam/nss-
43 matches
Mail list logo
