[removed openwrt-adm@ from the Cc: loop]
Petr Štetiar [2024-04-01 14:49:46]:
> Perhaps this package source code integrity checks should be mandatory, not
> optional?
BTW I looked into this a bit and these are likely breakages caused by the
recent APK releated changes:
$ curl -s
On 03/04/2024 2:11 am, Daniel Golle wrote:
... and that crazy m4 script had to be noticed. As a diff one would ask:
Why was that change necessary?
While I agree with most of your points, I couldn't disagree more with
the "had to be noticed" part :P
I occasionally skim over treewide diffs.
Daniel Golle [2024-04-03 01:11:41]:
Hi,
> > In this case, they were targeting specific audience and this attack vector
> > was
> > cheapest/fastest, so the source code origin doesn't really matter.
>
> I tend to slightly disagree, because an attacker will always chose
> what ever means are
On Mon, Apr 01, 2024 at 02:49:46PM +0200, Petr Štetiar wrote:
> Daniel Golle [2024-03-30 15:30:49]:
>
> Hi,
>
> > In many ways, we are already better
>
> I would probably avoid such bold statements and would be more humble, since
> you never know why OpenWrt wasn't directly targeted.
We are
Daniel Golle [2024-03-30 15:30:49]:
Hi,
> In many ways, we are already better
I would probably avoid such bold statements and would be more humble, since
you never know why OpenWrt wasn't directly targeted.
> I believe that the current tendency to use tarballs rather than
> (reproducible!)
> Le 31 mars 2024 à 19:06, Thibaut a écrit :
>> Le 31 mars 2024 à 18:46, Daniel Golle a écrit :
>>
>> I've seen that, and by itself it does not present a security risk in
>> the context libarchive is intended to be used.
BTW in case that isn’t obvious, the deadliest exploits typically
> Le 31 mars 2024 à 18:46, Daniel Golle a écrit :
>
> On Sun, Mar 31, 2024 at 12:05:03PM +0200, Thibaut wrote:
>>
>>> Le 31 mars 2024 à 01:07, Elliott Mitchell a écrit :
>>>
Normally upstream publishes release tarballs that are different than the
automatically generated ones in
On Sun, Mar 31, 2024 at 12:05:03PM +0200, Thibaut wrote:
>
> > Le 31 mars 2024 à 01:07, Elliott Mitchell a écrit :
> >
> >> Normally upstream publishes release tarballs that are different than the
> >> automatically generated ones in GitHub. In these modified tarballs, a
> >> malicious version
> Le 31 mars 2024 à 01:07, Elliott Mitchell a écrit :
>
>> Normally upstream publishes release tarballs that are different than the
>> automatically generated ones in GitHub. In these modified tarballs, a
>> malicious version of build-to-host.m4 is included to execute a script
>> during the
Hi,
ne 31. 3. 2024 v 1:07 odesílatel Elliott Mitchell napsal:
> On Sat, Mar 30, 2024 at 10:54:00PM +0100, Oldřich Jedlička wrote:
> >
> > so 30. 3. 2024 v 16:31 odesílatel Daniel Golle
> > napsal:
> > > Hiding a malicious change in a commit is infinitely harder than hiding
> > > it in a
On 31.03.24 01:07, Elliott Mitchell wrote:
On Sat, Mar 30, 2024 at 03:30:49PM +, Daniel Golle wrote:
unchanged. Git has a lot of security built-in, and by using tarballs
as a base for our package builds we are basically throwing all that
away, for the sake of saving a negligible amount of
Reordering since I want to respond to different bits in a different
order...
On Sat, Mar 30, 2024 at 03:30:49PM +, Daniel Golle wrote:
>
> Hiding a malicious change in a commit is infinitely harder than hiding
> it in a tarball.
Yet most of the exploit/payload found so far was in commits,
Hi,
so 30. 3. 2024 v 16:31 odesílatel Daniel Golle napsal:
> Hiding a malicious change in a commit is infinitely harder than hiding
> it in a tarball.
Just a note: The malicious code was part of the tarball because it was
part of the main Git repository in the first place. Using Git would
not
Hi everyone!
you may all have heard and read about CVE-2024-3094. If not, please do
so now [1], [2].
This incident has exposed many long standing issues and should not be
seen as a singular event, but rather as the result of several
unhealthy patterns. And while OpenWrt was not affected by the
14 matches
Mail list logo
