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 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 Fri, 2024-04-05 at 20:47 +0200, Sirius:
> > If there is a final result, can we as a project share the results on a
> > prominent place? Or at least under d-devel-announce and/or d-security-
> > announce? I was also wondering about what could have been compromised,
> > what data might have been
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, 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 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
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
>> >>
g able to
actually test Debian as many have said in this thread. Case in point,
the xz backdoor has been discovered by a Debian unstable user: it would
have likely been found much later had they used stable instead.
Without trying to be overly dramatic though, I consider the xz incident
as some sort o
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 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
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
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
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
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
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
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
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
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, 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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >
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 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
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
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
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
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
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?
>
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
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
Diane Trout wrote:
> On Sun, 2024-03-31 at 03:34 +0100, Wookey wrote:
>> 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.
On 2024-03-31 Wookey wrote:
[...]
> e.g. I remember it took me years to realise that I used _my_ public
> key for signing,
[...]
Good morning,
s/public/private/ - $recipient can then use your public key to verify
the sig.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His
On Sun, 2024-03-31 at 03:34 +0100, Wookey wrote:
> 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
Hi!
On Sat, 30 Mar 2024 at 14:32, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 10:49:33AM +0200, 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
> > to consider it
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 couple of recent posts have given me the
same thought:
El 31/03/24 a las 00:53, Christian Kastner escribió:
> On 2024-03-30 22:59, Santiago Ruano Rincón wrote:
> > The backdoor was discovered by someone using the compromised xz-utils *in
> > their own machines*. So we are lucky we have people eating our own sid
> > stuff before it becomes part of a
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 rolled it back and is
rebuilding everything that was built using it,
On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote:
>...
> On 2024/03/29 23:38, Russ Allbery wrote:
> > I think the big open question we need to ask now is what exactly the
> > backdoor (or, rather, backdoors; we know there were at least two versions
> > over time) did.
>
> Another
On 2024-03-30 22:59, Santiago Ruano Rincón wrote:
> The backdoor was discovered by someone using the compromised xz-utils *in
> their own machines*. So we are lucky we have people eating our own sid stuff
> before it becomes part of a stable release.
The luck was that this particular compromise
De : Adrian Bunk
À : Pierre-Elliott Bécue
Cc : debian-devel@lists.debian.org
Date : 31 mars 2024 00:25:09
Objet : Re: xz backdoor
> On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
>> ...
>> I'd be happy to have Debian France care about buying and
On Sun, Mar 31, 2024 at 01:20:39AM +0200, Adrian Bunk wrote:
> On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
> >...
> > I'd be happy to have Debian France care about buying and having yubikeys
> > delivered to any DD over the world.
>
> Including Russia?
>
Supporting DDs
On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
>...
> I'd be happy to have Debian France care about buying and having yubikeys
> delivered to any DD over the world.
Including Russia?
cu
Adrian
Hi,
On Sat, Mar 30, 2024 at 7:00 PM Santiago Ruano Rincón
wrote:
>
>
>
> Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri
> escreveu:
> >On Mar 30, Jonathan Carter wrote:
> >
> >> Another big question for me is whether I should really still
> >> package/upload/etc from an unstable
Santiago Ruano Rincón wrote on 30/03/2024 at
22:59:43+0100:
> Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri
> escreveu:
>>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
Ansgar wrote on 30/03/2024 at 20:52:29+0100:
> Hi,
>
> On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
>> On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
>>
>> > I think that the real question is whether we should really still
>> > use
>> > code-signing keys which
Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri
escreveu:
>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
>If we do not use unstable for development
On Mar 30, Christian Kastner 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
> > If we do not use unstable for development then who is going to?
> Are you both talking about unstable
Sirius (2024-03-30):
> 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 being discussed within Debian as well?
Talking about alternatives to autotools:
On 2024-03-30 20:20, Russ Allbery wrote:
> I personally specifically want my workstation to be running unstable, so
> I'm watching to see if that's considered unsafe (either, immediately,
> today, or in theory, in the future).
>
> If I have to use a stable host, I admit I will be sad. I've been
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 being discussed within Debian as well?
It's not in general something
On Sat, Mar 30, 2024 at 08:52:29PM +0100, Ansgar wrote:
> Hi,
>
> On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
> > On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
> >
> > > I think that the real question is whether we should really still
> > > use
> > >
Hi,
On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
>
> > I think that the real question is whether we should really still
> > use
> > code-signing keys which are not stored in (some kind of) HSM.
> What are the
On Sat, Mar 30, 2024 at 05:00:26PM +0100, 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
> If we do not use unstable for development then
On Sat, Mar 30, 2024 at 10:49:33AM +0200, 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
> to consider it best practice to work from stable machines where any private
> keys are
Christian Kastner writes:
> This is both out of convenience (I want my workstation to be based on
> stable) and precisely because of the afforded isolation.
I personally specifically want my workstation to be running unstable, so
I'm watching to see if that's considered unsafe (either,
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
> If we do not use unstable for development then who is going to?
Are
In days of yore (Fri, 29 Mar 2024), Russ Allbery thus quoth:
> Russ Allbery writes:
> > Sirius writes:
>
> >> 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
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
If we do not use unstable for development then who is going to?
I think that the real question is whether we should
Jonathan Carter wrote on 30/03/2024 at 09:49:33+0100:
> Hi Russ
>
> On 2024/03/29 23:38, Russ Allbery wrote:
>> I think the big open question we need to ask now is what exactly the
>> backdoor (or, rather, backdoors; we know there were at least two versions
>> over time) did.
>
> Another big
On Sat, Mar 30, 2024, at 05:49, 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
I have been using stable or old stable + pbuilder for this. Test runs of the
results might need a VM
Hi Russ
On 2024/03/29 23:38, Russ Allbery wrote:
I think the big open question we need to ask now is what exactly the
backdoor (or, rather, backdoors; we know there were at least two versions
over time) did.
Another big question for me is whether I should really still
package/upload/etc from
Moritz Mühlenhoff writes:
> 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 share the
> payload with a company
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 share the payload
with a company specialising in such reverse engineering. If
Russ Allbery writes:
> Sirius writes:
>> 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.
> The version of xz-utils
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.
>
Sirius writes:
> 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.
The version of xz-utils was reverted to 5.4.5 in
xz-utils (5.6.1+really5.4.5-1) unstable; urgency=critical
* Non-maintainer upload by the Security Team.
* Revert back to the 5.4.5-0.2 version
-- Salvatore Bonaccorso Thu, 28 Mar 2024 15:59:38
+0100
Le ven. 29 mars 2024 à 21:17, Sirius a écrit :
> Hi there,
>
> This is quite
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.
--
Kind regards,
/S
98 matches
Mail list logo
