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.
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.
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
Sirius <sirius@trudheim.com> 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 unstable yesterday by
the security team and migrated to testing today. Anyone running an
unstable or testing system should urgently upgrade.
Russ Allbery <rra@debian.org> 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 that
went through, I'd expect results to be publicly available in the next
days.
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.
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 an unstable machine. It seems that it may be
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 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 involved. For me it's just been so
convenient to use unstable because it helps track changes that affect
my users by the time it hits stable and also find bugs early that I
care about, but perhaps I just need to make that adjustment and find
more efficient ways to track unstable (perhaps on additional machines
/ VMs / etc). Not sure how other DDs think about this, but I'm also
curious how they will deal with this, because there's near to no
filter between unstable and the outside world, and this is probably
not the last time someone will try something like this.
Another big question for me is whether I should really still package/upload/etc from an unstable machine. It seems that it may be prudentIf we do not use unstable for development then who is going to?
Russ Allbery <rra@debian.org> writes:look at reverse-engineering the .o and figure out what it did. The fact
Sirius <sirius@trudheim.com> 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 unstable yesterday by
the security team and migrated to testing today. Anyone running an unstable or testing system should urgently upgrade.
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. If they only target sshd, that's one thing, and we have a bound on systems possibly affected. But liblzma is linked directly or indirectly into all sorts of things such as, to give an obvious example, apt-get. A lot of Debian developers use unstable or testing systems. If
the exploit was also exfiltrating key material, backdooring systems that didn't use sshd, etc., we have a lot more cleanup to do.
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.
From what I understand and have read, there is someone that will take a
On Mar 30, Jonathan Carter <jcc@debian.org> wrote:
Another big question for me is whether I should really stillIf we do not use unstable for development then who is going to?
package/upload/etc from an unstable machine. It seems that it may be prudent
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 involved. For me it's just been so convenient to use unstable because it helps track changes that affect my users by the time it hits stable and also find bugs early that I care about, but perhaps I just needFor me it's simple: if I'm forced to run my tools not on the host but in
to make that adjustment and find more efficient ways to track unstable (perhaps on additional machines / VMs / etc). Not sure how other DDs think about this, but I'm also curious how they will deal with this, because there's near to no filter between unstable and the outside world, and this
is probably not the last time someone will try something like this.
This is both out of convenience (I want my workstation to be based on
stable) and precisely because of the afforded isolation.
On Mar 30, Jonathan Carter <jcc@debian.org> wrote:Yup.
Another big question for me is whether I should really still package/upload/etc from an unstable machine. It seems that it may be prudentIf we do not use unstable for development then who is going to?
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 options for random DDs for that?
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 stillWhat are the options for random DDs for that?
use
code-signing keys which are not stored in (some kind of) HSM.
Hi,Sure (though all the discourse around USB keys in the past 10 years or so
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 stillWhat are the options for random DDs for that?
use
code-signing keys which are not stored in (some kind of) HSM.
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.
If someone cannot afford them, I think Debian paying for them is a good investment; Debian buying tokens for all project members would also beThis was even suggested at least once in the past.
nice,
but logistics are probably annoying...Exactly.
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?
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 using unstable for my personal client and development (not server, never
exposing services to the Internet) systems for well over a decade (and, before, that, testing systems for as long as I've been working on Debian)
and for me it's a much nicer experience than using stable.
It also lets
me directly and practically dogfood Debian, which has resulted in a fair number of bug reports.
(This is an analysis specific to me, not general advice, and relies
heavily on the fact that I'm very good at working around weird problems
that transiently arise in unstable.)
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?
I am talking about our own computers.Are you both talking about unstable hosts, or unstable chroots, or...?Another big question for me is whether I should really stillIf we do not use unstable for development then who is going to?
package/upload/etc from an unstable machine. It seems that it may be prudent
On Mar 30, Jonathan Carter <jcc@debian.org> wrote:
Another big question for me is whether I should really stillI think that the real question is whether we should really still use >code-signing keys which are not stored in (some kind of) HSM.
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?
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 stillWhat are the options for random DDs for that?
use
code-signing keys which are not stored in (some kind of) HSM.
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.
If someone cannot afford them, I think Debian paying for them is a good investment; Debian buying tokens for all project members would also be
nice, but logistics are probably annoying...
A compromised computer alone is then not enough to get a copy of the
private key: one would also need an exploit for the hardware token.
(A compromised computer can still give temporary access to the key when
it is in use and unlocked; some devices can require pushing a button
for signing, but of course a compromised computer could claim to sign something different than what gets signed and just show a "wrong PIN"
message to have the user try again.)
If you believe the hardware token to have a backdoor, exploiting it
might still require physical access to the token.
Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri <md@Linux.IT> escreveu:
On Mar 30, Jonathan Carter <jcc@debian.org> wrote:
Another big question for me is whether I should really stillIf we do not use unstable for development then who is going to?
package/upload/etc from an unstable machine. It seems that it may be prudent
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.
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.
...
I'd be happy to have Debian France care about buying and having yubikeys delivered to any DD over the world.
On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:It I leagally can, yes.
...
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
On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bcue wrote:
...
I'd be happy to have Debian France care about buying and having yubikeys delivered to any DD over the world.
Including Russia?
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 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.
...
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 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 involved. For me it's just been so convenient to use unstable because it helps track changes that affect my users by the time it hits stable and also find bugs early that I care about, but perhaps I just need
to make that adjustment and find more efficient ways to track unstable (perhaps on additional machines / VMs / etc). Not sure how other DDs think about this, but I'm also curious how they will deal with this, because there's near to no filter between unstable and the outside world, and this
is probably not the last time someone will try something like this.
-Jonathan
On 2024-03-30 22:59, Santiago Ruano Rincn 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 was discovered, not that it happened.
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.
As I mentioned earlier, I think containers are one good way to have
almost the best of both worlds. One can do anything one could do on
host, all while being isolated from that host, and with very little
overhead but also a ton of useful extra features.
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 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 prudentFor me it's simple: if I'm forced to run my tools not on the host but in
to consider it best practice to work from stable machines where any private keys are involved. For me it's just been so convenient to use unstable because it helps track changes that affect my users by the time it hits stable and also find bugs early that I care about, but perhaps I just need to make that adjustment and find more efficient ways to track unstable (perhaps on additional machines / VMs / etc). Not sure how other DDs think about this, but I'm also curious how they will deal with this, because there's near to no filter between unstable and the outside world, and this is probably not the last time someone will try something like this.
some kind of inconvenient VM/chroot/whatever, I'll just stop contributing.
e.g. I remember it took me years to realise that I used _my_ public[...]
key for signing,
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 off-topic, but a couple of recent posts have given me the
same thought:
Can someone point to good docs on this? I've had a
yubikey for 3/4 of a year now but have not yet worked out
how I put my GPG key in it. (or if it should be another
key, or a subkey, or whatever). So I'm not actually using
it yet.
I've also been thinking I needed to this, and so far this has looked
like the most detailed write up I've found so far.
I haven't followed the advice but I've been working on trying to
understand it.
https://github.com/drduh/YubiKey-Guide
Aren't these answers to different questions?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.
As I mentioned earlier, I think containers are one good way to have
almost the best of both worlds. One can do anything one could do on
host, all while being isolated from that host, and with very little overhead but also a ton of useful extra features.
I don't see the real benefit.
As others have said, the best solution is to relay on HSW for handling
the cryptographic material.
I am doing all my builds inside a (Podman) container with the sources loop-mounted.
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 handlingAren't these answers to different questions?
the cryptographic material.
Not all attacks are about stealing the key or using it to sign unintended things.
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 that Debian can unilaterally change. And
in a number of cases switching build system would be pretty non-trivial.
On Sat, Mar 30, 2024 at 08:15:10PM +0000, 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.It's not in general something that Debian can unilaterally change. And
Is that something being discussed within Debian as well?
in a number of cases switching build system would be pretty non-trivial.
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.
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 Rincn wrote:
As others have said, the best solution is to relay on HSW for handlingAren't these answers to different questions?
the cryptographic material.
Not all attacks are about stealing the key or using it to sign unintended
things.
Also a HSM does only allow to control access to the cryptographic
material. But it asserts no control over what is actually signed.
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, but it did make it into noble-proposed (the current unstable analogue) for some time and noble
(the current testing analogue) briefly.
I don't see the real benefit.
As others have said, the best solution is to relay on HSW for handling
the cryptographic material.
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 motivate those projects to upstream their modifications.
If it is double digits percent, it might not be possible to disallow vendoring the files.
On Sat, Mar 30, 2024 at 08:15:10PM +0000, 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.It's not in general something that Debian can unilaterally change. And
Is that something being discussed within Debian as well?
in a number of cases switching build system would be pretty non-trivial.
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.
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?
Not all attacks are about stealing the key or using it to sign unintended things.
Also a HSM does only allow to control access to the cryptographic
material. But it asserts no control over what is actually signed.
So an attacker needs to wait until you ask the HSM it is okay to sign something.
Bastian
On 2024-03-30 17:00, Marco d'Itri wrote:
On Mar 30, Jonathan Carter <jcc@debian.org> wrote:
Another big question for me is whether I should really stillIf we do not use unstable for development then who is going to?
package/upload/etc from an unstable machine. It seems that it may be prudent
Are you both talking about unstable hosts, or unstable chroots, or...?
I do all my development on a stable host, within rootless podman
containers which are trivial to set up. I run final sbuilds and
autopkgtests in QEMU VMs, also trivial to set up.
This is both out of convenience (I want my workstation to be based on stable) and precisely because of the afforded isolation.
On Sun, 31 Mar 2024 at 08:39, Bastian Blank <waldi@debian.org> 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 cryptographic material.Aren't these answers to different questions?
Not all attacks are about stealing the key or using it to sign unintended things.
Also a HSM does only allow to control access to the cryptographic
material. But it asserts no control over what is actually signed.
So an attacker needs to wait until you ask the HSM it is okay to sign something.
Bastian
This is true as in the default configuration you get asked for the
yubikey pin only once per "session", and then it's cached
transparently and there's no GUI feedback when the token is used (the
light on it blinks, but noticing that requires having it in line of
sight at all times). However, it's already better than nothing as it
means such an attack must be "online", and run in the same "session"
as the active user, so perfect should definitely not be the enemy of
good here IMHO. Also, iirc this can be configured to always ask for
the pin on each signature, although this could get burdensome. But
given the very low price of yubikeys (or similar tokens), and how well
and seamless they work these days, I think the offer of buying any DD
that doesn't have one such a token is one that we should take up and
make it happen.
Le dim. 31 mars 2024 à 10:17, Sirius <sirius@trudheim.com> a écrit :Yeah, those MRs never made sense to time, it's obvious that "run gbp import-orig and propose the result as MRs" is just not a workflow we
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 likely not be near authentication, crypto and compression at least initially).
It's worse than that: to make the xz MR looks more legit;
the fake puppet profile "Hans Jansen" also sent _maybe_ legit MR to
random games repos:
https://news.ycombinator.com/item?id=39868390
Here fixing our Salsa tooling could help also making real newcomers
life more enjoyable by always disabling MR again upstream & pristine-tar tar.
What we can do unilaterally is to disallow vendoring those files.That's doable unilaterally to some extent, using the dh-autoreconf style
Does it help? At least in the case of autoconf it removes one common source of hard to read files.
of approach: the files may be vendored in the upstream tarball, but
we'll throw them away and rebuild them.
I did that recently for the
packages that use gnulib where I'm upstream (e.g. https://salsa.debian.org/debian/libpipeline/-/commit/b596ee5555fb342e93136cf1f479415981fc7f48).
Frankly, I suspect that it will introduce slightly more FTBFS bugs over
time due to differences between the packaged version of gnulib and the version in use upstream (although things have got better in that regard
over the last year or so with the introduction of stable branches), but
it does seem to be worth it for transparency.
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:
Can someone point to good docs on this? I've had a yubikey for 3/4 of
a year now but have not yet worked out how I put my GPG key in it. (or
if it should be another key, or a subkey, or whatever). So I'm not
actually using it yet.
PEB also described what sounded like a very sensible way to manage
keys (using subkeys) in one of these threads but I don't know how to
do that myself.
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 five people who can login as buildd and potentially trigger
capability reachable problems in the kernel. This is what got as in
part of the situation, as we don't even know if the buildd hosts are untampered.
On Sun, 31 Mar 2024 at 08:39, Bastian Blank <waldi@debian.org> 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 cryptographic material.Aren't these answers to different questions?
Not all attacks are about stealing the key or using it to sign unintended >> > things.
Also a HSM does only allow to control access to the cryptographic
material. But it asserts no control over what is actually signed.
So an attacker needs to wait until you ask the HSM it is okay to sign
something.
Bastian
This is true as in the default configuration you get asked for the
yubikey pin only once per "session", and then it's cached
transparently and there's no GUI feedback when the token is used (the
light on it blinks, but noticing that requires having it in line of
sight at all times). However, it's already better than nothing as it
means such an attack must be "online", and run in the same "session"
as the active user, so perfect should definitely not be the enemy of
good here IMHO. Also, iirc this can be configured to always ask for
the pin on each signature, although this could get burdensome. But
given the very low price of yubikeys (or similar tokens), and how well
and seamless they work these days, I think the offer of buying any DD
that doesn't have one such a token is one that we should take up and
make it happen.
Wookey <wookey@wookware.org> 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 couple of recent posts have given me the
same thought:
Can someone point to good docs on this? I've had a yubikey for 3/4 of
a year now but have not yet worked out how I put my GPG key in it. (or
if it should be another key, or a subkey, or whatever). So I'm not
actually using it yet.
PEB also described what sounded like a very sensible way to manage
keys (using subkeys) in one of these threads but I don't know how to
do that myself.
I have started (and never finished) a blog article on how I use my
YubiKey and what config I put in it. I'll definitely try to get it out
before the end of next week. I'll probably extend it to mention the
creation of GPG subkeys etc.
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. But not in
the same piece I guess.
On 2024-03-31 10:47:57, Luca Boccassi wrote:
On Sun, 31 Mar 2024 at 08:39, Bastian Blank <waldi@debian.org> 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 cryptographic material.
Aren't these answers to different questions?
Not all attacks are about stealing the key or using it to sign unintended
things.
Also a HSM does only allow to control access to the cryptographic
material. But it asserts no control over what is actually signed.
So an attacker needs to wait until you ask the HSM it is okay to sign
something.
Bastian
This is true as in the default configuration you get asked for the
yubikey pin only once per "session", and then it's cached
transparently and there's no GUI feedback when the token is used (the
light on it blinks, but noticing that requires having it in line of
sight at all times). However, it's already better than nothing as it
means such an attack must be "online", and run in the same "session"
as the active user, so perfect should definitely not be the enemy of
good here IMHO. Also, iirc this can be configured to always ask for
the pin on each signature, although this could get burdensome. But
given the very low price of yubikeys (or similar tokens), and how well
and seamless they work these days, I think the offer of buying any DD
that doesn't have one such a token is one that we should take up and
make it happen.
Jumping in late in the HSM thread, but I'm not sure I understand the
exact setup people propose.
Option 1: Moving keys to one yubikey, while keeping the original key
material "safe" offline. How do you know the "safe offline" material is
safe and hasn't been copied?
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 keep track of _two_ keys, but it does ensure there's a physical
binding to the key.
Are there other options? And which option is proposed?
I have quite a few yubikeys, but I haven't migrated to use them since
it's not clear to me what is a good, and recommended, workflow. I'm relatively against option 1, since the "safe offline" key material
somehow doesn't appeal to me.
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 motivate those projects to upstream their modifications.
If it is double digits percent, it might not be possible to disallow vendoring the files.
This is difficult to answer because it's comparing apples and oranges to
some extent: not all autoconf customizations are vendored or would make
any kind of sense to upstream. For example, https://gitlab.com/man-db/man-db/-/blob/main/m4/man-arg-config-file.m4
is obviously specific to that project; it's just in a separate file for
the same reasons that projects past a certain size don't typically put
all their code in a single file.
I suspect the question you're aiming for is something like "how many
packaged projects have copied autoconf macros from elsewhere and
modified them but kept the same file names, so that a nave attempt to
update them would drop those modifications". My guess is that the
number here is very low - IME it's much more common in such cases to
either rename the macro file to be obviously project-specific or to find
some workaround that doesn't require changing the upstream macro - but
I've never seen anything resembling a robust analysis of this and I may
well have a skewed view.
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 container environment
just fails to set up some things? Does there exist a way to test GUI >applications inside a container without requiring superuser privileges to run >the container?
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 all eggs
in one basket" and just make things worse? And by how much vis-a-vis the effort to do it?
I think that what I am trying to get at is this: is there low-hanging
fruit that for minimal effort would disproportionately improve things
from a security perspective. (I have an inkling that this is a question
that every distribution is wrestling with today.)
Hi,
On Sun, Mar 31, 2024 at 02:31:37PM +0200, Pierre-Elliott Bcue 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. But not in
the same piece I guess.
My suggestion is to create a wiki page with these concepts plus a guide
on best practices dor the gpg key (subkeys + hsm - yubikey and others).
On Sat, Mar 30, 2024 at 08:15:10PM +0000, 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.It's not in general something that Debian can unilaterally change. And
Is that something being discussed within Debian as well?
in a number of cases switching build system would be pretty non-trivial.
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.
...
Bastian
On Sun, Mar 31, 2024 at 09:53:06AM -0300, Carlos Henrique Lima Melara wrote:I also thought I remember some Debian-specific PGP-related document but I couldn't find it.
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. But not in
the same piece I guess.
My suggestion is to create a wiki page with these concepts plus a guide
on best practices dor the gpg key (subkeys + hsm - yubikey and others).
Didn't DKG start something like this some time ago? Or am I
mis-remembering?
Hello,
Iustin Pop <iustin@debian.org> 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 keep track of _two_ keys, but it does ensure there's a physical
binding to the key.
Are there other options? And which option is proposed?
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.
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 that a benefit rather than a disadvantage?
You lose the key, or it gets destroyed / unusable; good, you get a new subkey
instead of reusing the existing one on a different HSM.
Didn't DKG start something like this some time ago? Or am II also thought I remember some Debian-specific PGP-related document
mis-remembering?
but I
couldn't find it.
Didier 'OdyX' Raboud <odyx@debian.org> 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 that a benefit rather than a disadvantage?
You lose the key, or it gets destroyed / unusable; good, you get a new subkey instead of reusing the existing one on a different HSM.
For the authentication and signing subkeys this is indeed true. For the encryption subkey significantly less so (as things encrypted against
that key then become impossible to decrypt).
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 to the archive and encourage
git uploads instead.
Does it help? At least in the case of autoconf it removes one common source of hard to read files.But I doubt every DD would be able to review the 2k LOC non-vendored
autoconf code in xz.
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.
On 2024-03-31 22:23:10, Arto Jantunen wrote:
Didier 'OdyX' Raboud <odyx@debian.org> 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 that a benefit rather than a disadvantage?
You lose the key, or it gets destroyed / unusable; good, you get a new subkey
instead of reusing the existing one on a different HSM.
For the authentication and signing subkeys this is indeed true. For the
encryption subkey significantly less so (as things encrypted against
that key then become impossible to decrypt).
Personally I have generated the signing and authentication subkeys on
the HSM itself (and thus at least in theory they cannot leave the HSM),
and the encryption subkey I have generated on an airgapped system and
stored on the HSM after making a couple of backups.
I am really confused now on how all this works. How can you generate
parts of a key (i.e. subkeys) on the HSM (well, yubikey), and the other
parts locally?
On Mon, Apr 01, 2024 at 08:13:58AM -0700, Russ Allbery wrote:
Bastian Blank <waldi@debian.org> 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 in m4/* that do not come from an external source.
Ditto. And a bunch of the packages where I'm not upstream too, such as
that famously enthusiastic adopter of all things GNU, OpenSSH.
Didier 'OdyX' Raboud <odyx@debian.org> 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 that a benefit rather than a disadvantage?
You lose the key, or it gets destroyed / unusable; good, you get a new subkey
instead of reusing the existing one on a different HSM.
For the authentication and signing subkeys this is indeed true. For the encryption subkey significantly less so (as things encrypted against
that key then become impossible to decrypt).
Personally I have generated the signing and authentication subkeys on
the HSM itself (and thus at least in theory they cannot leave the HSM),
and the encryption subkey I have generated on an airgapped system and
stored on the HSM after making a couple of backups.
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.
Another big question for me is whether I should really still package/upload/etc from an unstable machine.
Speaking about that, I'm a simple guy: how can anyone trustAs opposed to sources not signed by any key at all?
sources signed by an unsigned-gnupg-key committer (I mean both the
actors of this tragically ridicolous drama)? In 2024. Really?
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)
Wookey <wookey@wookware.org> 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 couple of recent posts have given me the
same thought:
Can someone point to good docs on this? I've had a yubikey for 3/4 of
a year now but have not yet worked out how I put my GPG key in it. (or
if it should be another key, or a subkey, or whatever). So I'm not
actually using it yet.
PEB also described what sounded like a very sensible way to manage
keys (using subkeys) in one of these threads but I don't know how to
do that myself.
I have started (and never finished) a blog article on how I use my
YubiKey and what config I put in it. I'll definitely try to get it out
before the end of next week. I'll probably extend it to mention the
creation of GPG subkeys etc.
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. But not in
the same piece I guess.
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.
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`.
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 testing? >Absolutely not. I just don't have the amount of free-time this would require of
me. Just performing the 12-13 bisection steps to find the offending kernel >commit which makes my system lock up would easily require a day of free time >from me. I'm afraid I do not have this luxury. Not even remotely close!
So I'll continue to not dogfood as hard as I could and run as much from >bookworm as I can. Would it make me a better contributor if I ran unstable? >Certainly! But this thing is just a hobby of mine and I can only allot that >much time to do risky experiments with my only computer. I guess others are in >the same boat?
Am Freitag, dem 29.03.2024 um 23:20 +0100 schrieb Moritz Mhlenhoff:
Russ Allbery <rra@debian.org> 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 that went through, I'd expect results to be publicly available in the next days.
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 stolen, etc. And there is so many sources to
follow right now. So sharing the final results would be great.
Hi,Yes, I did not mention the touch policy because right now I fail to have it enforced by the Yubi after having set it.
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 otherwise)
I think presence confirmation is more useful, that is, interacting
physically with the device for each signature. The Yubikey can do that
also for OpenPGP:
```
$ ykman openpgp keys set-touch --help
[...]
Touch policies:
Off (default) no touch required
On touch required
Fixed touch required, can't be disabled without deleting the private key
Cached touch required, cached for 15s after use
Cached-Fixed touch required, cached for 15s after use, can't be disabled
without deleting the private key
```
(The PIN can still be cached.)
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`.
Ansgar
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 to the archive and encourage
git uploads instead.
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.
Does it help? At least in the case of autoconf it removes one common source of hard to read files.But I doubt every DD would be able to review the 2k LOC non-vendored autoconf code in xz.
But at least changes to this code are visible. In this case the changes
to the m4 stuff did not exist in the somewhat reviewed repo, but just in
the unreviewed tarballs.
Bastian
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.
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 stolen, etc. And there is so many sources to follow right now. So sharing the final results would be great.
If you have followed the discussion on Openwall ML, there have been a
couple of posts that points at both a general overview of what the 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.
Pierre-Elliott Bécue <peb@debian.org> wrote on 31/03/2024 at 14:31:37+0200:
Wookey <wookey@wookware.org> 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 couple of recent posts have given me the
same thought:
Can someone point to good docs on this? I've had a yubikey for 3/4 of
a year now but have not yet worked out how I put my GPG key in it. (or
if it should be another key, or a subkey, or whatever). So I'm not
actually using it yet.
PEB also described what sounded like a very sensible way to manage
keys (using subkeys) in one of these threads but I don't know how to
do that myself.
I have started (and never finished) a blog article on how I use my
YubiKey and what config I put in it. I'll definitely try to get it out
before the end of next week. I'll probably extend it to mention the
creation of GPG subkeys etc.
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. But not in
the same piece I guess.
Hello,
For those interested in: I've published two articles:
1. One on PGP subkeys https://pe.becue.phd/openpgp-subkeys
2. One on the OpenPGP module of YubiKeys:
https://pe.becue.phd/yubikey-workfow-openpgp
I'm happy to receive any kind of constructive feedback.
On 4/5/24 10:30, Pierre-Elliott Bécue wrote:
Pierre-Elliott Bécue <peb@debian.org> wrote on 31/03/2024 at 14:31:37+0200: >>> Wookey <wookey@wookware.org> wrote on 31/03/2024 at 04:34:00+0200:
Hello,
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:
Can someone point to good docs on this? I've had a yubikey for 3/4 of >>>> a year now but have not yet worked out how I put my GPG key in it. (or >>>> if it should be another key, or a subkey, or whatever). So I'm not
actually using it yet.
PEB also described what sounded like a very sensible way to manage
keys (using subkeys) in one of these threads but I don't know how to
do that myself.
I have started (and never finished) a blog article on how I use my
YubiKey and what config I put in it. I'll definitely try to get it out
before the end of next week. I'll probably extend it to mention the
creation of GPG subkeys etc.
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. But not in
the same piece I guess.
For those interested in: I've published two articles:
1. One on PGP subkeys https://pe.becue.phd/openpgp-subkeys
2. One on the OpenPGP module of YubiKeys:
https://pe.becue.phd/yubikey-workfow-openpgp
I'm happy to receive any kind of constructive feedback.
Thank you so much for working on these. I last-minute cobbled together
a BOF on GPG Key Best Practices at Columbia in 2010, since the topic
came up in another talk. I was blown away at how much I did not know,
the complexity, as well as how many people crammed in that room -
definitely there are interested people (I think Wookey was there,
too?). I include myself in each of the things others mentioned, that I
should have been doing since then, but just never got around to.. At
least I now have a fist full of Yubikeys to play with, as we use them
at work, so thanks for your work. I appreciate it, and I'm guessing
there's a rather large, quiet group of people thinking the same.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 22:05:53 |
| Calls: | 6,707 |
| Calls today: | 1 |
| Files: | 12,239 |
| Messages: | 5,351,987 |