Le dimanche, 31 mars 2024, 21.23:10 h CEST Arto Jantunen a écrit :
> 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 fo
Russell Stuart writes:
> The reason I'm replying is after one, probably two decades this still
> annoys me:
>$ dpkg -S /etc/profile
>dpkg-query: no path found matching pattern /etc/profile
> It was put their by the Debian install, and I'm unlikely to change it.
> Its fairly important se
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 -> /usr/bin shift.
The reason I'm replying is after one, probably two decades thi
On Apr 01, gregor herrmann wrote:
> > I switched long ago all my packages from tar archives to the git
> > upstream tree. Not only this makes much easier to understand the changes
> > in a new release,
> That's not mutually exclusive. When adding an additional git remote
> and using gbp-import-
On Sun, 31 Mar 2024 23:59:20 +0200, Marco d'Itri wrote:
> I switched long ago all my packages from tar archives to the git
> upstream tree. Not only this makes much easier to understand the changes
> in a new release,
That's not mutually exclusive. When adding an additional git remote
and using
On Sun, 31 Mar 2024 10:12:35 -0700, Russ Allbery wrote:
> > My point is that, while there will be for sure exceptions here and
> > there, by and large the need for massaged tarballs comes from projects
> > using autoconf and wanting to ship source archives that do not require
> > to run the autoco
On Sun, 31 Mar 2024 19:44:24 +0200, Hans wrote:
> as I could not find, which package /usr/bin/mv is belonging to and
> apt-file search /usr/bin/mv did not help either, I just in form you here.
% apt-file search -x "usr/bin/mv$"
coreutils: /usr/bin/mv
Faster:
% dpkg -S $(whi
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 _prefer_ that.
The distribution archives
Hi Guillem (2024.03.30_04:41:37_+)
> > 1. Move towards allowing, and then favoring, git-tags over source tarballs
>
> I assume you mean git archives out of git tags? Otherwise how do you
> go from git-tag to a source package in your mind?
There are some issues with transforming upstream's git
On Mar 31, Russ Allbery wrote:
> Most of this is pregenerated documentation (primarily man pages generated
> from POD), but it also includes generated test data and other things. The
> reason is similar: regenerating those files requires tools that may not be
> present on an older system (like a
Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: poke-elf
Version : 1.0
Upstream Author : Jose E. Marchesi
* URL : http://www.jemarch.net/poke-elf
* License : GPL-3+ and others
Programm
On Sun, Mar 31, 2024 at 02:45:29PM -0300, Maycon Antônio wrote:
> PLEASE unscrisbe from this list
>
Antonio,
You need to send a mail to
debian-devel-request
with the subject of
unsubscribe
The robot should send back a confirmation request that you can
accept to confirm that you want to be
On 17185 March 1977, Andrey Rakhmatullin wrote:
Didn't DKG start something like this some time ago? Or am I
mis-remembering?
I also thought I remember some Debian-specific PGP-related document
but I
couldn't find it.
You may remember https://keyring.debian.org/ which has a bunch of links
to
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 as you lose
>> it or it dies.
>
> For subkeys, isn't th
Le dimanche, 31 mars 2024, 14.37:08 h CEST Pierre-Elliott Bécue a écrit :
> Hello,
>
> Iustin Pop wrote on 31/03/2024 at 13:13:27+0200:
> > Option 2: Generate keys on the yubikey and have them never leave the
> > secure enclave. That means having 2 yubikeys per developer, and ensuring
> > you kee
Hi Sven,
just did as you suggested.
Thanks for the hint
Best regards
Hans
> Problems with German translations are best reported to
> debian-l10n-ger...@lists.debian.org.
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com
* Package name: python-pyzipper
Version : 0.3.6
Upstream Contact: Daniel Hillier
* URL : https://github.com/danifus/pyzipper
* L
Am 31.03.2024 um 19:44 schrieb Hans:
> Hi folks,
>
> as I could not find, which package /usr/bin/mv is belonging to and
> apt-file search /usr/bin/mv did not help either, I just in form you here.
Problems with German translations are best reported to
debian-l10n-ger...@lists.debian.org.
> There
PLEASE unscrisbe from this list
On Sun, Mar 31, 2024, 7:30 AM Joerg Jaspert wrote:
> Hi
>
> > currently the archive processing is turned OFF.
>
> > It will be turned back on - when we figured out, how to best go about
> > dealing with the XZ compromise, and what it will all mean for the
> > arch
Hi folks,
as I could not find, which package /usr/bin/mv is belonging to and
apt-file search /usr/bin/mv did not help either, I just in form you here.
There is a little translation problem with this command. In German moving a
file to anbother
place is telling this:
mv -v test2/bla.txt test1
On Sun, Mar 31, 2024 at 12:28:35PM -0400, Roberto C. Sánchez wrote:
> On Sun, Mar 31, 2024 at 09:53:06AM -0300, Carlos Henrique Lima Melara wrote:
> > Hi,
> >
> > On Sun, Mar 31, 2024 at 02:31:37PM +0200, Pierre-Elliott Bécue wrote:
> >
> > > I would also be happy if it helps my fellow DDs to try
On Sat, Mar 30, 2024 at 11:55:04AM +, Luca Boccassi wrote:
>...
> 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 by default so it's all moot
Luca Boccassi writes:
> On Sat, 30 Mar 2024 at 15:44, Russ Allbery wrote:
>> Luca Boccassi writes:
>>> In the end, massaged tarballs were needed to avoid rerunning
>>> autoconfery on twelve thousands different proprietary and
>>> non-proprietary Unix variants, back in the day. In 2024, we do
>>
On Sun, Mar 31, 2024 at 09:35:09AM +0200, Bastian Blank wrote:
> On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote:
> > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > > I have seen discussion about shifting away from the whole auto(re)conf
> > > tooling to CMake or Meson wit
Sirius writes:
> Would throwing away these unmodified (?) macros packaged projects may be
> carrying for hysterical raisins in favour of just using the autoconf
> native macros reduce the attack-surface a potential malicious actor
> would have at their disposal, or would it simply be a "putting a
On Sun, Mar 31, 2024 at 09:53:06AM -0300, Carlos Henrique Lima Melara wrote:
> Hi,
>
> On Sun, Mar 31, 2024 at 02:31:37PM +0200, Pierre-Elliott Bécue wrote:
>
> > I would also be happy if it helps my fellow DDs to try making an article
> > about some basic crypto concepts regarding PGP, RSA et al
On Sun, 31 Mar 2024 at 07:40, Johannes Schauer Marin Rodrigues
wrote:
[snip]
> 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 least
Package: wnpp
Severity: wishlist
Owner: Faidon Liambotis
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: bootterm
Version : 0.4+git2023013
Upstream Contact: Willy Tarreau
* URL : https://github.com/wtarreau/bootterm
* License : Expat
Programming
On 31 March 2024 12:39:55 CEST, Johannes Schauer Marin Rodrigues
wrote:
>
>Another example is when I wanted to run a GUI program inside an unshared chroot
>environment. Wayland does not seem to be happy about that and I didn't find a
>way to test my GUI application successfully. But maybe my co
In days of yore (Sun, 31 Mar 2024), Colin Watson thus quoth:
> On Sun, Mar 31, 2024 at 10:10:42AM +0200, Sirius wrote:
> > Not worth boiling the ocean over, but is there an estimate of how many
> > packaged projects have customisations to their autoconf that is not found
> > in the upstream autoco
Hi,
On Sun, Mar 31, 2024 at 02:31:37PM +0200, Pierre-Elliott Bécue wrote:
> 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.
> >>
> >
Bastian Blank wrote on 31/03/2024 at 09:11:59+0200:
> On Sat, Mar 30, 2024 at 07:15:28PM -0700, Otto Kekäläinen wrote:
>> I am doing all my builds inside a (Podman) container with the sources
>> loop-mounted.
>
> You do, but Debian itself (aka DSA) does not. They still prefer to
> trust all 100k
Hello,
Iustin Pop wrote on 31/03/2024 at 13:13:27+0200:
> On 2024-03-31 10:47:57, Luca Boccassi wrote:
>> On Sun, 31 Mar 2024 at 08:39, Bastian Blank wrote:
>> >
>> > On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
>> > > On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago R
Luca Boccassi wrote on 31/03/2024 at 12:47:57+0200:
> On Sun, 31 Mar 2024 at 08:39, Bastian Blank wrote:
>>
>> On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
>> > On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
>> > > As others have said, the best sol
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 be used for both OpenPGP and SSH keys.
>
> Slightly off-topic, but a
On Sun, Mar 31, 2024 at 11:59:35AM +0100, Colin Watson wrote:
> > What we can do unilaterally is to disallow vendoring those files.
> > Does it help? At least in the case of autoconf it removes one common
> > source of hard to read files.
> That's doable unilaterally to some extent, using the dh-a
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
On Sun, Mar 31, 2024 at 10:27:05AM +0200, Simon Josefsson wrote:
> Gioele Barabucci writes:
>
> > But pulling a successful collision attack is not a trivial task. For
> > instance, the xz attacker did not have all that was required to carry
> > it out (for example they had no direct access to the
On Sun, Mar 31, 2024 at 12:13:30PM +0200, Alexandre Detiste wrote:
> Le dim. 31 mars 2024 à 10:17, Sirius a écrit :
> > Reduction of complexity is IMHO always worthwhile as it would open the
> > door for more people being able to step up as maintainers (taking into
> > account that volunteers righ
On 2024-03-31 08:03:40, Gioele Barabucci wrote:
> On 30/03/24 20:43, Iustin Pop wrote:
> > On 2024-03-30 11:47:56, Luca Boccassi wrote:
> > > On Sat, 30 Mar 2024 at 09:57, Iustin Pop wrote:
> > > > Give me good Salsa support for autopkgtest + lintian + piuparts, and
> > > > easy support (so that I
Hi Diane,
On Sat, Mar 30, 2024 at 08:59:39PM -0700, Diane Trout wrote:
> Hi Julian,
>
> On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote:
> > Lovely to hear from you, and oh wow, that's amazing, thank you!
> >
> > I can't speak for anyone else, but I suggest that pushing your
> > updates
>
On 2024-03-31 10:47:57, Luca Boccassi wrote:
> On Sun, 31 Mar 2024 at 08:39, Bastian Blank wrote:
> >
> > On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
> > > On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > > > As others have said, the best solution
On Sun, Mar 31, 2024 at 10:10:42AM +0200, Sirius wrote:
> Not worth boiling the ocean over, but is there an estimate of how many
> packaged projects have customisations to their autoconf that is not found
> in the upstream autoconf project? If that number is low single digit
> percent, it may motiv
On Sun, Mar 31, 2024 at 09:35:09AM +0200, Bastian Blank wrote:
> On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote:
> > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > > I have seen discussion about shifting away from the whole auto(re)conf
> > > tooling to CMake or Meson wit
On Sat, 30 Mar 2024 at 15:44, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > In the end, massaged tarballs were needed to avoid rerunning autoconfery
> > on twelve thousands different proprietary and non-proprietary Unix
> > variants, back in the day. In 2024, we do dh_autoreconf by default
On Sun, 31 Mar 2024 at 08:39, Bastian Blank wrote:
>
> On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
> > On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > > As others have said, the best solution is to relay on HSW for handling
> > > the cryptographi
Hi,
Quoting Christian Kastner (2024-03-30 19:49:48)
> On 2024-03-30 17:00, Marco d'Itri wrote:
> > On Mar 30, Jonathan Carter wrote:
> >
> >> Another big question for me is whether I should really still
> >> package/upload/etc from an unstable machine. It seems that it may be
> >> prudent
> > I
Le dim. 31 mars 2024 à 10:17, Sirius a écrit :
> Reduction of complexity is IMHO always worthwhile as it would open the
> door for more people being able to step up as maintainers (taking into
> account that volunteers right this minute might not be overly welcome and
> when they are, they should
On Sun, Mar 31, 2024 at 11:22:05AM +0200, Andreas Metzler wrote:
> hdf5 1.10.10+repack-3.3
This one has an unanswered question from the maintainer in the NMU report,
and I feel like the reason for the missing line is the package having
debian/control.in.
--
WBR, wRAR
signature.asc
Description:
31.03.2024 12:16, Andreas Metzler wrote:
...
Looking through testing, I see the following t64 libraries present:
libaio1t64
libfyba0t64
libglibmm-2.68-1t64
libnetcdf19t64
libudns0t64
libczmq4t64 (virtual package; libczmq4 provides this)
Unfortunately the other four are not similar, but rather
On 2024-03-31 Andreas Metzler wrote:
[...]
> Afaict these are broken, though:
[...]
> tnat64 0.06-1
false positive, grep error.
On 2024-03-31 04:22, Santiago Ruano Rincón wrote:
> I don't see the real benefit.
>
> As others have said, the best solution is to relay on HSW for handling
> the cryptographic material.
That's extremely important (which is why I use a HSM) but that "just"
prevents exfiltration of the keys. An a
On 2024-03-31 Andreas Metzler wrote:
> On 2024-03-31 Sven Joachim wrote:
[...]
>> Unfortunately the other four are not similar, but rather lacked a build
>> dependency on dpkg-dev (>= 1.22.5) which would have prevented their
>> migration to testing. Testing users on armel and armhf should avoid
On 2024-03-31 Sven Joachim wrote:
> On 2024-03-31 06:54 +0200, Andreas Metzler wrote:
> > On 2024-03-30 Julian Gilbey wrote:
[...]
> >> Looking through testing, I see the following t64 libraries present:
> >> libaio1t64
> >> libfyba0t64
> >> libglibmm-2.68-1t64
> >> libnetcdf19t64
> >> libudns0t
On Sun, Mar 31, 2024 at 03:07:53AM +0100, Colin Watson wrote:
> On Sun, Mar 31, 2024 at 04:14:13AM +0300, Adrian Bunk wrote:
> > The timing of the 5.6.0 release might have been to make it into the
> > upcoming Ubuntu LTS, it didn't miss it by much.
>
> It didn't miss it at all, even. Ubuntu has
Gioele Barabucci writes:
> But pulling a successful collision attack is not a trivial task. For
> instance, the xz attacker did not have all that was required to carry
> it out (for example they had no direct access to the git
> servers... yet).
Is that necessary? It seems that if you have push
Bastian Blank writes:
> On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
>> On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
>> > As others have said, the best solution is to relay on HSW for handling
>> > the cryptographic material.
>> Aren't these answe
In days of yore (Sun, 31 Mar 2024), Bastian Blank thus quoth:
> On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote:
> > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > > I have seen discussion about shifting away from the whole auto(re)conf
> > > tooling to CMake or Meson wit
On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote:
> On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > I have seen discussion about shifting away from the whole auto(re)conf
> > tooling to CMake or Meson with there being a reasonable drawback to CMake.
> > Is that something bei
Quoting Otto Kekäläinen (2024-03-30 22:09:46)
> Is it so that the debian/copyright file is reviewed by ftp-masters
> only for packages in NEW queue, and there is probably no automation in
> place to flag subsequent copyright changes for re-review?
It is my understanding that it is, and always has
On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > As others have said, the best solution is to relay on HSW for handling
> > the cryptographic material.
> Aren't these answers to different questions?
> N
On Sun, Mar 31, 2024 at 08:16:33AM +0200, Lucas Nussbaum wrote:
> On 29/03/24 at 23:29 -0700, Russ Allbery wrote:
> > This is why I am somewhat skeptical that forcing everything into Git
> > commits is as much of a benefit as people are hoping. This particular
> > attacker thought it was better to
Hi!
On Sun, 2024-03-31 at 06:54:10 +0200, Andreas Metzler wrote:
> On 2024-03-30 Julian Gilbey wrote:
> > My very limited understanding of this major transition was that the
> > t64 libraries are being held in unstable until (almost) everything is
> > ready, at which point there will be a coordin
On Sat, Mar 30, 2024 at 07:15:28PM -0700, Otto Kekäläinen wrote:
> I am doing all my builds inside a (Podman) container with the sources
> loop-mounted.
You do, but Debian itself (aka DSA) does not. They still prefer to
trust all 100k packages and run them as root in the init namespace over
the f
On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > I agree that dogfooding is important for discovering quality issues, but
> > I think it's a poor argument for discovering security issues, especially
> > if it concerns a host which is used for building and signing packages.
On Sat, Mar 30, 2024 at 10:41:55PM +, Julian Gilbey wrote:
> My very limited understanding of this major transition was that the
> t64 libraries are being held in unstable until (almost) everything is
> ready, at which point there will be a coordinated migration into
> testing. But I've now be
On 2024-03-30 12:19 +0100, Simon Josefsson wrote:
> Gioele Barabucci writes:
>
>> Just as an example, bootstrapping coreutils currently requires
>> bootstrapping at least 68 other packages, including libx11-6 [1]. If
>> coreutils supported [2], the transitive closure of its
>> Build-Depends woul
67 matches
Mail list logo
