Kilian Hanich via devel wrote:
> The fact that you can share the keys is actually part of the design and
> wanted. Apple for exmaple has (or wants to) implement easy sharing of
> passkeys via AirDrop.
So the Apple Cloud can see your private key, but you cannot? Sounds like
GREAT "security", LOL…
Am 17.04.24 um 23:34 schrieb Kevin Kofler via devel:
And in my view, the fact that, in those implementations, there is no
Treacherous Computing hardware preventing me from doing what I want with my
own private key (e.g., just copying the same key to all my devices, as I can
also do with TOTP) is
Gary Buhrmaster wrote:
> [2] As I understand it, the issue is the
> lack of the required trusted environment
> in generic Linux. There are software
> implementations that do not have the
> hardware enclave protections,
And to be honest, I do not see the problem there. I will use whatever will
On Thu, Apr 11, 2024 at 6:50 PM Adam Williamson
wrote:
> On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote:
> >
> > What is the best way to formally propose
> > that 2FA is required for packagers after
> > some date
>
> There is already a FESCo ticket. https://pagure.io/fesco/issue/3186 /
On Fri, Apr 12, 2024 at 4:05 PM Kevin Fenzi wrote:
> So, if FESCo decided we wanted to enforce 2fa for provenpackagers or
> whatever, right now that would require some work on some scripting,
> which I guess would remove people without otp? But then there would
> still be a window when the user
On Fri, Apr 12, 2024 at 03:45:40PM -0400, Steve Cossette wrote:
> What about simply blocking access to the git repos/koji/bodhi for those
> without 2fa?
Well, git I suppose could be a hook that checks the status of the user,
but koji and bodhi don't really have any place to hook that in directly.
On Sat, Apr 13, 2024 at 8:44 AM Richard W.M. Jones wrote:
> I sometimes think how hard it would be to explain all of this to my
> mother. I don't understand why 2FA needs to be so obscure and clumsy
> to use.
FIDO2 (Apple branded[0] as "passkeys") is
not that hard to use, or explain. The
On 4/13/24 01:44, Richard W.M. Jones wrote:
On Fri, Apr 12, 2024 at 04:50:13PM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones said:
So the problem with github is they don't allow you to have 2FA on a
backup device (or rather, it *is* possible, but the process is
On Fri, Apr 12, 2024 at 04:50:13PM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones said:
> > So the problem with github is they don't allow you to have 2FA on a
> > backup device (or rather, it *is* possible, but the process is
> > ludicrous[1]). If you have your phone as second
Adam Williamson wrote:
> Also, these days, most authenticator apps support some kind of backup
> mechanism. FreeOTP lets you back up to a file (which you should, of
> course, keep somewhere safe and ideally encrypted). Google
> Authenticator can backup To The Cloud.
If you use Keysmith, you can
The idea is rather to scan the same QR twice, for two yubikeys, and then
screenshot it and save it securely in case you lose one yubikey and need to
load it into a new one.
On Fri, Apr 12, 2024 at 2:39 PM Richard W.M. Jones
wrote:
> On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson
Once upon a time, Richard W.M. Jones said:
> So the problem with github is they don't allow you to have 2FA on a
> backup device (or rather, it *is* possible, but the process is
> ludicrous[1]). If you have your phone as second FA and lose it then
> you have to immediately fall back to the piece
On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote:
> On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote:
> > I was hesitant to have MFA for a while. Imagine losing a phone with tons
> > of tokens. What a hassle to recover from that. I found it less than
> > ideal
What about simply blocking access to the git repos/koji/bodhi for those
without 2fa?
On Fri, Apr 12, 2024 at 12:05 PM Kevin Fenzi wrote:
> On Thu, Apr 11, 2024 at 05:49:27PM -0700, Adam Williamson wrote:
> > On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote:
> > >
> > > What is the best
On Fri, 2024-04-12 at 10:10 -0700, Carlos Rodriguez-Fernandez wrote:
> Yes that works too. By the time I was setting up MFA everywhere, and
> doing the code printing, I recall not all systems giving me that option,
Yeah, FreeOTP resisted doing backups for a long time on the basis that
it wasn't
Yes that works too. By the time I was setting up MFA everywhere, and
doing the code printing, I recall not all systems giving me that option,
and finding the paper thing not very good as recovery mechanism for me,
so I went with Yubikeys and my own backup-in-the-cloud mechanism. I was
just
On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote:
> On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote:
> > I was hesitant to have MFA for a while. Imagine losing a phone with tons
> > of tokens. What a hassle to recover from that. I found it less than
> > ideal
On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote:
> I was hesitant to have MFA for a while. Imagine losing a phone with tons
> of tokens. What a hassle to recover from that. I found it less than
> ideal for practical reasons.
This is one reason most systems provide a sheet of
On Thu, Apr 11, 2024 at 05:49:27PM -0700, Adam Williamson wrote:
> On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote:
> >
> > What is the best way to formally propose
> > that 2FA is required for packagers after
> > some date
>
> There is already a FESCo ticket.
I was hesitant to have MFA for a while. Imagine losing a phone with tons
of tokens. What a hassle to recover from that. I found it less than
ideal for practical reasons.
However, I decided instead to buy two Yubikey (primary and backup), and
I add the QRs to both of them with the Yubico App.
On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote:
>
> What is the best way to formally propose
> that 2FA is required for packagers after
> some date
There is already a FESCo ticket. https://pagure.io/fesco/issue/3186 /
Please don't discuss there, discuss here; FESCo will vote in that
On Mon, Apr 1, 2024 at 1:10 AM Kilian Hanich via devel
wrote:
> 2FA in a lot of cases is just access to a different account (e.g. email
> or even SMS) and these normally aren't unique. Sure, there are other
> ways like FIDO2, but these are not necessarily used (or liked, quite
> frankly I know a
Zbigniew Jędrzejewski-Szmek wrote:
> So… this is what I'm talking about: there is no obvious way to
> figure out what to set. Looking at the logs and trying to figure out
> some variables from that is not very attractive.
The comments at the top of the relevant Find*.cmake module are the best
On Mon, Apr 08, 2024 at 05:52:07AM -0400, Neal Gompa wrote:
> On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> > > I wrote:
> > > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew
On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> > I wrote:
> > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > >> Hmm, why? Oh, rpm uses cmake, and cmake has
On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> I wrote:
> > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > wrote:
> >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> >> detection of python, and it found /usr/bin/python3.13t
I wrote:
> On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> wrote:
>> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
>> detection of python, and it found /usr/bin/python3.13t that I have
>> installed, and subsequently it got all the paths wrong.
>
> That's why
That's why you should never build packages outside of mock.
Kevin Kofler
On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew
Jędrzejewski-Szmek wrote:
One particular issue I have with CMake as a downstream
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> One particular issue I have with CMake as a downstream maintainer is
> it's often very hard to override linking or compilation options
> or when the project is using one of the cmake find scripts that gets
> something
I wrote:
> That is exactly the problem with autotools code, almost nobody understands
> what the heck it does, almost everybody just copies and pastes somebody
> else's snippet hoping it does not do bad things. And gnulib is a
> particularly ugly piece of the puzzle.
PS: Here is a pretty good
On 2024-04-04 06:10, Zbigniew Jędrzejewski-Szmek wrote:
+1. I put the tool on my TODO list of things to look into.
When you get that time, I've also opened the following PR that includes
a proof-of-concept test
https://src.fedoraproject.org/rpms/openssh/pull-request/73
It's sloppy at the
Hello,
I have been deleting most of these emails, but I feel like this is a bit
myopic.
On Tuesday, April 2, 2024 6:25:56 PM EDT Kevin Kofler via devel wrote:
> Gary Buhrmaster wrote:
>
> > And, more importantly, the industry has agreed
> > to use the term supply chain. Is the term
> >
On Tue, Apr 02, 2024 at 04:32:24PM +0100, Richard W.M. Jones wrote:
> On Tue, Apr 02, 2024 at 12:45:18AM -0700, Gordon Messmer wrote:
> > On 2024-04-01 23:59, Gordon Messmer wrote:
> > >Now gdb can print the GOT with the paths providing the memory
> > >section containing a function. For example,
On Tue, Apr 02, 2024 at 08:59:32PM +0200, Kevin Kofler via devel wrote:
> Matthew Miller wrote:
> > I sometimes see unit test failures. The developer ran the tests, but not
> > on S390.
>
> Why would I want a test failure on such an exotic architecture to fail my
> build?
The architecture is
On Wed, Apr 03, 2024 at 07:48:03PM +0200, Kevin Kofler via devel wrote:
> Eric Blake wrote:
> > The upstream autoconf discussion says that 'autoreconf -fi' behavior
> > on which 'serial NN' .m4 files to update is determined by automake,
> > not autoconf, in part inspired by semantics desired in
Eric Blake wrote:
> The upstream autoconf discussion says that 'autoreconf -fi' behavior
> on which 'serial NN' .m4 files to update is determined by automake,
> not autoconf, in part inspired by semantics desired in gnulib. And
> the automake and gnulib developers have argued that the upstream
>
On Wed, Apr 03, 2024 at 07:27:12AM -0400, Stephen Gallagher wrote:
> On Tue, Apr 2, 2024 at 7:41 PM Kevin Fenzi wrote:
> >
> > On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> > > On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette wrote:
> > > >
> > > > I personally would very
On Wed, Apr 03, 2024 at 12:47:39AM +0200, Kevin Kofler via devel wrote:
> Richard W.M. Jones wrote:
> > Yes, in this case the attacker had set the serial number to 30, but
> > the latest upstream serial number was 3. autoreconf won't replace the
> > file in this case unless it is deleted. There
On Tue, Apr 2, 2024 at 7:41 PM Kevin Fenzi wrote:
>
> On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> > On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette wrote:
> > >
> > > I personally would very much agree with enforcing the use of 2fa on the
> > > Fedora Account System.
On Wednesday, 3 April 2024 01:34:00 CEST Gordon Messmer wrote:
> On 2024-03-30 11:52, Dmitry Belyavskiy wrote:
> > We have an upstream-adjusted version of this patch, see
> > https://bugzilla.mindrot.org/show_bug.cgi?id=2641
> > I'm OK to bring the updated version of this script to Fedora as soon
On 2024-04-01 23:59, Gordon Messmer wrote:
On 2024-03-30 13:18, Gordon Messmer wrote:
The write up describing the back door indicates that the malicious xz
library "changes the value of rsa_public_decr...@plt to point to
its own code." So the back door has pointed one of the symbols that
On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette wrote:
> >
> > I personally would very much agree with enforcing the use of 2fa on the
> > Fedora Account System. Maybe take that opportunity to make it a bit more
> > user
On 2024-03-30 11:52, Dmitry Belyavskiy wrote:
We have an upstream-adjusted version of this patch, see
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
I'm OK to bring the updated version of this script to Fedora as soon
as it is finalized.
I proposed
Richard W.M. Jones wrote:
> Yes, in this case the attacker had set the serial number to 30, but
> the latest upstream serial number was 3. autoreconf won't replace the
> file in this case unless it is deleted. There really should be an
> "always replace if you can" option in autoreconf.
Is that
Gary Buhrmaster wrote:
> And, more importantly, the industry has agreed
> to use the term supply chain. Is the term
> perhaps overloaded, or perhaps too
> ill-defined/imprecise? Sure. But if one wants
> to use a different term one would need to work
> across the industry to change the term, and
On Wed, 2024-04-03 at 00:15 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > It occurs to me - maybe you don't agree, but this is how it looks to me
> > - that, ironically, you and I usually argue the exact *opposite* side
> > of this case, no? I argue in *favor* of
Adam Williamson wrote:
> It occurs to me - maybe you don't agree, but this is how it looks to me
> - that, ironically, you and I usually argue the exact *opposite* side
> of this case, no? I argue in *favor* of somewhat-arbitrary delays to
> packages appearing in 'stable', and you argue *against*
Gordon Messmer wrote:
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.
This proves again that this is a very targeted attack that carefully
analyzed
On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette wrote:
>
> I personally would very much agree with enforcing the use of 2fa on the
> Fedora Account System. Maybe take that opportunity to make it a bit more user
> friendly? (Such as the fkinit prompt requiring the 2fa code being added at
> the
I personally would very much agree with enforcing the use of 2fa on the
Fedora Account System. Maybe take that opportunity to make it a bit more
user friendly? (Such as the fkinit prompt requiring the 2fa code being
added at the end of your password -- to be clear I think the 2fa code
should be
On 2024-04-02 03:42, Lennart Poettering wrote:
Also, I don't think we should get hung up too much on the libsystemd
thing. I know people like to hit on systemd,
I know, and one of the problems that results from having just a torrent
of undeserved criticism is that it naturally predisposes
Chris Adams wrote:
> However, it's a good trigger to review Fedora's security approach in
> general (like 2FA use).
Using such an issue that made it through upstream 2FA and would also have
made it through any 2FA enforcement in Fedora as an excuse to force 2FA on
us is just pure nonsense.
Matthew Miller wrote:
> I sometimes see unit test failures. The developer ran the tests, but not
> on S390.
Why would I want a test failure on such an exotic architecture to fail my
build? The only reason Fedora supports that architecture at all is pressure
from IBM. Basically nobody uses it.
* Kilian Hanich via devel:
> Am 02.04.24 um 10:22 schrieb Florian Weimer:
>>> - Can some wrappers be developed to make it both easier and safer?
>> GCC already provides function multi-versioning/target clones as a
>> higher-level interface.
>
>
> Also, upstreams should by default properly mark
On Sat, 2024-03-30 at 15:23 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
> > Once upon a time, Michael Catanzaro said:
> > > I agree that running autoreconf on our packages makes sense to start
> > > doing. Still, to avoid this
On Tue, Apr 02, 2024 at 12:45:18AM -0700, Gordon Messmer wrote:
> On 2024-04-01 23:59, Gordon Messmer wrote:
> >Now gdb can print the GOT with the paths providing the memory
> >section containing a function. For example, on a Debian 12 system
> >with liblzma 5.6:
>
>
> Purely as trivia, and as
On Tue, Apr 02, 2024 at 05:09:18PM +0200, Kilian Hanich via devel wrote:
> Am 02.04.24 um 10:22 schrieb Florian Weimer:
> >> - Can some wrappers be developed to make it both easier and safer?
> >GCC already provides function multi-versioning/target clones as a
> >higher-level interface.
>
>
>
Am 02.04.24 um 10:22 schrieb Florian Weimer:
- Can some wrappers be developed to make it both easier and safer?
GCC already provides function multi-versioning/target clones as a
higher-level interface.
Also, upstreams should by default properly mark their stuffs with
restrictive
Dne 30. 03. 24 v 18:26 Artem S. Tashkinov via devel napsal(a):
Hi,
It was sheer luck that the exploit was discovered and major distros haven't yet
included it in their stable releases. It's quite possible and plausible it
could have reached RHEL, Debian, Ubuntu, SLES and other distros and
Dne 30. 03. 24 v 22:14 Zbigniew Jędrzejewski-Szmek napsal(a):
On Sat, Mar 30, 2024 at 08:00:29PM +0100, Kevin Kofler via devel wrote:
Zbigniew Jędrzejewski-Szmek wrote:
I think there's some useful points here, but this would need to be
qualified and/or made more flexible to be applied.
For
* Lennart Poettering:
> On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org)
> wrote:
>
>> > In systemd git main, libsystemd is only linked to libc, libcap,
>> > and libgcrypt + libgpg-error. A pull request to convert that that last
>> > pair to dlopen is under review.
>>
On Sa, 30.03.24 13:18, Gordon Messmer (gordon.mess...@gmail.com) wrote:
> On 2024-03-30 02:37, Richard W.M. Jones wrote:
> > (3) We should have a "security path", like "critical path".
> >
> > sshd is linked to a lot of libraries:
>
>
> I really don't want to start a systemd thread, but... the
On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > In systemd git main, libsystemd is only linked to libc, libcap,
> > and libgcrypt + libgpg-error. A pull request to convert that that last
> > pair to dlopen is under review.
>
> That helps somewhat (it would
* Gordon Messmer:
> Why doesn't dlopen() solve the problem? As best I understand it,
> liblzma was able to steal one (or more) of the symbols from
> libcrypto.so.3 because it ran constructors at a point in time when the
> GOT was still writable. After loading shared objects is complete,
> that
On Tue, Apr 02, 2024 at 02:00:52AM -0700, Gordon Messmer wrote:
> On 2024-03-30 09:12, Neal Gompa wrote:
> > Note that dlopen() doesn't fix the problem of the giant libsystemd in
> > the first place. It just obfuscates the true dependency graph of
> > libsystemd.
>
>
> This isn't my area of
On Tue, Apr 02, 2024 at 10:59:10AM +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
> > In the xz case this wouldn't have been enough, it turns out we would
> > also have to delete m4/build-to-host.m4, which then autoreconf
> > regenerates. I don't fully understand why that is.
>
> I would
On Tue, Apr 2, 2024 at 4:59 AM Florian Weimer wrote:
>
> * Richard W. M. Jones:
>
> > I'm not pretending these will solve everything, but they should make
> > attacks a little harder in future.
> >
> >
> > (1) We should routinely delete autoconf-generated cruft from upstream
> > projects and
On 2024-03-30 09:12, Neal Gompa wrote:
Note that dlopen() doesn't fix the problem of the giant libsystemd in
the first place. It just obfuscates the true dependency graph of
libsystemd.
This isn't my area of expertise, but I am curious:
Why doesn't dlopen() solve the problem? As best I
* Richard W. M. Jones:
> I'm not pretending these will solve everything, but they should make
> attacks a little harder in future.
>
>
> (1) We should routinely delete autoconf-generated cruft from upstream
> projects and regenerate it in %prep. It is easier to study the real
> source rather
On 4/1/24 14:46, Neal Gompa wrote:
On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
wrote:
On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:
On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
Adam,
Is there a way already to achieve test isolation
On Tuesday, 2 April 2024 09:52:38 CEST Richard W.M. Jones wrote:
> On Tue, Apr 02, 2024 at 07:40:33AM +0200, Andreas Schneider wrote:
> > On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote:
> > > These are just my thoughts on a Saturday morning. Feedback welcome of
> > > course.
>
* Richard W. M. Jones:
> That said, ifunc is a very complicated, fragile but powerful mechanism
> and I'd like to know from the glibc developers what we should
> look out for. For example:
>
> - Is it ever valid for ifunc to take control of functions in another
>library? Can this be
On Tue, Apr 02, 2024 at 07:40:33AM +0200, Andreas Schneider wrote:
> On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote:
> > These are just my thoughts on a Saturday morning. Feedback welcome of
> > course.
>
> I find the use of the ifunc attribute is really uncommon at this
On 2024-04-01 23:59, Gordon Messmer wrote:
Now gdb can print the GOT with the paths providing the memory section
containing a function. For example, on a Debian 12 system with
liblzma 5.6:
Purely as trivia, and as I haven't seen it discussed elsewhere, the
malware steals a different set
On 2024-03-30 13:18, Gordon Messmer wrote:
The write up describing the back door indicates that the malicious xz
library "changes the value of rsa_public_decr...@plt to point to
its own code." So the back door has pointed one of the symbols that
should point to a page mapped to
On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote:
> These are just my thoughts on a Saturday morning. Feedback welcome of
> course.
I find the use of the ifunc attribute is really uncommon at this place. I
would expect it in ffmpeg or some media codecs. In xz it looks like it
Matthew Miller,
Unit tests, even though in theory developer should mock dependencies to
isolate their code to the maximum, in reality, it is not that clear cut.
Therefore, those unit tests do serve to some extent as a validation that
their code works with the system libraries and platforms
Chris,
The specific points of entry were evading the strength of open source:
many skilled eyes. Therefore, there is value in programmatically
enforcing that everything used as an input in a build must have been
exposed to *normal opensource workflows*. It is a very simple principle,
yet very
Once upon a time, Gabriel Somlo said:
> IMHO, there's no good way to *programmatically* protect ourselves
> from a malicious upstream on which we depend. If their goal is to
> compromise us, they will work around whatever programmatic/technical
> measures we happen to have in place at the time
> On Mon, Apr 1, 2024 at 17:11:46 -0400, Matthew Miller via devel wrote:
> On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:
> > Unit tests are something for upstream developers. They should NEVER be run
> > in a distribution build.
>
> Even in the few little packages I'm
On Mon, 2024-04-01 at 23:37 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > > * Deleting ALL files automatically generated or imported by autotools in
> > > %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it
> > > would NOT have done the right thing here. Delete
Adam Williamson wrote:
>> * Deleting ALL files automatically generated or imported by autotools in
>> %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it
>> would NOT have done the right thing here. Delete the files, THEN run
>> autoreconf.)
>
> No. This would not have avoided
On Mon, Apr 01, 2024 at 01:36:48PM -0400, Peter Jones wrote:
> Unrelated to the idea that some packages are special in this way, it's
> probably worth writing some static analysis tools we could put into
> rpm-inspect to detect when (a) a binary grows new public keys it didn't
> have before, and
On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:
> Unit tests are something for upstream developers. They should NEVER be run
> in a distribution build.
Even in the few little packages I'm still responsible for, I sometimes see
unit test failures. The developer ran the
> (3) We should have a "security path", like "critical path".
>
> sshd is linked to a lot of libraries:
>
> /lib64/libaudit.so.1audit-libs
> /lib64/libc.so.6glibc
> /lib64/libcap-ng.so.0 libcap-ng
> /lib64/libcap.so.2 libcap
> /lib64/libcom_err.so.2
On Mon, Apr 1, 2024 at 4:42 PM Adam Williamson
wrote:
> I think we *are* part of a supply chain, regardless of any handwaving
> about The Open Source Model.
And, more importantly, the industry has agreed
to use the term supply chain. Is the term
perhaps overloaded, or perhaps too
Understood. However, at least for those unit tests run in the %check, it
is going to be almost unfeasible, because of the variability of the way
things are done in the different programming ecosystems. In Java, unit
tests are nicely separated in a different folder (i.e., `src/test`), but
in
On Mon, 2024-04-01 at 12:27 -0400, Neal Gompa wrote:
> >
> > ii) the fact that this attack reinforces the painful truth that
> > sophisticated attackers *are* extremely interested in attacking the
> > supply chain of which we form a significant component
>
> Can we please reframe it for what it
On Mon, 2024-04-01 at 05:58 -0700, Carlos Rodriguez-Fernandez wrote:
> Test isolation is still assuming the attack comes in the test phase.
As I initially suggested it, it does not. My suggestion was that we
ensure the test code is not available to the prep / build / install
phases *at all*, and
On Mon, Apr 1, 2024 at 12:22 PM Adam Williamson
wrote:
>
> On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> > > Adam Williamson wrote:
> > > > Maybe this needs to go on the growing pile of reasons
On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> > Adam Williamson wrote:
> > > Maybe this needs to go on the growing pile of reasons why the
> > > traditional Linux model *does* need to go away. Maybe
On Mon, Apr 01, 2024 at 02:23:19PM -, François Rigault wrote:
> > Those blobs were not in systemd,
>
> that was not my point, nevertheless putting it this way: nobody knows.
>
> For the example about compression methods you could generate your binary
> using a piece of code, that can be
Dne 01. 04. 24 v 3:16 dop. Kilian Hanich via devel napsal(a):
Also, I have seen build setups which encode the status of tests in the
eventual binary and as such info page or integrated bug report
generators. Often because some distros sometimes turned them off or
ships software even with failed
Definitely this attack leveraged places where eyes don't look:
distributed tar.gz and blobs.
I put the PoC to flag those two in github[1]
Example output:
$ ./rpmseclint tests/rpmseclint-test.spec
-Diff-
~ test.txt
+ additional.txt
+ blob.txt.gz
-Blobs
application/gzip
I created a discussion issue for this idea:
https://github.com/rpm-software-management/rpm/discussions/3009
I think it worth pursuing further.
On 4/1/24 04:46, Neal Gompa wrote:
On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
wrote:
On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam
> Those blobs were not in systemd,
that was not my point, nevertheless putting it this way: nobody knows.
For the example about compression methods you could generate your binary using
a piece of code, that can be reviewed (maybe using a fixed seed as inspired by
Test isolation is still assuming the attack comes in the test phase. The
attack can come in the `make`, or in the `make install` too. That's why
the idea of other techniques being discussed are still valid, but
perhaps not abstracted out enough for a wider defense.
However, the test
Christoph Erhardt writes:
I strongly oppose this suggestion. While it would have prevented this
particular backdoor as a side-effect, the primary effect of going without
unit
tests would be an outsize hole in Fedora's QA.
There have been several suggestions here for ways that this specific
On Mon, 1 Apr 2024 at 04:47, François Rigault
wrote:
> To echo
>
> > To trust code, it needs to be reviewed.
> > If the code is reviewed, and the build system is sane, [..]
>
> I deduce from your response that the binary tests committed in systemd
> were not reviewed neither by co-maintainers
On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:
> > On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
> > > Adam,
> > >
> > > Is there a way already to achieve test isolation during the rpm
1 - 100 of 208 matches
Mail list logo
